Web Components -- 24 Mar 2020

<hober> Scribe: annevk

<fantasai> Send PDF exports to www-archive@w3.org

Theming options for shadow roots

<fantasai> They'll show up in https://lists.w3.org/Archives/Public/www-archive/

fantasai++

[Presentation not minuted. Link will be shared in a bit.]

<masonfreed> Theming: https://docs.google.com/presentation/d/1xx9Ta2dM37uCSnLQZ6OQRRX3k1Zj4HguMe7hzEAuquw/edit?usp=sharing

<fantasai> For yesterday's minutes, https://lists.w3.org/Archives/Public/www-archive/2020Mar/att-0004/Web_Components_Integrity.pdf

<fantasai> https://lists.w3.org/Archives/Public/www-archive/2020Mar/att-0005/Theming_for_Web_Components.pdf

<pmdartus> Justin is speaking

<fantasai> ScribeNick: fantasai

Justin: Need to let them have richer control over properties
... A few levels of requirements for customer A
... Have to be able affect styling across shadow root in some way
... affect over multiple levels
... and have components very strictly opt in to styling
... Second requirement is around targetting
... CSS properties good, can control which properties are stylable, but hard for broad styling APIs
... ::part() has no control over which properties are styleable, probably a problem there
... but easy to use from author point of view
... 3rd level of requirements is around abstraction
... Wrt abstraction, want to be able to control, e.g. only two valid border-radius values in the design system, pick one
... Maybe 2 different button types, based on button type they want to choose the border radius for you
... design system
... ::part() doesn't really allow this kind of parameterization
... CSS properties doesn't let you define new value types liek this
... Thinking about evolving CSS more
... CSS Custom Properties can be interesting because inherit
... but limited in how to communicate
... Our teams at Google using Sass a lot
... CSS-in-JS world builds Sss-like things in JS as well
... Ideas around evolving CSS, we use custom properties as a style parameter
... then we give that shadow root more power, transform into concrete styles
... looks like standardizing some of Sass's features
... areas to look at have to do with expressiveness
... e.g. mixing, calc() functions, modularity, import-export across CSS files
... and possibly extensibility
... Most important is epressiveness
... in calc(), want a ternary operator
... functions around introspecting and building strings, etc.
... one common need, if you have an enum token, so lookup tables would be very useful
... also turns out container queries is something a lot of design systems want
... Another abstraction that's important, once you build out a complex transformation, want to share it across the design system
... custom functions / mixins would be useful for that
... and also allows sharing the components across systems
... Modularity is how do we share once we build them?
... Made a CSS References proposal, to pull rulesets, mixins, variables, etc. to import into file
... big idea here is that devs to a large extent want lexical scoping
... @apply was like a mixin, but mixed in a CSS property which was a container for other things
... this was dynamic scoping
... no way to import a variable, just have to rely on it being in the tree

<rniwa> +present

Justin: harder to control
... Mentioned custom functions before in CSS, some people have very complex things
... wrt calc, turning it into another complex programming language...
... Houdini has some parts built in
... one thing very useful for people is some kind of style observation
... so they can respond to a change in a custom property
... and either goes back into CSS or not
... classic use case: AMP built a carousel to display 1/2/4 up impages
... want to choose layout with CSS property
... have to do JS work to trigger layout changes
... observe via an attribute, even though it's a styling concern
... Last, very small example
... suppose styles inside a shadow root, and shadow root has button in it, has three different possible types
... might include a mixin where you give it the button type variable
... and mixin translates to concrete CSS
... One thing nice about idea, would benefit a lot of users other than Web Components
... so might see traction and support outside our circle as well
... that's it for slides
... almost random thoughts, wanted open discussion

<annevk> scribe: annevk

<Zakim> fantasai, you wanted to talk about !important

<Zakim> fantasai2, you wanted to note parameterization via custom properties

fantasai: With regard to which properties you're allowed to style vs not style. I think you can control that with @importable
... Don't remember the cascade details, but I think it should be possible, with CSS Levels(?)

<jan> Yes, you can control which properties ::part() can affect by using !important

<fantasai> See https://github.com/w3c/csswg-drafts/issues/4470

Justin: Folks would like to use allowlists

fantasai: use the all shorthand

rniwa: ???
... [I think rniwa is asking about the specific order]

