– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<emilio> scribenick emilio

<astearns> we are finding that the Apple desks do not allow Apple power adapters to plug in to them

<noamr> There was the `@sheet` proposal on the morning agenda (w3c/csswg-drafts#11509), Simon didn't express specific interest in it. Should we use some of the early session to discuss that perhaps if we're out of working mode topics?

@sheet

<kschmi> https://docs.google.com/presentation/d/1zE9NgFltry9Qor6ajT695wZiN74zEpydtc1oEbzlhOw/edit#slide=id.p

<emilio> github-bot: take up w3c/csswg-drafts#11509

Proposal: CSS @sheet

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11509.

Slideset: https://docs.google.com/presentation/d/1zE9NgFltry9Qor6ajT695wZiN74zEpydtc1oEbzlhOw/edit#slide=id.p and archived PDF copy

<emilio> kschmi: justin proposed this in 2020

<emilio> ... great discussion in 2023 where there was a resolution to add it to css-cascade

<emilio> ... and we have some suggestions to expand it

<emilio> ... so I want to touch on those

<emilio> ... quick recap

<astearns> new explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtSheet/explainer.md

<emilio> ... main initial goal is bundling

<emilio> ... non-obvious is that this is not obvious but this helps compression rations

<emilio> ... if you can combine more things into one file dictionaries you get more hit

<emilio> ... some testing gives 0.4% compression improvements, so not massive but not nothing

<emilio> ... the important thing I want to go through is that there's a solution for sharing inline styles with declarative shadow DOM

<emilio> ... core concept was resolved in 2023

<emilio> ... where we allowed to reference fragments

<emilio> ... not yet in the cascade spec

<emilio> ... so that was the original proposal

<emilio> ... so you have an `@sheet` block with an identifier and you can import them with a constructable stylesheet

<emilio> ... so that's kinda the bundling scenario. The CSS bits are a pre-requisite

<emilio> ... but we can't get the JS part until CSS adds the syntax

<emilio> ... so `<link rel=foo.css#fragment>` and also `@import`

<emilio> ... so it can cache the file and only make one request

<emilio> ... hasn't been spec'd yet, but I think that's worth doing independently

<emilio> ... but the extension is why doesn't this work for same-page URL

<emilio> ... so plain fragments would work on inline styles

emilio: 2 things that come to mind

emilio: 1. Why is this CSS-specific, in the sense that other resources ... including fragments and stuff

emilio: This introduces quite a divergence in how we interpret URLs

emilio: What you're proposing feels a bit weird because a plain fragment URL usually references the same document

emilio: I guess we do have some precedent for some fragment-only URLs being a bit special

emilio: One thing I'm concerned about, how does this behave-- if a browser doesn't implement it, the browser pulls the whole stylesheet and ignores it

emilio: it would import nested stylesheets

emilio: feels like a more explicit mechanism here would be nice, but maybe we can live with this?

emilio: I'm a bit worried about feature detection and fallbacks

<miriam> We allow `supports()` in imports

noamr: When i see the # i expect it to be an id
… mixes html and css too much
… would prefer so,meting that has a sheet attr on link
… and other modifier to import, we have one for layer
… in general would be careful to use hasehs for sth that is not dom id
… confuses things

kurt: fragment already acceptd in prior discussion
… mgiht need to be revisited
… if fragment does work, much like acnhors you dont need a URL it means local
… this is building on that
… there’s a precedent: if there is no file assume it is in the same doc
… only thing doing that is anchors, which is excepction to a lot of things
… if we do revisit fragment for this scenario, then we need to revisit for this
… other syntax or attr … would feel inconsistsent to not do this

noamr: wnated to say that it is different
… fragmetns and svg clip path and shapes – there are precedents but they refer to the dom id
… no prob with multidoc

dbaron: from a URL design perspective the meaning of a fragment is generally specific to the mime-type of th resource

<fantasai> +1 dbaron

dbaron: the idea that in a css file to refer to an @sheet can be sensible

<justinf> +1 as well

dbaron: and in an HTML file they already refer to IDs and we should be very careful about changing that
… I could imagine with an @sheet inside a style element, and then use the id of the style element

<justinf> fragments without a preceding URL refer to something in the HTML document already

dbaron: one of the design principles here is the meaning of fragment in a URL is specificy to the mime-type

kurt: makes sense
… we do have a .css file in this example
… but there is HTML and there is a mismatch witht he mimetype
… great point

<noamr> +1, exactly, I have no problem with it inside CSS files

matthieud: answer for emilio about old browser
… that dnt udnerstand @sheet
… how to resolve the rules inteh block

<emilio> ... So re. what happens for all browsers, are we going to lose all the rules

matthieud: same solution with @layer can be applied

<emilio> ... but we could make like @layer where anything after is considered part of it

<emilio> ... so this looks a lot about @layer

<emilio> ... just with no notion of priority\

<fantasai> emilio: Concern is not only with what's in the block

emilio: concern is not only what happens with contents of the blocks but older browser dont have concept of importing parts of a stylesheet
… external parts would apply

matthieud: doesnt work for @import

emilio: but doesnt work for link either

<astearns> acj justinf

<emilio> justinf: Wanna comment on the fragment thing

<matthieud> I would have like an answer about the @layer vs @sheet though ?

<emilio> ... has been touched that the impolicit URL is the HTML document url

<emilio> ... being able to do about dom vs. stylesheet

<emilio> ... on the DSD case there could be multiple sheets

<emilio> ... and in order to do this we have to have a central resource

<emilio> ... and I'd be a bit wary of this

<emilio> ... there's also a question of external stylesheets with nested @sheets

<emilio> ... it's something I'd want to avoid, we're trying to avoid global resources like custom element names or what not

<emilio> ... so I wouldn't add another one

<emilio> florian: narrowly on this specific slide, as long as @sheet is something that exists I agree it'd be nice to use it on inline style elements

<noamr> For the `#` - it can be `#:~:sheet=the-sheet-name` like text fragments

<emilio> ... slightly more generally I think this is quite complex and we need to move into the discussion of what this does for shadow dom

<emilio> ... yeah it's convenient to have one file with preprocessing

<emilio> ... http/2 deals with some of the multiple request complexity

<justinf> for shadow DOM basic bundling is sufficient, IMO

<emilio> ... so outside of shadow dom I don't see a lot of use for this

emilio: agree with florian that main use case feels … basically about shadow dom. if you have no, you can bundle and call it a day
… want to try a counter proposal tha tmight work
… and doesnt need to add anything new
… except 1 thing
… what you really want is @import but without separate request to import into shadow dom
… talked about removing constructbile stylesheet restircition in adoptable ones
… if you have data-uri @import that you could import into SD you kinda get this behavior
… not user friendly, but if use case is bundlers then they can prolly manage
… idea would be to get the @import stylesheet and shadowroot.adopted.push(…)
… and if you dont want that to aply to the doc, you could isable with a non-mathcing media in the elem
… we have a lot of similar pieces that would be nice
… if use cases are narrow, e.g shadow dom and bundling
… then you might be able to get away with this
… has that been explored?

<justinf> isn't that unwinding the whole proposal, including the previous resolutions?

<emilio> yes

<justinf> `@sheet` seems a lot simpler than data URI and changes to import to me

<emilio> castastrophe: just a question, trying to picture things in the design systems space

<emilio> ... how would you import multiple sheets, multiple `<link>` or `@import`?

<emilio> kschmi: yeah you'd need multiple sheets or @import or both

<emilio> justinf: Responding to emilio or florian... The basic @sheet to me is very simple

<emilio> ... there's no way currently to include an inert chunk of CSS

<emilio> ... turns out you can with @supports

<emilio> ... but @import + data uri + ... feels a lot more complex than @sheet

<emilio> ... The additional complexity is adding ways to reference these from inline styles

<emilio> ... I don't think that complexity applies to that part of the proposal

<emilio> FWIW `@import url("data...") not all;` doesn't seem /terribly/ complex to me

<emilio> kschmi: so re. shadow dom

<justinf> but then you need that `@import()` to 1) be inert, and 2) be importable as a separate sheet

