- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Oct 2022 19:30: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.
=========================================
Meeting Schedule
----------------
- There will be an extended meeting on Wed Oct 26, 2022 from 7:00am –
10:00am PT
CSS Text
--------
- RESOLVED: Incorporate trim-end behavior into the normal keyword
(Issue #7055: text-spacing: trim-end is better than
allow-end for the normal value)
CSS Ruby
--------
- RESOLVED: Add text-justify:ruby, which is like 'auto' but disables
justification opportunity on spaces and bopomofo (Issue
#771: Treatment of multiple Latin words in space-between
& space-around)
- RESOLVED: `rt, rtc { text-justify: ruby; }` to UA stylesheet (Issue
#771)
Selectors
---------
- RESOLVED: `lang=und` matches :lang("*")`, `lang=""` doesn't match
any `:lang()` (Issue #6915: `:lang` for documents without
content language and for elements of unknown language;
consider `:lang("")` over `:not(:lang("*"))`)
- RESOLVED: Accept :open and :closed with definitions as proposed by
TabAtkins (Issue #7319: Add `:open` or `:top-layer`
pseudo class)
- Proposed definitions:
The :open pseudo-class represents an element that has both
"open" and "closed" states, and which is currently in the
"open" state. Exactly what "open" and "closed" mean is
host-language specific, but exemplified by elements such as
HTML's <details>, <select>, and <dialog> elements, all of
which can be toggled "open" to display more content (or any
content at all, in the case of <dialog>).
Note: Being "open" is a semantic state. An element not
currently being displayed (for example, if it is in a
display: none container) can still be "open" and will match
:open.
CSS Values
----------
- The proposal for issue #7431 (Restrict none/auto/normal from
<custom-ident>) was to restrict none/auto/normal from
<custom-ident> however, after conversation, there is a desire to
revisit in context of the overall <custom-ident> grammar to
ensure this doesn't make other naming issues worst.
Nesting & Selectors
-------------------
- RESOLVED: Accept to make & valid everywhere, maps to :scope where
not otherwise defined (Issue #7545: Move nest-containing
and nest-prefixed selector definitions to Selectors)
CSS Tables
----------
- The group is going to think more about the possible use cases
around issue #7340 (Allow 'order' on table columns) and decide
next week if this is something they want to pursue further.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Oct/0003.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Elika Etemad
Robert Flack
Mason Freed
Megan Gardner
Paul Grenier
Daniel Holbert
Brad Kemper
Jonathan Kew
Vladimir Levin
Peter Linss
Alison Maher
François Remy
Morgan Reschenberg
Florian Rivoal
Regrets:
Chris Harrelson
Miriam Suzanne
Lea Verou
Chair: Rossen
Scribe: TabAtkins
Next vF2F/Extended Call
=======================
<Rossen> Wed Oct 26, 2022 from 7:00am – 10:00am PST
CSS Text
========
text-spacing: trim-end is better than allow-end for the normal value
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7055
fantasai: About text-spacing
fantasai: One of its functions is to handle the blank half of CJK
punctuation
fantasai: A couple of values of how to handle it at start or end of
the line, trim or not
fantasai: Proposal from murakami-san is incorporate the trim-end
behavior into the 'normal' value
fantasai: review from i18n is to recommend adopting this
<fantasai> https://www.w3.org/TR/css-text-4/#text-spacing-property
Rossen: Objections?
[none]
RESOLVED: Incorporate trim-end behavior into the normal keyword
Selectors
=========
`:lang` for documents without content language and for elements of
unknown language; consider `:lang("")` over `:not(:lang("*"))`
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6915#issuecomment-1247024928
fantasai: When a lang is unknown, there's two ways to make it unknown
fantasai: first is blank `lang` value
fantasai: second is `lang=und`
fantasai: So how do you match these elements?
fantasai: Proposal is `:lang("")` matches untagged (blank tag), and
add a note that `"und"` and `""` are matched differently
despite similar semantics
fantasai: And then `:lang("*")` will match any tagged element,
including `lang=und` (but won't match untagged/empty string)
TabAtkins: Sorry, hadn't read the discussion, but what's the
justification for treating empty string differently from
und?
Rossen: I'm not sure about treating them differently
<PaulG> which spec does "und" value come from?
<fantasai> Probably BCP47
Rossen: Is it in selectors, or text...?
fantasai: und is in the lang tag spec
PaulG: rfc 5646 doesn't have it, it's not in the IDN reg
Rossen: Perhaps we should delay a week for florian to be able to
weigh in
<dbaron> und looks like it's for undetermined
CSS Ruby
========
Treatment of multiple Latin words in space-between & space-around
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/771#issuecomment-1182339573
<fantasai> https://github.com/w3c/csswg-drafts/issues/779
fantasai: Ruby text, when you put it on base text, it has different
default alignment. Latin text and bopomofo is centered, but
cjk ruby, if the annotation is smaller than base, it'll be
justified
fantasai: Straightforward way to handle this is to say that ruby
annotations are justified by default, and to adjust the
justification opportunities
fantasai: In normal text we allow spaces to stretch, and
inter-character for CJK
fantasai: So if we create a justification method where spaces don't
expand, but CJK still does, we'll get the intended behavior
fantasai: And then people who want a different behavior can use
text-justify: inter-word or inter-character if they want it
fantasai: So proposal is to create this new justification mode
fantasai: One, we could say text-justify:auto on ruby annotation has
special behavior,
fantasai: Two, we could introduce a new text-justify:ruby keyword,
and use that in the UA stylesheet
fantasai: Probably introducing a new keyword is a little more
straightforward for impls
<TabAtkins> Sounds reasonable to me, but I'm not a text implementors.
Also lean slightly toward new keyword.
florian: I agree
Rossen: Can we have a res with a path forward, not open options?
fantasai: Yes, one or the other
Rossen: So proposal to add new text-justify mode as a keyword
fantasai: Yes, add text-justify:ruby. It disables justification
opportunities on spaces and bopomofo, but otherwise is like
'auto'
RESOLVED: Add text-justify:ruby, which is like 'auto' but disables
justification opportunity on spaces and bopomofo.
fantasai: Also need a resolution to apply it to rt and rtc in UA
stylesheet
Rossen: Objections?
RESOLVED: `rt, rtc { text-justify: ruby; }` to UA stylesheet
Selectors
=========
`:lang` for documents without content language and for elements of
unknown language; consider `:lang("")` over `:not(:lang("*"))`
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6915#issuecomment-1247024928
<fantasai> dbaron dropped a link to the "und" definition in
https://www.rfc-editor.org/rfc/rfc5646.html#page-56
Rossen: So question was inconsistency between empty string and und
both being "undefined", but they match differently
florian: Empty string is defined to mean "undefined" by HTML. "und"
is defined as "undefined by ISO [something]
florian: Possibly HTML shouldn't have introduced another value to
mean the same thing
florian: but it did
florian: i18n group was somewhat struggling with whether to unify it
or not
florian: Could be pushed back, but logic was that HTML didn't unify
them, and when we do the string matching of lang selectors
we do string matching without worrying about the semantics
florian: So our :lang() just does standard lang string parsing +
matching
florian: So logic was probably "just keep it simple"
florian: In practice HTML semantics somewhat combine both "explicitly
undetermined" and "author couldn't be bothered to specify".
florian: but generally, this is a space where we don't control the
semantics
florian: But I don't think i18n was firm on the conclusion, so if we
want to push back it could be heard
TabAtkins: That does answer the question
TabAtkins: I think I'd be happier if we push back
TabAtkins: but having this distinction from HTML be reflected in our
Selectors should be avoided if possible
florian: I think what happened in practice is the observation is that
"und" wasn't really used on the web, so empty string is how
it was actually done in HTML
florian: So effectively we can ignore the "und" value and have
:lang("*") match everything *but* the empty string.
florian: And so while technically "und" matches the lang, in practice
undefined langs don't match it
fantasai: Yeah, "*" matches "und", but we've had a request for "can I
match things without a language", and we'd be able to do
that if we make a distinction in this manner
<TabAtkins> My position is very weak, I defer to whoever has expertise
jfkthame: I think this is a distinction we should maintain, seems
there is a semantic difference between lang being undefined/
untagged and explicitly tagged as undetermined
jfkthame: I agree "und" is rarely used but it does seem semantically
meaningful
TabAtkins: If we accept to keep distinct, we don't need to push back.
Since several people think it's good to keep separate, I'm
ok with that
florian: The group that came up with the original rec was just weakly
leaning - I think they got it right, but still
PaulG: Agree with keeping them separate. I suspect coalescing would
encourage more "und", where default lang choice is used when
undefined, but I think it shouldn't when it's explicitly
"undetermined"
<TabAtkins> Sounds good to me
<TabAtkins> (I appreciate the "undefined" vs "undetermined"
distinction. Was just objecting to two separate
"undefined" notions.)
Rossen: Objections?
RESOLVED: `lang=und` matches :lang("*")`, `lang=""` doesn't match any
`:lang()`
CSS Values
==========
scribe: fantasai
Restrict none/auto/normal from <custom-ident>
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1178237576
TabAtkins: In the definition for <custom-ident> in Values and Units
TabAtkins: can be any keyword, except CSS-wide keywords
TabAtkins: can't name an animation "initial"
TabAtkins: any other keywords that need to be excluded for
grammatical ambiguity reasons, you need to specify that
explicitly
TabAtkins: However, there's a handful of keywords that are used so
often in properties, and seem so not-very-useful for
naming things
TabAtkins: that it might make sense to restrict them as well
TabAtkins: specifically: auto, none, normal
TabAtkins: these are used in a lot of properties, and are not good
names for animations/counter-styles/etc.
TabAtkins: First question is, are sites using these?
TabAtkins: dbaron did an initial analysis, and while they are used in
a few places
TabAtkins: they appear to be invalid in those places anywhere
TabAtkins: e.g. 'none' as a line name in Grid, but no 'none' line
TabAtkins: so makes sense to treat as invalid anyway
TabAtkins: I believe compat impact will be minimal to none
TabAtkins: all uses we saw were already invalid
TabAtkins: and this should make custom idents safer to use in
general, without us having to remember to explicitly cut
out these common keywords
TabAtkins: so that's the proposal -- restrict none/auto/normal from
<custom-ident>
plinss: If using 'none' as a line name now, would that invalidate the
line name or the whole declaration
TabAtkins: invalidate the whole declaration
plinss: That's more breakage than making valid but matching nothing
plinss: That said, I'm not too concerned
plinss: probably too late to do anything, allowing custom-idents
without prefixing was risky in the first place
TabAtkins: Definitely it's a problem we should avoid
plinss: Should we require that, and not repeat this mistake that
allows potentially conflicting <custom-ident>
TabAtkins: Could do that, make these legacy
fantasai: I would prefer to stay consistent with existing practice
fantasai: Anyway that's outside the scope of the issue
<dbaron> One other example I've seen is the use of `auto` as a named
toggle state in https://toggles.oddbird.net/#named-modes
dbaron: There are probably some uses of <custom-ident> that could be
<ident> because don't conflict with other stuff
dbaron: not sure if that's one of them
TabAtkins: names, toggle-state, and line names won't
TabAtkins: Problems are things like animation-name, which we screwed
up on, and don't want to repeat that
plinss: Original sin here was unquoted font names, all kinds of
problems from day 1
fantasai: Back to original issue, do we exclude these keywords? I
propose to accept
TabAtkins: I'm now less convinced that we should
TabAtkins: Maybe revisit grammar, and require only using in
unambiguous contexts like line names
TabAtkins: Let's not screw it up again
fantasai: I still think it's worth excluding these keywords
TabAtkins: I say take it back to issue
Nesting & Selectors
===================
Move nest-containing and nest-prefixed selector definitions
to Selectors
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5745#issuecomment-1271874448
TabAtkins: Separate from discussion of which exactly nesting syntax
TabAtkins: all of our proposals use the &
TabAtkins: We have a few different contexts where we do nesting
TabAtkins: and they don't currently allow &
TabAtkins: Right now assumption is that & only has meaning and
possibly only valid in direct nesting
TabAtkins: this is not great, particularly if use & > .foo
TabAtkins: meaning of this is clear in any nestable context
TabAtkins: so being able to copy-paste rule between different things,
from nesting to @scope or querySelector
TabAtkins: even globally, makes sense, just say parent context is
:root
TabAtkins: similarly in shadow DOM
TabAtkins: So proposal is, to avoid authors being forced to edit
selectors as they move nesting context
TabAtkins: defined & to be valid and to have meaning in other context
TabAtkins: If not defined specially, is equivalent to :scope
TabAtkins: and this is already defined globally, top level it is host
element of shadow stylesheet or :root otherwise
TabAtkins: so make this analogous unless context explicitly defines
it analogously
florian: Seems reasonable, but haven't thought about it much
Rossen: I'm convinced, too
Rossen: Objections?
PaulG: Gotten to comments about how used inside scope would be
referencing, if possible to get up to another nested context
PaulG: Getting confused to understand, anyone can describe clearly?
PaulG: "What would the below example be? Would be unable to reference
:scope in a nested context"
<TabAtkins> (comment is
https://github.com/w3c/csswg-drafts/issues/5745#issuecomment-1271646202
)
TabAtkins: The answer is later in the thread, where the call was to
not to change meaning of :scope
TabAtkins: Doesn't change the meaning, & is always using the local
definition of it
TabAtkins: Question was if you put nested style rule under the img
style rule, what would & refer to, it would refer to img
TabAtkins: Direct nesting doesn't change :scope
PaulG: Thanks
Rossen: Back to objections?
RESOLVED: Accept to make & valid everywhere, maps to :scope where not
otherwise defined
Selectors
=========
Add `:open` or `:top-layer` pseudo class
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1242377579
TabAtkins: We've talked about this topic before, last time we did the
name :open seemed to be preferred
TabAtkins: we wanted a strict definition before resolving
TabAtkins: so I drafted one, see comment
TabAtkins: [reads comment]
TabAtkins: Secondary question, do we want a :closed pseudo-element
TabAtkins: because :not(:open) selects all elements not just openable
TabAtkins: First question is, should we resolve to add :open with
this definition?
TabAtkins: second, do we want to add :closed
<tantek> SGTM and +1 to :closed
<flackr> +1 to both
<fantasai> +1 to both
<masonf> +1 to both
Rossen: +1 to both
TabAtkins: There's also a comment from annevk about asking ":shown",
and masonf replied that it would be less confusing to use
:open
TabAtkins: I agree with masonf's comment
[see https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1274745594 ]
<PaulG> +1 to both
<tantek> agreed, open/closed sound more semantic than shown/hidden.
also "hidden" already has a different meaning in CSS
<flackr> +1
<ydaniv> how will :closed match differently from :not(:open)?
plinss: :open also matches the .open property
TabAtkins: Only elements that have a notion of open and closed can
match :closed
TabAtkins: similar to :playing :paused, can only match elements that
have that notion
Rossen: Anything else?
Rossen: Objections?
RESOLVED: Accept :open and :closed with definitions as proposed by
TabAtkins
CSS Tables
==========
scribe: TabAtkins
Allow 'order' on table columns
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7340#issuecomment-1247390415
fremy: Can summarize, maybe can't resolve
fremy: So we have some props that apply to grid-ish layout modes but
not tables
fremy: we discussed 'gap' earlier
fremy: But 'order', think it makes sense to be able to swap columns
fremy: Right now you have to change every single row to swap columns
fremy: So you'd be able to apply 'order' to columns and it will swap
them around. Sounds reasonable, but raises some questions
fremy: column groups, spanning cells, etc
fremy: There's a concrete proposal - you glue together columns that
are part of a column group or have spanning cells, and they
can't be moved separately
fremy: Seems doable, but is it something we want to do?
iank: My concern - this sounds ok - but this is slightly special and
new because it isn't how order works in the other properties
iank: Like flex and grid, it just literally reorders the items as you
lay them out
iank: This has a second-order effect
iank: So a little more complexity
iank: Also want to spend more time thinking about how columns move
when they're spanning
PaulG: Table semantics often have grid controls like arrow keys,
focus groups, etc
PaulG: Reordering columns means devs also have to understand the
impact on those, and adjust
PaulG: Seems quite complex and fraught
PaulG: If it doesn't adjust, the arrow keys will jump columns and not
match visual order
PaulG: If we adopt focus group controls, it'll get more complicated
fremy: Agree, but we're just talking about data tables. If you use
for anything else you're doing wrong
fremy: But this is same for Flexbox generally, if you change the
order you have to worry about keyboard order.
fremy: But I do think this is a valid concern
fremy: I think if we assume it's just data tables it's ok
dbaron: In terms of column spans/groups, I think reordering in a way
that doesn't break them is probably desirable
dbaron: But it's not especially clear to me what you do to keep them
together
dbaron: Can maybe be flushed out in the issue
dbaron: Also concerned with same things as PaulG, whether there are
*good* use-cases that justify the problematic with keyboard
a11y
fantasai: Question really is not whether this is ready to adopt right
now, but if this is something we potentially care about at
all. If we think it's bad we can just drop it, rather than
asking fremy to work on it.
fremy: Suggest we give everyone a week to think about it.
Rossen: agreed
Received on Wednesday, 12 October 2022 23:31:12 UTC