<fantasai> I think it references https://www.w3.org/TR/css-cascade-4/#cascade-scope?

emilio: yeah

<fantasai> bkardell_: Going through use cases ... seems there was a class of things with custom elements that can be useful in different ways, that we haven't talked about much

<fantasai> bkardell_: You can think about components like a Markdown component, wrapper element around markdown

<fantasai> bkardell_: or latex math

<fantasai> bkardell_: shorthand for something known, creating a macro rather than hiding secret

bkardell_: 3 comments; 1 about the use cases, it seems to me that there's a class of thing that people do with custom elements that can be useful in different ways that we haven't talked about a bunch. You could think about a component as a shorthand such as Markdown or LaTex Math

<fantasai> ScribeNick: annevk

<inserted> bkardell: Might want to say, e.g. that these page styles apply to me

Justin: Mason might be able to speak to that since we had some people talking about similar things
... there might be a proposal for scoped styling in light trees

masonfreed: I think it's a lil premature to talk about that

bkardell_: 2 want to talk more about container queries. Community is positive. dbaron is looking into it.
... We're looking at turning container queries into some proposals for the CSS WG.

hober: quick question, if I remember correctly you shared a sketch of what you had in mind
... you basically have a switch statement
... it seems to me it might have broader applicability

bkardell_: yes
... 3 I'm hugely supportive of custom functions

Justin: custom functions from JS or CSS? How are they implemented?

bkardell_: TBD, presumably registered in JS like the rest of Houdini
... there are resolutions to do this in the CSS WG

<fantasai> ?: Our designers don't want to work in JS

<rniwa> ugh... sorry let me sort it out

<fantasai> ?: Houdini registration APIs greatly complicate build systems

<fantasai> hober: Same feedback, authors don't want to pull in JS just do do something clever in CSS

<fantasai> Justin: Sound similar to ways trying to solve this before, any new insight that makes this more tractable?

<fantasai> bkardell_: combinators are combinators

<fantasai> bkardell_: using iframes, have to find a way to pass the styles that inherit

<scribe> scribe: fantasai

bkardell_: combinators are combinators, and shadow root is shadow root
... not suggesting to blur the lines
... but say this particular component is styleable, and you can style the elements and their internal stuff

Justin?: So an @-rule?

bkardell_: or attribute on a link, or style tag
... not any discussion yet, so not proposing any specific solution

masonfreed: Block of styles, like an adopted style, into shadow root

Justin?: Don't know context of this, where have been proposed before and fallen over?

hober: Many have come up before, but there's a limited amount of time active members have and lots of things to work on
... not necessarily been rejected, but been starved of attention

<masonfreed> ?? above is masonfreed

hober: I think it's very useful for us as webcomponents to go to CSSWG with these ideas and the use cases
... say, know you talked about it before, didn't go anywhere, but here's why it's urgent now

Justin: Still see ::theme() or something expanding ::part() as useful
... but without ability for abstraction, large-scale systems aren't looking to map directly to CSS properties
... so parameterization and abstraction is the top priority to solve here

rniwa: One thing I would add to what's said, discussion is getting more fuzzy, so good to state concrete use cases based on info provided
... In previous discussion about these CSS features, it was helpful to have a very concrete use case and try to solve that problem
... really abstract discussion, very hard to figure out whether solution discussed is appropriate

Justin: we can bring concrete code as use cases, just have to pick easy-to-understand ones

rniwa: great
... previously when designing solution to styling features, one thing that happened, we come up with something
... and you or someone tries, and edge case doesn't work well
... can short circuit a bit with concrete use cases

RobE: Share what we're working on at MSFT
... everything Justin is talking about is things we're creating workarounds for
... we're creating a component library
... talk about design tokens etc.
... want to define our component system in terms of e.g. primary color, secondary color, elevation, luminance
... want to determine actual foreground/background/etc. based off of these more abstract design system concepts
... looking at button inside card inside drawer, foreground colors are really for a11y need to be based on bg color
... and bg colors are determined by what bg colors they're on top of sometimes
... need to compose
... there has to be another set of rules determining set of foreground colors, based on primary/secondary color combined with bg + rules for a11y to produce final actual color

Note https://www.w3.org/TR/css-color-5/

rniwa: ???

<bkardell_> lab colors functions useful for unblocking, which is under development in webkit and now chromium it seems

