<scribe> ScribeNick: dael

astearns: We'll give people a couple more minutes to call in

<dbaron> I didn't hear the usual beep when I connected audio...

<TabAtkins> Update the topic to current agenda?

<dbaron> I tried... did you hear?

<dbaron> I still haven't heard anything

astearns: Let's get started
... When dbaron gets on we can switch to F2F
... Does anyone else have extra agenda items?

Rossen: My only question was about...are we intending to cover all the topics around forced colors as part of the 2nd item on the agenda?

astearns: 3rd holistic review?

Rossen: Yes, that. There's 2 or 3 github issues where we're tracking parts in a similar way to the topic. Want to know if we should go issue by issue or if this is meant to cover everything

astearns: I put it first in case there was anything in that discussion that informs the others. I don't expect to get to everything by going through the review

Rossen: Thanks

astearns: dbaron are you back on?

Should Element.pseudo("unknown") be an error or return null?

github: https://github.com/w3c/csswg-drafts/issues/3603#issuecomment-467363388

astearns: There was additional conversation after we resolved. Is fantasai or TabAtkins on?

TabAtkins: Yes
... Question came up from Anna. Import is exactly how argument should be parsed. Direct string match or full css parse so you get escapes and that business?
... I usually prefer direct string but I believe this function will be extended to handle other pseudo elements with arguments. AS soon as you get past a single name string compare falls down. When we have css parsing there we shouldn't do custom
... I propose we do a css parse on the string and match against grammar of supported elements

astearns: Any discussion? Objections?

RESOLUTION: Do a css parse on parameter for element.pseudo()

<dbaron> ok, I'm on now -- the problem seems to be that WebEx doesn't work in Nightly Firefox any more (across 2 machines) -- but it works in Chrome

F2F

dbaron: I hoped to bring this up a few weeks ago. Hotels in Toronto seem to be more expensive then usual for dates we chose. I'd encourage looking for hotel or airBnB reservations soon. There is substantial airBnB availablility in Moz offices.
... THis was from a few weeks ago but at that time there way availability

astearns: I did airBnB earlier this week and still lots of options

minimum nested pairs of parentheses in calc to 32

github: https://github.com/w3c/csswg-drafts/issues/3462#issuecomment-478408798

TabAtkins: Get a resolution that we should have limit on req. number nested parans that impl must support
... calc imposes min on terms but there's no spot where we allow you to fail with nested
... Prop: Put in a mandatory min for paren depth. Past that you're allowed to fail. Number is set to 32

fantasai: And this is a min, not a max.

florian: It's setting a min and saying when you fail how you do so?

TabAtkins: Yes, we have that term in other parts of calc so reuse

AmeliaBR: This is specfically about parsing nesting so this is literal parens not conseptual order of operations? Chrome when serializes adds a lot of parens so from authoring might be confusing. One paren with multi operations is it literal parens?

TabAtkins: It's a parsing problem so literal parens. Further order of operations can only impose one additional level so don't have to worry about that nesting indefinetly.

florian: If chrome inserts unnec parens it's probably wrong.

TabAtkins: Yep

AmeliaBR: True but I think 32 number comes out of chrome so not sure if anybody has tested how the 32 is counted in chrome and maybe has an effect?

florian: Are we saying 32 included or excluded?

TabAtkins: I do not care. I'll put one down.

fremy: Similar question because it's a difference of one. Need to be clear if it's inside the code.

florian: As long as clear doesn't matter

fremy: Agree

astearns: Serialization bug will be an extra problem if people using serialized values to set other prop. Importance of fixing prob. go up

florian: But it's a min not a max.

astearns: We have a limit on terms which is 20, why choose different number?

<bkardell_> can someone explain why that is not a good assumption?

<bkardell_> (that you should be able to round-trip parse/serialize)

<fantasai> bkardell_, because browsers have bugs :)

<bkardell_> are these bugs not fixable?

