<dael> scribenick: dael

astearns: Let's get started. Any changes to the agenda? We will skip item 4

chrishtr: Did hober request move to F2F?

astearns: Just next week

[css-color-adjust-1] Cascade within forced-colors MQ

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

Rossen_: Is fantasai on?
... I'll introduce.
... Brought up by some framework devs when starting to adopt new forced colors MQ and forced colors adjust properties
... Feedback is in contrast to previous impl in IE and Edge when used high-contrast and high-contrast-adjust the MQ and the way properties inside MQ evaluate is sign different
... Boils down to it's currently...ergonomocs are such that if you decide to adjust a single color properties inside a forced color MQ you have to take over entire styling of elements

astearns: Because the forced color wins of MQ declaration?

Rossen_: NO. Current way to do it is you have to set foced color adjust to none inside the selector in the MQ. Once selected yoru lemeents, set it to none. Means you're taking the entire element and its subtree from forced color being applied

astearns: Why need to say none?

Rossen_: To change border color for ex

astearns: B/c forced color will otherwise override?

Rossen_: Correct.
... We have a MQ that detects forced color adjust. Just like in example. When forced colors evaluates active inside MQ you do whatever you want. In this case select disabled = true elements. Wants to set the color of those to gray
... To do this today you have to set forced-color adjust to none. Otherwise color would be window color
... Making sense?

astearns: Yes

Rossen_: Previous to that high contrast impl we had we allowed individual prop to apply to individual elements. Color for that one property would override.
... That's the proposal of this change when it started. Since there was discussion between AmeliaBR emilio and fantasai.
... fantasai prop which I want to understand better is to do it other way around. Spec properties except ones you want to adjust. So forced colors except in this case border-stroke
... Some support to this, but not seeing it recorded

astearns: Not sure anyone is agreeing with fantasai prop except something like it need to happen

dbaron: Was going to say I think a way to frame this is what we want is more granular way to override forced colors. A property that's everything or nothing isn't granular enough. Peopl care about properties or maybe declarations. Maybe makes sense to re-title issue?
... I think there's a 3rd option, complex, but have it in value of prop rather than sep prop. In hindsight when we have a property that modifies how another works we end up regretting. I think this is like box sizing in that way. But that's a lot of syntaxes to modify. Not sure if there's a more elegent way to do it.

heycam: I wanted to agree with emilio initial comment finding it confusing if we change depending on what properties are inside. In favor of some opption that makes it more explicit be that fantasai prop or something like dbaron
... Question on MQ itself. Does it respond to value of [missed]> Forced color property determines if MQ matches?

chrishtr: I believe prop is not MQ but another property or value that overrides instead.

<TabAtkins> So a possible "adjust the value" option is to finally jump into using new ! options. Like `!override-forced-color`, so that *if* this declaration wins the cascade, it's allowed to override a forced color.

astearns: It's an alternative we're discussing but so far no one on thread has liked prop to having MQ allow override

heycam: Question is what determines if the MQ matches. Is it the property that enables forced color adjusting on a subtree?

Rossen_: Request is to enable single properties on selected items to take precedence over forced color
... Target BG color which is set to canvas. If you select a given element within forced color acive MQ we would have allowd bg color to take precedence over forced color.

<TabAtkins> Then we switch forced-colors mode to, rather than using the cascade and UA-!important rules, instead just use magic to win the cascade automatically, *unless* the cascade-winning declaration has the appropriate ! on it.

Rossen_: Now to do it you have to first set foced-color-adust to none and take over everything by your self

heycam: Property to turn it to none would that make MQ not match?

Rossen_: NOt really. Mode of browser is still active

heycam: MQ is the overall mode, not individual sub trees where you set htat property

Rossen_: Yeah

heycam: Cool.