RobE: we want to calculate colors, but these things dependent
... We have component, html attributes that are design system tokens
... we run tons of custom JS when those attributes change to calculate all the colors
... Can't do through CSS, because CSS calc() falls down in color calculations
... don't have mapping tables or color ramps
... downstream in DOM, have to calculate properties
... Product-specific, Office or Teams, people write plugins, want to use our components
... our designs system is set up over a region, but ppl want to override parts of it
... We have in MSFT design, have a few flavors
... all these things have to co-exist within a single UI
... we end up using HTML attributes because we need to do custom calculations when things change, need them to be observabl
... calculations on these things change
... lookup tables, calculations, enums, all useful
... even basic stuff like ternary and ??
... need to observe when styles change
... but conceptual ideas are a lot of things we think about and work around through our observations, using custom attributes
... lots of perf implications for that stuff, and to be honest, we don't even know how feasible some is to do
... so that's specific to my team's world, but hopefully some concrete idea why features like Justin describes would be extremely valuable for us

https://www.w3.org/TR/css-color-5/

fantasai: Might want to look at FPWD css-color-5, which is about color cacluations

<RobE> Definitely will check out the new color calc work :) Very happy to hear about that.

rniwa: Might be interesting to see if RobE's can be solved in CSS, and which can't
... we don't want to add feature in CSS that update DOM, e.g.
... perhaps even bring that feedback back to CSSWG

RobE: I can share exact code, we're open source
... love to share with group

hober: Coming to us with concrete examples is good, also going straight to CSSWG with that info would be very useful

Propagation of lang/dir

<westbrook> Scribe: westbrook

<smaug> smaug

<hober> https://github.com/whatwg/html/issues/3821

smaug: let's close `title` as it seems agreed on.

we are agreed no https://github.com/whatwg/html/issues/3821#issuecomment-432978926

rniwa: dir has many values, but "auto" is the worse

<fantasai> dir = ltr | rtl | auto

rniwa: the browser decides the value of "auto" by the first character in the element
... slots make that tricky

<fantasai> https://github.com/whatwg/html/issues/3699#issuecomment-433901340

rniwa: shadow root content and slot content must be considered
... seeing intot he shadow root leaks the encapsulation.

<fantasai> https://github.com/whatwg/html/issues/3699#issuecomment-435030561

rniwa: slot can have text node, which further tricks the way this algorithm is resolved

fantasai: dir and lang inherit in the DOM tree, and must be handled there rather than in CSS
... dir=auto should resolve based on the light DOM for this reality to support selectors

hober: this supports shadow content being one dir and slotted content being another dir
... would it leak slot reality if we use the dir on a slot?
... don't want the user to learn about the internals

rniwa: bounding rects will already surface this data

<annevk> Can't we require that if you want your text that's assigned to a slot to be dir=auto to just <span> it as such

annevk: could we just require <span dir="auto"> in slotted text nodes?

<fantasai> annevk, the issue is if the shadow host or its ancestor has dir=auto

<annevk> fantasai, isn't there an equivalent issue with the slot element having dir=auto?

emilio: tab bar in ltr page...internals should know about the externals...

rniwa: to respect the pages dir shadow root should get the dir from the outside
... fancy link el with icon at end, would need to ignore outside dir if the content had an alternate dir

hober: what do we need to make decisions on?
... in summary? the outer tree resolves based on its tree, but the inner tree can acquire dir from the outer tree

group: seem to be in agreement

fantasai: acquire means two things. auto acquires by introspection.

rniwa: will expand on github

fantasai: directionality looks at its text content, so what do the elements look at when dir=auto

fantasai: does <div dir=auto><slot> resolve against the <slot> or the slotted content?
... resolving on the slotted content seems the most useful for a user, but might not be the easiest to make happen

hober: aligns with being able to use information from up the tree

<hober> https://github.com/whatwg/html/issues/3699#issuecomment-603345811

rniwa: we also have to think about the chained <slot>s with alternating dir values
... whenever we hit a <slot> we'll have to take a look at it's assigned nodes for this value or dir and/or existing directionality

annevk: is there really a use case for slotted content that you don't know the directionality of?

hober: text nodes again are an issue here

<fantasai> https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute:attr-dir-auto-state-3

hober: so always looking a the current tree is the simplest option

