-
Rossen_
Zakim, start meeting
-
Zakim
inviting RRSAgent
-
RRSAgent
-
Zakim
RRSAgent, make logs Public
-
RRSAgent
I have made the request, Zakim
-
Zakim
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
-
Rossen_
present+
-
» Rossen_ is the Google Meet on?
-
» astearns I think we need Google people to let us in, since Christian set up the links
-
TabAtkins
Ah, I'm in now
-
TabAtkins
was wondering why I was alone
-
GameMaker
present+
-
dholbert
present+
-
Morgan
present+
-
miriam
present+
-
florian
present+
-
smfr
present+
-
alisonmaher
present+
-
TYLin
present+
-
plinss
present+
-
dlibby
present+
-
heycam
present+
-
» leaverou2 Will join late
-
sanketj
present+
-
myles
present+ myles
-
fantasai
present+
-
» fantasai can scribe stuff, unsure what stuff
-
TabAtkins
ScribeNick: TabAtkins
-
» gregwhitworth if someone gets tired I can jump in - assuming I'm on the call
-
Rossen_
Topic: questions about text decorations on highlight pseudos
-
hober
present+
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #6022 ([css-pseudo] questions about text decorations on highlight pseudos).
-
gregwhitworth
present+
-
castastrophe
present+
-
astearns
present+
-
fremy
present+
-
TabAtkins
fantasai: This is about painting order of text decorations on ::highlight pseudos
-
TabAtkins
fantasai: There is a stacking order fo the highlights
-
TabAtkins
fantasai: Original text is bottom layer, and things stacked above that: spellcheck, grammar check, target text, selection, something like that
-
TabAtkins
fantasai: defined in spec
-
TabAtkins
fantasai: When you draw text, text and decorations are also layered spearately: overline, underline, text, strikethru, so over/under are below text and strikethru is above
-
TabAtkins
fantasai: so what's the interaction between these two stacking orders
-
TabAtkins
fantasai: the proposal is that you maintain the same order between over/under, text, and strikethrus
-
TabAtkins
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
-
TabAtkins
fantasai: but over/under/etc stack
-
TabAtkins
fantasai: If you have spelling, grammar error and are highlighting, you'll see all the different underlines
-
TabAtkins
fantasai: Suggestion is that we do all the underlines in z-index order, then overlines, then the topmost text, then all the strikethrus
-
TabAtkins
fantasai: So CSS2 ordering is the "outer" ordering
-
TabAtkins
fantasai: This makes strikethru always on top, regardless of where it's from.
-
TabAtkins
fantasai: thoughts?
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
TabAtkins
TabAtkins: sounds reasonable to me, ignoring implementation
-
TabAtkins
dholbert: Do you know how browsers currently do?
-
dbaron
present+
-
TabAtkins
fantasai: i haven't tested who supports the various new highlight pseudos yet.
-
TabAtkins
fantasai: I know there is some weird behavior wrt text decorations...
-
bkardell_
present+
-
» dbaron will be around for a bit, but then have to leave without warning at some point
-
TabAtkins
smfr: can you give the ordering again?
-
TabAtkins
fantasai: custom highlights are between text and built-in higlights, with selection on top
-
TabAtkins
fantasai: under/overlines defined by non-selection highlights will interleave
-
cbiesinger
present+
-
TabAtkins
fantasai: So proposal is all the underlines, then all underlines, then the text (only once), then all the strikethrus on top.
-
TabAtkins
fantasai: I think this generally makes sense; selection has some trickiness on some platforms that i'm not sure about
-
TabAtkins
TabAtkins: I know iOS has a special ordering for ::selection, but not sure if they do text decorations there
-
-
TabAtkins
smfr: No, ::selection is drawn on top of the text, and doesn't allow text deco
-
» tantek RRSAgent, pointer?
-
-
» astearns tantek you’re using the one that ends with yzf?
-
» tantek astearns yes
-
TabAtkins
fantasai: [gives example, i missed some early bits]
-
» dbaron or the code that ends with 935#
-
TabAtkins
i dm'd tantek the ur4l
-
TabAtkins
smfr: So is is true that custom highlights can contribue text decos? And they're sorted in that order with the built-ins?
-
TabAtkins
fantasai: yes
-
TabAtkins
smfr: Okay, now I understand
-
TabAtkins
fantasai: So we could draw the text decors for the lower layers below the text, and draw the text decos for higher layers above the text
-
TabAtkins
fantasai: problem is that strikethru on lower layers would be below the text
-
TabAtkins
fantasai: maybe that's what we want, i dunno
-
» tantek apparently I typed it in wrong 3 times when reading from the email, and somehow was able to type it in correctly from TabAtkins's dm 🤦🏻♂️
-
» tantek thanks TabAtkins
-
chrishtr
q+
-
» Zakim sees chrishtr on the speaker queue
-
» tantek is still the only one in #css-chat
-
TabAtkins
TabAtkins: I think the fact taht 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
-
» fantasai q+
-
» Zakim sees chrishtr, fantasai on the speaker queue
-
» TabAtkins wtf is #css-chat
-
Rossen_
ack chrishtr
-
» Zakim sees fantasai on the speaker queue
-
TabAtkins
smfr: Okay, as long as ::selection is on top, it's fine for us - the rest can sort their decorations together
-
TabAtkins
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
-
TabAtkins
chrishtr: no interop or complexity issues
-
TabAtkins
fantasai: The person who raise dthe issue is implementing in Chrome
-
leaverou_
present+
-
Rossen_
ack fantasai
-
» Zakim sees no one on the speaker queue
-
TabAtkins
fantasai: I wanna be clear, smfr, that the strikethrus of a custom highlight can paint atop a selection
-
TabAtkins
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
-
TabAtkins
fantasai: The point that Tab brought up - that the existence of another custom highligh shouldn't cause a previous custom highlight to have its strikethru go below - is correct, but due to the nature of ::selection, that's probably fine.
-
TabAtkins
fantasai: So like if spelling error used a strikethru, that shoudl paint over the text
-
TabAtkins
fantasai: If you have ::text-target as well, we don't want this to cause the spellcheck strikethru to go under the text
-
TabAtkins
fantasai: But if you select the text, and we say that it causes the text to come to the forefront and paint over the decos, I think taht's reasonable behavior and would solve your concerns on iOS.
-
TabAtkins
smfr: We don't paint the text itslef on that top layer, but just the 'blue wash' the highlights it. I'm fine with reordering the decos, as long as the user selection is atop everything else
-
TabAtkins
fantasai: So if you specify ::selection { color: yellow; background: blue; }, waht happens?
-
TabAtkins
smfr: Text will be yellow, don't know if we support the background
-
TabAtkins
GameMaker: Let me check...
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
TabAtkins
florian: So you'e proposing we *allow* ::selection to be on top, or *require* it?
-
TabAtkins
fantasai: I can go either way. I think ::selection overpainting isn't unreasonable.
-
fantasai
s/overpainting/overpainting all lower-level text decorations/
-
TabAtkins
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 transluscent thing, etc.
-
TabAtkins
smfr: Yes, it's special
-
TabAtkins
GameMaker: We already do something special with making even user colors slightly transluscent
-
TabAtkins
GameMaker: It doesnt' affect text, but if you ahve a red background and yellow selection, it'll be a little transluscent [and look a little orange] - it's not solid color
-
TabAtkins
fantasai: Cool, we have another issue on that. So do you paint that transluscent bg over the text?
-
TabAtkins
GameMaker: Yes.
-
TabAtkins
fantasai: So you can't have yellow text if you have a blue bg, it'll always be a little green?
-
TabAtkins
GameMaker: Yes, but it's a subtle effect, not as green an effect as you think.
-
TabAtkins
florian: So based on this I suggest we *allow* ::selection to be painted atop - don't need to clone iOS.
-
TabAtkins
fantasai: I'm fine with that.
-
TabAtkins
fantasai: Proposal is that the "outer" ordering is CSS2 ordering - what type of deco it is.
-
TabAtkins
fantasai: "Inner" sort is what type of highlight you hae.
-
TabAtkins
fantasai: And as an option, the impl *may* paint all the aspects of the ::selection as a topmost layer above the rest.
-
TabAtkins
Rossen_: Objections?
-
fantasai
fantasai: let's handle background in a separate issue though
-
TabAtkins
chrishtr: I'd just like to have some time to review
-
TabAtkins
[chatter about this being provisional for review or what]
-
chris
present+
-
» chris sorry, just got back from hospital
-
TabAtkins
RESOLVED: Text decos 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.
-
Rossen_
Topic: maplike vs setlike
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5910 ([css-highlight-api] maplike vs setlike).
-
TabAtkins
fantasai: 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 teh stylesheet
-
TabAtkins
s/fantasai/florian/
-
TabAtkins
florian: Question is how to group these
-
TabAtkins
florian: Could say priority is an attribute of the highlight object
-
TabAtkins
florian: But what about the name?
-
TabAtkins
florian: One is a Map where key is name and vlaue is Highlight
-
TabAtkins
florian: Another is a Set where name is a property of Highlight.
-
Rossen_
s/maplike vs setlike/Highlight API collection, maplike vs setlike/
-
TabAtkins
florian: If you use a Map, you coudl potentially register the same highlight multiple times under multiple names.
-
TabAtkins
florian: Has some odd ergonomics for user.
-
TabAtkins
florian: You style ::custom-spelling and ::custom-grammar, but they have the same priority, it's got some odd stacking.
-
TabAtkins
florian: Not *hard* to explain or implement, just unintuitive. We consider it a footgun.
-
TabAtkins
florian: So we decided to make it impossible to set up the same highlight multiple times.
-
hober
q+
-
» Zakim sees hober on the speaker queue
-
TabAtkins
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.
-
TabAtkins
florian: Or a Map that throws if you register multiple.
-
TabAtkins
florian: Or we could just ignore it all and let it happen.
-
leaverou_
q+
-
» Zakim sees hober, leaverou_ on the speaker queue
-
TabAtkins
florian: Currently the spec has it as a Set where name is an attribute, and it throws if you register the same thing twice.
-
TabAtkins
florian: But that's unusual.
-
TabAtkins
florian: Simplest is a Map that doesn't throw, but that might not make sense. But maybe that's fine.
-
TabAtkins
hober: This came up in a TAG review
-
Rossen_
ack hober
-
» Zakim sees leaverou_ on the speaker queue
-
TabAtkins
hober: been several months so convo is swapped out by now...
-
TabAtkins
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"
-
TabAtkins
hober: Might have a few libraries that use highlights for various purposes, and they don't want to clobber themselves
-
TabAtkins
hober: With a Map that's super easy
-
TabAtkins
hober: just check the key
-
TabAtkins
hober: With a set you have to iterate
-
TabAtkins
hober: We thought that's weird, we expected checking to see if it's registered to be a common op
-
TabAtkins
hober: I think we saw the ergonomic downside as more of dev inconvenience than the dev registering the same thing multiple times
-
TabAtkins
hober: So I think we're inclined to just let the dev hurt themselves if they want to register things twice
-
TabAtkins
hober: Not a hill we want to die on, just want common operations to be easy.
-
» fantasai q?
-
» Zakim sees leaverou_ on the speaker queue
-
sanketj
q+
-
» Zakim sees leaverou_, sanketj on the speaker queue
-
TabAtkins
florian: With time that has passed since original decision, sounds good to me
-
Rossen_
ack leaverou_
-
» Zakim sees sanketj on the speaker queue
-
» TabAtkins I think it's fine for the OP to respond in the queue.....
-
TabAtkins
leaverou_: Agree with hober, she said most of what I wanted to
-
TabAtkins
leaverou_: I think using try/catch every time you register a highlight isn't ideal
-
TabAtkins
leaverou_: I think there might even be use-cases for doing this - providing aliases for the same highlight
-
TabAtkins
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?
-
TabAtkins
florian: I thougth about that, but then how would you set it?
-
TabAtkins
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.
-
tantek
present+
-
TabAtkins
sanketj: You could say the prio is associated with the name rather than the highlight, but you'd need a different data structure
-
TabAtkins
Rossen_: What's your position on the change to use Map?
-
iank_
sanketj: likely want an options arg for the ctor, e.g. "new Highlight({name: 'hi', priority: 2})"
-
TabAtkins
Yeah, it'd take a sequence or options object instead, i guess
-
iank_
can't it be a maplike with an additional convenince function?
-
TabAtkins
sanketj: hober and leaverou_'s argumetns make sense. And I think associating prio with highlight is convenient; I'd prefer not to change that if there's not a big reason to
-
TabAtkins
sanketj: If we do allow a highlight to have multiple names, what's the messaging around it?
-
TabAtkins
sanketj: Lea mentioned a use-case; I always thought about this as making a separate Highlight object, then they can prio against each other properly
-
TabAtkins
sanketj: Sounds like you were suggesting having the same highlight be prio'd two different ways, which might be more complicated
-
Rossen_
q?
-
» Zakim sees sanketj on the speaker queue
-
TabAtkins
florian: I think the proposal is to just do it the naive way - same highligh under two names would share prio
-
TabAtkins
florian: So painting order would use the fallback of registration order
-
TabAtkins
florian: A bit limiting, but it's not there *because* of the use-case, it's just the natural fallout.
-
TabAtkins
florian: And if people find ways to make it nice for them, sure.
-
leaverou_
+1 to florian
-
TabAtkins
florian: Probably it's a footgun, but possibly there's good things to come out of it
-
iank_
e.g. ```interface Highlights { readonly maplike<string, Highlight>; addHighlight(Highlight or HightlightDictionary); }```
-
TabAtkins
sanketj: Do we want something in the spec warning against it?
-
leaverou_
Yes, this would need to be a note in the spec
-
TabAtkins
sanketj: Seems could be unexpected results
-
TabAtkins
florian: Don't think we should have a normative thing, but a Note saying this would be odd if you did it woudl be approriate
-
TabAtkins
leaverou_: agreed
-
TabAtkins
sanketj: We could just document the case from the issue
-
TabAtkins
sanketj: Seems fine
-
TabAtkins
Rossen_: Sounds like we're approaching a reoslution?
-
TabAtkins
iank_: I left some IRC comments
-
TabAtkins
iank_: You don't need to strictly make it a setlike - could add convenience functions
-
TabAtkins
iank_: Dunno if this changes the discussion particularly
-
TabAtkins
florian: Not sure what's being proposed to help here
-
TabAtkins
iank_: could make it a readonly maplike, then provide an add() that takes a Highlight, plus a remove()
-
TabAtkins
florian: Does that bring us back to what we have today?
-
TabAtkins
sanketj: I think the impl is that the name would live on the highlight, and also be exposed as a key on the readonly maplike
-
TabAtkins
TabAtkins: I don't think the3re's enough worth innovating in data structures, versus just letting authors do this
-
» astearns smap
-
TabAtkins
porposed 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
-
» Rossen_ astearns, I'll take it over sap
-
» astearns a special set-like map could be a ssmap
-
TabAtkins
leaverou_: Just wnat to make sure that if you register to an existing key, it doesn't throw - that was mentioned in the ear4ly options
-
TabAtkins
florian: Right, normal Map behavior
-
TabAtkins
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
-
Rossen_
Topic: Ensuring selection foreground/background contrast
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #6150 ([css-pseudo-4] Ensuring selection foreground/background contrast).
-
TabAtkins
chrishtr: ::selection can set fg and bg color. What happens if they're not contrasty enough?
-
» fantasai q+
-
» Zakim sees sanketj, fantasai on the speaker queue
-
TabAtkins
chrishtr: If they're the same, you can't read the text
-
TabAtkins
chrishtr: For that reason, wk/chrome has special code to invert one of them in that case
-
TabAtkins
chrishtr: There's at least one site reported as "can't see selections" in Gecko, because fg and bg were both white, and dev might not have noticed it in testing because wk/chrome intervene and fix it
-
TabAtkins
chrishtr: so should we remove the intervention, or require it?
-
chris
q+
-
» Zakim sees sanketj, fantasai, chris on the speaker queue
-
Rossen_
ack sanketj
-
» Zakim sees fantasai, chris on the speaker queue
-
Rossen_
ack fantasai
-
» Zakim sees chris on the speaker queue
-
TabAtkins
fantasai: So someone was using white ::selection 'background' and 'color'. This works in wk/chrome because neither uses an opaque bg
-
TabAtkins
fantasai: Gecko, following the spec, paints the color as specified
-
TabAtkins
fantasai: So that brings up an interesting question of - we need to decide either the specified bg is what's used, or the bg is modified in some way
-
TabAtkins
fantasai: If UA's differ, you'll get these interop issues
-
TabAtkins
fantasai: They're either assuming the tranparency is there, or assuming it's not, and it might not work in the other cases
-
TabAtkins
fantasai: So we need to have interop on the alpha of the bg color in ::selection
-
chris
CSS Color 4 "The following system color pairings are expected to form legible background-foreground colors ... Highlight background with HighlightText foreground.
-
TabAtkins
chrishtr: Our code is flipping the color, definitely - I checked
-
chris
q?
-
» Zakim sees chris on the speaker queue
-
TabAtkins
chris: In Color 4, certain combos of system colors are required to be legible
-
leaverou_
q?
-
» Zakim sees chris on the speaker queue
-
TabAtkins
chris: One of those pairings is HighlightColor and HighlightBackground
-
leaverou_
q+
-
» Zakim sees chris, leaverou_ on the speaker queue
-
fantasai
WebKit is using semi-transparent white, though, and that's probably what the author was expecting
-
TabAtkins
TabAtkins: This is about author-chosen colors tho
-
TabAtkins
chris: Ah, sorry
-
myles
q+
-
» Zakim sees chris, leaverou_, myles on the speaker queue
-
TabAtkins
leaverou_: I'm skeptical about UA intervening in author choices here...
-
TabAtkins
leaverou_: Sounds like this issue happened because author was setting bg and not text?
-
TabAtkins
fantasai: They were setting both
-
Rossen_
q?
-
» Zakim sees chris, leaverou_, myles on the speaker queue
-
Rossen_
ack chris
-
» Zakim sees leaverou_, myles on the speaker queue
-
Rossen_
ack leaverou_
-
» Zakim sees myles on the speaker queue
-
TabAtkins
leaverou_: Wonder if we could set better defaults? Set default bg to always contrast with text color using Color 5 colors
-
fantasai
This is a case where the author explicitly asked for white text and white background
-
fantasai
-
TabAtkins
myles: We think the spec should say *at least* that UAs should do something to make sure text is legible when highlighted
-
» leaverou_ TabAtkins: thanks for minuting my rambling as what I actually intended to say!
-
TabAtkins
myles: No opinion on how far the spec shoudl go
-
TabAtkins
myles: If the spec had an algo, that's fine
-
TabAtkins
myles: If the spec just says "UA must do something", that's fine with us too
-
» fantasai q?
-
» Zakim sees myles on the speaker queue
-
TabAtkins
florian: Gets interesting when fg and bg are coming from different pseudos
-
TabAtkins
florian: As an author you ought to set fg and bg together, but you can make this mistake
-
TabAtkins
florian: So ahving a req that the UA must ensure the topmost fg and bg colors must contrast...
-
TabAtkins
florian: Just making sure it's clear this can happen accidentally from different pseudos interacting, and that should be considered
-
TabAtkins
fantasai: Cause of the bug:
-
TabAtkins
fantasai: Person filing was assumign a semi-transparent whitewash with white text
-
TabAtkins
fantasai: Chrome used to do that
-
TabAtkins
fantasai: In Moz, it was rendering as solid white on white
-
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
-
TabAtkins
fantasai: Author literally wrote ::selection { color: white; background: white; }
-
TabAtkins
fantasai: They were expecting a particular rendering, which they were getting in Chrome and WebKit, but not Gecko, bc both were applying magic opacity
-
TabAtkins
fantasai: So I think ti's harmful for some browsers to have magic opacity and osme not
-
leaverou_
agreed with fantasai that if author specifies both, they should be respected
-
TabAtkins
fantasai: So we need to align on some behavior here.
-
TabAtkins
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
-
TabAtkins
florian: So if you're in a non-legible combo (for any reason, including the browser applying magic opacity or wahtever), the UA must change something to make it legible.
-
TabAtkins
florian: Mandating one algo woul be great, but not sure we can do that.
-
TabAtkins
fantasai: So example: authors choose a semi-transparent color for the bg. It's just enough to show a selection, but not enough to be probablematic against the bg
-
TabAtkins
fantasai: In WK browsers, they'll compound the opacity, so it's even more faint of a bg. No legibility problem, but there's no longer a visible highlight, which is another problem.
-
TabAtkins
fantasai: Now author has a problem despite making good choices originally.
-
TabAtkins
fantasai: Whether we adjust or not is fine, but having it work differently across browsers is problem.
-
TabAtkins
florian: So from Apple pov, if we specify a particular transparency, is that a problem for y'all?
-
TabAtkins
smfr: Unsure if we have an answer to that. We want our selection to match the OS convention, so there's magical opacity
-
TabAtkins
smfr: Dont' know if we'd be willing to turn off magic opacity in some cases, seems hard...
-
TabAtkins
florian: If we specify exactly *your* opacity, woudl that work? Or do you reserve the right to change the exact method?
-
TabAtkins
smfr: I don't think it's just opacity, there's a blend mode involved too
-
TabAtkins
florian: So your behavior is too magic to spec?
-
TabAtkins
smfr: Could probably spec it, but not all platforms might want to match the Mac OS conventions
-
gregwhitworth
I agree with fantasai there
-
TabAtkins
fantasai: Don't think people have problems with amtching OS conventions by defautl, just when the author says something specific, it should be predictable
-
fantasai
s/predictable/predictable across platforms/
-
TabAtkins
smfr: Generally we solve this by adding a CSS property that lets authors opt out of the correction
-
TabAtkins
fantasai: We do have a long-standing request for a bg-opacity property
-
TabAtkins
florian: So a default value of "auto" that can do magic things in some OSes?
-
TabAtkins
fantasai: Maybe.
-
Rossen_
q?
-
» Zakim sees myles on the speaker queue
-
TabAtkins
florian: I think we should explore more in this area.
-
TabAtkins
florian: We *will* get interop problems if we don't ahve something like this.
-
TabAtkins
Rossen_: So should we take this back to the issue?
-
hober
q+
-
» Zakim sees myles, hober on the speaker queue
-
hober
q- myles
-
» Zakim sees hober on the speaker queue
-
Rossen_
ack hober
-
» Zakim sees no one on the speaker queue
-
TabAtkins
hober: I think this action sounds reasonable.
-
TabAtkins
hober: Could we resolve on the direction to go in - to require UAs to ensure there be sufficient contrast, exact details TBD?
-
TabAtkins
hober: UAs do need to do something, right?
-
TabAtkins
florian: I think elika pointed out that if you do that, you can hit the opposite situation, where a good fg/bg contrast gets magicked into a lack of contrast between selection and page bg?
-
TabAtkins
hober: I think we can word the reoslution to avoid that
-
TabAtkins
hober: I hope we can end up with simple details
-
TabAtkins
hober: We just shouldn't punt on this, right?
-
TabAtkins
fantasai: Yes, shouldn't punt. I just think I can throw a lot of wrenches into this. ^_^
-
TabAtkins
fantasai: [another example]
-
TabAtkins
fantasai: So there will be a lot of thought needed for the details
-
TabAtkins
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 perf path but would ensure contrast so the text scenario would result in no adjustment by the UA
-
TabAtkins
florian: I think we overall agree, just resolving to "browsers must do X" is a little premature at the moment
-
fantasai
[another example] = author intended transparent selection background (so UA detection of no contrast between selection bg and page would be a problem) and is using color change on the text to indicate the selection
-
TabAtkins
<br duration="15min">
-
TabAtkins
Topic: end
-
-
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
-
-
sanketj
s/the impl is that the name would live on the highlight, and also be exposed as a key on the readonly maplike/the impl is that the name would not live on the highlight, but be the key to the maplike/
-
TabAtkins
No I was describing Ian's thing, sanket
-
TabAtkins
the readonly maplike would be a view into the underlying setlike unique'd by name
-
» fantasai TabAtkins, if that means don't make the replacement, drop a note to clarify for Dael
-
» astearns all of the errors returned by smap and ssmap objects MUST end in "you dolt!"
-
TabAtkins
Dael: don't make the above replacement
-
emilio
present+
-
sanketj
@tabatkins, I see. It got minuted as "sanketj: "
-
TabAtkins
hm, indeed, was that not waht you were describing?
-
TabAtkins
apologies if I mistranscribed, then
-
» fantasai notes that when y'all decide what the minutes should actually say, pls drop some notes into the IRC log so Dael and I can make sure it's fixed ^_^
-
melanierichards
present+
-
sanketj
The replacement above is what I was intending to say. We should fix that up, unless Tab was intending to transcribe someone else.
-
dlibby_
scribenick: dlibby_
-
Rossen_
Topic: Are normal and light synonymous for color-schemes?
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5898 ([css-color-adjust-1] Are `normal` and `light` synonymous for `color-schemes`?).
-
» fantasai nominates TabAtkins
-
dlibby_
TabAtkins: Answer is no, not the same, not all UAs display on a light background by default
-
dlibby_
TabAtkins: despite current browser that ship do this, this is not a requirement
-
dlibby_
emilio: tons of things break if you use dark background by default
-
dlibby_
TabAtkins: indeed, but works reasonably
-
dlibby_
florian: users of console-based UAs tend to expect oddness, VR browsers might not assume this as well
-
» heycam misinterpreted "console" as e.g. "browser on a Wii"
-
dlibby_
emilio: how many of these will implement color scheme, and prefers-color-scheme media feature?
-
dlibby_
TabAtkins: more VR UAs will show up and assumptions they make are still valid to consider
-
dlibby_
fantasai: some UAs are not browsing the web, might be browsing books, requirements different from browsing the web in general
-
» gregwhitworth I think that "I'm not going to die on this hill" should be a drinking game for this call :)
-
dlibby_
Rossen_: back to TabAtkins' short original answer: "no"
-
dlibby_
Rossen_: perhaps a bit more is needed, proposed resolution is no, due to various requirements across UAs and devices
-
dlibby_
Rossen_: other comments, objections?
-
dlibby_
RESOLVED: normal and light are not synonymous, they will stay
-
Rossen_
Topic: Combine forced-color-adjust and color-adjust properties somehow?
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #3880 ([css-color-adjust-1] Combine forced-color-adjust and color-adjust properties somehow?).
-
dlibby_
leaverou: I was in the breakout, there are many use cases where you want both. should be an easy way to enable both
-
dlibby_
leaverou: perhaps a shorthand would provide flexibility
-
dlibby_
TabAtkins: i think these are sufficiently different that we shouldn't turn them off at one. printing well is conceptually similar but different that color adjustment for forced colors
-
dlibby_
TabAtkins: wouldn't want to trigger one, but accidentally the other (i.e. if authors optimize for screen media, not print)
-
dlibby_
TabAtkins: suspect they shouldn't be done at the same time
-
dlibby_
Rossen_: in two environments, the properties have almost opposite effect (on-by-default vs. off-by-default)
-
dlibby_
Rossen_: historically they have different usage as well, increasing adoption, i'm on the side of keeping these separate for the same reasons
-
dlibby_
fantasai: agree with reasons to keep them separate. color swatches is a use case for using them in both situations.
-
dlibby_
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
-
fantasai
s/a use case/the one use case I can think of /
-
dlibby_
Rossen_: Proposed resolution no change - any objections?
-
» leaverou_ dbaron awwwwwwwwwwwwww, a baby!
-
» fantasai wishes we'd named it print-color-adjust
-
dlibby_
RESOLVED: no change, keep both forced-color-adjust and color-adjust
-
» astearns print-color-adjust is a terrible name for a baby
-
» dlibby_ this one might be hard to minute accurately :)
-
Rossen_
Topic: Capitalization: "User Agent" or "user agent"
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5200 (Capitalization: "User Agent" or "user agent").
-
» TabAtkins oh dang i was wondering who you were d'awwing for on the video, i coudln't see dbaron's pane on my screen!
-
» leaverou_ fantasai agreed. Too late to change? (the property, not the baby!)
-
hober
q+
-
» Zakim sees hober on the speaker queue
-
dlibby_
florian: writing some spec text and wanted consistency, but we're completely inconsistent everywhere. using fully lowercase a bit more often
-
dlibby_
florian: hard to do this in an automated fashion. uppercase can be done unconditionally. maybe we don't care
-
dlibby_
hober: i don't actually care, can't pretend. w3c style guide says lowercase so lets follow that
-
dlibby_
hober: should update the guide or follow
-
» gregwhitworth File a TAG review :)
-
chris
regex FTW
-
» TabAtkins we thought about putting `print-` into the name when originally making it, but wanted it to apply more widely.
-
» Rossen_ gregwhitworth, that's more of an AB/AC issue :)
-
dlibby_
florian: hard to do in practice and hard to enforce. you might automate replacement by being sentence aware
-
dlibby_
fremy: not sure i follow, maybe we can put up a warning, think its doable
-
dlibby_
florian: yes sounds doable
-
dlibby_
Rossen_: do we care enough to resolve one way or another
-
» gregwhitworth lol - do we care enough :) Let's propose on that
-
dlibby_
TabAtkins: I volunteer florian to implement the lowercasing
-
» astearns this is the hill I will die on, my line in the sand…
-
chris
I'm fairly sure zero interop bugs are caused by this
-
fremy
s/not sure i follow/user agent at the start of a sentence would be User agent not User Agent, so User Agent is detectably wrong/
-
dlibby_
RESOLVED: Match the style guide of lowercase for "user agent"
-
Rossen_
Topic: [css-values-4] inherit() function: like var() for parent value, for any property
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #2864 ([css-values-4] inherit() function: like var() for parent value, for any property).
-
» fantasai fremy, that's if we weren't doing User Agent everywhere -- which was the other proposal
-
» fantasai avoids the need for position-sensitivity
-
dlibby_
leaverou: numerous request to extend var() to arbitrary properties, can't do this generally due to cycles. seems to be a less powerful pattern that may be possible
-
dlibby_
leaverou: we can use it to get the value from the parent
-
dlibby_
leaverou: should we do work to pursue this? I volunteer if consensus that it is a good idea
-
» fremy fantasai, Ah yes I see florian's point now. You can flag but it's more difficult to do the replace. Ok, got it now.
-
dlibby_
leaverou: I can point to many use cases, in case they are not obvious.
-
Rossen_
q?
-
» Zakim sees hober on the speaker queue
-
Rossen_
ack hober
-
» Zakim sees no one on the speaker queue
-
dlibby_
emilio: seems implementable, but we want it to work like var() at the token level
-
dlibby_
emilio: you need to define for each property how it serializes, etc.. it's a lot of work
-
dlibby_
leaverou: would be equivalent to the token sequence
-
dlibby_
emilio: but what sequence? font-stretch as an example. you need to get interoperable serialization for all properties
-
dlibby_
leaverou: don't you need that anyways?
-
dlibby_
emilio: yes, just pointing out it is a lot of work
-
dlibby_
Rossen_: this is indiciative of how long it might take to implement
-
dlibby_
emilio: seems fine to implement
-
castastrophe
q+
-
» Zakim sees castastrophe on the speaker queue
-
fantasai
[what emilio is saying is that as a prerequisite to this, we need to get interop on serialization of all properties, which is something we don't have yet]
-
» emilio thanks fantasai :)
-
fantasai
[that requires a bunch of spec work, QA work, and implementer follow-up to fix all the inconsistencies]
-
dlibby_
castastrophe: for container queries, computing ancestors comes down to a 'contract' as things are flagged as cascading 'down'
-
leaverou_
q?
-
TabAtkins
q+ TabAtkins
-
» Zakim sees castastrophe on the speaker queue
-
» Zakim sees castastrophe, TabAtkins on the speaker queue
-
dlibby_
castastrophe: can we use a similar mechanism (!inherited) to indicate such a pattern
-
Rossen_
ack castastrophe
-
» Zakim sees TabAtkins on the speaker queue
-
TabAtkins
ack TabAtkins
-
» Zakim sees no one on the speaker queue
-
» TabAtkins emilio is getting me
-
dlibby_
emilio: i don't think that is necessary, as long as you inherit with the same property, you already need the complete ancestor style
-
smfr
q+
-
» Zakim sees smfr on the speaker queue
-
dlibby_
TabAtkins: shouldn't need that since there is no circularity
-
Rossen_
ack smfr
-
» Zakim sees no one on the speaker queue
-
leaverou_
q?
-
» Zakim sees no one on the speaker queue
-
dlibby_
smfr: concerned about impl complexity vs. usefulness. in the example, you could say inherit z-index to a font property
-
dlibby_
leaverou: there are use cases that you have to use a mixture of properties
-
dlibby_
emilio: this would be implemented via existing serialization rules, so this doesn't explode, you don't convert between properties, use serialization syntax, then reparse token stream
-
dlibby_
leaverou: in most cases you'll probably end up with an invalid declaration
-
dlibby_
Rossen_: hearing consensus on what we want to achieve, but some warning on how long this might take
-
dlibby_
Rossen_: any other points on the topic?
-
dlibby_
leaverou: proposed resolution - add an inherit function to values-4 to get the value of parent properties
-
dlibby_
RESOLVED: adopt an 'inherit' function to values-5
-
Rossen_
Topic: Same behavior or alias for text-justify: inter-character and text-justify: distribute
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #6156 (Same behavior or alias for text-justify: inter-character and text-justify: distribute).
-
dlibby_
florian: in CSS text, we say that text-justify: inter-character has an old name of distribute and has same behavior. should these be aliases, conceptually this makes sense and is what implemetnations do
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
dlibby_
florian: Firefox implements as an alias where distribute serializes to inter-character
-
dlibby_
fantasai: distribute was implemented in IE5, aliasing in Firefox demonstrates web compatibility, maybe we should go with that behavior
-
dlibby_
florian: not 100% clear if aliased at parse time or computed value time, but it's being converted
-
fantasai
s/IE5/IE5.5 (IIRC)/
-
fantasai
s/aliasing/computing/
-
dlibby_
emilio: we do it at computed value time, but wonder if we should do at parse time
-
dlibby_
florian: compute time is easier to spec, parse time make sense
-
dlibby_
emilio: we alias a lot of properties at parse time
-
dlibby_
florian: for values, i'm not sure if it is well specified what it means for a parse-time aliasing
-
dlibby_
emilio: the only difference is when querying specified style
-
dlibby_
florian: we can spec Firefox behavior, or we can change to spec to desired behavior
-
dlibby_
emilio: given that we have a lot of parse-time aliasing, maybe better to go in that direction
-
dlibby_
fantasai: parse-time aliasing is not actually spec'd so we should figure out which direction to go
-
fantasai
s/which direction to/where that would/
-
dlibby_
emilio: [provides example of linear-gradient and -moz-linear-gradient]
-
dlibby_
Rossen_: this is a good precedent to clean up and specify
-
dlibby_
fantasai: suggest that existing impl computes, we should update spec to match impl. Separately we should define how aliasing works
-
dlibby_
fantasai: at that point, if Gecko wants to change the text spec to use the alias definition, we can do that in a separate step
-
dlibby_
emilio: sounds good to me
-
dlibby_
florian: we should not leave the spec as-is, either spec what is happening today or what we want in the future
-
dlibby_
florian: proposed resolution - update spec to match Gecko implementation
-
dlibby_
RESOLVED: update spec to alias at compute time
-
Rossen_
Topic: [fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?
-
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #6116 ([fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?).
-
dlibby_
smfr: noticed that % stroke-width are relative to viewport, this seems unexpected that it would change when resize window
-
dlibby_
smfr: i would expect it to map to line-height or something more local
-
-
» github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
-
dlibby_
Rossen_: didn't we have something in the SVG spec that was disambiguating properties that derive from SVG viewport, what happens in CSS
-
dlibby_
smfr: i don't recall
-
miriam
q+
-
» Zakim sees miriam on the speaker queue
-
» fantasai q+
-
» Zakim sees miriam, fantasai on the speaker queue
-
dlibby_
heycam: transform-box has all the keywords and how they map in non-SVG contexts. we can probably use the same mapping
-
dlibby_
Rossen_: in most cases resolving to containing box
-
dlibby_
heycam: that's right
-
dlibby_
Rossen_: may or may not be expected here
-
fantasai
-
dlibby_
smfr: context: filed when noticing some odd webkit code, not high priority
-
heycam
fantasai: that's it
-
dlibby_
Rossen_: I'd like to align behaviors that is coming from SVG, and how to map the concepts when they come to CSS
-
heycam
so 'border-box' according to that definition
-
dlibby_
Rossen_: continue to use the escape hatch for weirdness in the future
-
Rossen_
ack miriam
-
» Zakim sees fantasai on the speaker queue
-
dlibby_
miriam: consistent translation from SVG makes sense. i associated with text-decoration-thickness which resolves against em
-
dlibby_
fantasai: there's not a good reason for text stroke width to reference contaning box, but resolving against font metrics makes sense, and we should do what is useful if there are no webcompat concerns
-
Rossen_
ack fantasai
-
» Zakim sees no one on the speaker queue
-
dlibby_
fantasai: re: diverging from SVG behavior, would be beneficial for conceptual clarity rather than trying to stay consistent in an unclear manner
-
dlibby_
fantasai: not sure if %'s on stroke-width on text in SVG is common, maybe we can switch SVG as well?
-
heycam
q+
-
» Zakim sees heycam on the speaker queue
-
dlibby_
fantasai: more compat concerns but can't imagine that authors were intentionally using is as it is currently spec'd
-
dlibby_
Rossen_: worth getting data
-
dlibby_
fantasai: agreed for SVG, we should probably just do it for CSS
-
dlibby_
heycam: you can use stroke-width on non-text
-
Rossen_
ack heycam
-
» Zakim sees no one on the speaker queue
-
dlibby_
heycam: hopefully we can do it across SVG
-
dlibby_
fantasai: might be more risk, not sure we can change all the behavior
-
dlibby_
fantasai: we should have percentages resolve against 'em' since it provides a pixel value
-
fantasai
s/'em' since it provides a pixel value/'font-size', and inherit as a percentage, as it does for text decoration/
-
dlibby_
Rossen_: proposed resolution - for CSS stroke-width on text will resolve percentages against 'em' size
-
fantasai
s/em/computed font-size/
-
dlibby_
RESOLVED: CSS stroke-width on text will resolve percentages against 'em' size
-
Rossen_
Topic: break
-
-
» heycam emilio thanks :)
-
castastrophe
putting the kids to bed - thanks all!
-
myles
ScribeNick: myles
-
myles
Rossen_: Let's resume!
-
Rossen_
Topic: appearance: base to enable interoperable styling of controls/components
-
Rossen_
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5998 ([css-ui] appearance: base to enable interoperable styling of controls/components).
-
myles
gregwhitworth: The context is that we're trying to start down the path of standardizing form controls and components. We'll need an agreed-upon DOM and styles.
-
myles
gregwhitworth: Last time I presented on this, I presented about the base appearance keyword and the pseudo element for checkbox. I want to de-tangle them. I've had requests for input type=range
-
myles
gregwhitworth: I want to move forward with the base keyword.
-
myles
gregwhitworth: For more context, the base keyword would be a toggle that informs the browser that you want to have a standardized dom and styles for a given element. That would allow you to style interoperably.
-
myles
gregwhitworth: UAs want to provide their own defaults. Authors need to opt-in.
-
emilio
q+
-
» Zakim sees emilio on the speaker queue
-
myles
gregwhitworth: I'm looking for feedback. questions, thoughts.
-
» fantasai q+
-
» Zakim sees emilio, fantasai on the speaker queue
-
» tantek listents
-
Rossen_
ack emilio
-
» Zakim sees fantasai on the speaker queue
-
florian
q+
-
» Zakim sees fantasai, florian on the speaker queue
-
» tantek listens even
-
» fantasai q- later
-
» Zakim sees florian, fantasai on the speaker queue
-
myles
emilio: If we want this to change the shadow dom that UAs create, this is better as an attribute, despite that option sucking.
-
myles
emilio: for gecko, it's kind of okay to create a lot of dom during layout. it's not amazing. I'd like to get rid of that mechanism. Blink generates the shadow dom at the DOM level, not depending on layout.
-
myles
emilio: Making CSS changes affect DOM for them, i suspect it would be more of an issue.
-
myles
emilio: Conceptually, it feels wrong
-
myles
gregwhitworth: Sure. I'm primarily .... not that that's bikeshedding .... I want to get at the more meta-issue. If implementors say they prefer the attribute, I can bring this to WHATWG. I'm asking if this group accepts standardized styles and standarized DOM
-
myles
emilio: I'm definitely okay in getting more interop in form controls.
-
myles
emilio: This detail probably matters.
-
myles
emilio: Can chrishtr weigh in?
-
hober
q+
-
» Zakim sees florian, fantasai, hober on the speaker queue
-
myles
emilio: Is CSS the right place for this toggle?
-
» fantasai hober, feel free to cut me
-
tantek
+1 emilio
-
myles
hober: My understanding is that we're also pretty reluctant to add more mechanisms in CSS that cause DOM to get created.
-
» tantek in general is opposed to any extension to the 'appearance' property, but that's a lower level concern (borderline bikeshedding)
-
myles
hober: So, I think, this does seem like a problem we should be trying to solve. An attribute would be less weird.
-
myles
hober: ... on the implementation side of things.
-
Rossen_
ack florian
-
» Zakim sees fantasai, hober on the speaker queue
-
myles
florian: In addition to the implementation complexity, I have 2 other reasons for why attributes are probably better.
-
Rossen_
ack hober
-
» Zakim sees fantasai on the speaker queue
-
myles
florian: 1. If we got with a CSS property with a single bas keyword, we need to introduce it simultaneously on all the elements that accept it, or have a bunch of values so people can detect their way into doing the right thing. That problem isn't true if we do it as an attribute.
-
myles
florian: 2. Depending on whether an element is base or not base, you want to style it differently. If you cause it to be base or not base through CSS, then you can't select on it.
-
tantek
+1 florian about what you want to style differently
-
myles
florian: The UA stylesheet needs to be different for a regular checkbox vs a base checkbox, if the switch is in CSS, all that solves itself if the switch is done via an attributre.
-
Rossen_
ack fantasai
-
» Zakim sees no one on the speaker queue
-
myles
florian: We have multiple things pointing in this direction. All of these work better if we got with an attribute vs a CSS property.
-
myles
fantasai: Just to throw a wrench into that, florian, you want to style them differently based on the attribute, but also on whether or not the browser supports that attribute
-
myles
florian: We should have an attribute an attribute AND a pseudoclass.
-
myles
fantasai: We can also add an @supports query.
-
myles
fantasai: We need a way to answer the question "is this implemented"
-
myles
florian: The base pseudoclass would mean "is it present AND implemented"
-
fremy
+1 to the pseudo-class suggested by florian
-
myles
florian: pseudoclasses are simpler
-
tantek
+1 to considering pseudoclass
-
myles
fantasai: For style vs content vs behavior, this belongs more in CSS than HTML. But emilio and florian gave good arguments for why it might have to end up in HTML regardless.
-
myles
fantasai: If we add appearance: value, I would go for appearance: basic
-
tantek
in general I'm opposed to any extension to the 'appearance' property, but that's a lower level concern
-
heycam
`input[type=checkbox]:custom`
-
myles
Rossen_: Most of the conversation leans toward attribute. gregwhitworth, does that work?
-
myles
gregwhitworth: I want a resolution, as ammunition for going to WHATWG
-
myles
gregwhitworth: Also for adding styles to checkbox. I'm looking for a resolution.
-
myles
florian: 2 resolutions: 1. to use an attribute, and 2. to add a pseudoclass
-
myles
fantasai: proposed resolution: This functionality be pursued as an attribute, and CSS adds a mechanism to detect an element in this mode in a browser that has support for it
-
myles
gregwhitworth: I'm fine working on that BTW
-
fantasai
"CSS Working Group recommends that"
-
myles
bkardell_: Wouldn't existing "define" work?
-
myles
bkardell_: the "define" pseudoclass
-
myles
bkardell_: should work
-
myles
bkardell_: I guess not, because it's already defined. never mind
-
myles
emilio: It almost works, because you can't extend form controls. But maybe you can. If you can, then it doesn't work
-
myles
gregwhitworth: I don't want to go down that rabbit hole
-
myles
emilio: It seems cleaner to use a different thing
-
myles
Proposed resolution: This functionality be pursued as an attribute instead of a CSS property, and CSS adds a mechanism to detect an element in this mode in a browser that has support for it
-
bkardell_
it woudl already be true, is the real problem I think
-
myles
florian: I support the resolution as it stands. But I would also support a more specific resolution: the mechanism is a pseduclass. @supports would be awkward. Psedudoclass would make it easy. If we do a pseudoclass, we have to figure out which element you're testing against. Would look like a selector
-
bkardell_
0 specificity pseudo please?
-
myles
fantasai: Yeah, this is element-by-element
-
myles
florian: It's also applied element-by-element
-
myles
fantasai: yeah.
-
myles
fantasai: I guess that what it's going to have to be. I can't think of a name that makes sense
-
myles
florian: We should match the name that HTML sues
-
myles
bkardell_: Can it be 0 specficity?
-
myles
gregwhitworth: Can we figure this out after I open the issue?
-
myles
bkardell_: yes.
-
myles
fantasai: I support greg investigating whether or not it should be 0 specificity
-
myles
s/greg/gregwhitworth/
-
myles
Rossen: We were leaning toward using an attribute. Second resolution: Adding a mechanism to detect the state of the feature. Is this right?
-
myles
RESOLVED: This feature should be solved with an attribute rather than a CSS value
-
fantasai
[I would like to note that it's not great that, in order to change the styling of the form element, it's necessary to change the markup. But it seems we're constrained by practical considerations.]
-
» bkardell_ awaits a resolution that myles is awesome
-
» hober |myles is awe|some
-
myles
ACTION gregwhitworth: Create an issue about adding a mechanism in CSS to determine if this feature is enabled
-
» RRSAgent records action 1
-
» gregwhitworth thanks for helping on that folks :)
-
Rossen__
Topic: viewport propagation of scrollbar-gutter
-
-
Rossen__
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #6079 ([css-overflow-4] viewport propagation of scrollbar-gutter).
-
» fantasai q+
-
» Zakim sees fantasai on the speaker queue
-
myles
chrishtr: when you apply properties on the HTML or body elements, under certain conditions, ti gets propagated to the root element's scroller. Does this apply to scrollbar gutter properties? Proposed: yes.
-
myles
Rossen: This is reverse propagation thing for overflow and direction
-
myles
fantasai: Overflow doesn't inherit so it's less bad
-
Rossen__
ack fantasai
-
» Zakim sees no one on the speaker queue
-
» tantek waits for the DIAF comment
-
myles
fantasai: I absolutely hate body propagation rules in CSS. They should die. The web depends on them. I don't want it to propagated from teh body to the viewport
-
tantek
+1 fantasai
-
myles
emilio: Right. The scroll-snap stuff, and the thing that allows you to do smooth scrolling, those don't propagate.
-
fantasai
s/The web/But the web/
-
myles
chrishtr: If the user puts overflow on the body, and <missed> then they're just out of luck?
-
myles
florian: They should put it on the root instead.
-
fantasai
s/to the viewport/to the viewport. But we do need to specify that it propagates from the root to viewport./
-
myles
florian: Putting things on HTML instead of body causes no problem. It's confusing if you've put it on body and it works, but you want to put other stuff on body but it doesn't work
-
tantek
+1 florian, can we deprecate putting it on body so it's still "supported" but warned in CSS validators?
-
myles
Rossen: let's go back to the actual issue here
-
myles
Rossen: There's a proposal here about scrollbar gutter.
-
» fantasai q+
-
» Zakim sees fantasai on the speaker queue
-
myles
Rossen: For better or worse, we have behavior today that does the propagation
-
myles
Rossen: Can we make that work for scrollbar gutter as well
-
» fantasai q-
-
» Zakim sees no one on the speaker queue
-
myles
florian: There are 2 potential resolution. The first is required. Propagate from the root to the viewport is required. Whether or not we ALSO propagate from the body is controvertial
-
tantek
+1
-
myles
fantasai: Let's resolve that we propagate from root to viewport first.
-
myles
Rossen: Any objections?
-
myles
RESOLVED: We propagate scrollbar-gutter from the root to the viewport
-
myles
Rossen: Now what about body?
-
myles
Rossen: It still works everywhere. I think our mutual feelings are the same.
-
heycam
q+
-
» Zakim sees heycam on the speaker queue
-
myles
fantasai: We're not saying that it should stop working on overflow. W'ere saying we shouldnt' add more properties to that list
-
chrishtr
q+
-
» Zakim sees heycam, chrishtr on the speaker queue
-
tantek
can we instead introduce an informative WARNING about depending on <body> propagation? (i.e. that devtools could flag for example)
-
myles
emilio: There was a huge discussion years ago in gecko and other browsers. Gecko only propagates overflow and .....
-
myles
florian: Overflow, background, and writing mode
-
myles
emilio: Browser do differen things. Fancy new properties dont' propagate. Let's leave it as it is. Not propagate from body to root.
-
tantek
+1 emilio
-
florian
s/writing-mode/principal writing mode (i.e. writing-mode and direction)/
-
fantasai
tantek, I'm happy to warn about it for the properties which currently do propagate (overflow/background/direction/writing-mode). But I *do not* want to add more properties to that list.
-
tantek
fantasai, 100%
-
myles
emilio: A lot of other properties dont' eitehr
-
myles
iank_: Overscroll behavior does.
-
myles
emilio: Scroll snap does
-
myles
emilio: Those only work on the root
-
myles
emilio: If UAs want to add a warning, if you detect you ahve a body that's not scrollable and it has scroll properties, they can log them to the console, that would be helpful, but let's not add more propagation
-
» tantek checks scrollbar colors 😬
-
myles
Rossen: It's less worse to put your custom scroll bar ... is to not have the appropriate space for it, so you're risking to have some broken UI experience in this case
-
Rossen__
q?
-
» Zakim sees heycam, chrishtr on the speaker queue
-
myles
florian: If you apply a property and it doesnt' do what you want then ... <missed>
-
florian
s/... <missed>/you fix your code/
-
Rossen__
ack heycam
-
» Zakim sees chrishtr on the speaker queue
-
myles
heycam: I was going to askw hat the specific list of scrollbar related properties is that currently propagates from body to the viewport. I don't wnat to end up in a situation where some scrollbar related things propagate but others don't. If scroll snaping and scrollbar color and scrollbar width propagate, then that's good
-
tantek
A-ha "scrollbar-color value set on the HTML body element are not propagated to the viewport."
drafts.csswg.org/css-scrollbars-1/#scrollbar-color
-
fantasai
s/propagate/propagate don't propagate/
-
» tantek sighs a sigh of relief
-
myles
chrishtr: I'm okay with the not body thing.
-
myles
chrishtr: That shortens the conversation
-
myles
Rossen: I'm okay with this.
-
» fantasai :)
-
myles
Rossen: Anyone else want to keep it?
-
myles
Rossen: Objections?
-
tantek
can we generalize that to any future scroll-*?
-
myles
RESOLVED: Scrollbar-gutter does not propagate from <body>
-
» astearns also resolved: use this property as a precedent for future propagation decisions
-
myles
fantasai: Tantek is asking "can we generalize ..."
-
tantek
yes please fantasai
-
myles
fantasai: The proposed resolution is "don't propagate anythign else ever"
-
myles
chrishtr: Do we need a resolution for scrollbar-width and one other?
-
tantek
s/else ever/else ever from BODY to viewport
-
myles
emilio: Those already don't propagate
-
myles
Rossen: I think that was the generalized proposed resolution that fantasai said
-
fantasai
chrishtr, they do propagate from the root already
-
tantek
no more BODY propagation
-
myles
Rossen: "Anything outside of overflow, direction, and background should not propagate from body"
-
myles
florian: In addition, we need to propagate some things from HTML to the viewport
-
myles
florian: Otherwise you can't change the scrollbar width
-
myles
Rossen: I'm talking about <body>
-
myles
florian: We should open a new issue about which things need to be propagated and are missing
-
myles
fantasai: Proposed resolution: no future properties will propagate from <body> to the ICB
-
tantek
+1
-
myles
chrishtr: I'll open a new issue about scrollbar-width on the HTML element
-
florian
s/to be propagated /to be propagated from :root/
-
myles
Rossen: No new objectsion
-
fantasai
chrishtr, the spec already defines this
-
fantasai
-
fantasai
chrishtr, no need to open an issue...
-
myles
RESOLVED: No future properties should propagate from <body> to the ICB
-
chrishtr
fantasai, great!
-
tantek
even current properties that don't say they propagate too right?
-
fantasai
s/ICB/ICB or viewport/
-
myles
fantasai: Tantek said something in IRC
-
myles
tantek: proposal: deprecate, or add a warning, to any existing use of body propagation. This would enable CSS validators and dev tools to warn and flag when they depend on that behavior
-
myles
emilio: I don't feel strongly. but sure.
-
myles
emilio: Dev tools can warn for whatever without anything in the spec
-
myles
emilio: We warn for stuff that doesn't apply. Saying "this is bad and you should feel bad" is not good
-
myles
fantasai: I'm fine with deprecating and making that a statemetn so it can make its way to author-facing materials
-
myles
fantasai: Deprecating settings values on <body> with the expectation it propagates to root
-
myles
florian: Making it officially bad. "please don
-
myles
florian: 't do this"
-
myles
RESOLVED: deprecate any existing use of body propagation
-
» bkardell_ neigh
-
» tantek wanted to dig that hole
-
fantasai
scribenick: fantasai
-
Rossen__
Topic: Clarify font-optical-sizing behaviour under size-adjust
-
-
fantasai
Topic: [css-fonts] Clarify font-optical-sizing behaviour under size-adjust #6190
-
fantasai
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #6190 ([css-fonts] Clarify font-optical-sizing behaviour under size-adjust).
-
Rossen__
-
fantasai
chrishtr: Question of size-adjust interaction with font-optical-sizing
-
fantasai
chrishtr: The proposed resolution is to use font-optical-sizing of the used font size
-
fantasai
myles: of course
-
» astearns is disappointed easy-peasy/lemon-squeezy didn’t make it to the official minutes
-
fantasai
RESOLVED: font-optical-sizing: auto references the used font-size, accounting for 'size-adjust' and 'font-size-adjust'
-
» tantek lemons are not really easy to squeeze
-
fantasai
Topic: [css-display] Should <display-legacy> values be aliased at parse time? #5575
-
-
fantasai
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5575 ([css-display] Should <display-legacy> values be aliased at parse time?).
-
fantasai
github: none
-
» github-bot OK, I won't post this discussion to GitHub.
-
astearns
fantasai: add a comment with your proposed resolution
-
Rossen__
Topic: end
-
fantasai
proposed resolution: resolve at computed value time, not at parse time, so that specified value is how you specified it
-
astearns
we have plenty of agenda already to fill next week’s meeting
-
Rossen__
Zakim, end meeting
-
Zakim
As of this point the attendees have been Rossen_, GameMaker, dholbert, Morgan, miriam, florian, smfr, alisonmaher, TYLin, plinss, dlibby, heycam, sanketj, myles, fantasai, hober,
-
Zakim
... gregwhitworth, castastrophe, astearns, fremy, dbaron, bkardell_, cbiesinger, leaverou_, chris, tantek, emilio, melanierichards
-
Zakim
RRSAgent, please draft minutes v2
-
RRSAgent
I have made the request to generate
w3.org/2021/04/08-css-minutes.html Zakim
-
Zakim
I am happy to have been of service, Rossen__; please remember to excuse RRSAgent. Goodbye