<emilio> ... current mechanism are duplicate `<link rel>` or inline styles or script-based adoptedStyleSheets

<emilio> ... so for declarative shadow DOM is not great

<emilio> ... If we support the standalone fragment we can support it for declarative shadow dom

<emilio> ... that's kinda why this is relevant to DSD

<emilio> ... solves that messy problem r/n

<emilio> ... big question justinf is concerned about is scoping

<emilio> ... which is an issue, might be the same as inheriting from parent

<emilio> ... lots of open issues, we have an explainer in MSEdgeExplainers

<emilio> ... big list of open issues, but key problem we're solving is inline styles with declarative shadow dom

<emilio> ... another solution for this would be declarative CSS modules

<emilio> ... `<script type=css-module>` and `adoptedstylesheets=""`

<emilio> ... TAG pointed to `@sheet`

<emilio> ... seems this still has more issues

<emilio> ... If we could get this standalone fragment thing would be nice

<emilio> ... both seem good proposals, but I think there's a big demand to solve this

<emilio> ... so there's shared goals, but they can solve the same problem

<emilio> ... curious to see what the WG and developers prefer

<emilio> ... that was more or less it

<justinf> noam +1

<emilio> noamr: When I see this whole thing I see it like an HTML problem and not a CSS problem

<emilio> ... You can fix this with shadow DOM if you have a fragment refer to an ID of a <style> or <link> element in your document