emilio: it's about how the slotted content might effect the directionality in other parts of the shadow root

fantasai: if we don't introspect we can acquire the directionality from the host as long as it isn't reset along the way by elements in the shadow tree
... put dir=auto on hold and visit inheritance?
... we want the directionality to inherit into the shadow dom from the shadow host by default, leaving other elements to alter that by opt-in?
... light DOM should inherit as if shadow root doesn't exist and shadow DOM should resolve its directionality on each element from the host

rniwa: when light DOM accepts dir=auto and the slots content determines directionality, does the entire block need to follow the slotted content?

<rniwa> <div dir=auto><div id=host>Some Hebrew</div></div>

<rniwa> is the light DOM

<rniwa> then you have <slot></slot> in the shadow root of #host

fantasai: auto introspects content, sees <div>. looks deeper, sees hebrew, content resolves both <div>s as RTL.
... with that light DOM resolving as if shadow didn't exist, then the slotted <div> will continue to be RTL no matter the attributes in the shadow DOM.

<fantasai> <div dir=auto><div id=host>Some <span>Hebrew</span></div></div>

<fantasai> all of these would be rtl

<tomalec> <div dir=auto><div id=host>Some Hebrew</div></div>

annevk: what is #shadowDOM = hello world! <slot></slot>

<tomalec> <div dir=auto><div id=host><shadowroot>HelloWorld</shadowroot>Some Hebrew</div></div>

<annevk> Shadow tree is "Hello world"

<fantasai> annevk, doesn't the shadow dom need a root element?

<annevk> fantasai, no

<fantasai> k

rniwa: with that example, outer did would still have RTL.

<fantasai> s%<slot></slot>%%

<fantasai> all the divs would end up with dir=rtl

<fantasai> and exclamation point would be on the wrong side of HelloWorld

<rniwa> The tricky case is <div dir=auto><div id=host>Some Hebrew</div></div>

<rniwa> with shadow root of #host being "hello world! <slot></slot>"

fantasai: places responsibility of managing internal directionality on the shadow content creator.

<fantasai> <div>hello world ! SOME HEBREW</div>

<fantasai> It is impossible to isolate "hello world!" because there is no element

<fantasai> isolation requires an element.

<rniwa> <div dir=auto><div id=host>Some Hebrew</div></div>

<annevk> Example: <div dir=auto><div id=host><slot>HEBREW FALLBACK</slot></div></div> + <slot> gets assigned Hello World

<rniwa> with shadow root of #host being <span dir=rtl>hello world!</span><slot></slot>

annevk: do we look at assigned nodes in special ways?

rniwa: can we agree that directionality inherits into the shadow root.

fantasai: when an element doesn't have a dir attribute, it inherits from its parent ignoring all shadow content (as if the shadows didn't exist).

<TabAtkins> I agree with these rules.

fantasai: top level elements in the shadow tree inherit from the shadow host.

<TabAtkins> perhaps simplified: directionality inheritance happens over the tree-of-trees, not the flattened tree.

<TabAtkins> annevk, you know DOM better than me - is there a term for the tree-of-trees?

<annevk> TabAtkins, composed tree is the thing we've yet to define

<annevk> TabAtkins, though composed tree would go from slot -> assigned children which this does not, iiuc

<TabAtkins> Well, actually, I don't think it needs the term. We just define that each element inherits its lang/dir from its parent element, if that exists; otherwise its shadow host, if that exists; otherwise the default values.

