- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:22:05 -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 Pseudo
----------
- RESOLVED: Attempt to make this work for ::marker as well as
::before/after, come back with a specific proposal that
allows it while respecting platform conventions (Issue
#8892: Allow user-select on ::marker pseudoelements)
- Clarify spec that custom props can be set on highlight pseudos.
- RESOLVED: Highlight pseudos inherit across the highlight tree, and
the root highlight inherits custom props from the root
element (Issue #6641: Custom properties on :root)
- RESOLVED: If a unit (or similar value) relies on the value of a
property that's not applicable to highlights to resolve
itself, it uses the value from the originating element
(Issue #7591: Highlight pseudos and non-applicable
properties)
- RESOLVED: Do not support them until unprefixed (Issue #7580:
Highlight pseudos and compat stroke/fill properties)
===== 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
Sebastian Zartner, Invited Expert
Scribe: TabAtkins
CSS Pseudo
==========
Allow user-select on ::marker pseudoelements
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8892
fantasai: Someone's trying to copy out a list, and not getting the
::marker numbers
fantasai: So this brings up, what do we do with ::marker when
copying?
fantasai: There's 4 things we could do
fantasai: 1) never output gencon
fantasai: 2) always output gencon
fantasai: 3) output ::marker gencon but not others
fantasai: 4) output only html-derived content (ignore css, only
markup-based list markers)
fantasai: In terms of controlling whether you want to copy out
gencon, user-select might help manage that
fantasai: That was the commenter's original impression of how it
should work when they filed
fantasai: Then if we use CSS content, do we use the primary string,
or the alt text if present?
fantasai: So the question is, again, what part of gencon should be
part of plaintext copying
florian: We touched on a related topic before, it's tricky
florian: user-select says it may optionally apply to ::before/after
florian: Gives some advice on what to do
florian: Trick here is that if we think about css and html only it's
not that hard
florian: I think the options Elika listed are what's on the menu
there
florian: But this also relates to the Selection API
florian: You expect to get a match between selection and what you
copy
florian: As it exists, I believe Selection is not capable of
describing pseudos
florian: I think it would be good to allow this to work, but to make
it coherent we need to make Selection API capable of
describing pseudos in its range
emilio: Is there a pre-existing difference between the output of
Range.toString and the clipboard?
emilio: The clipboard use-case seems fixable without the selection
API
emilio: I don't think we should include gencon in the text/html
clipboard, but maybe in the text/plain one
emilio: I just think we might be able to fix clipboard without
having to touch Selection
florian: I believe there's no current difference between them, but I
think you're right - we can either introduce a difference
or complexity the Selection API
<fantasai> +1 to emilio
Rossen: We're assuming there's only one thing on the clipboard,
that's usually not the case for rich editing cases
Rossen: Also, I'd expect whatever ends up in the clipboard isn't
what we serialize to a11y tools. So if they today get the
gencon or lose the gencon, I'd expect the same from copy/
paste
hober: I'm not an expert on this apart of webkit but we have people
elsewhere who are, I've asked Wenson to come over and express
an opinion. I'd prefer not to resolve until we have an expert
on our side weigh in.
myles: When you said multiple things on the clipboard did you mean
multiple mime types?
Rossen: Yes, sorry
Rossen: So what do we want to do with this?
Rossen: For me, one of the stronger goals is to make sure we're not
degrading a11y tools and experience
Rossen: But if we're waiting for input we can postpone this issue
a bit.
TabAtkins: I think it's fine to wait a little bit
florian: In general for ::marker I think it's at least as desirable
as ::before/after.
florian: So wanting to do something seems reasonable.
florian: The spec says it *may* work for ::before/after but not how,
so we should consider these together.
florian: Selection API, clipboard, etc. We should circle back to see
what's feasible.
florian: So I think the use-case makes sense but it's about how to
make it work.
florian: I don't think it's reasonable to resolve quite yet until
research.
hober: Other thing to keep in mind is that different native
platforms have diff behavior
hober: It's usually the case that a browser wants to match that
platform's behavior for cut/paste interop
hober: Myles is trying to figure out what our platform behavior
even is
hober: But just noting if the spec requires us to violate platform
behavior we'd probably violate spec
florian: I think it's probably not an issue
florian: The broader conventions outside the browser don't have
anything to say about web platform pseudos
hober: Right but they do have lists, so there's at least an analogy
<emilio> Browsers diverge even on `data:text/html,<p style="display:
inline">foo</p><p style="display: inline">bar</p>` :)
fremy: I just tried out of curiosity multiple browsers, and they
don't copy the same formatting now anyway
fremy: So not sure if it makes much sense to specify this behavior
if browsers don't have interop on simpler things
fremy: But they are at least consistent that they don't copy gencon
fremy: So I'm just not sure it makes sense to specify behavior on
::marker if we don't specify copy/paste in general
<fremy> test case: https://wptest.center/#/4ff743
fantasai: I'm fine to defer the discussion if we're asking for more
info, just don't think we should close and forget about it
fantasai: To Francois' point, if the default is to not copy out,
yeah it should keep being the default
fantasai: But think there should be a way to copy it, it's confusing
when you copy out and the numbers disappear
fantasai: You lose a lot of important context
Rossen: Agree, just wanting to narrow down the issues in a while
that'll help
myles: Our platform behavior isn't just that the marker text isn't
put on the clipboard
myles: We *also* put tab characters in the clipboard so the list
looks indented
<fremy> @myles, what you describe seems to match Firefox, not Chrome
myles: So our resolution shouldn't be that it only takes the gencon,
it should allow for matching platform behavior
florian: I suggest we take a resolution that we try to make this
work, take an action item to check in with people already
working in this area with Selection. We should know if they
have plans or have already rejected in this space.
florian: Also to check in with the a11y api. That might rescope the
problem a bit.
florian: And based on that, trying to define in a way that wouldn't
conflict with the constraint that Myles expressed
florian: So I think we should try to add ::marker to that list and
then figure out what it means
emilio: Just looked at our code, we do have different serialization
for Selection API vs clipboard
emilio: There's a weird mix where for some things we serialize based
on DOM, and others based on CSS, and there's probably a
bigger meta question
emilio: so if you copy a <p style=display:table> are you copying a
table or a paragraph
emilio: In general it probably makes sense to look at CSS
emilio: But then the html clipboard and plaintext clipboard will be
rather different.
Rossen: That's good
Rossen: So first two options are opposite ends of the spectrum,
don't do anything, yes do everything
Rossen: Sounds like we're aiming at a nuanced approach between these
Rossen: Would it make sense to eliminate these two, and make
progress navigating something like the other two, designing
and refining what gets output and when?
fantasai: I mean what if you actually want to copy everything?
florian: As a reminder, and we can change if it's wrong, the way
user-select is currently defined is that initial value is
auto, and auto computes to none on pseudos
emilio: Used value
florian: It resolves to none
florian: But authors can explicitly opt into saying yes. Whether
that works or not is fuzzy
florian: So default is to not copy the content. Whether that still
affects something with lists, that's up to us
fantasai: So if we wanted to copy lists by default we could make
::marker have non-none behavior
florian: Sure
Rossen: So can we eliminate those two extreme options to make
progress?
fantasai: Do other browsers need info?
fantasai: If I'm working on this issue what do I need besides
talking to Tess and Myles?
florian: So first ask for existing standards people on Selection or
editing to see if they're already working in this area.
fremy: Maybe an action on browser vendors to describe what they're
doing today?
florian: Selection is edited by rniwa
fantasai: So that makes it easy
myles: Because our primary concern is platform consistency, the
result of this investigation shouldn't be "write down exactly
what platforms do", it should be flexible enough to allow
platforms to do different things that could change.
Rossen: So a proposed resolution?
<fremy> (at least on Windows, no browser outputs Text that is
similar to Word for the same code...)
florian: Attempt to make this work for ::marker as well as ::before/
after, come back with a specific proposal that allows it
while respecting platform conventions
Rossen: Objections?
RESOLVED: Attempt to make this work for ::marker as well as ::before/
after, come back with a specific proposal that allows it
while respecting platform conventions
Custom properties on :root
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6641
schenney: Problem with highlight pseudos with custom properties
schenney: Right now you have to double your custom props on the root
schenney: I summarized the options on the issue
schenney: From our perspective (chromium/igalia) our preferred
option is that custom props come through the highlight
inheritance chain, then if you get to the root and still
don't have a value for the custom prop, look at the root
element
schenney: We feel that has advantage of all the proposals
<fantasai> summary of the options ->
https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1404031937
schenney: Simple inheritance chain, don't do two lookups
schenney: It addresses the problem that most people put custom props
on the root, so we don't have to change our advice
schenney: Only problem is that if custom props are further down the
tree we won't discover them
schenney: But an author always has the ability to put them in the
highlight inheritance chain manually
schenney: So proposal is to use the selection inheritance chain, and
put the root element at the top
schenney: That's the last proposal in my summary
<bramus> The summary being
https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1641196754
fantasai: So that means highlight pseudos are able to be assigned
custom props?
schenney: Yes, they can use existing from the root, or you can
define them in the highlight itself
fantasai: Okay, just need to make that clear in the spec
emilio: Is there behavior difference between this and saying custom
highlights always inherit custom props from the root?
schenney: I think that is the proposal
schenney: We're only saying to inherit custom props from the root
not all
emilio: Okay as an aside I think the highlight inheritance is funky
emilio: but generally I think it's weird that custom props work in
some places but not others
emilio: You can't see a custom prop defined on non-root elements
TabAtkins: Unless you spam them in
emilio: It makes me sad that this is more complicated and doesn't
solve ::backdrop either
TabAtkins: ::backdrop is pretty different
iank: The current behavior in the spec is breaking sites, fwiw
fremy: What is that behavior?
emilio: A highlight pseudo inherits from your parents highlight
pseudo, etc. then the root's highlight doesn't inherit from
the root, so you have to specify your custom props on both
root and highlight root
emilio: Current non-spec behavior is that selection pseudos just
inherit from the originating element, no inheritance from
the highlight tree at all
delan: Clarification - the proposal is not that highlight styles
inherit from the root, but rather that they continue to
inherit from parent highlight styles, but at the top the root
highlight inherits from the root element
delan: So we're only changing what happens at the top
florian: For custom props only
delan: Right. There was an earlier proposal where we considered
doing it for all, and it's simpler, but it breaks paired
defaults which are a really important compat behavior
fantasai: 1) if we want internally to implement as inherit
everything from root to root highlight, you can do that
and set "all:initial"
fantasai: You'll have to pull out writing-mode/direction as well.
But internally you can just inherit everything and reset a
bunch
fantasai: For ::backdrop I think it's completely unrelated, there's
no weird cascading/inheritance behavior
fantasai: We should discuss ::backdrop but separately. I don't
understand why we didn't give it inheritance to begin with
fantasai: I feel like this is a good proposal.
fantasai: If you're using custom props in your highlight styling
you'll have to set that on the highlight itself, but at
that point you're already selecting that highlight so it's
not bad
schenney: I still think that taking a resolution to consider the
broader solution of different place to define custom props
(the @document idea from earlier) I think is still
important, it would solve other cases
schenney: But I think our current proposal for now will fix the
breakage we currently see
fremy: I think I agree with that, we should fix the local problem
fremy: One comment, to me it makes sense to inherit properties from
the originating element
fremy: but you say it would be challenging from impl perspective
fremy: Why?
schenney: It's *doable* but it requires two sets of inheritance
passes to make it work as authors expect
schenney: You'd have to look down the highlight inheritance chain,
and if you didn't find a custom variable you'd have to go
back to the originating element and walk its inheritance
chain
schenney: Weird behavior from an author's perspective too, it grates
me as an author
fremy: It is still confusing to me that you can't make a property
called --selection-color and change it further down and have
it work, you have to send it to the highlight itself
fremy: But it's not for me to say what's hard to implement
fremy: I do think the root will solve 95% of the problems
<TabAtkins> (I strongly disagree, I think two inheritances is much
worse than just rooting the highlight tree under the
root el)
oriol: In the spec we resolved that ::backdrop now inherits from
originating element
TabAtkins: When I asked Anne about it, he didn't know why it was
that way, so we fixed it
emilio: The backdrop case is similar in that the root el isn't in
its inheritance chain, so if that's fixed it's good
emilio: But I still think it'll be confusing for authors that they
can't set further down the tree
fantasai: Given that highlights don't inherit *anything else* from
their originating element, I don't think it's unreasonable
to assume the custom props inherit the same
fremy: Some things are inherited...
emilio: currentcolor
fantasai: That's not inheritance
delan: I think we're getting sidetracked
delan: I was originally queued to say that all the breakage we've
seen (and we've had dozens of bug reports) were about custom
props on root
delan: So not a single instance reported of breakage from custom
props elsewhere in the tree
delan: so for the compat issue this should be enough
schenney: re: things coming from originating element, yes
currentcolor
schenney: And next issue is about another case where we might take
some info, still not a property tho
schenney: In *all* cases though, for properties themselves it comes
solely through the highlight inheritance chain
ntim: I see authors put custom props on shadow roots, I'd expect
that to work
<emilio> To clarify, ntim means via `:host`
<astearns> +1 to accommodating :host as well
schenney: So if you put custom props on the shadow root, do you want
it to have different values for the highlight than
elsewhere on the page?
<TabAtkins> :host::selection should work, right?
<delan> does this proposal change anything around that?
<emilio> Having an editor custom-element doing something like `:host
{ --selection-color: red }` and use that from highlight
pseudos seems reasonable...
<emilio> no
emilio: It seems reasonable if you have an editor custom element to
set custom props on :host
emilio: This is what I was talking about - it seems weird as an
author that setting props on the root works but setting
anywhere else doesn't work
emilio: I understand you can say :host::highlight but I think people
wouldn't do that
<ntim> I agree with emilio
emilio: They'd think if the root case worked, why wouldn't other
cases work
emilio: I understand this fixes the compat issue and there are ways
to get the behavior you want, I just think it's not great
schenney: I just think the only option would be to go to dual
inheritance
schenney: Which is a bad option too
schenney: So I'd prefer minimum compat maintenance
<iank> I would prefer no double inheritance
TabAtkins: I don't agree that this would be confusing for authors
TabAtkins: having one single inheritance tree is usual
TabAtkins: and I feel it would be even more strange if different
properties inherit in different paths
TabAtkins: I can see people stumbling on this once, of course, but
they can look up and fix it with specific code
TabAtkins: so I don't see this being a long term confusion for
authors
florian: Going in the same direction as Tab, custom props are also
sometimes used to polyfill regular properties
florian: Having them be more similar rather than more different
probably is better
emilio: I'm just not convinced authors would understand that
highlight style inherits from other highlight pseudos and
finally the root
dbaron: I have mixed feelings overall, but think I'm reasonably
sympathetic to Tab's argument about consistent model
dbaron: One of the things we might require authors to do is write
something both for the el and its highlights
dbaron: Which might be painful because there's several highlight
pseudos
dbaron: We might want a pseudo that refers to all the highlights.
dbaron: Probably only useful for custom props
dbaron: Would probably make this less painful for moving custom
props around
delan: I think that's a good idea
delan: I also wanted to say that I'm not convinced that the proposed
behavior would be too difficult for authors to understand
delan: and that it would be much worse than the legacy behavior
where selection inherited from the originating el
delan: That model, which most browsers currently have, also has
un-intuitive aspects
delan: For example, I set a selection color and background color on
`p`, then the children don't have those colors. Highlight
inheritance fixes that
delan: It is something authors could trip on but I think I generally
agree with Tab, they'll trip over it once and then move on
fremy: could we have an example of how you fix this with custom els?
<dbaron> (The example I gave was that authors could style element,
element::all-the-highlight-pseudos { --custom-properties:
values }.)
<emilio> `:host, :host::highlight { --foo: red }
TabAtkins: You just need to shift them into the highlight tree as
well
fremy: Okay that's not that bad
<emilio> Well, without dbaron's proposal you'd need `:host,
:host::selection, :host::spelling-error,
:host::grammar-error, :host::highlight(<foo>),
:host::highlight(bar), ... { --foo: red }`
Rossen: So can we get to a resolution?
proposed resolution: highlight pseudos inherit across the highlight
tree, and the root highlight inherits custom props from the
root element
Rossen: Objections?
RESOLVED: Highlight pseudos inherit across the highlight tree, and
the root highlight inherits custom props from the root
element
Highlight pseudos and non-applicable properties
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7591
schenney: This issue arises when properties in highlights, like
shadow blur radius, etc
schenney: Use property values that have font-dependent metrics
schenney: or any other type of context-dependent value that can only
be resolved from outside the highlight
schenney: Like, you can't set font-size on a highlight, but if you
use 1em in the highlight we need to look that up somehow
schenney: Currently the spec would have us walk the highlight chain
for a font-size property, never find one, and use the
initial value
schenney: So the proposal is that property-dependent metrics you
find in a highlight property, you take from the
originating element
schenney: font size, line height, etc
schenney: So if you use the same property on the el and the
highlight you'd get the same behavior
delan: A few extra notes
delan: font-size and line-height are, as the issue title says,
they're not applicable properties for highlights
delan: Can't actually change them in highlights, we don't want
highlighting to change the font size
delan: so when you highlight *in practice* it takes the font-size
and line-height from what it would be when it wasn't selected
delan: So we're trying to make the font-relative units consistent
with that, matching the actual used font-size and line-height
delan: rather than some arbitrary initial value
delan: Also, we had a previous resolution for this a while back
delan: but it seemed muddled, there were other issues mixed in
delan: But all we're really trying to do is resolve what happens
when you use em/etc units
delan: not really changing anything else here about how shadows or
decorations work in highlights, just what happens with those
units
florian: So we're not *really* discussing property inheritance, just
unit resolution
fantasai: I support this proposal and think it's the right thing,
and the fact that it's implemented is great
<florian> +1
emilio: Can't we just... could we fix the previous issue the same way
TabAtkins: That was the 'don't inherit custom props at all, just
from originating element'. That runs into you expect
custom props to inherit
TabAtkins: [missed]
TabAtkins: it ends up being a lot weirder in a lot of cases
TabAtkins: We talked about that solution earlier, i.e. not
inheriting custom props at all and inheriting from
originating element
TabAtkins: that ends up being more confusing, because you can't set
custom props on highlight a tall, you have to rely on
light DOM to inherit
TabAtkins: was confusing that you could set a var() but not set it
in the same place
TabAtkins: Because resolution is off a completely different element
TabAtkins: basically it's confusing
<TabAtkins> `::highlight { --foo: 1; --bar: var(--foo); }` would
*not* do what you think
schenney: Yeah I think the previous behavior would be the bad author
behavior, using different metric values than what you'd
see if you used that property on the originating element
Rossen: So do we still have a proposed resolution?
schenney: I propose that font and other metrics that used in
highlights, where that value isn't available from a
highlight-applicable property, use the originating element
to resolve that unit
dbaron: Just to clarify: that's about whether the property in
question is *valid* for highlights, not whether it's used.
schenney: Yes
delan: I wonder if this could be phrased more simply as "in a
highlight pseudo, the values of font-relative metrics come
from the originating element"
schenney: I'm concerned that any other cases where this problem
arises need a general resolution
delan: Fair
dbaron: I think there's a very slight risk in the opposite
direction, where a unit depends on a combo of properties
where some are valid in highlights, and there you probably
want it from the originating element still and not try to
mix things
dbaron: maybe there's no example of that right now
Rossen: So returning to the resolution, any objections?
RESOLVED: If a unit (or similar value) relies on the value of a
property that's not applicable to highlights to resolve
itself, it uses the value from the originating element
<br until=10am-local>
Highlight pseudos and compat stroke/fill properties
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7580
scribe: emilio
scribe's scribe: bramus
schenney: Simple question: -webkit- prefixed stroke / fill
properties are interoperable and supported across
browsers, but not supported in highlights
schenney: question is should they?
emilio: I think they are not synonymous with their unprefixed
versions. Some are not impl as aliases
emilio: I think it is worth trying not to support them
<TabAtkins> agree
fantasai: I think the intention was that they would eventually be
synonymous
fantasai: We should look into whether we can make them aliases
fantasai: Up until we do that I'm fine with them not being supported
schenney: I'd support not supporting them but could in the future if
unprefixing them becomes appropriate
florian: The compat spec isn't entirely clear between the
interaction between these and the unprefixed versions
florian: We should be looking into doing this
florian: and if they end up being aliases then yeah they should work
fantasai: Makes sense, I guess that means TabAtkins and I are
responsible for that
fantasai: if/when we can make them aliases then they'd start working
GameMaker: I'm agreeing with fantasai, support them once unprefixed,
not support them until then
<TabAtkins> (elika and I stopped working on fill-stroke because
there was no one biting on implementation)
<TabAtkins> (we're happy to pick it up again)
<GameMaker> WebKit obviously has an implementation, and we were just
looking at supporting these in highlights, so I would
love if we can move forward with the unprefixed versions
RESOLVED: Do not support them until unprefixed
Received on Sunday, 10 September 2023 15:22:41 UTC