<emilio> ... it seems also a problem with script importing

<emilio> ... maybe we can present this at WHATNOT

<fantasai> +1 noamr

<emilio> ... But I wonder if there are commonalities to importing style and script

<emilio> ... and there are solutions that could require less work

<emilio> kschmi: Yeah if there was a way like svg fragment you're right we wouldn't need @sheet for this

<justinf> the only issue with IDs with DSD is that we need a *global* ID to cross shadow root boundaries. But that's a DOM issue

<emilio> ... We could have an attribute

<emilio> noamr: you'd add a link pointing to the ID

<emilio> justinf: re. the scoping, one of the reasons I was shaking my head with scoping

<emilio> ... we want to render instances, in a way that the root needs to hold the stylesheet of component a, but you don't want to emit them until you've found the first

<emilio> ... so I think we need some sort of global resource

<emilio> ... but I'd be very careful about choosing what global resource

<noamr> for bundling, you can have an external HTML file that has multiple <style> elements with IDs and you refer to them

<emilio> ... but I agree with noamr that this is kind of an HTML issue, because IDs don't propagate across shadow boundaries

emilio: wanted to ask whether other subresources have same nees
… but tha t is what noam ended up asking

<astearns> ac castastrophe

<emilio> castastrophe: had a question about @sheet, the syntax makes me think that if I wanted to override a sheet namespace I would be able to

<emilio> ... with the fragment syntax it makes me feel like you can't

<emilio> ... if I declare another ID in the DOM it doesn't override the first

<emilio> ... what is the behavior here?

<emilio> kschmi: That's one of the open questions

<emilio> ... @layer would add to it

<emilio> florian: I find the shadow dom use case very compelling

<emilio> ... more compelling than the other use cases

<emilio> ... if we agree to solve it with @sheet it motivates solving some of the `@sheet`s

<emilio> ... issues

<emilio> ... the way @sheet is imported seems problematic

<emilio> ... browsers doing different things for `url(#foo)` seems like a problem

<emilio> ... the overriding is question is a challenge as well

<emilio> ... the shadow dom use case seems the most compelling, the other ones seem nice

<emilio> ... if we decide to solve the shadow dom use case some other way, not sure we want `@sheet`

<justinf> this difference in behavior with legacy browser is always the case... I'm personally hoping that @sheet support can coincide with CSS imports support in Webkit and Gecko so that if you can import a stylehsheet you can also import an `@sheet`

<emilio> kschmi: Great points, I think the original proposal was about importing / bundling

<noamr> justinf: I think hash-fragments, e.g. in same-document links, cross shadow boundaries?

<emilio> justinf: this is an addon to JS import asserts in CSS modules

<emilio> ... you have a lot of JS modules which depend on small fragments on CSS

<emilio> ... but bundlers don't know how to deal with bundling CSS there

<emilio> ... that was my main motivation, you end up with lots of small CSS files otherwise

<emilio> ... was kinda hoping that if @sheet is simple enough it'd ship along CSS imports in webkit / gecko