<annevk> (smaug can correct me if I'm wrong)

<TabAtkins> Not sure which you mean by "composed tree"; I'm *not* talking about flat tree (which is defined in CSS Scoping, fwiw)

<smaug> right, slot to assigned children

<annevk> TabAtkins, yeah, for fantasai's definition we don't need the composed tree, at least not for the inheritance aspects (we might for resolving dir=auto)

<fantasai> I think DOM should be defining the flat tree, tbh.

<annevk> TabAtkins, composed tree is the tree of trees thing, or how events work

<TabAtkins> Ok.

<fantasai> CSS Scoping is a weird place to put it

<annevk> fantasai, it should define composed tree

<TabAtkins> Yeah, agreed, but it was needed in CSS before it was needed in DOM, so I defined it. ^_^

<annevk> fantasai, but flat tree is very much a layout matter

<fantasai> it's not specific to CSS, though, it's a general concept of how to flatten the tree for applications that need such

<smaug> this is not about flattened tree, at least some of this, since querySelector deals with trees-of-trees

fantasai: remaining open question... is dir=auto able to look at slotted content or not?

<smaug> tree-of-trees

<annevk> fantasai, I guess I could be persuaded to define the flat tree in DOM

<annevk> fantasai, but we can't have non-layout dependencies on it, basically

<TabAtkins> fantasai, I guess the question is what concept *other* than CSS-related stuff needs the flat tree...

<rniwa> Updated https://github.com/whatwg/html/issues/3699#issuecomment-603345811 with the latest discussion

<TabAtkins> (I still think it's probably appropriate to define it in DOM as well, just for centralization of similar concepts, tho.)

<TabAtkins> annevk, there's no layout dependency in the flat tree, it's based purely on DOM relationships.

<annevk> TabAtkins, I know

<TabAtkins> ah kk, i misread you then

<fantasai> There's applications that render HTML without using CSS.

<fantasai> I presume they should be using the flat tree.

<annevk> TabAtkins, but we don't want non-layout dependencies on that concept

<annevk> TabAtkins, since it's expensive to compute

<TabAtkins> Mm, ok.

<TabAtkins> fantasai, Catering to non-CSS implementations of web content isn't something I care about in the slightest; they can live with ignoring all the CSS parts we write everything else with.

<fantasai> I think it's a good guide for thinking about where the definition of things belong

<annevk> But I'm not sure that means it belongs in DOM

:state

<fantasai> ScribeNick: fantasai

TabAtkins: Topic came up in TAG review of :state() which allows custom states
... Suggestion to call this a "custom pseudo class" and use CSS's custom identifier syntax, :--foo
... I believe this is the appropriate place to introduce custom pseudo classes
... For both the current design and future design we plan for
... I believe going with actual custom pseudo-class is the right way to go
... just check for -- in ident, and then expose accordingly
... functional pseudo classes would be the same way
... Instead of :state(..)
... Maciej had argument against
... first argument is that :state() is more symmetrical with ::part()
... and since semantically close together, keep syntactically close to gether
... Second argument is that "state" as a word has meaning
... lastly, :--foo() looks like noise
... My counter arguments:
... I disagree with the noise argument, think it's a question of familiarity with syntax
... nobody much liked --foo syntax for custom properties at the beginning
... but now it's a widely-used convention
... meaning author-defined
... Works same as any other pseudo-class, clearly author-defined
... Second argument, disagree that "state" is meaningful. It's like "mode". Provides no additional context.
... Every single pseudo-class is asserting some state.

<hober> https://github.com/w3c/webcomponents/issues/738

TabAtkins: Meaning will be clear once people associate "--foo" with "foo is a custom thing"
... :state() doesn't make clear that it's custom
... Symmetry with ::part() is a reasonable argument, but
... pseudo-classes can be stacked and combined so that you can have multiple pseudo-classes combined together, to filter element on multiple criteria
... pseudo-elements are not like that, they're treated much more like tag names
... and it essentially includes a combinator
... If we wanted to select on multiple criteria [...]
... No way to do pseudo-element using --foo, so take multiple names in ::part()
... CSS syntax has always been bad in this way
... ::part() is how it is, because we couldn't do it any other way
... Pseudo-classes can be done any way we want, and --foo is well-established, so I think using :--foo() is more meaningful here,
... and if it was possible for ::part() would have used there as well
... So I propose to make this change.

hober: I'm not going to attempt to channel Maciej on this issue, I think he expressed himself well.
... Also, particular choice of :--foo vs :state() is not a hill I'm interested in dying on

<TabAtkins> Pseudo-element syntax is bad because of the combinator built in.

hober: When this came up in the TAG review, main concern was that we wanted non-binary states
... I don't find that to be terribly compelling
... I haven't seen examples of interesting non-binary states
... that don't decompose into straightforward binary states
... That said, I agree with Tab that we may want functional pseudo-classes built into CSS in the future
... and it makes sense to think ahead and to try to make custom pseudo-classes and built-in pseudo-classes upgrade to functional form in the same way
... so compelling argument for using --foo here

TabAtkins: CSS already has functional pseudo-classes already
... beyond tree-structural ones like :nth-child(An+B)
... :dir() can decompose into binary :rtl / :ltr
... but :lang() can't
... I don't think :lang() is a one-off, I think it's a reasonable design of things that could be desired to expose by authors in the future
... so we should make sure that sort of thing is consistently allowed with whatever design we go with

<Zakim> annevk, you wanted to ask if .states changes

annevk: Wanted to ask about the API
... you said "state" is a meaningless word
... but still have .states
... or was there a corresponding proposal to change?

TabAtkins: don't think needed to change
... CSS can occupy --syntax, but JS doesn't have such thing
... and controlling API makes sense to have a name

hober: why not call it something like custom pseudo-classes?

Justin: I think state is more confusing on the JS side

<hober> annevk: i was going to bikeshed this in a similar direction to hober

Justin: because CSS syntax have context that it's a pseudo-class
... on JS side, it could mean anythng

<rniwa> q

TabAtkins: OK, let's take an action on me to go suggest a changeover to either pseudo-classes or custom-pseudo-classes or something

<hober> ack bkardell_:

bkardell_: Like Tess, don't know it's a hill I'm particularly interested in standing too hard for
... but in 2014 CSSWG made decisions about how custom things would work, e.g. custom pseudo-classess would be --foo()
... This is that feature
... TAG review had some answers that make me feel like we could live with it, if it's not that
... but I don't honestly see a compelling reason to not be :--foo
... I think it's a good move.
... One of Maciej's concernswas about consistency, and it's about where consistency and how much
... if all custom CSS shares the same syntax, that's very good

<Zakim> fantasai, you wanted to mention multi-state as a consideration

fantasai: I support the idea that we will eventually expand to multi-state and parameterized pseudo-classes
... so we need to make sure that we can expand in that direction
... wrt the name of the JS API, I don't think calling it pseudo-classes is great
... a) I'm uncertain that it will be the only place we use this state
... b) pseudo-class is really hard to spell

