- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Jan 2023 18:55:07 -0500
- 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 Nesting
-----------
- RESOLVED: Publish updated WD of CSS Nesting with an added issue
about lookahead
CSS Text
--------
- RESOLVED: A single-string value changes what is inserted, but not
where (Issue #2975: hyphenate-character doesn't just put
hyphen at end of line)
- RESOLVED: Close WONTFIX (Issue #5972: Hyphenation styling should
apply to the wbr element)
- RESOLVED: Accept changes [changes:
https://github.com/w3c/csswg-drafts/commit/03935eae48ead18beed74ff665f8724c532b49a9
]
(Issue #5973: Better describe the likely outcomes of
hyphenation (editorial))
- RESOLVED: Republish CR [of CSS Text 3]!
CSS Pseudo
----------
- RESOLVED: Restriction will be relaxed to allow punctuation-only
matching (Issue #2254: Multi-line ::first-letter)
- RESOLVED: Revert previous resolution; accept :blank works for this
use case (Issue #2517: Clarification: do ::placeholder/
:placeholder-shown apply to <select>s' “placeholder
label option”?)
- RESOLVED: ::first-line applies to markers when
`list-style-position` is `inside` but excludes them when
it's `outside` (Issue #5406: Should ::first-line include
markers?)
- RESOLVED: CSS inline layout properties are not applied to
::placeholder (Issue #5379: Should `line-height` be
applicable to ::placeholder?)
- Discussions began around use cases for issue #6641 (Custom
properties on :root) but the call time ended before the group
could do any deep discussion about the potential usage.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0010.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Daniel Holbert
Jonathan Kew
Peter Linss
Alison Maher
Eric Meyer
François Remy
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Rachel Andrew
Delan Azabani
Chris Harrelson
Chair: Rossen
Scribe: emeyer
CSS Nesting
===========
Rossen: Any changes to the agenda?
flackr: Propose breakout session for scroll animations?
Rossen: Let's do that on the mailing list
fantasai: We should publish updated WD of CSS Nesting, it was last
updated 2021
plinss: Want to revert a previous resolution before republishing,
but it's not a big deal since it is a WD
fantasai: Yes, we can add an issue about lookahead
RESOLVED: Publish updated WD of CSS Nesting with an added issue
about lookahead
CSS Text
========
hyphenate-character doesn't just put hyphen at end of line
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2975
fantasai: Last two comments on issue clarify that single-string
value changes what is inserted, but not where
<jfkthame> +1
Rossen: Any opinions?
florian: I think it's the right thing to do for now
florian: When we look into expansions, we'll need to think harder
about whether this is novelty hyphens or about manually
defining hyphenation in unsupported languages
RESOLVED: A single-string value changes what is inserted, but not
where
Hyphenation styling should apply to the wbr element
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5972
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/5972#issuecomment-826582035
fantasai: We propose to close WONTFIX because <wbr> is a soft-wrap
but not a hyphenation opportunity
fantasai: HTML could extend itself to do more, but current spec is
written that if that ever happens, this will all apply to
that correctly
<florian> I'm the other part of "we", so I agree
<TabAtkins> +1 to wontfix
RESOLVED: Close WONTFIX
Better describe the likely outcomes of hyphenation (editorial)
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5973
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/5973#issuecomment-1366321015
fantasai: We added examples
fantasai: and made a normative change to say a hyphenation character
property applies to soft hyphenation opportunities
fantasai: if there's supposed to be a spelling change in a
hyphenated word, you should apply that
fantasai: we want the UA to make a best effort but it may or may not
match up
<fantasai> normative changes ->
https://github.com/w3c/csswg-drafts/commit/03935eae48ead18beed74ff665f8724c532b49a9
florian: Examples were added to show these sorts of situations
Rossen: Anything else?
(silence)
Rossen: Any objection to these changes, or do we need more time?
florian: We did get a heart emoji on the issue, so there's that
RESOLVED: Accept changes
Republish
---------
github: https://github.com/w3c/csswg-drafts/issues/6900
fantasai: We compiled a changes list and disposition of comments
fantasai: There's a minor change we made as a followup to one of the
issues
fantasai: Assuming that's good, we'd like to request an updated CR
snapshot
<fantasai> https://github.com/w3c/csswg-drafts/commit/d3ed39e04fb2a3087aa745dce57abd59c93412c5
fantasai: `text-justify: distribute` addition
fantasai: spec was updated to allow Firefox treatment
florian: About testing, all normative changes since last CR do have
tests
florian: Spec itself has pretty extensive test coverage
florian: Not complete, but pretty exhaustive
Rossen: All the more reasons to republish
RESOLVED: Republish CR!
CSS Pseudo
==========
Multi-line ::first-letter
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/2254
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/2254#issuecomment-1367476156
oriol: We discussed in the past what happens if first-letter
container is very narrow
oriol: And then would span multiple lines
oriol: We resolved to clamp to match characters in the first line
oriol: Focus of the previous proposal was not addressing this
question
oriol: Better to discuss this and clarify
oriol: So: what to do if the first-letter container only contains
punctuation?
oriol: Spec currently selects punctuation if there's another letter
character that appears later in the container
oriol: This seems strange; if the letter character is in another
line and you remove it, this suddenly makes the first-letter
unable to match punctuation characters
oriol: first-letter should only be allowed to match punctuation
oriol: I think Gecko's behavior makes more sense
oriol: Some prefer the specification as it is now
Rossen: Opinions?
(silence)
Rossen: Any objections to resolving on the option to use Gecko's
behavior?
iank: Basically logic UAs use to skip punctuation characters would
have that logic removed?
oriol: Yes, since the only one affected would be Blink, it would
need to start matching punctuation-only containers
Rossen: I believe the answer is yes, Blink can stop skipping
punctuation-only
RESOLVED: Restriction will be relaxed to allow punctuation-only
matching
Clarification: do ::placeholder/:placeholder-shown apply to <select>s'
“placeholder label option”?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2517
fantasai: The placeholder-shown example is about validation and it's
not really a placeholder option, it's just a validation
thing
fantasai: Tab and I propose to undo previous resolution and have
:blank match the default option in a dropdown
TabAtkins: Placeholder pseudo doesn't explicitly refer to validation
TabAtkins: Any time your input is empty, it will match ::placeholder
TabAtkins: I agree with Elika, we can revert about adding
placeholder label option to matching placeholder pseudos
and lean on :blank for use cases
TabAtkins: This will get us where we want without binding us to this
weird solution
Rossen: Any objections?
(silence)
RESOLVED: Revert previous resolution; accept :blank works for this
use case
Should ::first-line include markers?
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4506
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/4506#issuecomment-1367490644
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/4506#issuecomment-1001846929
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/4506#issuecomment-558592436
fantasai: Does ::marker part of a ::first-line or not?
fantasai: A lot of tests were done on implementations
fantasai: Proposed resolution is ::first-line includes markers when
`list-style-position` is `inside` but excludes them when
it's `outside`
oriol: I think that's fine
<TabAtkins> No strong opinion from me, but the proposed resolution
seems good
emeyer: So this would mean that if list-style-position is outside,
and color is set by ::first-line, the marker would not pick
up that color
TabAtkins: correct
TabAtkins: With outside positioning, it's positioned, so we're
considering it outside the line
fantasai: This is important if you set a background color on the
first line and it wouldn't match well with the marker, we
don't want it to apply to that outside marker
RESOLVED: ::first-line applies to markers when `list-style-position`
is `inside` but excludes them when it's `outside`
Should `line-height` be applicable to ::placeholder?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5379
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/5379#issuecomment-1367499300
fantasai: Proposal is to exclude CSS inline layout properties from
::placeholder
Rossen: Objections?
(silence)
RESOLVED: CSS inline layout properties are not applied to
::placeholder
Custom properties on :root
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6641
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1367600040
TabAtkins: Authors often define a big set of custom properties on
the root element
TabAtkins: These reasonably might want to be used in highlight
pseudos
TabAtkins: Currently, highlight pseudos don't inherit from the
normal DOM tree
TabAtkins: So they won't see any of the stuff on the root
TabAtkins: The way around that is to have that big block have a
selector of `:root, ::highlight`
TabAtkins: It's a little weird and funky
TabAtkins: There are a few suggestions to address this
TabAtkins: One is to have some kind of at-rule allowing you to apply
custom properties at a level higher than the root, which
highlight pseudos could see
TabAtkins: Another is to change things so that highlight pseudos
resolve their vars against the originating element
TabAtkins: Another is to say highlight inherits all custom
properties from the root
<fantasai> ... and maybe all properties from the root
TabAtkins: I don't like resolving var() differently
TabAtkins: I think it would complicate or break setting vars
directly on highlights
TabAtkins: Inheriting from the root element has possibilities, but
could cause cascade problems
TabAtkins: Inheriting just custom properties would be a little
weird; it has minimal impact but it's a new way of doing
things that might have implementation problems
TabAtkins: Having a root-superior at-rule is also a new weird way to
address this
TabAtkins: Not really sure how to approach this, but leaving as is
where you have to select both root and highlights has
some implementor objections over memory cost
<bramus> A use-case for inheriting only custom properties is
`::backdrop`
<fantasai> bramus, why?
<bramus> Authors want it:
https://kilianvalkhof.com/2023/css-html/backdrop-doesnt-inherit-from-anywhere/
<fantasai> bramus, but ::backdrop could just inherit from its
originating element like all pseudo-elements, couldn't
it? why would you want it to inherit from :root
specifically
miriam: ::backdrop has a similar problem and it's caused author
problems, and articles are starting to pop up about having
to address both
miriam: I like ::document or something like that, maybe could also
respond to dark and light modes
miriam: I'm not sure a document-selector toggle could respond, though
bramus: There's author demand for backdrop inheriting custom props
fantasai: That is a little different, as ::backdrop can inherit from
its originating element and we should make it do that
fantasai: highlights have to inherit from a tree parallel to the
document tree
fantasai: I can see reasons why we might want an @document
fantasai: Downside to inherit-from-root is that you can only ever
get variables from the root, not from other elements
between root and the highlight
<bramus> Spec says it doesn't:
https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element
<bramus> “It does not inherit from any element and is not inherited
from.”
<TabAtkins> Right, spec says it doesn't, but we can't see any reason
*why* it shouldn't inherit.
<bramus> True :)
<TabAtkins> We asked about it in the repo but haven't gotten a
response
<fremy> +1 to inherit custom properties from :root, I think they are
de-facto considered "global" by authors
argyle: If I do define a bunch of vars on @document I could toggle
them, but it's a good place to put them
argyle: The at rule would be the place things are originally
defined, but can be changed later
fremy: I don't see why a document is different form an initial value
in this case
fremy: Why would we ask authors define things in @document and then
ask them to redefine later
<fremy> (for the minutes, I mentioned how developers already assume
:root variables are global, and we could acknowledge them
as-is)
<dbaron> argyle, what about miriam's point about things like light/
dark mode depending both on media queries *and* an
attribute on the root that comes from a user-facing toggle
<argyle> dbaron: @document { --brand: hotpink }, and for dark mode
`@media (prefers-color-scheme: dark) { :root { --brand:
deeppink } } .dark { --brand: deeppink }` is what I was
thinking
<fremy> @ argyle what is the value of @document here? @property
{ initial } feels identical (and, I believe, not that great
in this case, you would want the deeppink in dark mode)
Rossen: Any other thoughts?
(silence)
Rossen: Do we feel like we're close to resolution, or should we just
capture this and pick it up next week?
fantasai: Is there any reason we should NOT have the highlight
pseudo inherit from :root?
TabAtkins: If you put color: black on root and then inherit into the
highlight, it would break the cascade
fantasai: I think that can work by having the UA stylesheet break
inheritance for color
fantasai: You can have paired default highlight colors happen based
on author style rules
<TabAtkins> (I'm completely confused as to what fantasai is trying
to say.)
<TabAtkins> (Either I, her, or both of us don't understand what
we're talking about.)
dbaron: A reason not to add it is that it still doesn't solve the
variables problem when they're set on something other that
the root
Rossen: We'll have to close here, the clock has run out
+++++++++++++++++++++
IRC chat post-meeting
+++++++++++++++++++++
<TabAtkins> fremy: Problem with `@property {initial:...}` is (a)
it's a lot more verbose than a `--foo:...;`, and (b)
initial values can't refer to each other, so you can't
set a default composite custom property
<fremy> @ TabAtkins, ah yes, the compositionality argument makes
sense (still feel :root ought to be enough, but different
question)
<TabAtkins> I agree that something just referencing :root is gonna
be the best ^_^
<fantasai> [post-meeting discussion]
fantasai: three options
fantasai: 1. inherit from :root
fantasai: 2. inherit custom properties from originating element,
other properties from highlight parent
fantasai: 3. don't manage custom properties on the highlight, have
var() look up on the originating element
<fantasai> 1. Doesn't handle subtree variable changes
<fantasai> 2. is hard to implement, because you have two different
inheritance models for the same element
<fantasai> 3. has the weird problem that you can't set a custom
property and use it in the same declaration block
<fantasai> emeyer indicates that as an author, he'd expect behavior
of #2
Received on Wednesday, 25 January 2023 23:55:50 UTC