<emilio> ... happens to be a simple polyfill for transforming to @import

<justinf> transforming to @supports, not @import

<emilio> castastrophe: I see where you're coming from florian

<emilio> ... if we solve it for webcomponents my preference would be to solve it for native DOM solutions as well

Big +1

<emilio> ... I'm doing so much transforming of code between the two systems, so it'd be nice to allow authors to just write it once

<justinf> btw, CSS imports is mainly a feature that makes CSS more usable from JS defined components... it doesn't need to be web components or shadow DOM

<emilio> miriam: high level syntax thought, there was some mention of syntax looking similar to @layer, but funcitonality is entirely different

<emilio> ... I think it overlaps more with @scope

<noamr> +1

<emilio> kschmi: Yeah the way I think about @sheet is a separate file

<matthieud> actually yes I agree, @scope is closer to this than @layer

<emilio> ... @layer is a different cascade layer, and that's why you can have multiple layers and so on

<emilio> ... @sheet is only one definition per sheet, that kinda helps my mental model a bit

<emilio> matthieud: I agree that @scope is closer than @layer

<emilio> justinf: Wanted to comment, I wanted to make sure that this is not always associated with shadow dom and webcomponents

<emilio> ... having a way to import this seems useful for non-shadow-dom related use cases as well

<emilio> ... so I'm hoping this would be much broader

(FWIW: I believe @layer was only mentioned in relation to what browsers do when they don’t support it: they discard the entire block.)

emilio: want to suggest that if we are doing this we could bypass a lot of the fragment issues if we allow importing using a different syntax

<emilio> @import sheet(name)

emilio: that bypasses a lot of the questions about what the fragment means

<castastrophe> or both? @import url() sheet()

<florian> +1

justinf: still seems to have the global namespace

