Meeting minutes
Ah, I'm in now
was wondering why I was alone
questions about text decorations on highlight pseudos
<Rossen_> github: https://
fantasai: This is about painting order of text decorations on ::highlight pseudos
fantasai: There is a stacking order fo 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 spearately: 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 over/under/etc 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 wrt text decorations...
smfr: can you give the ordering again?
fantasai: custom highlights are between text and built-in higlights, with selection on top
fantasai: under/overlines defined by non-selection highlights will interleave
fantasai: So proposal is all the underlines, then all underlines, then the text (only once), then all the strikethrus on top.
fantasai: I think this generally makes sense; 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 deco
fantasai: [gives example, i missed some early bits]
i dm'd tantek the ur4l
smfr: So is is true that custom highlights can contribue text decos? 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 decos 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 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
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 raise dthe 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 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.
fantasai: So like if spelling error used a strikethru, that shoudl 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 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.
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
fantasai: So if you specify ::selection { color: yellow; background: blue; }, waht happens?
smfr: Text will be yellow, don't know if we support the background
GameMaker: Let me check...
florian: So you'e 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 transluscent thing, etc.
smfr: Yes, it's special
GameMaker: We already do something special with making even user colors slightly transluscent
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
fantasai: Cool, we have another issue on that. So do you paint that transluscent bg over the text?
GameMaker: Yes.
fantasai: So you can't have yellow text if you have a blue bg, 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 deco it is.
fantasai: "Inner" sort is what type of highlight you hae.
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> 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]
Resolution: 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.
Highlight API collection, maplike vs setlike
<Rossen_> github: https://
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 teh 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 is a Map where key is name and vlaue is Highlight
florian: Another is a Set where name is a property of Highlight.
florian: If you use a Map, you coudl 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 convo 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 thougth 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 prio is associated with the name rather than the highlight, but you'd need a different data structure
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})"
Yeah, it'd take a sequence or options object instead, i guess
<iank_> can't it be a maplike with an additional convenince function?
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
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 prio against each other properly
sanketj: Sounds like you were suggesting having the same highlight be prio'd two different ways, which might be more complicated
florian: I think the proposal is to just do it the naive way - same highligh under two names would share prio
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
<iank_> e.g. ```interface Highlights { readonly maplike<string, Highlight>; addHighlight(Highlight or HightlightDictionary); }```
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 woudl be approriate
leaverou_: agreed
sanketj: We could just document the case from the issue
sanketj: Seems fine
Rossen_: Sounds like we're approaching a reoslution?
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 the3re's enough worth innovating in data structures, versus just letting authors do this
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
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
florian: Right, normal Map behavior
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
Ensuring selection foreground/background contrast
<Rossen_> github: https://
chrishtr: ::selection can set fg and bg 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 fg and bg 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 bg
fantasai: Gecko, following the spec, paints the color as specified
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
fantasai: If UA's differ, you'll get these interop issues
fantasai: They're either assuming the tranparency 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 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.
chrishtr: Our code is flipping the color, definitely - I checked
chris: In Color 4, certain combos of system colors are required to be legible
chris: One of those pairings is HighlightColor and HighlightBackground
<fantasai> WebKit is using semi-transparent white, though, and that's probably what the author was expecting
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 bg and not text?
fantasai: They were setting both
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> https://
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 shoudl go
myles: If the spec had an algo, that's fine
myles: If the spec just says "UA must do something", that's fine with us too
florian: Gets interesting when fg and bg are coming from different pseudos
florian: As an author you ought to set fg and bg together, but you can make this mistake
florian: So ahving a req that the UA must ensure the topmost fg and bg colors must contrast...
florian: Just making sure it's clear this can happen accidentally from different pseudos interacting, and that should be considered
fantasai: Cause of the bug:
fantasai: Person filing was assumign a semi-transparent whitewash with white text
fantasai: Chrome used to do that
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> https://
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, bc both were applying magic opacity
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
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 wahtever), the UA must change something to make it legible.
florian: Mandating one algo woul be great, but not sure we can do that.
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
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.
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: Dont' know if we'd be willing to turn off magic opacity in some cases, seems hard...
florian: If we specify exactly *your* opacity, woudl 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
<gregwhitworth> I agree with fantasai there
fantasai: Don't think people have problems with amtching OS conventions by defautl, just when the author says something specific, it should be predictable across platforms
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 bg-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 ahve 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 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?
hober: I think we can word the reoslution 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: [another example]
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 perf 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
<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
<br duration="15min">
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
No I was describing Ian's thing, sanket
the readonly maplike would be a view into the underlying setlike unique'd by name
Dael: don't make the above replacement
<sanketj> @tabatkins, I see. It got minuted as "sanketj: "
hm, indeed, was that not waht you were describing?
apologies if I mistranscribed, then
<sanketj> The replacement above is what I was intending to say. We should fix that up, unless Tab was intending to transcribe someone else.
Are normal and light synonymous for color-schemes?
<Rossen_> github: https://
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?
Resolution: normal and light are not synonymous, they will stay
Combine forced-color-adjust and color-adjust properties somehow?
<Rossen_> github: https://
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 one. 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?
Resolution: no change, keep both forced-color-adjust and color-adjust
Capitalization: "User Agent" or "user agent"
<Rossen_> github: https://
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
<chris> regex FTW
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
<chris> I'm fairly sure zero interop bugs are caused by this
Resolution: Match the style guide of lowercase for "user agent"
[css-values-4] inherit() function: like var() for parent value, for any property
<Rossen_> github: https://
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
leaverou: we can use it to get the value from the parent
leaverou: should we do work to pursue this? I volunteer if consensus that it is a good idea
leaverou: I can point to many use cases, in case they are not obvious.
emilio: seems implementable, but we want it to work like var() at the token level
emilio: you need to define for each property how it serializes, etc.. it's a lot of work
leaverou: would be equivalent to the token sequence
emilio: but what sequence? font-stretch as an example. you need to get interoperable serialization for all properties
leaverou: don't you need that anyways?
emilio: yes, just pointing out it is a lot of work
Rossen_: this is indiciative of how long it might take to implement
emilio: seems fine to implement
<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]
<fantasai> [that requires a bunch of spec work, QA work, and implementer follow-up to fix all the inconsistencies]
castastrophe: for container queries, computing ancestors comes down to a 'contract' as things are flagged as cascading 'down'
castastrophe: can we use a similar mechanism (!inherited) to indicate such a pattern
emilio: i don't think that is necessary, as long as you inherit with the same property, you already need the complete ancestor style
TabAtkins: shouldn't need that since there is no circularity
smfr: concerned about impl complexity vs. usefulness. in the example, you could say inherit z-index to a font property
leaverou: there are use cases that you have to use a mixture of properties
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
leaverou: in most cases you'll probably end up with an invalid declaration
Rossen_: hearing consensus on what we want to achieve, but some warning on how long this might take
Rossen_: any other points on the topic?
leaverou: proposed resolution - add an inherit function to values-4 to get the value of parent properties
Resolution: adopt an 'inherit' function to values-5
Same behavior or alias for text-justify: inter-character and text-justify: distribute
<Rossen_> github: https://
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
florian: Firefox implements as an alias where distribute serializes to inter-character
fantasai: distribute was implemented in IE5.5 (IIRC), computing in Firefox demonstrates web compatibility, maybe we should go with that behavior
florian: not 100% clear if aliased at parse time or computed value time, but it's being converted
emilio: we do it at computed value time, but wonder if we should do at parse time
florian: compute time is easier to spec, parse time make sense
emilio: we alias a lot of properties at parse time
florian: for values, i'm not sure if it is well specified what it means for a parse-time aliasing
emilio: the only difference is when querying specified style
florian: we can spec Firefox behavior, or we can change to spec to desired behavior
emilio: given that we have a lot of parse-time aliasing, maybe better to go in that direction
fantasai: parse-time aliasing is not actually spec'd so we should figure out where that would go
emilio: [provides example of linear-gradient and -moz-linear-gradient]
Rossen_: this is a good precedent to clean up and specify
fantasai: suggest that existing impl computes, we should update spec to match impl. Separately we should define how aliasing works
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
emilio: sounds good to me
florian: we should not leave the spec as-is, either spec what is happening today or what we want in the future
florian: proposed resolution - update spec to match Gecko implementation
Resolution: update spec to alias at compute time
[fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?
<Rossen_> github: https://
smfr: noticed that % stroke-width are relative to viewport, this seems unexpected that it would change when resize window
smfr: i would expect it to map to line-height or something more local
Rossen_: didn't we have something in the SVG spec that was disambiguating properties that derive from SVG viewport, what happens in CSS
smfr: i don't recall
heycam: transform-box has all the keywords and how they map in non-SVG contexts. we can probably use the same mapping
Rossen_: in most cases resolving to containing box
heycam: that's right
Rossen_: may or may not be expected here
<fantasai> heycam, https://
smfr: context: filed when noticing some odd webkit code, not high priority
<heycam> fantasai: that's it
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
Rossen_: continue to use the escape hatch for weirdness in the future
miriam: consistent translation from SVG makes sense. i associated with text-decoration-thickness which resolves against em
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
fantasai: re: diverging from SVG behavior, would be beneficial for conceptual clarity rather than trying to stay consistent in an unclear manner
fantasai: not sure if %'s on stroke-width on text in SVG is common, maybe we can switch SVG as well?
fantasai: more compat concerns but can't imagine that authors were intentionally using is as it is currently spec'd
Rossen_: worth getting data
fantasai: agreed for SVG, we should probably just do it for CSS
heycam: you can use stroke-width on non-text
heycam: hopefully we can do it across SVG
fantasai: might be more risk, not sure we can change all the behavior
fantasai: we should have percentages resolve against 'font-size', and inherit as a percentage, as it does for text decoration
Rossen_: proposed resolution - for CSS stroke-width on text will resolve percentages against 'computed font-size' size
Resolution: CSS stroke-width on text will resolve percentages against 'em' size
break
<castastrophe> putting the kids to bed - thanks all!
Rossen_: Let's resume!
appearance: base to enable interoperable styling of controls/components
<Rossen_> github: https://
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.
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
gregwhitworth: I want to move forward with the base keyword.
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.
gregwhitworth: UAs want to provide their own defaults. Authors need to opt-in.
gregwhitworth: I'm looking for feedback. questions, thoughts.
emilio: If we want this to change the shadow dom that UAs create, this is better as an attribute, despite that option sucking.
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.
emilio: Making CSS changes affect DOM for them, i suspect it would be more of an issue.
emilio: Conceptually, it feels wrong
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
emilio: I'm definitely okay in getting more interop in form controls.
emilio: This detail probably matters.
emilio: Can chrishtr weigh in?
emilio: Is CSS the right place for this toggle?
<tantek> +1 emilio
hober: My understanding is that we're also pretty reluctant to add more mechanisms in CSS that cause DOM to get created.
hober: So, I think, this does seem like a problem we should be trying to solve. An attribute would be less weird.
hober: ... on the implementation side of things.
florian: In addition to the implementation complexity, I have 2 other reasons for why attributes are probably better.
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.
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
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.
florian: We have multiple things pointing in this direction. All of these work better if we got with an attribute vs a CSS property.
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
florian: We should have an attribute an attribute AND a pseudoclass.
fantasai: We can also add an @supports query.
fantasai: We need a way to answer the question "is this implemented"
florian: The base pseudoclass would mean "is it present AND implemented"
<fremy> +1 to the pseudo-class suggested by florian
florian: pseudoclasses are simpler
<tantek> +1 to considering pseudoclass
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.
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`
Rossen_: Most of the conversation leans toward attribute. gregwhitworth, does that work?
gregwhitworth: I want a resolution, as ammunition for going to WHATWG
gregwhitworth: Also for adding styles to checkbox. I'm looking for a resolution.
florian: 2 resolutions: 1. to use an attribute, and 2. to add a pseudoclass
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
gregwhitworth: I'm fine working on that BTW
<fantasai> "CSS Working Group recommends that"
bkardell_: Wouldn't existing "define" work?
bkardell_: the "define" pseudoclass
bkardell_: should work
bkardell_: I guess not, because it's already defined. never mind
emilio: It almost works, because you can't extend form controls. But maybe you can. If you can, then it doesn't work
gregwhitworth: I don't want to go down that rabbit hole
emilio: It seems cleaner to use a different thing
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
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?
fantasai: Yeah, this is element-by-element
florian: It's also applied element-by-element
fantasai: yeah.
fantasai: I guess that what it's going to have to be. I can't think of a name that makes sense
florian: We should match the name that HTML sues
bkardell_: Can it be 0 specficity?
gregwhitworth: Can we figure this out after I open the issue?
bkardell_: yes.
fantasai: I support gregwhitworth investigating whether or not it should be 0 specificity
Rossen: We were leaning toward using an attribute. Second resolution: Adding a mechanism to detect the state of the feature. Is this right?
Resolution: 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.]
Action: gregwhitworth: Create an issue about adding a mechanism in CSS to determine if this feature is enabled
viewport propagation of scrollbar-gutter
<Rossen__> github: https://
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.
Rossen: This is reverse propagation thing for overflow and direction
fantasai: Overflow doesn't inherit so it's less bad
fantasai: I absolutely hate body propagation rules in CSS. They should die. But the web depends on them. I don't want it to propagated from teh body to the viewport. But we do need to specify that it propagates from the root to viewport.
<tantek> +1 fantasai
emilio: Right. The scroll-snap stuff, and the thing that allows you to do smooth scrolling, those don't propagate.
chrishtr: If the user puts overflow on the body, and <missed> then they're just out of luck?
florian: They should put it on the root instead.
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?
Rossen: let's go back to the actual issue here
Rossen: There's a proposal here about scrollbar gutter.
Rossen: For better or worse, we have behavior today that does the propagation
Rossen: Can we make that work for scrollbar gutter as well
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
fantasai: Let's resolve that we propagate from root to viewport first.
Rossen: Any objections?
Resolution: We propagate scrollbar-gutter from the root to the viewport
Rossen: Now what about body?
Rossen: It still works everywhere. I think our mutual feelings are the same.
fantasai: We're not saying that it should stop working on overflow. W'ere saying we shouldnt' add more properties to that list
<tantek> can we instead introduce an informative WARNING about depending on <body> propagation? (i.e. that devtools could flag for example)
emilio: There was a huge discussion years ago in gecko and other browsers. Gecko only propagates overflow and .....
florian: Overflow, background, and writing mode
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%
emilio: A lot of other properties dont' eitehr
iank_: Overscroll behavior does.
emilio: Scroll snap does
emilio: Those only work on the root
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
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
florian: If you apply a property and it doesnt' do what you want then you fix your code
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 propagate don't propagated to the viewport." https://
chrishtr: I'm okay with the not body thing.
chrishtr: That shortens the conversation
Rossen: I'm okay with this.
Rossen: Anyone else want to keep it?
Rossen: Objections?
<tantek> can we generalize that to any future scroll-*?
Resolution: Scrollbar-gutter does not propagate from <body>
fantasai: Tantek is asking "can we generalize ..."
<tantek> yes please fantasai
fantasai: The proposed resolution is "don't propagate anythign else ever from BODY to viewport"
chrishtr: Do we need a resolution for scrollbar-width and one other?
emilio: Those already don't propagate
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
Rossen: "Anything outside of overflow, direction, and background should not propagate from body"
florian: In addition, we need to propagate some things from HTML to the viewport
florian: Otherwise you can't change the scrollbar width
Rossen: I'm talking about <body>
florian: We should open a new issue about which things need to be propagated from :rootand are missing
fantasai: Proposed resolution: no future properties will propagate from <body> to the ICB
<tantek> +1
chrishtr: I'll open a new issue about scrollbar-width on the HTML element
Rossen: No new objectsion
<fantasai> chrishtr, the spec already defines this
<fantasai> chrishtr, see https://
<fantasai> chrishtr, no need to open an issue...
Resolution: No future properties should propagate from <body> to the ICB or viewport
<chrishtr> fantasai, great!
<tantek> even current properties that don't say they propagate too right?
fantasai: Tantek said something in IRC
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
emilio: I don't feel strongly. but sure.
emilio: Dev tools can warn for whatever without anything in the spec
emilio: We warn for stuff that doesn't apply. Saying "this is bad and you should feel bad" is not good
fantasai: I'm fine with deprecating and making that a statemetn so it can make its way to author-facing materials
fantasai: Deprecating settings values on <body> with the expectation it propagates to root
florian: Making it officially bad. "please don
florian: 't do this"
Resolution: deprecate any existing use of body propagation
Clarify font-optical-sizing behaviour under size-adjust
[css-fonts] Clarify font-optical-sizing behaviour under size-adjust #6190
github: https://
<Rossen__> github: https://
chrishtr: Question of size-adjust interaction with font-optical-sizing
chrishtr: The proposed resolution is to use font-optical-sizing of the used font size
myles: of course
Resolution: font-optical-sizing: auto references the used font-size, accounting for 'size-adjust' and 'font-size-adjust'
[css-display] Should <display-legacy> values be aliased at parse time? #5575
github: https://
github: none
<astearns> fantasai: add a comment with your proposed resolution
end
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