<fantasai> bkardell_, in an ideal state, it should otherwise be a good assumption

TabAtkins: 20 terms came because it seemed good. 32 is smallest limit across the browsers; Blink has 32. It would prob. be good to have similar numbers so I suggest raising term to 32 to make them symmertic

<fantasai> bkardell_, yes

AmeliaBR: I don't think it's conceptually possible to support 32 nesting and 20 terms. Doesn't bracket count as a term?

<bkardell_> fantasai: yes they are fixable, or yes they are not fixable? :)

<fantasai> bkardell_, fixable of course :)

TabAtkins: No. It doesn't count functions or parens so I need to update. When it's updated paren groups should count

astearns: bkardell_ asked on IRC about what's not a good assumption. We should not assume people writing serialization code and people writing paren code are talking to each other. Assuming if i's all chrome it'll work is bad.

bkardell_: SO we want to spec so when done it's safe assumption?

florian: We want chrome to fix bugs b/c having more parens in output then in input is not a thing that should happen. By shortest serialization it shouldn't do that

bkardell_: AS we spec it there should be a test that says that is a safe assumption

astearns: Should be a bug for a 32 paren that's parsed, you serialize, reparse, and then it works.
... I believe prop is?

TabAtkins: Make the term limit consistent with nested parens limit

astearns: 2 resolutions. Set a min parens that is set at 32. Then raise min terms to 32
... Obj to set minimum number of parenthesis to 32

RESOLUTION: Set minimum number of parenthesis to 32

astearns: Obj to raise the number of expressions that must be handled to 32

RESOLUTION: Raise the number of expressions that must be handled to 32

astearns: Lots of tests for all of this

florian: Writing a test is what prompted it

TabAtkins: For values stuff I'm enjoying writing tests so I'll make sure inputs go in with tests

Holistic review/proposal of color-modifying things

github: https://github.com/w3c/csswg-drafts/issues/3807

TabAtkins: fantasai and I have been watching with mild concern as various color modifying things have come about. Wanted to make sure they all corrdinated. Put together an issue that reviews all of it. For the most part people are doing same and that's good. Have a few suggestions that are minor
... Dark mode- The spec Rune put together based on our plan which basically matches Safari is good except long names. Hvae suggested shorter names. supported-color-scheme we wanted to call color-scheme. That's about it for dark mode.
... MS high contrast prop works pretty well
... Set of system colors we support has a few with appropriate names. Outlined those in issue with additional color names if we want to give access to authors via MQ
... If doing forced color scheme and bg is light or dark should also trigger light or dark mode MQ.
... You can do things like remove shadows based on it being dark or whatnot
... Question about inverted colors, but should discuss sep
... Main thing. Suggestion of modified names
... [missed...audio issues]

<dino> 🎁+

TabAtkins: Main thing is first this suggested shortened name for dark mode and meta tag. Only shipping impl is Safari b/c they shipped before a spec. No one else has shipped. So resolution if we change names or not.

smfr: Reason we choose prefers; we need to make clear to authors this is user's preferred appearance for the page. Similar to preferred reduced motion MQ.

TabAtkins: MQ is good. It's supported-color-scheme property and meta we want to rename.

<fantasai> @media (prefers-color-scheme: light | dark | no-preference)

<fantasai> color-scheme: only? && [light | dark | <custom-ident>]+

<fantasai> <meta name=color-scheme content="(same values)"> sets initial value of 'color-scheme' on the root

<fantasai> proposal ^

dino: I was going to say MQ has been in MQ spec for a long time

astearns: Given that, smfr is rename okay?

AmeliaBR: It's drop 'supported' in 'supported-color-scheme'

<fantasai> If we can change system colors to compute to themselves, then 'color-scheme' changes the used values of the system colors on the element. If not, 'color-scheme' on the root does so for the whole page. In either case, the affected system colors are at least the set defined for "high contrast".

florian: But not for MQ?