<weinig> (not sure if this has been mentioned, or how relevant it is, but there is a some written thoughts on fragments here

emilio: that’s kinda ???

<emilio> castastrophe: +1 to emilio, you could combine it with url and specify different sheets from that URL

emilio: that wouldn have global namespace issues
… because you arkimporting this sheet from that url

justinf: depends on … declarative dom use case (missed)

emilio: guess you could with no URL you import the document or some smaller thing
… if you ignore the improt and inline style hting, it still works for declarative shadow dom

<noamr> Perhaps "importing from inline" and "partially importing from a sheet" don't require the same solution?

emilio: do `@import url() sheet()`

justinf: if you can do that, solves 99% of ht eproblems
… if you can bundle all, you can do ahead of time and import later

kurt: challenge with file specific syntax is what justin was saying – need to support same doc styles
… you want a high per site to paint auickly with styles
… best option is not an external file
… that is feedback i got from devs
… "sure separte file is nice, but inline in html is powerful for first paint"

<emilio> `<style>@import url(..) sheet(..)</style>`

noamr: seems like different problem?

<emilio> justinf: wanted to clarify on `<stlye>`. In a server component case you don't have all the components, they depend on the page

<emilio> ... something like an amazon product page is a canonical example

<emilio> ... could render millions of components

<emilio> ... I don't think any external file solution deals with that

emilio: they are not exclusive
… as noam was saying, having a specific syntax to import sheets and being able to import from an inline style seem like differnet

justinf: agree
… would love to see capabitliy in html

emilio: ok
… then we are in agreement

florian: you emilio are proposing to solve with css syntax, not html

emilio: i was proposing to have specific syntax for importing style sheet from a file
… tha tdoes not avoid adding that fro m???

florian: if you have @import url() sheet() it imports tehs eet fro,m the url
… if you omit the url, its from the current file
… if the curernt file is the html, then that is where you try and go find it

emilio: or you could impor from url(#something) to refer to that style or link

florian: the syntax you proposed not only is useful but fully replaces need for link rel=stylesheet and makes it not an html problem

emilio: still need to define how to target a partciular element

<noamr> import url("#my-inline-style") sheet(my-sheet)

castastrophe: if you are inside sd with import, do you have timport @import from sd or from parent?
… does not exist right now

noamr: url fragment are not ???

astearns: should prolly close this for now

<emilio> noamr: URL fragments do cross shadow boundaries, like `<a href="#foo">` doesn't look only inside its shadow tree

astearns: was mentionedthat this should be presented at whatnot
… kurt, can you do that?

kurt: yes

astearns: and then we ahve issue of @sheet not being a spec
… would you kurt be intereste to be an editor for that?

kschmi: yes

astearns: So I proposed to add kschmi as editor for css-cascade-7 to spec that
… start with what we have not, and then extend to shadow dom and othe ruse cases and bring back to the group

kschmi: sgtm

TabAtkins: the number?

astearns: taking that from fantasai that @scope is prolly done and to take 6 to CR

TabAtkins: if 6 is ready for cr and 5 is in cr, then merge scope into 5
… dont like many numbers, especially when its only 1 feature per number

fantasai: we should get 4 in rec bc layers are shipping and 6 should move to cr and merge down contents of 5 into 6

PROPOSED RESOLUTION: Add kurt as editor of css-cascade and work with current editors to figure out the number

florian: IUC we resolved on adding @sheet syntax itself, but not on the importing part
… regardless we have had enough debate about that that we should add an inline issue in the spec
… that its a moving target

astearns: editor’s discretion

RESOLUTION: Add kurt as editor of css-cascade

astearns: let’s move on to shape issues

<justinf> thank you everyone!

Shapes

<argyle> squircle!!

<emilio> github-bot: take up w3c/csswg-drafts#10993

[css-shapes-2][css-borders-4] corner-shape support for superellipsis

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10993.

<emilio> smfr: there's a proposal to add a squircle function / different types of corner treatments

<emilio> ... there's also bevels / etc

<emilio> ... but more recently there's been a proposal of `superellipse` function

<emilio> ... which would allow those and also things in between

<emilio> ... including squircle

<emilio> ... wanted to give some background and some reservations I have about it

<emilio> ... this demo is using border-radius

<emilio> ... this is existing border-radius

<noamr> https://noamr.github.io/squircle-testbed/

<emilio> ... the "Apple rounded rect" is also a regular bezier point but with more control points

<emilio> ... There's some tricky cases with overlapping corners

<emilio> ... superellipse is this function that for a k=0 gets you bevel, with different ks you can get different joins

<emilio> ... with different ks you can get something like the squircle

<emilio> ... but now you got multiple parameters to change

<emilio> ... border-radius and the k

<emilio> ... it's not clear for authors which combination they'd choose

<emilio> ... The other thing is that it's generated iteratively

<emilio> ... not using bezier curves, so not very efficient to render unless you approximate it using bezier curves

<emilio> noamr: The proposal was also to add a squircle keyboard

<emilio> ... agreed with the perf concern

<emilio> ... specially stroking, filing should be fine with shaders

<emilio> ... for that reason I'm more inclined towards the apple-style continuous rect rather than superellipse

<emilio> ... on the other side I'd like more expresiveness for authors if we can solve the efficiency problem

<emilio> TabAtkins: in your later comments you said that to do a squircle you'd need both k and border-radius

<emilio> ... how does that work with just a squircle corner shape

<emilio> ... presumably the flat segment is specified by border radius

<emilio> smfr: yeah we apply the squircle only to the rounded corner area

<emilio> TabAtkins: ok so this is a different curve than superellipse

<emilio> TabAtkins: so in your preferred solution you have a small border radius with a separate knob

<emilio> smfr: right

<emilio> TabAtkins: so this seems to be two parameters as well right?

<emilio> smfr: Only one parameter, which is border-radius

<emilio> TabAtkins: is it just because the squircle is a fixed pos?

<emilio> smfr: pretty much

<emilio> TabAtkins: it seems for fserb's proposal the squircle thing would just be a fixed k=4 right? So seems similar?

<emilio> ... so if you're using the fixed squircle shape you have only one free parameter

<emilio> ... the computational issues are a thing, but the parameterization seems fine to me?

<emilio> smfr: depends on how we want to expose this to CSS

<emilio> ... so adding squircle / bevel with keywords or something more flexible

<emilio> TabAtkins: I think fserb's proposal was to add keywords that computed to the superellipse parameters

<emilio> ... but I don't understand the calculus of the different params here

<emilio> ... so that might trump it

<emilio> weinig: Is there any standardization in the design community outside apple / google that we could use here?

<emilio> smfr: I think there's a figma thing where they were looking at the apple one, but depends on which camp we're on

<emilio> weinig: Is there a built-in superellipse in illustrator or something?

<emilio> smfr: not sure illustrator but figma and so do

<emilio> ... there's also the question of what authors want, just apple/google squircle or something else

<emilio> weinig: I don't think we want to hardcode the apple one, it could change in the future or what not

<emilio> smfr: I agree we don't want a single keyword that just gives you exactly the apple one

<emilio> ... we're fine with authors having to tweak border-radius or what not

<emilio> smfr: For IP reasons we don't want a single keyword that gives you the apple shape, but we're fine giving the corner treatment

<emilio> weinig: that makes sense, was trying to see what the non-app-icon use from authors would be generally useful

<emilio> smfr: And agree on let's not lock in on the current rounded icon format

<emilio> florian: what I like about fserb's proposal is that it gives keywords for things authors really want, and an underlying system

<emilio> ... to explore other bits

<emilio> ... not in a position to talk about performance, but I hope it can be fixed

<emilio> ... there are more knobs that your demo doesn't show (like each corner separately, or each side of each corner…)

<emilio> schenney: wanted to point out that animation is not being discussed yet, but an animation would lean towards a functional notation

<emilio> smfr: agree, I think it's going to be possible to approximate superellipses with beziers

<emilio> ... I think it's tractable. Certainly more convenient with the k param

<emilio> noamr: From the perspective of how to bring this to the masses, I'd suggest to start with the continuous one and then build on top

<emilio> ... then try to figure out approximation of superellipse or what not

<emilio> ... thoughts?

<emilio> smfr: I agree we could do keywords first

<emilio> ... we'd have to think about animations

<emilio> ... maybe just discrete for now

<emilio> kizu: +1 to florian

<kizu> w3c/csswg-drafts#6980

<emilio> ... both the superellipsis and a set of keywords

<weinig> (likely the blog post from Figma smfr mentioned )

<emilio> ... issue above has lots of comments about that

<emilio> ... so yeah would be good to have the functional version to create something more interesting

<emilio> TabAtkins: if the idea is that a superellipse does get decent results but is computationally intractable

<emilio> ... can we allow a degree of approximation in the spec so that you're allowed to approximate

<emilio> ... I think that is not very controversial

<emilio> ... so if beziers are tractable then we can just allow that

<emilio> smfr: I think that's fine, I just haven't done the math to approximate the conversion yet

<emilio> weinig: at the lower level most graphics libs are already doing approximations of these things

<emilio> ... I think there's unlikely to be a sever penalty

<emilio> TabAtkins: anything more rounded than a bevel needs an extra check for overlapping curves

<emilio> smfr: Right, we already have some constraints on rounded rects

<emilio> TabAtkins: right, but the border-radius overlap is trivial

<emilio> smfr: Yeah for the simple case we can probably check the rects

<emilio> ... maybe too restrictive

<emilio> smfr: [draws something]

<emilio> smfr: people want to do [that]

<Zakim> florian, you wanted to ask how bad is the performance problem

<TabAtkins> example is: border-radius of 0 100% 0 100%

<emilio> florian: unfortunate that fserb isn't here

<emilio> ... curious, were you talking about approximating any k with bezier?

<emilio> ... or just some k values?

<emilio> ... if the former that's great

<emilio> ... I think for superellipse() fserb had a reasonable implementation

<emilio> smfr: Haven't tried generic k -> bezier conversion

<emilio> schenney: it's not so much whether you can but how expensive the approximation is

<emilio> ... even now with the existing rounded corners I'm 99% sure that there are still issues in browsers with border-width

<emilio> ... so the interaction with border-width makes this trickier

<emilio> ... certain border widths + radius cause this to be tricky, so would be good to consider it

<emilio> smfr: agreed

<emilio> noamr: we're not going to solve the computational issue in this meeting. Perhaps we should limit this to determine that we want the parametric superellipse() if achievable

<emilio> ... have a rough CSS syntax for it and we can adjust based on implementability

<emilio> astearns: was thinking of an even smaller step of starting with keywords, described in terms of superellipse

<emilio> TabAtkins: that doesn't allow for smooth transitions in the future

<emilio> astearns: if we're defining keywords in base of the superellipse, don't you get that?

<emilio> TabAtkins: but the interpolation wouldn't be expressable until we get the function version

<emilio> smfr: unless we do mix() function magic...

<emilio> ... before resolving corner-shape, we probably want to decide whether we want border-shap

<emilio> ... because they have interactive functionality

<emilio> astearns: #6997?

<emilio> smfr: yeah, would be nice to get leaverou's opinion about this too

<emilio> github-bot: take up w3c/csswg-drafts#6997

[css-shapes-2][css-borders-4] Add a way to change an element's shape

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6997.

<emilio> noamr: I can give a bit of a recap

<emilio> ... we resolved at TPAC on having a draft for border-shape

<emilio> ... I started working on that and discovered some questions

<emilio> ... one of them is how it relates to corner-shape

<emilio> ... other one is how it works with border-width etc

<emilio> ... so wanted smfr to demo what he has

<emilio> ... and then talk demos

<emilio> smfr: [shows prototype]

<emilio> ... uses border-shape with the recent `shape()` function

<emilio> ... so it effectively takes over the rendering of the rounded rect

<emilio> ... and replace it with effectively two shapes

<emilio> ... one for the inside of the rect, one for the outside

<emilio> ... actually first outside, second inside

<emilio> ... it uses two different beziers, and it shows background-clip: border-area, and also box-shadow which both follow those shapes

<emilio> ... the way I think about this is replacing the rendering of the border

<emilio> ... it follows the same rules regarding clipping of the content etc, just like border-radius

<emilio> ... that's the two-shape version of this

<emilio> ... [switches demo]

<emilio> ... this one is the one-shape version, with a hole

<emilio> ... I think I used border-top-width for the line width

<emilio> ... but single-shape has issues re. that interaction

<emilio> ... a separate draft of mine just specifies effectively a stroke width

<emilio> ... interpolating seems hard

<emilio> ... also this is purely decorative. Affects clipping and ink overflow, but layout still uses the general box model

<emilio> ... what that means is that you might specify shape that allow the inside edge to project outside of the border-box

<emilio> ... which exposes things like extra background area or what not which are a bit weird

<emilio> ... one other thing I wanted to mention the connection between this and corner-shape is that this breaks assumptions

<emilio> noamr: one of the oddities is how it interacts with border-width

<emilio> ... with border-radius it kinda works

<emilio> ... so that's one oddity of this

<emilio> ... if your shape is kinda boxy you probably want your border-width to affect it

<emilio> ... I think border-width would be a default you can override

<emilio> ... same with border-color

<emilio> ... my thinking was that this could behave like a mask going through the borders

<noamr> w3c/csswg-drafts#6997 (comment)

<emilio> ... would be a simple solution but not what people would want

<emilio> ... I think this should be separate from corner-shape

<emilio> ... we should restrict corner-shape to rectangles

<emilio> ... where we can use it with border-radius

<emilio> ... and this would smooth your radius rather than something that controls shape

<emilio> ... would be good to separate it at least in the beginning

<emilio> ... and we'd leave the interaction problems for later

emilio: i was wwondering if this corrected border matches stuff how border-image works today
… not sure how border-image and border-radius interact
… feels similar
… in the sense that b-i disregards b-w and layout
… would be good to be consistent witht hat
… can find some answers to the weird questions here

<emilio> TabAtkins: generally agree with emilio, border-image does use border-width for the area but you can override

<emilio> ... we should approach this to keep this simple, the geometry should be overridden by shape, which is what simon is suggesting as well

<emilio> ... supportive of not paying attention to color or width as much as possible

<emilio> ... had some suggestions but not fully fledges

<emilio> ... having some way of specifying variable colors along the path seems nicer than trying to interpolate based on existing border properties

<schenney> +1 to Tab's color/width idea.

<schenney> Interpolate between points.

<emilio> smfr: sounds hard, not sure if svg has a way of changing colors along the path

<emilio> ... nice suggestion

<emilio> TabAtkins: what about variable width stroke?

<emilio> smfr: you need to use multiple paths for that

<emilio> TabAtkins: that's kind of annoying

<emilio> ... quite a jump from border-radius to some two-path