- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 24 May 2021 18:51:43 -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: Text decorations of highlight pseudos sort *outermost*
by decoration category (per CSS2) then by highlight
type. ::selection has an out to allow it to paint on top
of everything else (Issue #6022: Questions about text
decorations on highlight pseudos)
- RESOLVED: Switch Highlights back to a maplike of (name)=>
Highlight, add a Note about what happens if you register
the same highlight with multiple names (Issue #5910:
Highlight API collection, maplike vs setlike)
- There is interest in having a requirement in the spec for browsers
to provide sufficient contrast between background and foreground
colors, even when the author has specified them as the same
value (Issue #6150: Ensuring selection foreground/background
contrast).
- Spec text will have to be thought through carefully to ensure
that all cases are appropriately handled.
- It's currently unclear how much the group will be able to
provide a specific algorithm vs a set of minimum
requirements. Having an 'auto' value with required contrast
would allow OSs to still have some custom behavior.
Color Adjust
------------
- RESOLVED: Normal and light are not synonymous, they will stay
(Issue #5898: Are normal and light synonymous for
color-schemes?)
- RESOLVED: No change, keep both forced-color-adjust and
color-adjust (Issue #3880: Combine forced-color-adjust
and color-adjust properties somehow?)
Capitalization: "User Agent" or "user agent"
--------------------------------------------
- RESOLVED: Match the style guide of lowercase for "user agent"
(Issue #5200)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/17
Present:
Rossen Atanassov
Tab Atkins-Bittner
L. David Baron
Christian Biesinger
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Sanket Joshi
Brian Kardell
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Myles Maxfield
Cameron McCormick
Tess O'Connor
François Remy
Morgan Reschenberg
Melanie Richards
Florian Rivoal
Cassonda Roberts
Alan Stearns
Miriam Suzanne
Lea Verou
Greg Whitworth
Scribe: TabAtkins
CSS Pseudo
==========
Questions about text decorations on highlight pseudos
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6022
fantasai: This is about painting order of text decorations on
::highlight pseudos
fantasai: There is a stacking order of the highlights
fantasai: Original text is bottom layer, and things stacked above
that: spellcheck, grammar check, target text, selection,
something like that
fantasai: defined in spec
fantasai: When you draw text, text and decorations are also layered
separately: overline, underline, text, strikethru. So over/
under are below text and strikethru is above
fantasai: So what's the interaction between these two stacking
orders?
fantasai: The proposal is that you maintain the same order between
over/under, text, and strikethrus
fantasai: highlight pseudos are defined by only the topmost pseudo
painting the text, so it's not painted multiple times; in
that topmost layer's color
fantasai: but line decorations stack
fantasai: If you have spelling, grammar error and are highlighting,
you'll see all the different underlines
fantasai: Suggestion is that we do all the underlines in z-index
order, then overlines, then the topmost text, then all the
strikethrus
fantasai: So CSS2 ordering is the "outer" ordering
fantasai: This makes strikethru always on top, regardless of where
it's from.
fantasai: Thoughts?
TabAtkins: Sounds reasonable to me, ignoring implementation
dholbert: Do you know how browsers currently do?
fantasai: I haven't tested who supports the various new highlight
pseudos yet.
fantasai: I know there is some weird behavior with regards to text
decorations...
smfr: Can you give the ordering again?
fantasai: Custom highlights are between text and built-in
highlights, with selection on top
fantasai: under/overlines defined by non-selection highlights will
interleave
fantasai: So proposal is all the overlines, then all underlines,
then the text (only once), then all the strikethrus on top.
fantasai: I think this generally makes sense; but selection has some
trickiness on some platforms that I'm not sure about
TabAtkins: I know iOS has a special ordering for ::selection, but
not sure if they do text decorations there
smfr: No, ::selection is drawn on top of the text, and doesn't allow
text decoration
fantasai: [gives example]
smfr: So is it true that custom highlights can contribute text
decorations? And they're sorted in that order with the
built-ins?
fantasai: Yes
smfr: Okay, now I understand
fantasai: So we could draw the text decors for the lower layers
below the text, and draw the text decorations for higher
layers above the text
fantasai: Problem is that strikethru on lower layers would be below
the text
fantasai: Maybe that's what we want, I dunno
TabAtkins: I think the fact that any arbitrary layer can co-opt the
text painting role means that having the underlayers draw
their strikethrus under the text when necessary is a bad
thing; it's not easy to predict what layer will actually
draw the text. So we should do the full grouping instead
smfr: Okay, as long as ::selection is on top, it's fine for us - the
rest can sort their decorations together
chrishtr: Before we resolve, I'd like to have the proposed
resolution be written down and tested on impls, so I can
double check that there aren't issues
chrishtr: no interop or complexity issues
fantasai: The person who raised the issue is implementing in Chrome
fantasai: I wanna be clear, smfr, that the strikethrus of a custom
highlight can paint atop a selection
fantasai: What we could do is special-case ::selection and say that,
*aside* from that, everything sorts as described, but
::selection text/etc can paint in a single layer on top of
everything else
fantasai: The point that Tab brought up - that the existence of
another custom highlight shouldn't cause a previous custom
highlight to have its strikethru go below - is correct,
but due to the nature of ::selection, it's probably fine
to treat it specially.
fantasai: So like if spelling error used a strikethru, that should
paint over the text
fantasai: If you have ::text-target as well, we don't want this to
cause the spellcheck strikethru to go under the text
fantasai: But if you select the text, and we can say that it causes
the text to come to the forefront and paint over the
decorations, I think that's reasonable behavior and would
solve your concerns on iOS.
smfr: We don't paint the text itself on that top layer, but just the
'blue wash' the highlights it. I'm fine with reordering the
decorations, as long as the user selection is atop everything
else
fantasai: So if you specify ::selection { color: yellow; background:
blue; }, what happens?
smfr: Text will be yellow, don't know if we support the background
GameMaker: Let me check...
florian: So you're proposing we *allow* ::selection to be on top, or
*require* it?
fantasai: I can go either way. I think ::selection overpainting all
lower-level text decorations isn't unreasonable.
florian: The iOS thing doesn't seem to be *only* on top, it just
works differently than the other highlight pseudos.
Background isn't 'background', it's a magic translucent
thing, etc.
smfr: Yes, it's special
GameMaker: We already do something special with making even user
colors slightly translucent
GameMaker: It doesn't affect text, but if you have a red background
and yellow selection, it'll be a little translucent [and
look a little orange] - it's not solid color
fantasai: Cool, we have another issue on that. So do you paint that
translucent background over the text?
GameMaker: Yes.
fantasai: So you can't have yellow text if you have a blue
background, it'll always be a little green?
GameMaker: Yes, but it's a subtle effect, not as green an effect as
you think.
florian: So based on this I suggest we *allow* ::selection to be
painted atop - don't need to clone iOS.
fantasai: I'm fine with that.
fantasai: Proposal is that the "outer" ordering is CSS2 ordering -
what type of decoration it is.
fantasai: "Inner" sort is what type of highlight you have.
fantasai: And as an option, the impl *may* paint all the aspects of
the ::selection as a topmost layer above the rest.
Rossen: Objections?
fantasai: Let's handle background in a separate issue though
chrishtr: I'd just like to have some time to review
[chatter about this being provisional for review or what]
RESOLVED: Text decorations of highlight pseudos sort *outermost* by
deco category (per CSS2) then by highlight type.
::selection has an out to allow it to paint on top of
everything else
Highlight API collection, maplike vs setlike
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5910
florian: A custom highlight is made of three things: the Highlight
object (a bunch of ranges), then a priority to know where
it stacks, then a name so it's addressable from the
stylesheet
florian: Question is how to group these
florian: Could say priority is an attribute of the highlight object
florian: But what about the name?
florian: One option is a Map where key is name and value is Highlight
florian: Another is a Set where name is a property of Highlight.
florian: If you use a Map, you could potentially register the same
highlight multiple times under multiple names.
florian: Has some odd ergonomics for user.
florian: You style ::custom-spelling and ::custom-grammar, but they
have the same priority, it's got some odd stacking.
florian: Not *hard* to explain or implement, just unintuitive. We
consider it a footgun.
florian: So we decided to make it impossible to set up the same
highlight multiple times.
florian: So we switched to a Set that throws if you register
multiple times. We could also have a Set that just ignores
if you set multiple.
florian: Or a Map that throws if you register multiple.
florian: Or we could just ignore it all and let it happen.
florian: Currently the spec has it as a Set where name is an
attribute, and it throws if you register the same thing
twice.
florian: But that's unusual.
florian: Simplest is a Map that doesn't throw, but that might not
make sense. But maybe that's fine.
hober: This came up in a TAG review
hober: been several months so conversation is swapped out by now...
hober: But I remember being surprised about, it would be common to
write code that says "have I registered this yet? No? then
add it"
hober: Might have a few libraries that use highlights for various
purposes, and they don't want to clobber themselves
hober: With a Map that's super easy
hober: just check the key
hober: With a set you have to iterate
hober: We thought that's weird, we expected checking to see if it's
registered to be a common op
hober: I think we saw the ergonomic downside as more of dev
inconvenience than the dev registering the same thing
multiple times
hober: So I think we're inclined to just let the dev hurt themselves
if they want to register things twice
hober: Not a hill we want to die on, just want common operations to
be easy.
florian: With time that has passed since original decision, sounds
good to me
leaverou: Agree with hober, she said most of what I wanted to
leaverou: I think using try/catch every time you register a
highlight isn't ideal
leaverou: I think there might even be use-cases for doing this -
providing aliases for the same highlight
leaverou: Sanket pointed out the problem is the priority (can't set
it in that case), but that sounds like priority is
associated with the name rather than the Highlight...
maybe it's misplaced?
florian: I thought about that, but then how would you set it?
sanketj: Design I had in mind originally was every Highlight has one
name and one priority, and that's reflected in the spec we
have today.
sanketj: You could say the priority is associated with the name
rather than the highlight, but you'd need a different data
structure
<iank> sanketj: likely want an options arg for the ctor, e.g. "new
Highlight({name: 'hi', priority: 2})"
<iank> can't it be a maplike with an additional convenience function?
<TabAtkins> Yeah, it'd take a sequence or options object instead, I
guess
<iank> e.g. ```interface Highlights { readonly maplike<string,
Highlight>; addHighlight(Highlight or HightlightDictionary);
}```
Rossen: What's your position on the change to use Map?
sanketj: hober and leaverou's arguments make sense. And I think
associating priority with highlight is convenient; I'd
prefer not to change that if there's not a big reason to
sanketj: If we do allow a highlight to have multiple names, what's
the messaging around it?
sanketj: Lea mentioned a use-case; I always thought about this as
making a separate Highlight object, then they can
prioritize against each other properly
sanketj: Sounds like you were suggesting having the same highlight
be prioritized two different ways, which might be more
complicated
florian: I think the proposal is to just do it the naive way - same
highlight under two names would share priority
florian: So painting order would use the fallback of registration
order
florian: A bit limiting, but it's not there *because* of the
use-case, it's just the natural fallout.
florian: And if people find ways to make it nice for them, sure.
<leaverou> +1 to florian
florian: Probably it's a footgun, but possibly there's good things
to come out of it
sanketj: Do we want something in the spec warning against it?
<leaverou> Yes, this would need to be a note in the spec
sanketj: Seems could be unexpected results
florian: Don't think we should have a normative thing, but a Note
saying this would be odd if you did it would be appropriate
leaverou: Agreed
sanketj: We could just document the case from the issue
sanketj: Seems fine
Rossen: Sounds like we're approaching a resolution?
iank: I left some IRC comments
iank: You don't need to strictly make it a setlike - could add
convenience functions
iank: Dunno if this changes the discussion particularly
florian: Not sure what's being proposed to help here
iank: Could make it a readonly maplike, then provide an add() that
takes a Highlight, plus a remove()
florian: Does that bring us back to what we have today?
sanketj: I think the impl is that the name would not live on the
highlight, but be the key to the maplike
TabAtkins: I don't think there's enough worth innovating in data
structures, versus just letting authors do this
Proposed resolution: Switch Highlights back to a maplike of (name)=>
Highlight, add a Note about what happens if you register the
same highlight with multiple names
leaverou: Just want to make sure that if you register to an existing
key, it doesn't throw - that was mentioned in the early
options
florian: Right, normal Map behavior
RESOLVED: Switch Highlights back to a maplike of (name)=> Highlight,
add a Note about what happens if you register the same
highlight with multiple names
Ensuring selection foreground/background contrast
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6150
chrishtr: ::selection can set foreground and background color. What
happens if they're not contrasty enough?
chrishtr: If they're the same, you can't read the text
chrishtr: For that reason, wk/chrome has special code to invert one
of them in that case
chrishtr: There's at least one site reported as "can't see
selections" in Gecko, because foreground and background
were both white, and dev might not have noticed it in
testing because wk/chrome intervene and fix it
chrishtr: So should we remove the intervention, or require it?
fantasai: So someone was using white ::selection 'background' and
'color'. This works in wk/chrome because neither uses an
opaque background
fantasai: Gecko, following the spec, paints the color as specified
fantasai: So that brings up an interesting question of - we need to
decide whether the specified background is what's used, or
the specified background is modified in some way
fantasai: If UA's differ, you'll get these interop issues
fantasai: They're either assuming the transparency is there, or
assuming it's not, and it might not work in the other cases
fantasai: So we need to have interop on the alpha of the background
color in ::selection
chrishtr: Our code is flipping the color, definitely - I checked
<fantasai> WebKit is using semi-transparent white, though, and
that's probably what the author was expecting
<chris> CSS Color 4 "The following system color pairings are
expected to form legible background-foreground colors ...
Highlight background with HighlightText foreground. "
chris: In Color 4, certain combos of system colors are required to
be legible
chris: One of those pairings is HighlightColor and
HighlightBackground
TabAtkins: This is about author-chosen colors tho
chris: Ah, sorry
leaverou: I'm skeptical about UA intervening in author choices
here...
leaverou: Sounds like this issue happened because author was setting
background and not text?
fantasai: They were setting both
<fantasai> This is a case where the author explicitly asked for
white text and white background
<fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5
leaverou: Wonder if we could set better defaults? Set default
background to always contrast with text color using Color
5 colors
myles: We think the spec should say *at least* that UAs should do
something to make sure text is legible when highlighted
myles: No opinion on how far the spec should go
myles: If the spec had an algorithm, that's fine
myles: If the spec just says "UA must do something", that's fine
with us too
florian: Gets interesting when foreground and background are coming
from different pseudos
florian: As an author you ought to set foreground and background
together, but you can make this mistake
florian: So having a requirement that the UA must ensure the topmost
foreground and background colors must contrast...
florian: Just making sure it's clear this can happen accidentally
from different pseudos interacting, and that should be
considered
<leaverou> maybe we should adopt the previously proposed
currentBackground keyword? Then UA default could be
color: color-contrast(to 4.5 currentBackground vs white,
black); (or appropriate system colors)
fantasai: Cause of the bug:
fantasai: Person filing was assuming a semi-transparent whitewash
with white text
fantasai: Chrome used to do that
fantasai: In Mozilla, it was rendering as solid white on white
<fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5
fantasai: Author literally wrote ::selection { color: white;
background: white; }
fantasai: They were expecting a particular rendering, which they
were getting in Chrome and WebKit, but not Gecko, because
both were applying magic opacity
fantasai: So I think it's harmful for some browsers to have magic
opacity and some not
<leaverou> agreed with fantasai that if author specifies both, they
should be respected
fantasai: So we need to align on some behavior here.
florian: I agree the state we're in is bad. Your proposal is one
possibility. Myles's too - require all browsers to require
legibility, but not specify how
florian: So if you're in a non-legible combo (for any reason,
including the browser applying magic opacity or whatever),
the UA must change something to make it legible.
florian: Mandating one algorithm would be great, but not sure we can
do that.
fantasai: So example: authors chooses a semi-transparent color for
the background. It's just enough to show a selection, but
not enough to be problematic against the background
fantasai: In WK browsers, they'll compound the opacity, so it's even
more faint of a background. No legibility problem, but
there's no longer a visible highlight, which is another
problem.
fantasai: Now author has a problem despite making good choices
originally.
fantasai: Whether we adjust or not is fine, but having it work
differently across browsers is problem.
florian: So from Apple pov, if we specify a particular transparency,
is that a problem for y'all?
smfr: Unsure if we have an answer to that. We want our selection to
match the OS convention, so there's magical opacity
smfr: Don't know if we'd be willing to turn off magic opacity in
some cases, seems hard...
florian: If we specify exactly *your* opacity, would that work? Or
do you reserve the right to change the exact method?
smfr: I don't think it's just opacity, there's a blend mode involved
too
florian: So your behavior is too magic to spec?
smfr: Could probably spec it, but not all platforms might want to
match the Mac OS conventions
fantasai: Don't think people have problems with matching OS
conventions by default, just when the author says
something specific, it should be predictable across
platforms
<gregwhitworth> I agree with fantasai there
smfr: Generally we solve this by adding a CSS property that lets
authors opt out of the correction
fantasai: We do have a long-standing request for a
background-opacity property
florian: So a default value of "auto" that can do magic things in
some OSes?
fantasai: Maybe.
florian: I think we should explore more in this area.
florian: We *will* get interop problems if we don't have something
like this.
Rossen: So should we take this back to the issue?
hober: I think this action sounds reasonable.
hober: Could we resolve on the direction to go in - to require UAs
to ensure there be sufficient contrast, exact details TBD?
hober: UAs do need to do something, right?
florian: I think fantasai pointed out that if you do that, you can
hit the opposite situation, where a good foreground/
background contrast gets magicked into a lack of contrast
between selection and page background?
hober: I think we can word the resolution to avoid that
hober: I hope we can end up with simple details
hober: We just shouldn't punt on this, right?
fantasai: Yes, shouldn't punt. I just think I can throw a lot of
wrenches into this. ^_^
fantasai: Example: author intended transparent selection background
(so UA detection of no contrast between selection
background and page would be a problem) and is using color
change on the text to indicate the selection
fantasai: So there will be a lot of thought needed for the details
fantasai: And I think we should start be having an ability for
authors to specify a more exact interop
<gregwhitworth> if you do it post composite you could but it would
be a bad performance path but would ensure contrast
so the text scenario would result in no adjustment
by the UA
florian: I think we overall agree, just resolving to "browsers must
do X" is a little premature at the moment
<br duration="15min">
<gregwhitworth> we discussed having a smart focus rect to ensure
contrast and decided to not do it since to truly
ensure contrast you'd need to do it post composite
Color Adjust
============
scribe: dlibby
Are normal and light synonymous for color-schemes?
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5898
TabAtkins: Answer is no, not the same, not all UAs display on a
light background by default
TabAtkins: Despite current browser that ship do this, this is not a
requirement
emilio: Tons of things break if you use dark background by default
TabAtkins: Indeed, but works reasonably
florian: Users of console-based UAs tend to expect oddness, VR
browsers might not assume this as well
emilio: How many of these will implement color scheme, and
prefers-color-scheme media feature?
TabAtkins: More VR UAs will show up and assumptions they make are
still valid to consider
fantasai: Some UAs are not browsing the web, might be browsing
books, requirements different from browsing the web in
general
Rossen: Back to TabAtkins' short original answer: "no"
Rossen: Perhaps a bit more is needed, proposed resolution is no, due
to various requirements across UAs and devices
Rossen: Other comments, objections?
RESOLVED: Normal and light are not synonymous, they will stay
Combine forced-color-adjust and color-adjust properties somehow?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3880
leaverou: I was in the breakout, there are many use cases where you
want both. should be an easy way to enable both
leaverou: Perhaps a shorthand would provide flexibility
TabAtkins: I think these are sufficiently different that we
shouldn't turn them off at once. Printing well is
conceptually similar but different that color adjustment
for forced colors
TabAtkins: Wouldn't want to trigger one, but accidentally the other
(i.e. if authors optimize for screen media, not print)
TabAtkins: Suspect they shouldn't be done at the same time
Rossen: In two environments, the properties have almost opposite
effect (on-by-default vs. off-by-default)
Rossen: Historically they have different usage as well, increasing
adoption, I'm on the side of keeping these separate for the
same reasons
fantasai: Agree with reasons to keep them separate. Color swatches
is the one use case I can think of for using them in both
situations.
fantasai: Would be nice for authors be able to have something that
works for future color adjustments, but currently
color-adjust is specific to print
Rossen: Proposed resolution no change - any objections?
RESOLVED: No change, keep both forced-color-adjust and color-adjust
Capitalization: "User Agent" or "user agent"
============================================
github: https://github.com/w3c/csswg-drafts/issues/5200
florian: Writing some spec text and wanted consistency, but we're
completely inconsistent everywhere. Using fully lowercase a
bit more often
florian: Hard to do this in an automated fashion. Uppercase can be
done unconditionally. Maybe we don't care
hober: I don't actually care, can't pretend. w3c style guide says
lowercase so lets follow that
hober: Should update the guide or follow
florian: Hard to do in practice and hard to enforce. You might
automate replacement by being sentence aware
fremy: user agent at the start of a sentence would be User agent not
User Agent, so User Agent is detectably wrong. Maybe we can
put up a warning, think its doable
florian: Yes sounds doable
Rossen: Do we care enough to resolve one way or another?
TabAtkins: I volunteer florian to implement the lowercasing
RESOLVED: Match the style guide of lowercase for "user agent"
Received on Monday, 24 May 2021 22:52:25 UTC