<TabAtkins> (And because we're using magic, this allows us to handle multiple such override modes in the future, if we introduce them, by internally handling conflicts, rather than trying to rely on the cascade to resolve them.)

astearns: Anything else heycam ?

heycam: No

chrishtr: When you enforce colors mode I think there is no defined spec for what UA does. Right?

Rossen_: Not correct. Spec defining this is css-color-adjustment

chrishtr: Spells out exact stylesheets applied?

<astearns> https://www.w3.org/TR/css-color-adjust-1/#forced

<Rossen_> https://drafts.csswg.org/css-color-adjust-1/#forced-color-adjust-prop

Rossen_: We have the exact stylsheet? Asking if we define UA stylesheet?
... No, we define colors are reverted to system colors. System colors are defined in Colors module

chrishtr: Different than heuristic darkening of page

Rossen_: Yes

<dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties is somewhat well-defined, I think

chrishtr: Any override is predictable to dev

Rossen_: Yep

chrishtr: Got it, thank you

TabAtkins: I wrote stuff in IRC.
... Revisiting dbaron about building funcitonality into property value space. We do have a spot to do that in syntax with guar compat. Using stuff after ! which we only use for one thing. Syntax spec allows for more
... Possible way to address particular properties overriding forced color and to simplify is first switch forced color to magically win cascade regardless of author. THen allow author spec after a ! they override forced color. Say it's explicitly meant even if forced. If it wins cascade it doesn't get overwritten
... Same as figuring out how to insert a new keyword but allows completely consistant regardless of value space. Auto-extensible to future things. As well having forced colors apply magically gives more flexibility if we have to add more things like this
... THen can have resolution rules based on whatever arbitratry requirements we need. Without having to worry about cascade we let ! and author cascade determine

Rossen_: Question. Your prop is !override after property?

TabAtkins: Yeah

Rossen_: Like it. Pretty cool

TabAtkins: ! value space is allowed multi value so you can do !important override so we're not limiting authors

astearns: Talking about a generic ! override or !over-forced-colors

TabAtkins: More specific one

florian: On one hand what TabAtkins desc makes snese for this and has future extensibility. Does feel a lot like additional cascade origins. Not long ago had prop from miriam about having control over these things. I wonder if we shouldn't try harder to figure out that story. Various levels of cascade origin feels like what we're doing here. Worth exploring before being sure that's not it

TabAtkins: DOn't believe it's similar. While UA provided forced colors live on a high cascade, cascade-origins doesn't allow selective override unless we allow opt into even higher cascade. I like my proposal b/c doesn't have author cascade finnagle. They have existing rules and if they happen to be rules that should apply even in case of forced colors you add an indicator vs having a different cascade that auto-wins over another cascade that auto-wins
... You have one instance auto-winning all the time in that case and that may not be what you want

miriam: Agree with TabAtkins. Feels different use case. I'd be willing to dig in further to see if overlap but offhand seems not same problem

astearns: Other opinions?

dbaron: Reference to custom cascade brought an interesting question. If an author has rules they want to override forced colors and other rules that would normally override them what happens? Do we want that to be possible? Maybe one arg is if author says this overrides forced color it overrides all the other rules.
... Maybe want authors to do that. SOme of these have confusing outcomes. Might think someone wants it, but may be 1 person wants and 99 are confused. Makes me think maybe more like custom-cascade origins. Maybe this is a little more like cascade. Worth thinking about what we want to allow and what's too confusing

florian: I think we can do 3 things. One is you set super override and always wins. Another is super override doesn't win if you've overwritten it with the normal cascade. Asking for trouble b/c people won't test with forced colors

dbaron: 3 is horrible

TabAtkins: Writing down 1, 2, and 3 would be good

<dbaron> 1. color: blue ! override always beats color: red, even if red would normally win the cascade

florian: If you have blue in yoru normal cascade which wins then red !white with specificifity that doesn't win it's still blue. THe red lost alreay. That's 1

<dbaron> 2. color blue ! override and color: red cascade normally, and if red wins in the cascade, then there's no longer an override and the blue just gets ignored

florian: 2 is ! override makes red more important than forced color and more important than blue. Implicitly important
... 3 which is bad is if !override-red lioses to blue in normal and over blue and system in forced.

TabAtkins: Agree. 1st is per declaration. 2nd is mega-important. 3rd is bad

dbaron: I think first is mega important

TabAtkins: Do we want to take this with the two good options to the issue? Or decide now?

astearns: Rossen_?

<dbaron> Issue discussion, I thnik -- there's a ton of stuff to sort out here.

Rossen_: It's easy to discount option 3. Exploring 2 is interesting but i'm hesitant on mega-important.

<TabAtkins> I mean, !mega-important is just Custom Cascade Origins

<dbaron> This 1/2/3 thing is a discussion within a discussion.

Rossen_: If we can agree on 1 vs 2 that's a path forward to experiment and see how it works

dbaron: Feel like 1 vs 2 is a discussion in a discussion and there's large points to sort out. Better in the issue

astearns: Can resolve that we'll solve this issue in the value space

TabAtkins: As opposed to properties, yeah

dbaron: When I said value space I wouldn't have counted TabAtkins proposal as there, but I like TabAtkins proposal

Rossen_: I like it as well

<heycam> if there are many properties to override to adapt to the forced color mode I wonder if it will be onerous to write an !override on every property declaration

astearns: Let's take it back to the issue for now since we have alternatives and people like emilio and fremy with strong opinions. THen we can hopefully resolve soon.

<TabAtkins> (Given a time machine, I'd have proposed adding `!border-box` to the sizing properties, rather than box-sizing. ^_^)

astearns: Any last words?

[css-color-adjust-1] background-color in forced color modes needs more than a simple unset

github: https://github.com/w3c/csswg-drafts/issues/4175#issuecomment-603965581

spec link: https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties

astearns: fantasai put 2 options into the draft
... She asked us to choose between option A and B. Opinions?

AmeliaBR: I realized looking at...one thing requested was examples so I did just post a reply with an example.

<astearns> https://codepen.io/AmeliaBR/pen/dyoLMGd

AmeliaBR: There are screenshots in the issue of what this looks like in a couple high contrast modes.
... Including ones that look broken currently in Edge
... Main issue comes up when you have paired colors i n high contrast mode for button. Designed to work together but b/c cascade you get a bg from normal text used with your button text color and contrast falls apart
... Other complications are transparency. I've got examples of where we need to say opaque and where we need transparent b/c if opaque obseures things it shouldn't
... There are cases where option B fixes and option A causes problems
... If we follow option A [reads]
... In my example I have an svg element inside a button that doesn't have a ua background color and I have a custom style div in a button. These would not get reverted colors...Option a forces to canvas color which would be very bad for some schemes.
... In option B bg color is calc after inheriting out foreground and finding all elements have button foreground and therefore if they get a bg it needs to be button. Also extra magic about if author supplied foreground was opaque or transparent

astearns: So one vote for option B.

AmeliaBR: Option B for me. Option A would cause problems

Rossen_: Did you try with non-buttons?

AmeliaBR: No, but it's child elements inside. Child in link is only other case where you'd see it.

astearns: Argument for option A Rossen_ ?

Rossen_: Just trying to understand more.

astearns: Any arguments for option A?

<TabAtkins> I'm thinking B.

Rossen_: Curious if fantasai has caught up

fantasai: I think AmeliaBR prop gets better results where this matters. It's up to WG. Interested in hearing from implementors. That's main concern is how impl would

florian: Implicit argument for option A is simplier

AmeliaBR: Both are complex b/c neither desc by cascade. Both need to look at author stylesheet and then do fixup. Just a case of if they factor in current color

heycam: Rossen_ was your question if previous issue could be a mech to solve this?

Rossen_: No....I agree complexity of one or the other is not deciding factor.
... Trying to work through AmeliaBR test cases.
... Not opposed to B if WG feels it's better. We can impl and see what it looks like

astearns: Not hearing clamoring for A so inclined to resolve on B and see how it goes
... Objections to resolve on option B?

RESOLUTION: Select Option B [Based on its resulting computed color value, the [computed|used] background-color of an element is forced by matching all channels other than alpha to the appropriate forced background color; which should be the corresponding system background color if color is a system color, and Canvas otherwise.]

[agenda wrangling]

<fantasai> https://drafts.csswg.org/css-color-adjust-1/#changes

astearns: Objections to publish update WD of css color-adjust-1?

AmeliaBR: Nice to do other issue before, but we're publishing often.

fantasai: We should publish early and often

AmeliaBR: 4883 changes are mostly in color so yeah. no objections

RESOLUTION: publish update WD of css-color-adjust-1

[css-lists] Should collapsible space after inside ::marker be preserved?

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

oriol: Follow up of #4448 where we resolved ::market is whitespace pre in user origin. b/c outside markers are a block contrain and we wanted to preserve these.
... When tried to impl some tests failed.
... Problem is that [missed] usually doesn't matter if you add trailing or leading spaces
... If you write open tag, text, closing tag or open tag, new line, text, another line, close tag it should look same
... If we assign whitespace pre to marker the spaces are no longer at beginning. They collapse as a space but not completely removed.
... If no space at beginning of list item you get one space. If there's additional space youg et 2 spaces. There no interop. In FF you get two spaces if there's space in the beginning. Other browsers it doesn't matter
... Not sure which we want. 3 options. 1) keep resolution and say FF is right there should be 2 spaces. 2) Keep whitespace pre and add some magic which says if you have sequence of collapsable spaces just inside you remove the spaces even if trailing space of marker is not collapsable. This is behavior of non-FF but magic is annoying and error prone
... 3) Only set whitepsace pre to outside markers but not inside ones. Closer to what Chromium is doing thought chromium assigns it kind of hacky. Proper way with selectors is defining marker-outside and marker-inside. If in future we say that the list style position property applies to ::marker instead of originating list item we have a supplarity.
... Leaning option 1 which is do what FF is doing right now. Maybe less intuitive to authors but more consistent

