- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:32:30 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
<details> styling
-----------------
- dbaron introduced his proposal to allow styling of <details> and
asked for feedback specifically around how he's solved for
addressing pieces of the widget and moving them around.
- There was some disagreement on how much of the shadow tree should
be exposed and if exposing the shadow tree falls out from making
a pseudo element or if there's a possibility of doing something
different.
- Exposing the shadow tree could lead to UAs being restricted in how
they can change the component in the future
- If the shadow tree is exposed, extra attention will be necessary
to ensure accessibility is handled well.
- With web component styling already considered difficult, it may be
better to continue working on the low hanging fruit to make web
components better before moving on to exposing UA elements for
styling.
- Exposing the internals could be the easiest solution, but it also
would involve doing so in a web component-like way which is
complex for authors.
- dbaron will add specific use cases to further discussions.
Interested group members will talk more offline and bring this
topic back when appropriate.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Present:
Rachel Andrew, Google
Tab Atkins, Google
David Baron, Google
Oriol Brufau, Igalia
Federico Bucchi, Apple
Stephen Chenney, Igalia
Mu-An Chiou, Ministry of Digital Affairs, Taiwan
Emilio Cobos, Mozilla
Yehonatan Daniv, Wix
Matthieu Dubet, Apple
Elika Etemad, Apple
Rob Flack, Google
Megan Gardner, Apple
Sammy Gill, Apple
Daniel Holbert, Mozilla
Brian Kardell, Igalia
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Una Kravets, Google
Vladimir Levin, Google
Peter Linss, Invited Expert
Theresa O'Connor, Apple
ChangSeok Oh, ByteDance
François Remy, Invited Expert
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Vitor Roriz, Apple
Noam Rosenthal, Google
Khushal Sagar, Google
Jen Simmons, Apple
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Bramus Van Damme, Google
Lea Verou, Invited Expert
Sebastian Zartner, Invited Expert
Scribe: bts
<details> styling
=================
github: https://github.com/dbaron/details-styling
dbaron: It is pretty early; would be standardized in HTML not CSS
dbaron: wanted to get feedback on this topic and reactions
dbaron: Widget built in HTML element; people use this a lot. Not
frequently used for things people do.
dbaron: People build disclosure widgets on it.
dbaron: Not especially style-able
dbaron: Issues 1. ability to address pieces of widget and move them
around. 2. ability to animate well.
dbaron: Want to discuss mostly around the first issue. Going to
research 2nd issue more.
<una> +1, one of the biggest requests we hear is being able to make
details/summary animate
dbaron: With styling details element 3 major engines implement using
shadow tree
dbaron: extremely interoperable between browsers
dbaron: Very minor details between browsers
dbaron: Questions about styling: How do we want to expose shadow
tree to styling?
dbaron: Do we want devs to address the pieces of it, and do we want
to devs replace shadow trees with their own? Not mutually
exclusive.
dbaron: How would we be comfortable with doing it?
dbaron: Not any great precedent.
dbaron: Select menu in open ui has pieces for addressing it.
dbaron: DOM spec indicates cannot attach on. Maybe it should be
allowed?
dbaron: Letting it be replaced may be considered.
dbaron: Could start minting pseudo element name; expose using ::
names. No standardized shadow trees exposed using ::part
dbaron: Want to get people's reactions to this.
<TabAtkins> We don't use ::part() on anything built-in currently,
but there's no conflict with doing so - we're not
stomping on any author namespaces.
dbaron: Don't think this is the only place we would want to do this.
dbaron: Not looking for any conclusions today. Just wanted feedback.
hober: Built in CSS properties have names like foo-bar. Built in CSS
pseudos have name ::foo.
hober: That they use a shadow dom is an implementation detail.
emilio: Was not an implementation detail
hober: Think there is a clear distinction between these things. Can
observe corpus of custom properties.
hober: Won't step on author toes. If we expose it call
::disclosure-widget
dbaron: Think there is room for a third space of things.
Implementation features that are built on top of platform
features.
hober: Don't think we should do that
dbaron: Think that is a reasonable space to explore.
<emilio> myles:
https://html.spec.whatwg.org/#the-details-and-summary-elements
<emilio> myles: > The details element is expected to render as a
block box. The element is also expected to have an internal
shadow tree with two slots. The first slot is expected to
take the details element's first summary element child, if
any. The second slot is expected to take the details
element's remaining descendants, if any.
nicole: Ask for an example?
hober: <std-foo> elements that domenic proposed a few years ago
dbaron: details is an example of that. Question is how much to
expose it.
tabatkins: Shadow trees are UA controlled. Part names don't have
issue have clashing.
emilio: Does not have any clashing with --
tabatkins: The exportparts attribute lets you re-expose your custom
element.
TabAtkins: this makes reusing ::part() more powerful than other
pseudo elements
<dbaron> https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/exportparts
plinss: Could define exportparts as exposing pseudo elements.
tabatkins: In theory yes.
ntim: Feeling a bit uneasy exposing more of the shadow tree.
Doesn't say exactly what the shadow tree looks like.
ntim: Wouldn't want to expose it more heavily.
Mason: Want to clarify on special powers.
ntim: Define pseudo elements in WebKit
emilio: Mentioned does not need special powers.
myles: Find in page needs to know structure inside the page. Web
Inspector needs to know the structure inside the details
element.
emilio: Why? In Gecko details shadow tree is just the details shadow
tree.
emilio: not modifying the DOM tree in the shadow tree. Make sure it
matches across engines.
emilio: Think details is different from media controls. Less opaque
than other shadow tree
chrishtr: Question for David. Do you think parts of pseudo elements
would be style user element?
dbaron: Not sure it is enough. Would need to work through different
cases.
Masonf: Following up on special powers think it is bad. Think shadow
tree should be fully specified.
masonf: people may want to move things around in widget.
maonsf: Makes it hard to use other features if you do not know the
structure you are inside of.
Masonf: Other thing built before web components. Don't know why we
can't use new stuff with it.
Masonf: We have been talking about ::part
masonf: want to know about using slot attribute
masonf: and being able to replace shadow tree with developer shadow
tree.
masonf: Looking for feedback on these questions
<TabAtkins> inability to make display an inline is *really* annoying
- can't use it for an inline spoiler >:(((((
emilio: Replacing shadow tree part not convinced of. No other
element allows you to do that.
emilio: Haven't brought up details always forms a block. Shadow tree
is inside a block box.
emilio: Remove special detail of creating a block box
hober: Asking emilio. You said earlier that <details> doesn't need
magic so it can be built with the author-facing shadow dom
machinery, but you just identified magic that it has
(<summary>'s automagic slotting behavior). I'm confused.
emilio: The only magic is equivalent to specifying a slot attribute
in the main summary element.
chrishtr: The magic can be explained by the web components.
<masonf> Emilio - we could get around the display:block issue by
allowing `<details><div style="display:flex"
slot=overallboxslot></details>`
<emilio> masonf: but not really right? Then you need to replace the
whole thing including the marker etc
<masonf> Right, but that can work too, as long as the UA can attach
behaviors to the right elements.
<TabAtkins> yeah, `<details><summary><span>long content</span>
</summary></details><style>summary { display: flex
}</style> would work
<TabAtkins> the ::marker would be one flex item, the span would be
another
nicole: Things authors want to do, but not particularly styleable at
the moment. Thinks may need a DOM tree change. Why is
styling so limited.
nicole: how to make text not wrap under the marker?
emilio: In block formatting context that is hard. The details forced
to be a block, but should not be.
dbaron: In this case more about styling the summary.
dbaron: The summary is less interoperable than the details. Chromium
and Gecko do it one way and WebKit does it another.
fremy: To answer question from Mason. Don't feel replacement is
useful. Agree with Nicole that there is a lot low hanging
fruit to go after.
nicole: Doing both styling and looking into how to modify internal
parts of the summary element.
castastrophe: Accessibility is a concern when opening up the shadow
DOM.
<nicole> +1 to needing to have a11y guarantees if authors can modify
the DOM of built in elements
<una> Can we enable accessibility semantics for this element with
attributes without requiring shadow DOM?
castastrophe: Next point about parts. Interesting approach. Authors
need to know quite a bit about the internal structure.
castastrophe: Advise only web components developers to use
castastrophe: Styling web components is considered very hard in the
CSS community. Should be addressed before opening UA
elements for CSS developers to start playing around
with.
<ntim> +1000 to cas
castastrophe: Several steps that need to be done.
castastrophe: Step 1. Open up the pain points. Nicole mentioned that.
castastrophe: Next step making web components more style-able, and
then UA components.
myles: Want to see if this is valuable for people not working on
browsers.
nicole: Think seeing authors not using it means it is unusable at
the moment.
<astearns> (many people in the room murmur about it being valuable)
<una> One developer told me they were unable to use details/summary
because of customization issues (specifically animation) and
they had to build one from scratch.
myles: Looking for one more steps in the logical process. People
don't use this element. Is this topic going to solve this
problem?
myles: asking authors not implementors.
una: Talked with client where they could not use because it because
couldn't animate it.
<myles> una: that's very helpful, thank you
dbaron: We don't know if it is sufficient, developers may have more
follow up.
dbaron: At a high level the reason we want to do this is because the
built in <details> element has better a11y and integration
with UA features, and while the platform does provide
features that let developers do those things, developers
probably aren't going to get *all* of them right.
ntim: Not opposed to idea of more flexibility. Argument against
exposing the shadow tree would be future proofing.
ntim: Maybe the UA wants to change its form. We could get stuck.
Focus on individual use cases rather than giving them a
skeleton.
<TabAtkins> I don't think the `open` attribute is what contributes
to the a11y, fwiw. I think it's just the display:none
<gregwhitworth> +1 to TabAtkins
<emilio> Yes
florian: The browser may tell you the wrong thing if you the web
developer changes it.
<myles> to add to what florian said: I was just going to add that
scroll-to-text-fragment is another thing that needs to
continue to work
<castastrophe> I think another way to say what florian has just
stated is that we run into issues when we try to
represent state in CSS-only
<flackr> forcing display: none on an ancestor would prevent
animations out though, right?
masonf: Turns out in practice that it works very nicely while giving
the accessibility guarantees.
<dbaron> I tend to think it's not desirable to make a <details>
appear open or closed in a way that doesn't match its
internal open/closed state. I think if we want the
responsive thing Florian described, we should have a way to
control the default open/closed state from media queries.
<florian> to dbaron, I agree, but I think (if I'm not confused) that
opening up things the way you are proposing would make it
possible for authors to open or close the details element
in a way that doesn't match the open/closed state. Not
that it's good to do it this way, but it would be
possible, and give that there is a need, it probably would
be done.
<gregwhitworth> dbaron did we note share this data in the explainer?
castastrophe: Actionable steps forward. Want to work with HTML group
on state. Need more information on the state in the
DOM.
<myles> +1 to cas
<masonf> more state than is provided by the `[open]` attribute?
<chrishtr> +1 to working with HTML; there is already progress there
via the new `name` attribute
<nicole> In general authors say they won't use elements if they
can't animate show/hide
<flackr> animating the details out is impossible today as the
ancestor forces it to disappear immediately.
emilio: Wanted to clarify when people discuss animating heights of
details content
hober: Look at this use case by use case in details on what to add.
emilio: Sure, I think this discussion has been helpful to figure out
all the use cases people care about. And sure, if we can add
a small feature to the platform to address 80% of the use
cases, sure, but exposing the details parts and removing the
block restriction I think would address most of the users. I
have a slight preference for ::part() but whatever
<gregwhitworth> one thing I want to avoid is doing this ad-hoc; as
we're looking at numerous components at once. So I'd
like to resolve the quagmire holistically rather
than a sprinkle here and there
<masonf> We're mostly talking about shadow DOM here, which doesn't
require JS.
dbaron: Ask Cassondra about addressing the styling in a simpler way.
Want to understand about what was simpler than exposing the
parts.
<ntim> +1 to cas
<castastrophe> A nice example of a web component that altered detail/
summary to a more stylable component:
https://shoelace.style/components/details
dbaron: I think trying to expose a model that could style it without
exposing the pieces would be a lot more complicated than
exposing the pieces
<fantasai> +1 dbaron
<masonf> +1 to what David just said. Exposing the internals might be
the simplest way. The only "downside" is that it uses "Web
Components" tech which is new and different.
<emilio> castastrophe: Yeah the only actionable feedback to avoid
exposing part() is using pseudo-elements
<emilio> FWIW another thing that TabAtkins didn't mention that
::part() gives you is being able to use `::before` /
`::after` etc
<castastrophe> To summarize my point, not arguing one way or the
other per say but I think the ergonomics of
semantically named pseudos will be easier for authors
to use
<castastrophe> Most authors probably have no idea why we would make
::parts available for styling a UA element
<lea> Another +1 to dbaron, albeit somewhat reluctant. I'm
conflicted about UA native elements using WC features to
expose internals, as these are supposed to be author-land
features. On the other hand, authors making WC want them to
behave like native elements as much as possible, so UAs using
these features could even facilitate adoption of them from
both WC authors and WC consumers.
<lea> It also means that problems with these can be solved in one
place (e.g. exposing :hover states etc, which is currently not
possible with ::part() afaik)
<nicole> I'm curious if cas thinks authors would be more comfortable
with pseudos
<castastrophe> Speaking in a totally uninformed manner and
off-the-cuff I'll guess that authors would prefer a
well-named pseudo to a familiar pseudo that is
typically used in a different way
dbaron: In the future present more detailed analysis on the use
cases.
<gregwhitworth> I would love a one-off session on this quagmire
<gregwhitworth> Open UI can dedicate a session to it
<masonf> Web Components features were built to explain UA internal
features. They're designed to be the same as each other.
astearns: Should discuss on a more case by case break.
astearns: No conclusions reached.
Received on Sunday, 10 September 2023 15:33:05 UTC