TabAtkins: I think it's fine.
... Wrt functional pseudo-classes, discussed with plinss, not sure how it should work, but sticking with current design of DOM token name list seems least clumsy way to go forward
... s/forward/forward to me/
... plinss disagrees though, thinks better idea is to move to map
... where key is pseudo-class thing, and key is something about the argument, currently restricted to truthy
... I think even if there's APIs that make it look like a set, it's awkward
... would prefer to have boolean and non-boolean pseudos be different

<annevk> +1 to your opinion TabAtkins

jan: I maintain an open source library that invested in supporting state and state selector
... When I saw Tab's proposal to change to :--foo(), my initial reaction was negative
... Tried to see what that would look like in the code
... after sitting with it for a while, I'm supportive of this change. I think it achieves the objectives that Tab mentions
... Makes it clear this is custom pseudo-class. Originally opposed, now supportive
... Also want to echo idea that it'd be fine to rename the API on the JS side

<TabAtkins> Here's the thread for boolean vs functional design: https://github.com/WICG/custom-state-pseudo-class/issues/4#issuecomment-594787465

jan: in writing code to use states API, it's been very confusing because we use concept of state throughout code
... so had to annotate when talking about element internal state API
... clarify not referring to component state
... so would support focusing API on pseudo-classes to clarify that

rniwa: Since talking about non-boolean state, make a point that attributes, we don't have different APIs for boolean and non-boolean APIs
... so don't see why have two different things for whether boolean or not
... Another point I'd make, there's a lot of requests and complaints about no way to emulate states like :checked/etc.
... if thinking about custom pseudo-classes, we should solve that problem
... Premature to add new API without thinking about how to emulate element state, e.g. :disabled etc.

TabAtkins: design for single API I've seen looks really weird and awkward, if you have better suggestion, post on thread
... ...

rniwa: No, I'm talking about if you're making a custom form control
... You need to be able to say "I'm in a checked state"

TabAtkins: That's an entirely different thing, though
... like being able to opt into various aria states with element.internals API

<hober> an API for custom elements to work with built-in pseudo-classes

TabAtkins: That seems reasonable

hober: It's not ARIA, but similar thing
... API for custom elements to work with built-in pseudo-classes
... and that sounds like a great idea

TabAtkins: if we try to overload this proposal to do that, that implies either there's a restricted set of non-prefixed names you can use...