TabAtkins: Option 3 was discared for circularity but I don't think need to be conerned. Onlyr eason to allow is set within a single list some markers outside and some inside and I don't know why we would make that easy. I don't think that will ever be the case. Never be a circularity for ::marker so we could through magic or pseudo let you style inside and outside different

<dbaron> +1 to TabAtkins

TabAtkins: I think that's reasonable b/c I don't like display FF gives. I think Chrome behavior is good, but need to solve it a good way

<Zakim> fantasai, you wanted to ask about compat

fantasai: I'm wondering if FF behavior is regression from earlier FF. Switch between inside and outside is old feature. I wonder if it has always been that you would get double whitespace in past or if relatively new since re-write marker code

astearns: Anyone know?

[several] no

<fantasai> +1 to option 1 being bad

dbaron: TabAtkins covered part of what i would say. Other thing is I think having whitespace in markup in block matter is bad so I think option 1 is bad. Little surprised FF does that

<dbaron> I think my preferences are probably 3 > 1 > 2, but that's not a very strong opinion.

florian: I agree with TabAtkins. I prefer 3 between 1 and 3. THere's also option 2 and I would like to not do this. CSS 3 text is already sufficiently complicated.. It's hard to spec and complicated and I would prefer not to add

smfr: Compat question- make any difference what we choose for compat?

