Zakim, start meeting

present+

Ah, I'm in now

was wondering why I was alone

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+

present+ myles

present+

ScribeNick: TabAtkins

Topic: questions about text decorations on highlight pseudos

present+

github: w3c/csswg-drafts #6022

present+

present+

present+

present+

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?

q?

TabAtkins: sounds reasonable to me, ignoring implementation

dholbert: Do you know how browsers currently do?

present+

fantasai: i haven't tested who supports the various new highlight pseudos yet.

fantasai: I know there is some weird behavior wrt text decorations...

present+

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

present+

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

q+

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

ack chrishtr

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

present+

ack fantasai

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...

q?

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 isn't unreasonable.

s/overpainting/overpainting all lower-level text decorations/

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: 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]

present+

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.

Topic: maplike vs setlike

github: w3c/csswg-drafts #5910

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

s/fantasai/florian/

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.

s/maplike vs setlike/Highlight API collection, maplike vs setlike/

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.

q+

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.

q+

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

ack hober

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.

q+

florian: With time that has passed since original decision, sounds good to me

ack leaverou_

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.

present+

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?

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

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

q?

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.

+1 to florian

florian: Probably it's a footgun, but possibly there's good things to come out of it

e.g. ```interface Highlights { readonly maplike<string, Highlight>; addHighlight(Highlight or HightlightDictionary); }```

sanketj: Do we want something in the spec warning against it?

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 live on the highlight, and also be exposed as a key on the readonly 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

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

Topic: Ensuring selection foreground/background contrast

github: w3c/csswg-drafts #6150

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?

q+

ack sanketj

ack fantasai

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

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

q?

chris: In Color 4, certain combos of system colors are required to be legible

q?

chris: One of those pairings is HighlightColor and HighlightBackground

q+

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

q+

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

q?

ack chris

ack leaverou_

leaverou_: Wonder if we could set better defaults? Set default bg to always contrast with text color using Color 5 colors

This is a case where the author explicitly asked for white text and white background

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

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: 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

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

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

s/predictable/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.

q?

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?

q+

q- myles

ack hober

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

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

