- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 27 Jun 2024 19:20:51 -0400
- To: www-style@w3.org, public-open-ui@w3.org, pastithas@google.com
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
OpenUI-WHATWG/HTML-CSSWG meeting
================================
CSS UI
------
- RESOLVED: <select> internals can be represented with shadow DOM
(but shadow DOM support is not required as long as the
behavior is the same) (CSS Issue #10380: DOM/Box
structure for appearance:base-select)
- RESOLVED: Accept shadow dom structure as proposed initial comment
in the issue, except for the svg part and naming of
pseudo elements. Issues to be opened for those (CSS Issue
#10380)
- RESOLVED: User agent styles can depend on appearance:base. Aim for
eventual interoperability across all values of the
property (CSS Issue #10028: Changing UA styles based on
the computed value of the appearance property)
Anchor Positioning
------------------
- RESOLVED: popovertarget creates an implicit anchor element
reference (WHATWG PR #9144: Add anchor attribute)
- RESOLVED: Develop HTML markup to represent semantic anchoring
relationships (and which also set the implicit anchor
element) for non-popover use cases (WHATWG PR #9144)
- RESOLVED: It would be a good idea to add an imperative way to set
invoker relationships between popovers (WHATWG PR #9144)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10401#issuecomment-2187251320
Present:
Joey Arhar
David Baron
Tantek Çelik
Keith Cirkel
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Mason Freed
Chris Harrelson
Brian Kardell
Aditya Keerthi
Sanket Joshi
Olli Pettay
Anne van Kesteren
Luke Warlow
Greg Whitworth
Chair: gregwhitworth
Scribe: emilio
Scribe's scribe: gregwhitworth
OpenUI-WHATWG/HTML-CSSWG meeting
++++++++++++++++++++++++++++++++
CSS UI
======
DOM/Box structure for appearance:base-select
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10380
chrishtr: We can mark as needs edit and once that's done that'd get
review and get closed
annevk: Sounds good
<dbaron> (above was about the previous item on the agenda)
jarhar: That's a proposal for base-select behavior and DOM structure
jarhar: higher level questions would be whether it'd be ok to use
shadow dom for this
jarhar: the other thing would be that in chromium elements inside the
shadow root for the base and auto appearance
jarhar: and switch based on the computed value
jarhar: wonder if that's acceptable
annevk: I think shadow roots are fine for this, we have the precedent
of <details>
annevk: in theory an implementation could not use shadow root
<fantasai> +1 to avoiding a true dependency on the shadow DOM
jarhar: That sounds promising
jarhar: it sounds like we can define this as a shadow root
masonf: Are we doing resolutions?
<fantasai> PROPOSED: <select> internals can be represented with
shadow DOM
<masonf> +1
<dandclark> +1
<keithamus> present+
emilio: I wanted to clarify fantasai point, I think she's fine
defining in terms of shadow DOM but in theory you can
implement it with something else
fantasai: Yeah, that's exactly right we should define it using shadow
but it's ok if the implementation does not use shadow DOM
emilio: Sounds good
chrishtr: They need to end up with the same interoperable result
chrishtr: It's not observable that there's a shadow root right?
jarhar: I think that's correct
chrishtr: We can put a non-normative note in the spec about it being
possibly implemented with other technology
<fantasai> PROPOSED: <select> internals can be represented with
shadow DOM (but shadow DOM support is not required as long
as the behavior is the same)
gregwhitworth: so fine to go with Elika's resolution?
<masonf> +1
<keithamus> +1
RESOLVED: <select> internals can be represented with shadow DOM (but
shadow DOM support is not required as long as the behavior
is the same)
jarhar: I want to also go through the slots and so on
gregwhitworth: Should we resolve that in this issue or move that to a
different one?
annevk: The one concern from our side is about the `multiple`
attribute
annevk: without that we can agree to this
annevk: but with `multiple` one of the slots ends up not being there
or rendered
jarhar: We can change the shadow DOM for the `multiple` attribute
jarhar: so that there's a shadow DOM but can be completely different
fantasai: Currently in HTML we combine two things, if you can select
one it's a popup and otherwise it's an embedded control
fantasai: I think we can split that into multiple axes
fantasai: so that we can make a popup where you can select multiple
attributes, and you can have an embedded thing where you
can select just one
<masonf> that's the multiple and size attributes, respectively.
<annevk> (modulo iOS where it's a little different from that even)
<lwarlow> (and android)
chrishtr: All those things can be figured out but can we leave those
not defined yet?
chrishtr: and define just the non-multiple case for now?
fantasai: I think we might need to come back and change things once
we tackle the others
chrishtr: We can take an action item to dig into that to make sure
that changes might not be needed
masonf: There's `multiple` and `size` which theoretically create
those two axes
masonf: behavior is a bit different in mobile vs. not, I think there
are a lot of issues with `multiple` without that
masonf: so I think we need feature detection but I'd like not to
block on that
fantasai: I think that'd be surprising, I'd like multiple to be
defined for styleable select
fantasai: I think you can't just ignore the semantics of `multiple`
masonf: I was thinking of just forcing `auto` rather than ignoring
`multiple`
fantasai: I think I worry about site issues once we start making
changes there, I think it's solvable and we should fix it
chrishtr: Agree on solvable, I don't think it blocks resolving on
jarhar's proposal for the single case
fantasai: I think the structure makes sense except the svg
fantasai: because it doesn't respect writing-mode
fantasai: In respect on the names of pseudos we want to be consistent
with other stuff we expect to do elsewhere, so probably
should discuss separately
fantasai: but over-all structure makes sense otherwise
<chrishtr> proposed: "accept shadow dom structure as proposed initial
comment in the issue, except for svg part"
<chrishtr> "pseudo element names to be decided later"
jarhar: For pseudo names I agree they're not great
jarhar: There's another issue for that
jarhar: As for the SVG I agree, there's a similar discussion for
checkmarks
jarhar: We moved to a unicode character
jarhar: there's a down arrow thing
jarhar: Do you think using it would be reasonable
fantasai: If you use the disclosure-open counter style then it takes
care of those issues
chrishtr: Suggestion is to make some forward progress on this. We can
discuss checkmarks / svg / names later
gregwhitworth: I agree, follow-up issues for glyph and
pseudo-elements makes sense
<chrishtr> "accept shadow dom structure as proposed initial comment
in the issue, except for svg part and naming of pseudo
elements. issues to be opened for those"
fantasai: Should probably be one issue for the pseudos and such, we
should decide them together
<jarhar> I already created an issue for pseudo elements here:
https://github.com/w3c/csswg-drafts/issues/10462
<masonf> +1
<chrishtr> "accept shadow dom structure as proposed in the initial
comment in the issue, except for svg part and naming of
pseudo elements. issues to be opened for those"
fantasai: Inside the button one of the elements is a `<span>` and
another a `<div>`, why?
RESOLVED: Accept shadow dom structure as proposed initial comment in
the issue, except for the svg part and naming of pseudo
elements. Issues to be opened for those
Anchor Positioning
==================
Add anchor attribute #9144
--------------------------
github: https://github.com/whatwg/html/pull/9144
masonf: It's related to anchor position and popover more than select
masonf: Proposal is to add an `anchor` attribute which does a few
thing
masonf: One is that it adds an element as implicit anchor
masonf: when you're doing that with popovers is also affect the
nesting rules so that when you anchor a popover to another
popover the outer doesn't close
masonf: The other one is about accessibility, and is that it'd be
good to have an HTML link to control focus fixup and
accessibility
masonf: There's been some pushback
fantasai: First question is why can't popover not create an implicit
anchor relationship?
masonf: How would it be automatic?
fantasai: Doesn't it know the relationship between the button and the
popover?
masonf: If you use invokers for it then yes
masonf: but if there's no button in the first popover or you open it
via JS then that would be the attribute
annevk: Those use cases wouldn't be using the declarative markup
correctly right? Shouldn't this be an API feature?
masonf: Like, connecting the elements on the JS call, via an
argument? That's already a proposal
masonf: If the proposal is to make the declarative popovertarget
connection and also a new setting in the JS API to make this
connection then that might meet the usecase?
<fantasai> https://github.com/whatwg/html/pull/9144#issuecomment-2189481315
lwarlow: Is there a use case for non-popover anchored things? If so
then that wouldn't work right?
lwarlow: worth keeping in mind
fantasai: For things that are not popovers we need to do something
fantasai: but there are three use cases for anchored:
semantic+presentationally anchored, presentation-only (like
the 'new' example I linked above), and semantic only (like
a footnote that pops up at the bottom of the screen, it's
not visually anchored to its anchor)
fantasai: so HTML needs an anchoring markup but it's not going to be
only about anchor positioning in the CSS
fantasai: if we add something to HTML we need to make it about the
semantics
fantasai: as proposed right now it's just presentational
fantasai: This proposal doesn't go far enough to provide what HTML
actually needs in terms of anchoring semantics
masonf: What would you propose to be added
masonf: a multi-valued anchor or somesuch?
fantasai: There's a11y and aria bindings, there's focus and tabbing
order (there are use cases for before and after), and the
other one is whether it's easy enough that they'll reach
for that and not just use CSS to get the right position
fantasai: The other thing is does this have an appropriate
description that we can point authors to?
masonf: I think a few things belong to aam and so but others would
belong to HTML
gregwhitworth: Would the explicit JS API allow to solve some of these
use cases?
masonf: There are a few things... would allow an explicit invoker
relationship, but we should also connect that to anchor
positioning as an implicit anchor
masonf: would be interesting to resolve to look into that direction
fantasai: I'd say to add markup to represent anchoring relationships
(i.e. not specific to anchor positioning)
<tantek> +1 fantasai markup for indicating anchoring relationships
annevk: Do we know what the a11y mapping would be or so?
annevk: seems too vague
chrishtr: The idea is to agree something is needed
annevk: The way I interpreted fantasai is "this what I'd expect of a
semantic attribute", not exactly what that might look like
fantasai: I agree, but "something is needed" is true
<tantek> FYI, per fantasai's list of use-cases for anchoring /
anchoring relationships / anchoring presentation and
combinations thereof, here is an example of semantic
anchoring without presentational anchoring, the footnote
link (and backlink) here:
https://tantek.com/2024/131/t1/mozilla-origin-trials
emilio: If we resolve on the invoker stuff to setup the anchor
relationship then doesn't that mean
emilio: don't we want that to work with non-popovers and we can
explore that
emilio: the other thing is whether we do an explicit JS API or some
other thing?
masonf: Yes, invoker relationships creates one of those and some
attribute or set of attributes will create an implicit anchor
relationship
emilio: That's a bit confusing to me
masonf: There is also the invoker/command attribute that will do this
for other things
chrishtr: If we could find a way for one thing to do both; then the
better
annevk: By invoker you mean popovertarget?
masonf: I mean command/commandfor
annevk: But we should do it for popovertarget too right?
masonf: Yeah
<masonf> Proposed: popovertarget creates an implicit anchor element
reference.
<lwarlow> +1
<keithamus> +1
RESOLVED: popovertarget creates an implicit anchor element reference
<fantasai> PROPOSED: Develop HTML markup to represent semantic
anchoring relationships (and which also set the implicit
anchor element) to address non-popover use cases
<tantek> +1
<lwarlow> +2
<masonf> +3
<keithamus> +4
<tantek> +1 emilio, including non-popover use-cases
<gregwhitworth> PROPOSED: Develop HTML markup to represent semantic
anchoring relationships (and which also set the
implicit anchor element) for popover or non-popover
use cases.
<tantek> +1
<masonf> thank you
<keithamus> +1
fantasai: I'd expect popover to work automatically as much as possible
masonf: I think the point is that even if it's a popover it'd work
annevk: I think we're too early in the process, doesn't really matter
at this point
lwarlow: Should we resolve on the imperative showPopover?
RESOLVED: Develop HTML markup to represent semantic anchoring
relationships (and which also set the implicit anchor
element) for non-popover use cases.
chrishtr: We should check on the API
chrishtr: Does anyone have concerns about the imperative API to
establish that link?
lwarlow: I think it'd be necessary to solve the web components use
case where you can't use the declarative API
<masonf> Proposed: it would be a good idea to add an imperative way
to set invoker relationships between popovers.
<lwarlow> +1
<keithamus> +1
RESOLVED: It would be a good idea to add an imperative way to set
invoker relationships between popovers.
CSS UI Con't
============
Changing UA styles based on the computed value of the appearance
property
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10028
jarhar: For appearance: base one of the things is that chrome and
webkit have different border property and we want to make
this interoperable
jarhar: For html-based solution this was not a problem
jarhar: so I thought it'd be not possible to solve, but lilles
suggested something like light-dark
jarhar: That took multiple values, one for auto/none and one for base
jarhar: I implemented it for border and so on
jarhar: not sure if you need details
<chrishtr> +1
emilio: This seems fine, it makes me sad that we can't get
interoperable UA stylesheets
emilio: Now we can not use regular CSS to represent the HTML styles
is unfortunate
emilio: Either we define this entirely and we can use this from HTML
then we have to say "if appearance is base" you need to do
this
emilio: It makes me a bit sad that it would spec fiction but maybe
it's fine
emilio: I think we should look into interoperable UA stylesheet.
Appearance: none is not interoperable at this point
<tantek> +1 emilio, it is surprising that appearance:none is not
interoperable across engines
masonf: First I think this doesn't mean that we shouldn't work on
making appearance: none interoperable, but decouples it
masonf: so that we don't have to worry about that for now
masonf: The other thing is that maybe there should be an
author-visible way to do this
<chrishtr> PROPOSED: user agent styles can depend on appearance:base
jarhar: I agree we can work on make appearance: none more interop,
but decoupling them is easier
jarhar: re author visibility, I had to implement it for each prop, so
I'm reluctant to do that
emilio: Can we resolve on the issue with the goal of making things
interoperable and this function would go away
emilio: once we make appearance: none consistent this would go away
<chrishtr> PROPOSED: user agent styles can depend on appearance:base.
Aim for eventual interoperability across all values of the
property.
<tantek> +1 emilio
jarhar: sounds good to me
<masonf> +1
<dandclark> +1
<emilio> +1
RESOLVED: user agent styles can depend on appearance:base. Aim for
eventual interoperability across all values of the property
Received on Thursday, 27 June 2024 23:21:28 UTC