<fantasai> 'color-scheme' must also affect input & scrollbar styling.

AmeliaBR: MQ keeps 'prefers'

smfr: Think okay

fremy: Wondering, on the issue color-scheme is written as a singular. Is that intentional?

TabAtkins: Property names are always singular so we went with that.

fremy: Okay, sounds good. If you thought about it I'm fine

astearns: Other discussion on if we should have 'supports' in prop name?

dino: Not changing values, jsut removing prefix?

fantasai: We also fixed the grammar. Current allows light or dark or only keyword. Defined to parse and not throw out additional IDs.

TabAtkins: As far as we know this matches what you intended

smfr: Sounds fine

<fantasai> Proposal is to rename supported-color-scheme to color-scheme

dino: Reading in #3807 in light/dark color scheme proposal. That's what to look at?

TabAtkins: Yeah

dino: I think we're okay with that

smfr: Allow only to be at end?

TabAtkins: Either spot because it matches general CSS. only light and light only make sense

astearns: Other questions about change from supported-color-scheme to color-scheme ?

<fantasai> smfr, you can't do "light only dark"

<fantasai> smfr, but "only light dark" and "light dark only" are fine

Rossen_: Reviewing this prop it aligns closely with some internal work we did on this in terms of wordsmithing and aligning. Thanks for taking the time TabAtkins and fantasai. It aligns with how I hoped this would mash together and make sense of all the darks and lights. +1 and thank you

astearns: Prop: Add the color-scheme property with updated grammar to a spec instead of supported-color-scheme

TabAtkins: Yes. Not sure if there's an existing spec that fits. Maybe colors but I'm not sure. Either Colors or a new spec

AmeliaBR: THis goes into larger discussion. Debated last week where adjust for forced colors goes. Maybe in same place as new color-scheme

TabAtkins: Yes. High contrast stuff should be same place as light/dark. That should be either Color or a new spec

florian: Feels coherent enough to be a sep spec and feels it will move faster

fantasai: Discussion was appendix to MQ until we figure out where it goes

AmeliaBR: Other property these are related to is appearance. It's turning on or off default UA styles. Not sure what spec that's in

florian: That's CSS UI L4. It's a bit of a stretch but only a little one

TabAtkins: Can we just make a color-adjust spec?

fantasai: Sure

Rossen_: We can always have one more spec :)

astearns: Obj to start a new Color Adjust draft?

RESOLUTION: start a new Color Adjust draft

astearns: Who will edit?

TabAtkins: fantasai and I

astearns: Who else

Rossen_: Rune and I should put time on this and put our edits

Tab: sgtm

astearns: I'm appointing Rune and Rossen as editors, TabAtkins and fantasai can provide feedback. Let's spread out editing

Rossen_: Resolutions for MQs?

astearns: Let's resolve on color scheme. Obj to Add the color-scheme property with updated grammar to Color Adjust spec instead of supported-color-scheme

AmeliaBR: Meta tag too?

astearns: Yes

dbaron: I think I said what I didn't like last time we discussed this.

florian: Don't think resolved

dbaron: My concern is we have a set up where all pages on web work with light form controls. Many pages break with dark. On systems where browser can choose they tend to light.
... This is designing around a few recent OS changes rather than say a general system them change a user has made. It's not clear to me this is impl across OS themes. It's a step forward and backward. All pages work with light, many broken in dark. this allows pages to say work with dark, but also allows broken in light and i"m not happy about that
... Want to have a page say I'm happy with a dark theme. Not happy about page overriding user choice

AmeliaBR: You okay taking this up in spec discussion? Sounds like you're concerned about the only keyword interacting with list of preferences. I'm not sure that blocks actual concept

dbaron: Once there's a spec it will ship. WE need to discuss before

fantasai: Well it shipped w/o a spec

<fantasai> already

astearns: Would concern be addressed if we did grammar such that you could not exclude supporting a light scheme?

dbaron: I believe so. I'm not up on semantics of current proposal.