rniwa: Not saying we need to use the same API, but we need to figure out how that works
... if we design a bad API, and we can't add standard states to custom elements because we messed up this API, that would be bad
... So we should try to solve this for at least one of them, to make sure we do it well

TabAtkins: Fair, make sure that if we want to be consistent, can be consistent.
... So agree to do that design work sooner rather than later

annevk: Isn't that form-associated custom elements?

rniwa: From-associated elements handle some, but some others not supported, e.g. :link
... element.internal is way to communicate internal state of elmeent
... e.g. media-like element, has certain states
... would be weird to call this property pseudo-classes, because then this element.internals would be all about pseudo-classes
... which would be weird

Justin: Wrt custom functions and non-binary state, don't think a map API is that awkward
... using true/false for custom pseudo-class
... Custom function vs non-binary is eager vs lazy
... If discussion is going towards implementing a function on JS side, called during styling
... Being able to push string values or some other type of values to custom pseudo points to a path forward for non-binary states, that have a consistent API
... Comment I want to make, would it make sense, ::part seems to be a special selector in my mind
... thinking about custom state, ::part ends up being conceptually a way to allow for abstracting over selectors into shadow root on the shadow host
... right now very specific prescribed set of things you can do, but maybe ::part() grows more syntax
... would it make sense for consistency, to allow ::part() to use --syntax?
... would that be two ways to do the same thing?

TabAtkins: not sure how I feel about it
... Post it as an issue, worthy of thought

<annevk> That seems awkward given part=""

hober: In context of CSS, I've often been someone who's skeptical of adding syntax aliases for things
... we've done that in some cases for legacy properties with bad names
... and I worry about expanding the API surface and confusing authors

<bkardell_> mapping legacy to a common better aligned this is definitely a case we do that tho, and it's an interesting idea

<Zakim> fantasai, you wanted to respond to Tab

hober: so base skepticism for aliases, but it's an interesting point

<bkardell_> so +1 to what hober just said

fantasai: CSS has distinct syntaxes for boolean vs functional pseudo-classes, so API needs to be clear which one the custom thing is

TabAtkins: ...
... [describes some thoughts in threads]
... There are also some pseudos that can be either functional or not, e.g. earlier proposal for :local-link/:local-link()
... If combined design, means we have to choose one of two paths
... either booleans can only be defined by true/false, anything defined with other syntax is functional
... or if you have boolean, :--foo and :--foo() are equivalent
... so those are choices to be made, not sure which one to make
... or if using separate APIs
... but do need to think about how it affects CSS syntax

annevk: Seems pretty self-evident that two separate APIs is the way to go

Justin: I prefer one API, because it seems for boolean functional attribute
... ...?

TabAtkins: We had functional pseudo-class :local-link(...) which interpreted argument particular ways
... but you ould also use :local-link which defaults behavior

fantasai: It's not generally true in CSS that parens are optional like that, though

annevk: ...

hober: I like Justin's idea that the custom pseudo-classes without parens is equivalent of passing in "true"

<annevk> (I proposed :heading at one point which was both :heading and :heading(level))

hober: parallel to attributes in the DOM

<bkardell_> there are lots of proposals, and if we had custom ones we could find out if they are good

hober: If simple rule for all the custom ones, that's great

TabAtkins: Wish we could have said could have parens optional

<bkardell_> local link is a good example of one I built myself and then realized i didn't understand it and it wasn't what I wanted at all :)

TabAtkins: but currently it's a syntax error, blows out entire style rule

jan: Rationalizing --pseudo-classes vs using for parts
... I do think important that place where dev is defining the custom thing, it's consistent with where they're using it
... replacing state with --, unclear what you would pass
... once Tab clarified that you include -- as part of the token being passed, that's OK

jan: I'd be concerned if you define part with part="bar" and refer to it with "--bar".
... I don't know the value of -- in signally "something custom going on"
... but name itself needs to be consistent

TabAtkins: we had discussion for custom properties, concluded it's important to always use full ident name including --
... for custom states, definitely have to include
... for ::part(), would apply the same rule
... that that means, it's the same rule
... might mean all part names have to start with --part
... or say current works, and part="--foo" means you can use --foo as a top-level pseudo-element

jan: Found it hard to remember whether to use one colon or two
... so preserving current part syntax is maybe helpful to keep that distinction

hober: This was useful discussion, seems lots reflected in open issues
... Suggest a break.
... if someone could summarize this discussion in agenda, would be really helpful