florian: If it's similar to chrome and safari even with different logic it should be fine

smfr: Was this bugs on webpages or jsut seen in testing?

oriol: Me impl ::marker. Currently Chromium sets it in style adjuster. For outside it sets whitespace to pre and for inside it's the list item. When I tried to impl the previous resolution some internal tests failed and I noticed this. I don't know any webpages in wild

fantasai: Space between li and content is not uncommon. I do imagine there's a number of web pages effected.

florian: But list inside is not common

fantasai: Yes, but it is used. Unlikely to break badly but won't look as intended

astearns: Not hearing consenus except no not 2. Split between 1 and 3. Is that the case or can resolve on 3?

oriol: Fine with 3

astearns: Objections to resolve on option 3

heycam: Are those internal pseudo classes?

florian: Start there and bikeshed later

TabAtkins: Until a use case I don't think need to expose. But safe to do so if someone is motivated to champion that

florian: Wondering if folks like glazou will be unhappy about things happening that cna't be replicated in an editor

astearns: We're out of time for the day.
... I suggest we resolve on 3 so oriol can try and perhaps come back with results. People can raise new objections if they like
... objections to option 3?

fantasai: I'm happy to put in spec there's a magic difference but not sure we want to spec it's with pseudo classes. If we want to say some kind of magic and UA can figure it out we can. If we're doing a pseudo class we should draw that up

