- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:59:44 -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.
=========================================
CSS Values
----------
- RESOLVED: ch units can cause a font download, no change to spec
(Issue #3135: ch units shouldn't cause font downloads)
Selectors
---------
- In the github discussion for issue #7422 (Add pseudo-classes for
`<select>` being a drop-down box vs a list box) the consensus was
generally in favor of adding a new pseudo-class.
- During the discussion, though, there were questions about the value
of adding a new pseudo-class that web developers will have to
memorize vs that value of this new functionality.
- Discussion will move back to github to draw out what the counter
proposal of adding integer attr selectors would look like so it's
easier to compare.
CSS Anchor Positioning
----------------------
- RESOLVED: ED of Anchor Positioning, editors TabAtkins, iank, jhey
(Issue #7282: Introduce CSS Anchor Positioning)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/32
Present:
Rachel Andrew, Google
Jake Archibald, Google
Adam Argyle, Google
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Google
Bert Bos, W3C
Tantek Çelik, Mozilla
Daniel Clark, Microsoft
Emilio Cobos Álvarez, Mozilla
Yehonatan Daniv, Wix.com
Jon Davis, Apple
Karl Dubost, Apple
Kevin Ellis, Google
Elika Etemad, Invited Expert
Robert Flack, Google
Megan Gardner, Apple
David Grogan, Google
Daniel Holbert, Mozilla
Ian Kilpatrick, Google
Una Kravets, Google
Chris Lilley, W3C
Alison Maher, Microsoft
Cameron McCormick, Apple
Eric Meyer, Igalia
Tess O'Connor, Apple
Olli Pettay, Mozilla
Simon Pieters, Bocoup
Manuel Rego, Igalia
François Remy, Invited Expert
Morgan Reschenberg, Mozilla
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Dominik Röttsches, Google
Peter Rushforth, Natural Resources Canada
Khushal Sagar, Google
Jen Simmons, Apple
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Fuqiao Xue, W3C
Scribe: fantasai
Scribe's scribe: emilio
CSS Values
==========
ch units shouldn't cause font downloads
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3135
astearns: We discussed this issue in NYC
astearns: whether ch units should cause font downloads
astearns: didn't resolve because Myles wasn't there
astearns: but general consensus was that we would leave spec
unchanged, meaning ch units can cause font downloads
myles: Given the author's perspective here, they just want to make
something e.g. 5ch wide, and the specific char isn't super
important
myles: so if your font doesn't have the char, search down the list,
but characters that are used are in the font
myles: in order to be exactly conformant you have to download things
that are unnecessary
myles: They asked for ch, didn't say you have to match zero
myles: just said "make it 5 characters wide" so I think it's the
wrong decision
dbaron: Idk how closely you read minutes from last time, we did talk
through the various possibilities
dbaron: one of the issues was, if the ch unit doesn't trigger a font
download, then you either end up in a situation where ch unit
might change later
dbaron: or that it might be different whether or not downloaded a font
dbaron: other options all have problems, too
dbaron: so leaving as-is seemed like the least bad thing
<florian> +1 to david
<fantasai> +1
astearns: Anyone else?
astearns: To close off, would like to resolve that we are making no
change for this issue.
RESOLVED: ch units can cause a font download, no change to spec
astearns: Any other details discussed not in the spec that we should
add in?
astearns: dbaron, you had a summary
dbaron: I have summarized discussion, leave to editors whether any
non-normative changes needed to clarify
Selectors
=========
Add pseudo-classes for `<select>` being a drop-down box vs a list box
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7422
zcorpan: Proposed pseudo-class for <select> elements
zcorpan: it's implemented in both Gecko and Chromium for their UA
styles, under a vendor prefix
zcorpan: WebKit doesn't implement the pseudo-class, instead uses
attribute selectors
zcorpan: and they have some bugs because of that, because hard to get
the details right
zcorpan: so I think there's agreement in the issue that we should
have this pseudo-class
zcorpan: and just need to settle the naming
<heycam> the WebKit UA style rules:
https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/css/html.css#1078-1092
zcorpan: :select-with-dropdown and :select-no-dropdown
fantasai: I haven't read the issue, was the bug in webkit about
parsing the size attribute as int?
zcorpan: It's parsing the size attribute correctly, the UA style
sheet has an approximation of what the HTML results are
zcorpan: so some edge cases will get wrong UA styles
zcorpan: get a drop-down widget, but UA style thinks it should be a
list box
zcorpan: so a bit of a mismatch
fantasai: Asking because if it's the way the UA parses integers not
being replicate-able in css
fantasai: maybe we want to introduce a way of selecting based on
whether the attr is parsed correctly as an integer
fantasai: that's been requested and more generally useful
zcorpan: I guess it would be possible
zcorpan: complication because HTML has multiple number attributes
zcorpan: It has integers and signed integers and floats
zcorpan: I guess CSS could have those as well
zcorpan: but CSS numbers are normally parsed differently from HTML
numbers
fantasai: We could make it the same or have a flag
zcorpan: Still seems more difficult to use as Web developer compared
to pseudo-class
zcorpan: there's also the multiple attribute
<dbaron> "The display size of a select element is the result of
applying the rules for parsing non-negative integers to the
value of element's size attribute, if it has one and parsing
it is successful. If applying those rules to the attribute's
value is not successful, or if the size attribute is absent,
then the element's display size is 4 if the element's
multiple content attribute is present, and 1 otherwise." is
the relevant quote from
<dbaron> https://html.spec.whatwg.org/multipage/#concept-select-size
emilio: I don't think it's a bad idea, but do we really need 2
pseudo-classes instead of one?
emilio: Would rather have single one, they're mutual exclusive
emilio: assuming it's <select>-specific
emilio: using select:listbox and select:not(listbox) would be nicer
zcorpan: I think that's an okay outcome, biggest difference is you
need to include a type selector to match the :not() state,
whereas with pseudo-classes can only use the pseudo-classes
fantasai: We need to consider that we keep adding pseudo-classes
fantasai: if we don't really need a pseudo-class
fantasai: it's better not to have it
fantasai: so that there's less for people to memorize
zcorpan: Agreed
fantasai: If we can do this with integer parsing and it's not too
tricky maybe that's a better way around it
<TabAtkins> In particular, if this is <select>-specific, then its
name should be pretty <select>-specific, not generic.
Probably means it needs a "select" in the name. But then
it's just awkward to have to specify select again, like
`select:not(:select-with-dropdown)`
heycam: I'm not strongly against adding pseudo-classes, but wondering
if really that useful to expose to authors
heycam: If WebKit wants to fix compat issues, they can have an
internal pseudo-class like other engines
heycam: but for authors, thinking whether they are using listbox or
dropdown, is something they know ahead of time
heycam: I think it's rare for pages to switch between the two, so
don't know how useful it is for authors to have different
styles depending on this
heycam: or need to rely on the flexibility of how HTML parses these
attributes, vs knowing through the DOM already
<fantasai> +1
zcorpan: For cases where dev controls both markup and CSS, but that's
not always the case
zcorpan: maybe you're writing a stylesheet for a design system, want
to apply to all WordPress pages
zcorpan: you don't know what HTML they will use
zcorpan: so that's why pseudo-class makes sense
emilio: Was going to make similar comment to heycam
emilio: We should encourage use of multiple attribute, it's easy to
write selectors for that
emilio: rather than relying on parsing of size attribute
emilio: if you're making design system, ask them to use that
emilio: but I'm on the edge on whether it's worth having a
pseudo-class for this or not
zcorpan: Multiple is a semantic difference
emilio: sorry, yes, you're right
zcorpan: You can have a listbox that's not multiple
fantasai: Doesn't seem to me like the selector for this would be that
difficult if we had number parsing
fantasai: is [multiple] plus size parsing as an integer >1
fantasai: The details of how to parse invalid size attributes is a
concern for implementors but not authors
zcorpan: Type out the two selectors?
fantasai: People usually don't write junk in their size attribute
<TabAtkins> `select[size > 1], select[multiple]`
<emilio> `select:is([multiple], [size]:not([size="1"]))` is probably
close enough in practice today
<fantasai> `select:not([size>1],[multiple])`
dbaron: One, I tend to agree that if you're building a design system,
you probably want these sorts of things
dbaron: I think part of the reason we don't see much demand is that
select is so hard to style, don't run into this problem much
dbaron: if styling select worked more reliably, they would want on
this more
<fremy> +1 to what dbaron just said, styling select is a pain
dbaron: Quoted HTML, which defines the display size of a select
element
dbaron: condition for a combobox vs listbox is display size being
equal to 1 or not
zcorpan: or multiple attribute being present or not
dbaron: There's a few reasons the selectors above are wrong
dbaron: one is that you need to test for size being zero
dbaron: because HTML applies rules for non-negative integers
dbaron: you want a valid size that is zero or 2 or more
dbaron: or the multiple attribute
dbaron: It's doable if you had HTML non-negative integer parsing
dbaron: but might be worth having this pseudo-selector anyway
TabAtkins: fantasai's point was that dealing with invalid things is
the sort of things that UA needs to care about, but page
author doesn't
TabAtkins: if they're putting random trash in their size attribute,
that's their problem
TabAtkins: but HTML UA needs to deal with all kinds of random trash
<heycam> +1 to if we do have a way to do this, would rather a
specific pseudo-class rather than a general integer parsing
selector
dbaron: As you go further down the stack to style sheets meant to
apply to more and more pages, get closer to needing to match
implementation
dbaron: bootstrap might get bugs on this
TabAtkins: Bootstrap can say, "don't write random trash in your size
attribute and this will work correctly"
TabAtkins: if we were stricter in parsing this earlier we wouldn't
have this problem for UAs
TabAtkins: but even widely-used library, nobody needs to deal with
this much trash
TabAtkins: put a number here, and it works. Put a non-number here and
it'll not work
fremy: Authors shouldn't have to read the spec to figure out the
conditions
fremy: of course they can copy some weird code, but not very
understandable
fremy: you will copy and paste it, but not clear what it does at
first sight
fremy: if already implemented in engines, have this pseudo-class
fremy: that sounds useful so why not
fremy: Why are we wasting time discussing if it's just removing a
prefix in the code, seems silly
<emilio> FWIW this is how Gecko used to implement this with attribute
selectors:
https://hg.mozilla.org/mozilla-central/rev/13062d9979d254481851c0f8c9d9e608d91f6ae3
astearns: We started with what we called a pseudo-class, and now
discussing maybe not having pseudo-class
astearns: With arguments presented so far, anyone convinced we should
have it?
heycam: Me
astearns: Should we try to resolve to add pseudo-class?
fantasai: I'd like to hear from Rachel Andrew and emeyer
fantasai: if they are like, "Yes, we should definitely have this!"
then great
fantasai: If not, I'm skeptical
<rego> there has been a lot of research about styling select in
openUI, does anyone know if this topic was discussed?
emeyer: It's hard for me to say, a pseudo-class mostly feels correct
here, but fantasai is correct, we have so many pseudo-classes
now
emeyer: even more than I realized until recently
emeyer: So I'm not sure I'm 100% convinced that it's best
emeyer: Some way of doing this is good
emeyer: but whether it should be a pseudo-class or ???
fantasai: We would add number-based attribute selectors, and you
would make a selector
astearns: It would be a copy-paste incantation
fantasai: Still have to do that if it's a pseudo-class!
<emilio> Another interesting edge case is `size=""`
<heycam> emilio, similar but not exactly the same as the current
WebKit UA style rule selectors
<heycam> emilio, yes that is exactly the difference
TabAtkins: Who is asking for this? In the UA is one thing, but do
other people need it?
zcorpan: Reset stylesheets use it
zcorpan: incorrectly, usually
fantasai: They are copy-pasted, so they can write a proper selector
zcorpan: But used in lots of pages, should get all the cases correct
<fremy> https://github.com/sansotmon/asistencia-salvarte/blob/50dde64556294e8e42dbb2f7950f1b9c078ebef7/web/core/themes/olivero/css/components/form-select.css
<fremy> ```[dir="ltr"] select[multiple] { padding-left: 9px }```
<fremy> ^ this is wrong, first hit on github
<TabAtkins> Are they getting bugs and ignoring them because parsing
numbers via CSS is hard? Or are they just not getting
bugs?
<TabAtkins> Importantly - if they're not getting it right, *is this
causing problems for people*?
emilio: Empty size attribute is another case
emilio: also slightly more efficient to do a pseudo-class
emilio: pre-parses faster than other random attributes
emilio: If people feel this is useful, then maybe it's not worth
copy-pasting a weird incantation
rachelandrew: I think in terms of being easier to explain and less
error-prone, pseudo-class is good
rachelandrew: but do people actually want to do this, is also a valid
concern
rachelandrew: if people aren't asking for it
rachelandrew: I like things to be straightforward
rachelandrew: but we also have a lot of pseudo-classes, and have to
teach people
rachelandrew: so I don't have a strong feeling, but like emeyer I'm
on the fence
astearns: Then what I want to do is to close off the discussion in
this meeting, take back to issue, have whatever the actual
correct integer and multiple check would be
astearns: so we have something to compare
astearns: and come back to this issue on a telecon
zcorpan: OK
astearns: Any other questions on this?
fantasai: Do we want to add integer attr selectors?
fantasai: generally speaking, do we want a proposal for that?
astearns: I don't think we can decide that right now
<fremy> select[multiple], select[size] { height: auto; }
<fremy> in bootstrap
CSS Anchor Positioning
======================
github: https://github.com/w3c/csswg-drafts/issues/7282
slides: https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0009/TPAC_2022_-_CSS_Anchoring.pdf
TabAtkins: Presented early idea in May
TabAtkins: continued working on it
TabAtkins: Jhey has prepared a slide deck intro with details
<xfq> https://jhey-presents.netlify.app/tpac-2022/
-> https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0009/TPAC_2022_-_CSS_Anchoring.pdf
jhey: CSS needs you! So want input on shaping where this goes
jhey: Anchoring on the Web is a common pattern, very tricky, and
headache for developers
jhey: when do I do it, how do I do it?
jhey: How to calculate the position, can I do it in an attribute
jhey: it's used for tooltips, menus, things driven by interaction
jhey: but the most common pattern is pop-ups, things that need to get
into the top layer
jhey: Thinking of a tooltip, we have a containing viewport, and then
we have the anchor thing like a tooltip, and then the anchor
which is a button or something
jhey: and then have the arrow visually connecting the two
jhey: There are workarounds using abspos, requiring a special DOM
structure involving wrappers and relpos
jhey: potential invalid HTML to put things inside other things
jhey: it's hard to scale or respond to viewport changes
jhey: might go with an example like this (shows code example)
jhey: you could go different route without a wrapper, then need to
work out positions
jhey: but it's hard to maintain
jhey: Could use JS, but then need boilerplate, and styles are leaking
into scriptland
jhey: then what info do you need, how to calculate offsets, etc.
jhey: (shows code example)
jhey: All of those solutions look the same
jhey: user sees it looks great, but dev experience is not great
jhey: done right this could be much better for a11y etc also
jhey: There's issues!
jhey: when something goes out of the viewport, if things change, how
do we change? what about scrolling?
jhey: Lots of edge cases
jhey: Someone solved it?
jhey: there was one called tether.js, another popper.js
jhey: interactions are handled by JS, very config-heavy
jhey: lots of things to decide on, and another dependency to maintain
jhey: it gets the job done, but devs don't typically like adding
extra JS files
jhey: Another is Floating UI, less download, but is it better to use,
still extra dependency, which to use?
jhey: How about we keep the styles in the styles and use a new
anchoring API?
jhey: we have container, viewport, tooltip
jhey: think about viewport like ocean, anchor is anchor , and chained
to the tooltip boat
jhey: here the browser is working out where to put it. Not enough
room for the boat here? shift it down
jhey: no dependencies, no wrappers
jhey: We're experimenting and learning, I've got some demos here
jhey: Basic anchor, this is how it looks
jhey: no DOM structure required, can live anywhere
jhey: here I've got two boats tethered to the same anchor
jhey: I have an anchor name, tether to it
jhey: passing anchor name and use whichever position I want
jhey: I'm using calc here, can use inside calc
jhey: and then anchor-side will get the width/height of anchor
jhey: browser will work out the offsets as I move things around
[What's happening slide]
jhey: Containment works as usual, browser handles offsets for us
jhey: different fallback positions
jhey: if boat can't fit in the ocean here, then move it somewhere else
jhey: UA does it for me
jhey: use position-fallback to attach to fallback list of positions
jhey: can change containment, is contained by viewport or something
lower in the tree
jhey: can clip x axis or y axis
jhey: or both
jhey: same demo again where constrained by scroller instead of
allowed to leak
jhey: Things needed are things like popups
jhey: being able to anchor things in the top layer
jhey: you can do this currently with JS solutions, but they do hit
some limits with regard to resizing
jhey: Another is <selectmenu>
jhey: Where this gets really cool, you can do some interesting things
jhey: we have a chart, can use anchor positions in calc() I can
tether a tooltip to the chart
jhey: and attach the min and maximum, and it'll work it out for me
jhey: you can use more than one anchor in your positioning
jhey: or anchor to highest bar or lowest bar
jhey: can also do nested menus, holy grail of anchoring
jhey: just anchor to something inside, and works well, menus squishes
as viewport gets narrower
jhey: A few open questions
jhey: how to detect which side to put your arrow?
jhey: how do we scope things like position-fallback
emilio: I had a question, seen a lot of ways of when viewport
resizes, most of the fallback is clipping or shrinking
emilio: how easily can you do sliding fallback instead?
emilio: when container goes out of view
emilio: Thinking about how some native platforms and even Gecko's
popups specify after position, and the way we do it, you have
an anchor node and you specify the side of the anchor and the
side of the popup you want to align
emilio: e.g. top left top left, would put your item on the bottom by
default
emilio: would give you various ways to figure out the final position
if you don't fit
emilio: It's not be so powerful with offsets, like the fancy chart
anchoring was pretty cool and not sure to what extent could do
emilio: but for anchoring to single thing, seems much easier to
reason about vs doing all the math and fallbacks yourself
emilio: Have you thought about that kind of API, you can specify
where the popup goes relative to anchor?
emilio: we allow customization with margins
emilio: so we use the top/left margin to shift in the direction
you're anchored
emilio: so was wondering what kind of exploration you've done of this
kind of space and other ways in platform
emilio: what Gecko does is very similar to what ??? does
emilio: I don't think Windows has a native thing
iank: We did do a more limited version of this, anchor to a single
version
iank: similar to what you're describing
iank: We found though that yes, it covers the 60-70% case, but you
start to lose out on some of the slightly more advanced cases
iank: and there are cases, multiple anchoring thing, is quite useful
for a number of use cases
iank: [missed example]
TabAtkins: You might want to use min/max zero or 100%
TabAtkins: or fallback 0 or 100%
TabAtkins: so you're anchored to the side until anchor goes off the
screen
TabAtkins: Right now here with the pop up terms, it's pretty awkward
right now
TabAtkins: Maybe these cases are simple enough to use syntax like you
suggested
TabAtkins: but this should be a reasonable case, and not require
hundreds of @position-fallback rules, because that's bad
[shows content out demo]
emilio: In your example where the container shrinks, the positioned
elements flips from below to on top of anchor
emilio: but in one example gets clipped instead of remaining in
viewport
emilio: inside a container instead of viewport
emilio: if you keep shrinking, it could be kept inside, but then leaks
emilio: by default, authors won't test all combinations, and things
will be offscreen in some cases
emilio: so more declarative could allow UA could make sure that the
positioning is on-screen
iank: Any time that we tried to go, "ok, we want this behavior",
there's a use case for opposite behavior
iank: some cases do actually want it fixed
iank: Hear your concern, but there's a plethora of use cases and all
of them want something slightly different
iank: similar argument could be made for testing all possible screen
sizes, and yeah you need to test
heycam: Thanks for presentation, a few questions
heycam: the pop-up thing, does that always move to the top layer or
not required?
TabAtkins: Not required
TabAtkins: if using popup API, moves to top layer
TabAtkins: but otherwise treated as abspos
iank: The containing block, you can only reference anchors within
that containing block
iank: So useful for components
iank: so go to the scrolling example, here the containing block is
inside the scroller so it stays inside
heycam: One question is what happens when there are transforms
between anchored thing and anchored
iank: Similar rules, scrolling is complicated and want to talk about
that separately
iank: but for transforms use staticpos propagation rules, basically
assume no transforms
heycam: No transforms?
emilio: Transforms make a containing block for fixed descendants
iank: Thing that breaks is if you're transforming the anchor, that
does break
iank: there's a tradeoff here in that this is fundamentally a layout
effect
iank: so animating a transform, don't want to slow it down
iank: there is an option to incorporate transform
heycam: What about shadow tree and visibility of names?
heycam: Is this another example of issues around exposing names to
shadow trees?
TabAtkins: Yes
TabAtkins: Using anchor name itself isn't problematic, because it's a
tree search
TabAtkins: but for the fallback rule and its name, that has the same
problems we have in other rules like @keyframes
<Bert> (For the historians: Around 1997, Håkon and I discussed floats
with anchors and ‘elastic bands’, to try and keep floats near
their anchors or near each other, depending on the strength of
the ‘elastic’. Among the goals were sidenotes and parallel
texts, such as a text and its translation. The difficulty for
the author to know whether to write "see on the left" or "see
on the right" was one reason we decided to postpone that
feature.)
emeyer: Seems like a lot of the examples use a lot of calc'ing,
emeyer: I wonder if anchor-side keywords in the draft, are those
supposed to be ands, can they be ors?
emeyer: so you could say something like center left?
<florian> +1 to emeyer
iank: A lot of these use left/right, and haven't implemented center
iank: so many could be replaced with left center
emeyer: So popup in the middle, wouldn't need calc?
jhey: Could use percentages
emeyer: So for simple things might not need calc()
emeyer: My other question is, am I understanding that a popup can be
placed in relation to multiple anchors?
TabAtkins: Yes
emeyer: So text with footnote reference in the middle, could have the
footnote could be vertically center-aligned but have its edge
against the column of text
TabAtkins: Yes
emeyer: ok!
jhey: [missed]
astearns: So little over time
TabAtkins: I'd like to request resolution
TabAtkins: last time was to have a UD, haven't done that yet
TabAtkins: but it seems like to become an ED at this point
TabAtkins: so would like to request an ED of this draft
astearns: Any objections?
[none]
[discussion of editors]
RESOLVED: ED of Anchor Positioning, editors TabAtkins, iank, jhey
astearns: Please make ED asap so we can file issueS!
iank: I'm free to chat during break
<br duration=25min>
Received on Tuesday, 25 October 2022 23:00:27 UTC