<jan> https://github.com/w3c/webcomponents/issues/566#issuecomment-539647628

<jan> That link points to a summary of the issue 566 we're about to discuss

Is there a way to retrieve the localName from a custom element constructor?

<hober> https://github.com/w3c/webcomponents/issues/566

<pmdartus> ScribeNick: pmdartus

<scribe> Scribe: pmdartus

jan: There seem to be browser differences:
... rniwa is ok except for built-in elements

rniwa: I am fine with overloading

jan: 2 points: should support built-in elements and should it support overloading
... The question of supporting built-in elements. Google want to support, Apple don't want to support this API. Are those positions still the same?

annevk: This is a question for masonfreed

masonfreed: Yes it's me, I will need more time to read the details

Justin: People want to pass around the constructor reference.
... The problem is that the built-ins are newable and there is no 1-1 mapping between the interface and the tag name.

rniwa: We don't want any mapping between built-ins and tag names, because we don't have that today.
... Why do we want this in the first place, this API is on the CE registry, what is the point of asking for a built-in?

Justin: This feature makes more sense against the global CE than the scoped CE.

Jan: The feature is that, a component author want to use a component but they don't know if the constructor is already registered or not?

Justin: An equivalent use case is JSX where you pass the constructor in the template instead of the tag name.

rniwa: If you use some sort of framework, you won't need this API.

annevk: We might add an API to access the registry from an element, but this is will be in the future since we don't have scoped CE now.

masonfreed: Google is more than one person, I will need to speak with Domenic.

Justin: I have talk with Domenic before, this is not only an abstract objection. From his point of view, we have tried to create an authoring components like built-ins.
... This proposal feels like a step back by introducing a new difference between the built-in and custom elements.

Jan: Why not having a built-ins registry?

Justin: Is it still a use case if we have scoped CE?

<jan> (I'll wait)

tomalec: ???

rniwa: I don't want this function to return built-in

<caridy> tomalec thinks that since we have the inconsistency with the tag name between custom elements and built-in elements, it is ok to keep them separate.

rniwa: The customElement.get can retrieve a custom element name and returns a constructor.

<tomalec> I was commenting on inconsistency point between API for custom elements and built-ins. We already agreed to have inconsistency in names. CE needs to have a dash. Therfore for me as Web Developer, it's naturalto lookup this name in different place.

rniwa: This API doesn't work with built-ins. Why do we need this API doing the opposite mapping.
... There is a real use case for this API, and we want to implement it. But we need real example for the built-ins.

<jan> https://github.com/w3c/webcomponents/issues/842

Jan: The original use case "we want to register a component with a random name automatically".
... There are case where you are not interested in the markup and create the elements on the fly by invoking new.

bkardell_: We have been stuck on topics around built-ins forever
... That being said there are real cases. The polyfill is always terrible in this case.
... Can we shift the conversation to move forward?

annevk: I am not sure if bkardell_ is speaking about customized built-in or a built-in.

rniwa: How is this related with the discussion?

bkardell_: Not entirely, that why I want to speak last.

<bkardell_> ^ that is why I shifted to the end of the queue

<bkardell_> it is different

<hober> https://github.com/w3c/webcomponents/issues/566#issuecomment-371049783

<annevk> (FWIW, I think I'm back to not overloading this as it's kinda weird.)

hober: It looks everyone agrees that we want this API. annevk's strawman proposal for the builtin mapping api can be polyfilled.

annevk: Do we have data, or existing sites with such polyfill?

Jan: Yes, there are example on stack overflow. So people might already use such pattern.

annevk: Is there any demonstration of demand in the wild?

Justin: Trey was using such pattern in one of his library.

caridy: If we go with the current proposal, we will end up with the same situation when using customized built-in in Safari.
... This is the world we live in, and if you want to use this in Safari you can polyfill it.

rniwa: caridy you are confused between customized built-ins and built-ins

<jan> customElements.get('button') => undefined

masonfreed: My take aways, there is a clear interest from developers and I will speak with Domenic to move forward.

<RobE> Thanks everyone!

- DRAFT -

Web Components

24 Mar 2020

Attendees

Contents

Theming options for shadow roots

Propagation of lang/dir

:state

Is there a way to retrieve the localName from a custom element constructor?

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output