<dbaron> +1 to fantasai, no need to add pseudo-classes right now. (Also, we'd had a totally different ::inside and ::outside proposal!)

astearns: Not resolving on option 3 but that's the direction we want to head in.

florian: Is difference observable fantasai?

fantasai: i don't know. But don't want more detail in spec then needed in case UA wants to think of a way to do it

TabAtkins: Agree. Should say it happens and have a note

astearns: Thanks everyone

end

astearns: We'll go back to the issue and add spec text there

fantasai: There was a proposal that eats whitespace. We could use that.

astearns: whitespace-trim or something like that?

fantasai: Yeah. That's another option. We can re-use that and set it on the marker and it's pretty normal.

<fantasai> https://www.w3.org/TR/css-text-4/#white-space-trim

astearns: Interesting

florian: Magic is bad but a generic system is fine

<dbaron> github: https://github.com/w3c/csswg-drafts/issues/4891

fantasai: That's my recommendation. Use that property to do magic.

oriol: Impl?

fantasai: No

TabAtkins: Not certain it works. We want to preserve whitespace but we don't want whitespace from marker and content start to both preserve.

dbaron: Don't think that'st he case. Shouldn't have different mark up depending on spaces after li. Not collapsing 2 things, get rid of one

TabAtkins: How with trim?

fantasai: Set it on after marker

<florian> https://drafts.csswg.org/css-text-4/#white-space-trim

<fantasai> ::marker { text-space-trim: discard-after }

<fantasai> ScribeNick: fantasai

florian: Interesting approach to solving it, would also be useful for other things
... My concern with option 2 was I didn't want a special magical kind of white space, avoids having to define all the weird cases like does it hang at the end of a line etc.

<astearns> https://usercontent.irccloud-cdn.com/file/8nb60o5c/image.png

florian: Probably need to define how the discarding interacts with bidi, but needs to be defined either way for the feature ...

Meeting closed.

end, really this time

<dbaron> I also saw weird behavior with Florian's camera where sometimes it would show the expected view and sometimes it would show some zoom of a beam that was maybe one of the upper corners of what should have been visible.

<dbaron> (like the beam at the corner of a wall and ceiling)

<dbaron> so I guess it turns out WebEx's video doesn't really work very well

<astearns> I rarely saw the person talking, and only got 5 thumbnails at the bottom of the screen (in a scrollable carousel)

<astearns> And my audio improved once I turned off my camera :(

<heycam> I feel like the video quality / sync was worse than when I have Zoom meetings with a similar number of people on video

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/micro/marker/
Succeeded: s/realy/really/
Default Present: dael, miriam, plinss, dholbert, chrishtr, heycam, Rossen_, dauwhe_, dino, smfr, TabAtkins, oriol, dbaron, bkardell_, fantasai, GameMaker
Present: dael miriam plinss dholbert chrishtr heycam Rossen_ dauwhe_ dino smfr TabAtkins oriol dbaron bkardell_ fantasai GameMaker
Found ScribeNick: dael
Found ScribeNick: fantasai
Inferring Scribes: dael, fantasai
Scribes: dael, fantasai
ScribeNicks: dael, fantasai

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


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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