TabAtkins: Ignoring future compat with other schemes. IT's saying I'm fine with light or dark or I'm only fine with light or only fine with dark. If at the moment 'only' works on light you can say I only do light or you can say I allow dark and if user wants that give it to me

astearns: That does seem more widely implementable

dbaron: I think that would help
... Still some edge cases where we couldn't do that

florian: Neither light nor dark systems?

dbaron: Or we don't know. We can just draw a control.

astearns: Another way addressing this is to have an implicit auto where there is a browser default that this prop cannot opt out of.
... If the color scheme is set to only dark if browser only has one set of form controls it can display with those auto controls

AmeliaBR: THat's clear in Rune spec. It's a matter of if browser has >1 color scheme the only is asking author pref to override user. BUt it presumes >1 color scheme

TabAtkins: Per current processing if you only have 1 color scheme it selects that. Only filters to values unless the set would be empty

dbaron: Nice spec says that but reality is if 99% browsers have both the 1% will have to do something b/c otherwise pages break

florian: That's the situation today. If your UI is orange on pink too bad for you.

dbaron: I'm concerned about Linux. Most users have light form controls. Edge case will expand from set of Linux users with dark controls to all Linux users

TabAtkins: On pages that are only dark and break in a bad way with a light form control
... Those don't exist now so it's theoretical future pages

astearns: How about this. Resolve on putting color scheme in the spec with an issue noting we are concerned about backwards compat and need some way of expressing that it is okay to display things with the controls you've got

florian: Prefer to start with restricted grammar. Then if we relax later it's easier.

AmeliaBR: Restricted grammar is do not allow dark only. You can say light only or light and dark but you can't say an only that doesn't include light.

florian: Yes

fremy: I still don't...it's removing a possibility that's a legit use case. We are assumign this new feature that doesn't work well on an OS that can chnage. If this becomes a problem Linux can do what every other system does and fix it.

florian: Compat problem. It's about writing a web page that says it doesn't work on existing OSs

fremy: That happens all the time. You need a webcam to do a skype call. I don't like spec around limitations of one system

astearns: CSS is long lived. I can see a new OS that's very concerned about its controls and it will never show a dark mode.

Rossen_: Are we solving anything? Feels like we're rambling

astearns: Current suggestion is we put color-scheme in with a change to grammar such that you can only express the only keyword for the light theme
... Heard concerns it's too restrictive. But it can relax in future

fremy: If you have a toggle on website that says I want dark theme you can't have dark form controls.

florian: You can ask for dakr, just not on OSs that can't do it

fremy: Doesn't work. If you have a website with a toggle and user clicks I want dark theme if the OS has a light you get light

<AmeliaBR> For clarification, I am not supporting the "restricted grammar". But I am very supportive of adding the property to the spec with an open issue.

fantasai: We're either adding this or not. Apple has shipped. Might be able to get away with not adding only, but we can debate on another day

fremy: So you can still do dark light for what I want

RESOLUTION: Add the color-scheme property and meta with updated grammar and no 'only' property to Color Adjust spec instead of supported-color-scheme

fantasai: MS had what they called high contrast MQ and high contrast adjust but they said same is used for low contrast so calling it high contrast is confusing
... TabAtkins and I suggest calling it forced-colors
... MQ for forced-color-adjust. Rather than diff keywords color scheme relying on dark mode switch so only none or active in the MQ

<AmeliaBR> Strong +1 to the forced-colors name

astearns: Concerned it's too abstract. contrast-adjust might be better

fantasai: Not adjusting. This is fixed set of colors and we're forcing on you

<fantasai> @media (forced-colors: none | active) {...}

<florian> I like forced-colors

<fantasai> forced-color-adjust: auto | none

Rossen_: Forced color desc well. Another name is user-color-scheme. That implies user choose that and only problem is too close to prefers-color-scheme. Forced-colors is fine

astearns: Other concerns?

