<hober> Scribe: annevk
<fantasai> Send PDF exports to www-archive@w3.org
<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
<br duration=9min>
<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
<hober> <shadow-host><div dir=auto><slot>
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
<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
<hober> <div part="foo"> isn't <div part="--foo">
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
<br duration=15min>
<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
<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!
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: i/Justin: Mason/bkardell: Might want to say, e.g. that these page styles apply to me Succeeded: s/??:/masonfreed:/ Succeeded: s/fantasia/fantasai/ Succeeded: s/fantasia/fantasai/ Succeeded: s/this/think/ Succeeded: s/slotted content/shadow host/ Succeeded: s/inherit/resolve its directionality on each element/ Succeeded: s/fantasai:/fantasai,/ Succeeded: s/element/shadow content/ Succeeded: s/low/lo/ Succeeded: s/fantasai:/fantasai,/ Succeeded: s/belongs/belong/ Succeeded: s/foo()/foo/ Succeeded: s/function/pseudo-classes/ Succeeded: s/--foo/:--foo/ Succeeded: s/Maciej's concern /One of Maciej's concerns/ Succeeded: s/Masson/masonfreed/ Succeeded: s/This is something that/annevk's strawman proposal for the builtin mapping api/ Present: bkardell_ hober rniwa annevk emilio jan pmdartus masonfreed Justin westbrook tomalec RobE smaug Lars kevin_schaaf Goffert edgar diervo DanClark fantasai Found Scribe: annevk Inferring ScribeNick: annevk Found ScribeNick: fantasai Found Scribe: annevk Inferring ScribeNick: annevk Found ScribeNick: annevk Found Scribe: fantasai Inferring ScribeNick: fantasai Found Scribe: westbrook Inferring ScribeNick: westbrook Found ScribeNick: fantasai Found ScribeNick: pmdartus Found Scribe: pmdartus Inferring ScribeNick: pmdartus Scribes: annevk, fantasai, westbrook, pmdartus ScribeNicks: annevk, fantasai, westbrook, pmdartus WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]