[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">

Topic: end

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

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/

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

present+

@tabatkins, I see. It got minuted as "sanketj: "

hm, indeed, was that not waht you were describing?

apologies if I mistranscribed, then

present+

The replacement above is what I was intending to say. We should fix that up, unless Tab was intending to transcribe someone else.

scribenick: dlibby_

Topic: Are normal and light synonymous for color-schemes?

github: w3c/csswg-drafts #5898

TabAtkins: Answer is no, not the same, not all UAs display on a light background by default

TabAtkins: despite current browser that ship do this, this is not a requirement

emilio: tons of things break if you use dark background by default

TabAtkins: indeed, but works reasonably

florian: users of console-based UAs tend to expect oddness, VR browsers might not assume this as well

emilio: how many of these will implement color scheme, and prefers-color-scheme media feature?

TabAtkins: more VR UAs will show up and assumptions they make are still valid to consider

fantasai: some UAs are not browsing the web, might be browsing books, requirements different from browsing the web in general

Rossen_: back to TabAtkins' short original answer: "no"

Rossen_: perhaps a bit more is needed, proposed resolution is no, due to various requirements across UAs and devices

Rossen_: other comments, objections?

RESOLVED: normal and light are not synonymous, they will stay

Topic: Combine forced-color-adjust and color-adjust properties somehow?

github: w3c/csswg-drafts #3880

leaverou: I was in the breakout, there are many use cases where you want both. should be an easy way to enable both

leaverou: perhaps a shorthand would provide flexibility

TabAtkins: i think these are sufficiently different that we shouldn't turn them off at 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 a use case 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

s/a use case/the one use case I can think of /

Rossen_: Proposed resolution no change - any objections?

RESOLVED: no change, keep both forced-color-adjust and color-adjust

Topic: Capitalization: "User Agent" or "user agent"

github: w3c/csswg-drafts #5200

q+

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

regex FTW

florian: hard to do in practice and hard to enforce. you might automate replacement by being sentence aware

fremy: not sure i follow, 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

I'm fairly sure zero interop bugs are caused by this

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/

RESOLVED: Match the style guide of lowercase for "user agent"

Topic: [css-values-4] inherit() function: like var() for parent value, for any property

github: w3c/csswg-drafts #2864

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.

q?

ack hober

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

q+

[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]

[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'

q?

q+ TabAtkins

castastrophe: can we use a similar mechanism (!inherited) to indicate such a pattern

ack castastrophe

ack TabAtkins

emilio: i don't think that is necessary, as long as you inherit with the same property, you already need the complete ancestor style

q+

TabAtkins: shouldn't need that since there is no circularity

ack smfr

q?

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

RESOLVED: adopt an 'inherit' function to values-5

Topic: Same behavior or alias for text-justify: inter-character and text-justify: distribute

github: w3c/csswg-drafts #6156

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

q?

florian: Firefox implements as an alias where distribute serializes to inter-character

fantasai: distribute was implemented in IE5, aliasing 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

s/IE5/IE5.5 (IIRC)/

s/aliasing/computing/

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 which direction to go

s/which direction to/where that would/

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

RESOLVED: update spec to alias at compute time

Topic: [fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?

github: w3c/csswg-drafts #6116

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

q+

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

heycam, w3.org/TR/css-box-3/#keywords ?

smfr: context: filed when noticing some odd webkit code, not high priority

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

so 'border-box' according to that definition

Rossen_: continue to use the escape hatch for weirdness in the future

ack miriam

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

ack fantasai

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?

q+

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

ack heycam

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 'em' since it provides a pixel value

s/'em' since it provides a pixel value/'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 'em' size

s/em/computed font-size/

RESOLVED: CSS stroke-width on text will resolve percentages against 'em' size

Topic: break

putting the kids to bed - thanks all!

ScribeNick: myles

Rossen_: Let's resume!

Topic: appearance: base to enable interoperable styling of controls/components

github: w3c/csswg-drafts #5998

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.

q+

gregwhitworth: I'm looking for feedback. questions, thoughts.

ack emilio

q+

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?

q+

emilio: Is CSS the right place for this toggle?

+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.

ack florian

florian: In addition to the implementation complexity, I have 2 other reasons for why attributes are probably better.

ack hober

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.

+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.

ack fantasai

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"

+1 to the pseudo-class suggested by florian

florian: pseudoclasses are simpler

+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

in general I'm opposed to any extension to the 'appearance' property, but that's a lower level concern

`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

"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

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

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 greg investigating whether or not it should be 0 specificity

s/greg/gregwhitworth/

Rossen: We were leaning toward using an attribute. Second resolution: Adding a mechanism to detect the state of the feature. Is this right?

RESOLVED: This feature should be solved with an attribute rather than a CSS value

[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

Topic: viewport propagation of scrollbar-gutter

github: w3c/csswg-drafts #6079

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

ack fantasai

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

+1 fantasai

emilio: Right. The scroll-snap stuff, and the thing that allows you to do smooth scrolling, those don't propagate.

s/The web/But the web/

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.

s/to the viewport/to the viewport. But we do need to specify that it propagates from the root to viewport./

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

+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

+1

fantasai: Let's resolve that we propagate from root to viewport first.

Rossen: Any objections?

RESOLVED: 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.

q+

fantasai: We're not saying that it should stop working on overflow. W'ere saying we shouldnt' add more properties to that list

q+

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.

+1 emilio

s/writing-mode/principal writing mode (i.e. writing-mode and direction)/

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.

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

q?

florian: If you apply a property and it doesnt' do what you want then ... <missed>

s/... <missed>/you fix your code/

ack heycam

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

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

s/propagate/propagate don't propagate/

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?

can we generalize that to any future scroll-*?

RESOLVED: Scrollbar-gutter does not propagate from <body>

fantasai: Tantek is asking "can we generalize ..."

yes please fantasai

fantasai: The proposed resolution is "don't propagate anythign else ever"

chrishtr: Do we need a resolution for scrollbar-width and one other?

s/else ever/else ever from BODY to viewport

emilio: Those already don't propagate

Rossen: I think that was the generalized proposed resolution that fantasai said

chrishtr, they do propagate from the root already

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 and are missing

fantasai: Proposed resolution: no future properties will propagate from <body> to the ICB

+1

chrishtr: I'll open a new issue about scrollbar-width on the HTML element

s/to be propagated /to be propagated from :root/

Rossen: No new objectsion

chrishtr, the spec already defines this

chrishtr, see drafts.csswg.org/css-scrollbars-1/#scrollbar-width

chrishtr, no need to open an issue...

RESOLVED: No future properties should propagate from <body> to the ICB

fantasai, great!

even current properties that don't say they propagate too right?

s/ICB/ICB or viewport/

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"

RESOLVED: deprecate any existing use of body propagation

scribenick: fantasai

Topic: Clarify font-optical-sizing behaviour under size-adjust

Topic: [css-fonts] Clarify font-optical-sizing behaviour under size-adjust #6190

github: w3c/csswg-drafts #6190

github: w3c/csswg-drafts #6190

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

RESOLVED: font-optical-sizing: auto references the used font-size, accounting for 'size-adjust' and 'font-size-adjust'

Topic: [css-display] Should <display-legacy> values be aliased at parse time? #5575

github: w3c/csswg-drafts #5575

github: none

fantasai: add a comment with your proposed resolution

Topic: end

proposed resolution: resolve at computed value time, not at parse time, so that specified value is how you specified it

we have plenty of agenda already to fill next week’s meeting

Zakim, end meeting