florian: Question- earlier talked about interact with prefers-color-scheme have prefers-contrast, interact?

<fantasai> "The (prefers-contrast) MQ is unrelated and unchanged."

fantasai: prefers-contrast is same and nothing changes

TabAtkins: It's orthogonal which is why want to get away from work contrast

florian: But if forced color scheme has something dramatic you can infer prefered contrast

TabAtkins: Prefers contrast is different.

AmeliaBR: Important to keep naming clear. Have set of prefers MQs that tells author user expressed a preference. forced-colors is very different so it's important to have a very different name that emphasizes the override. Also really important that it doesn't make any assumptions about what hte colors are

<fantasai> TabAtkins^: prefers-contrast is about letting author adjust things to match the contrast preferences. This is about you're using this set of colors, too bad.

AmeliaBR: Key feature for authos is that you're not going to know what colors will be used

<aja> fwiw, implementers, consider support for :has along with the meta, eg :root:has(meta) {--set-some-variables-on-root}}

florian: Not opposed. Little confused why you can infer prefer high if it's dark but can't infer prefer light

fantasai: What about lime green on pink. What does that mean? Is it high or low?

florian: Weird contrast ^-^

fremy: Agree with florian . Should be in spec. UA can decide to do these things, but we shouldn't spec it. User is allowed to decide they want high contrast. You can put a note saying you can be smart. I like proposal of not forcing this but UA can do smart things

florian: I'm sold

Rossen_: Can we go back to forced-colors and not talk contrast?

astearns: Is high contrast prop in a spec?

Rossen_: Which? One we prop?

fantasai: One you prop. There's enough explainers we can write a spec.

astearns: Prop: Add a forced-colors MQ into the new draft?

Rossen_: Or MQ, whichever

fantasai: In MQ

TabAtkins: Forced-color MQ into MQ spec

astearns: Objections to adding forced-colors MQ to MQ spec

RESOLUTION: Add forced-colors MQ to MQ spec

astearns: forced-color property in the new spec

TabAtkins: Indicates on a sub tree don't force colors I know what I'm doing.

Rossen_: Should go in color adjust
... Fitting to be in color adjust spec

florian: Presumably the adjust thing on print goes with it?

fantasai: We should move it, yeah

astearns: Obj to adding forced-color-adjust property as an opt to into new spec?

RESOLUTION: Add forced-color-adjust property as an opt to into new spec

AmeliaBR: In draft from Rossen_ and melanierichards lots of issues about interaction between author and UA will go. Is that into new spec?

TabAtkins: Yes

AmeliaBR: fremy had diff prop for same thing so that discussion would happen in this spec?

TabAtkins: Yep

astearns: We'll have continued discussion for this new spec, what goes in , and changes

fantasai: Reoslve to move print-color-adjust?

astearns: Obj?

RESOLUTION: Move print-color-adjust property into the new spec

astearns: I'll leave agenda+ on the new items

end

<fantasai> astearns, you're gone until June??

<dbaron> astearns, btw, were you using Firefox when you had the audio problem at the start?

<astearns> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/raise min/raise min terms/
Succeeded: s/preferred/supported/
Succeeded: s/preferred/prefers/
Succeeded: s/make/just make/
Succeeded: s/color adjust/color-adjust/
Succeeded: s/tantek/Tab/
Succeeded: s/fixed colors/fixed set of colors/
Default Present: dael, rachelandrew, leaverou, bkardell_, plinss, AmeliaBR, tgraham`, oriol, dbaron, dauwhe, melanierichards, gregwhitworth, myles, smfr, florian, svoisen, emilio, bradk, antonp, Rossen_, dino
Present: dael rachelandrew leaverou bkardell_ plinss AmeliaBR tgraham` oriol dbaron dauwhe melanierichards gregwhitworth myles smfr florian svoisen emilio bradk antonp Rossen_ dino
Regrets: tantek
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 17 Apr 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)