zakim, start meeting

present+

ScribeNick: dael

regrets+

present+

present+

present+

present+

present+

present+

present+

astearns: We'llw ait a minute or two for more people to join

present+

present+

present+

present+

present+

present+

present+

present+

present+

astearns: I think we have enought o start

astearns: One change to the agenda is not talk about item 1 since we discussed last week.

astearns: GH thread is long and we said last week we'd wait for it to be agenda+ again

chris: Looks like we're sort of resolving but let's give another week. Unless jfkthame joined for this

present+

jfkthame: Partly but happy to leave another week

astearns: Any other changes?

Topic: [css-scoping] Consider aligning ::slotted() for fallback content with implementations

present+

github: w3c/csswg-drafts #5482

present+

rune: Case is none of browsers impl spec. Spec says fallback should be styled by ::slotted() but all browsers style elements which are slotted following assigned slot chain so you can get not just first slot scope but if child of shadow host it's flattened to next scope.

rune: Question is if we should change spec to match impl or if we should try to agree all impl should move to what spec says.

present+

rune: Started as a bug reported by Salesforce. Bug in corner case in WK which makes Salesforce think they impl incorrectly, but mostly in agreement with Blink and WK.

rune: First level of slotting possible to style with a normal child selector on the slot. If you want to style the fallback in a nested slotting that's currently not possible.

present+

rune: Talked to polymer team at Google and people working on web components and they think should stick with current. Worried this has web compat concerns if we shift to match spec

gregwhitworth: As I said in GH I'd like to understand what compat they're worried about. Is it their own specific compat?

present+

rune: I don't think they have specific cases. Worried in general there is content that will break

gregwhitworth: Not sure why Polymer that's a component library...i'm confused.

rune: Need to check again

gregwhitworth: Chrome status data it's low in utilization. Part of me feels the scenario you outlined is not unheard of. My expectation...I would phrase do you match spec now or do we come up with another method that enables that use case?

gregwhitworth: The use case is not invalid. Browsers aren't impl to support it. We can fix by browsers match spec or we add new functionality to ::slotted()

q+

q+

rune: Most common use case is style fallback in same scope where we have a solution. this is case of slot child of shadow host which slotted into a different scope.

rune: Possibility to have syntax to target the reslotted as fallback.

rune: I don't think we would like to change Blink impl unless there's a plan to change in all browsers. I saw WK didn't have immediate plans to do anything about it. Not sure if anyone from WK has specific thoughts or if it's just low priority

ack TabAtkins

smfr: I don't know status, guessing low priority for us

present+

TabAtkins: As I put in comment late in the bug the fact that spec says the selector passed to ::slotted() should match fallback content as well as actual slotted is more accidental. Easiest way to spec what I wanted. I don't have opinion on one way or other. Weak behavior that current browser is probably right b/c usually want fallback styled diffeerently.

lol

TabAtkins: I'm fine with browsers keeping current. I found on investigation that how spec is written I don't think does what we want. Everyone is doing some funky I think you know what I mean behavior. The algo in the spec if you have nested shadow roots so slot going into light dom as written that doesn't matter for ::slotted() and it just sees slot children

TabAtkins: Apparently works in Safari but Safari styles actual children? Confused

rune: Bug is Safari is they match the slot which is not what's in spec. In Salesforce they styled the color and in Safari targetted the slot. If they set hte border wouldn't have worked.

TabAtkins: GOt it. I thought border styles also applied but if they don't that's fine.

rune: Behavior in Safari is corner case

present+ myles

TabAtkins: Find slottables is you find the slot elements themselves

rune: Flattening in HTML collapses all the slots. Only thing you style is the elements. Can't style slots themselves

TabAtkins: I'm pretty sure that's wrong. It's want I wanted, but not what I wrote.

TabAtkins: I would like to change to match current Chrome and FF behavior. I support that.

ack emilio

drafts.csswg.org/css-scoping/#slotted-pseudo Or hell, maybe I did write it correctly; it does say "assigned, after flattening", and links over to the "find flattened slotables" algo.

emilio: Going to say along lines of TabAtkins opinion. Regardless of which way you go if you want one or the other behavior you need to work around it. If you want fallback and sloted identical style you need to spec 2 selectors. If style differently you need to add a bunch of rules which is tricky for specificity.

smfr: bugs.webkit.org/show_bug.cgi?id=169948

emilio: As far as I can tell only thing you can't do in FF and Chrome is style fallback of nested slots. That doesn't seem like something a lot of people would want to do b/c don't know dom hierarchy of nested slot. Could be wrong.

rune: Share understanding with emilio. You're correct about case where you cannot targer

emilio: Like current b/c if you want style and slotted children the same it's way easier to do than if we impl what spec says.

TabAtkins: I prop we resolve to change the spec so fallback content are not part of content matched by ::slotted() to have spec match current Chrome and FF behavior

TabAtkins: Does that work?

gregwhitworth: Addendum request; I would love some examples about here's what flattening does. I understand that's WHATWG but examples in our spec as to what happened

TabAtkins: I agree, could use examples

gregwhitworth: If we can defautl style the default content it works for us

astearns: Prop: change the spec to match Chrome and Gecko behavior so fallback content is not matched by ::slotted()

rune: Noted Safari is mostly correct. It is mostly aligned

astearns: Yeah, it's the edge case

gregwhitworth: Yeah, it's that one bug

RESOLVED: change the spec to match current web behavior so fallback content is not matched by ::slotted()

astearns: Obj to add more examples?

RESOLVED: Add more examples to this section of the spec

astearns: If there is a further use case for finding some way to have a style that matches slotted and fallback content we can add that in the future, but not necessary right now

TabAtkins: umhum

rune: Need tests

rune: When I changed impl in Chrome I didn't fail any tests so we need more

emilio: I think the tests are for what should match but not for waht should not

gregwhitworth: Leo on our side is good with tests and I can loop him in if you need help on adding tests

Topic: [accent-color] Should interoperability be a goal for the `accent-color` spec?

github: w3c/csswg-drafts #5480

masonfreed: Heard 2 things from last time. One is ^ to add motivation and intent to help interpret written spec. I wrote that.

masonfreed: tl;dr is it's to provide a compromise between interop and not constraining browser impl.

masonfreed: Today is interop question. Are we going for interop? It's fundamental. Depending on your answer the spec changes. Should it be same across or hint to browsers?

masonfreed: My opinion is useful either way but lose a lot if don't strive for interop.

masonfreed: 2 reasons. 1 is not easily usable by devs without browser sniffing. Could also cause a11y and contrast issues if different expectation as to where the color goes. blue background, white accent for checkbox and you assume that's the background. If browser colors the check white you have contrast problems.

masonfreed: I started this with the idea of a single color and went through how it works for each control. Realized it's hard to use without language on how it's used for all controls. Helpful to look at examples section

masonfreed: Question today is should accent color be interoperable.

myles: Background concern is being able to match platform form controls is valuable. Some browsers system framework needs to fit in. Don't want to have 2 sets of form controls for web content vs rest of OS

q+

masonfreed: I think if you as a dev want to make form controls match platform it's easy, don't spec anything for fonm controls and it matches. If you spec colors you're trying to change away.

ack emilio

q+

q+

emilio: I feel a bit the same as myles. If we try and spec form controls...dev may spec accent color b/c chrome handles it and they don't look native but look better if you change accent color. I'm not sure your argument applies that some browsers will honor colors and others won't.

Present+

q+

q-

emilio: For some platforms like Windows and MacOS (I think) we don't have much control over which colors are native and which are for form controls. Alternatives are remove native but you don't want to do same as appearance:none, right?

masonfreed: Right. Idea here is make basic style of color easier for developers.

q+

masonfreed: The intention of proposal is that it's open to not do anything. It's explicit you can disregard a color. It says if you are going to respect it you should try and use it same way as everybody else. If you don't want to control colors of native form controls you can do that. But if you use accent color you should do it same as everyone else

emilio: But if Gecko and Wk want to keep native appearance we have to impl form controls twice if we want to honor it sometimes.

myles: Another way to say this, this is a world where some browsers impl intentionally and some done. Some browsers use own native design and others use non-native custom design. That doesn't sound like consistency. That world answers the question, it isn't consistent.

masonfreed: Agree form controls are all different. Is that what we want is the question. If we're adding something new should we point it toward interop?

q+

ack jensimmons

jensimmons: I think there's 2 ways to look at this. One is what we're discussing from impl. From author PoV is the other.

q-

jensimmons: I think some of what you're asking masonfreed gets at the root of the idea where coming up with accent color as the property...another way to do is pseudo class for checkmark and another for checkbox....having something more vague implies the idea we're not giving you a bunch of hooks

jensimmons: If I expect to say my checkbox bg is blue I expect that everywhere. But when it comes to saying accentColor: blue it's impled by the property and the name that hey author welcome to the wide world of chaos and there is not consistency even in the same browser what's happening

jensimmons: I thought the idea is hey we know it's chaotic so we're going to give authors something that's more generic and we'll give authors a way to say my accent color is blue and it's not interop in a way that pixel perfect designs would imagine

masonfreed: I appriciate and understand that. That is still my intent. Range looks different across everything. I think the realization I made going through each control is there are in a lot of cases 2 places where accent color comes in. There's background-y and foreground-y thing. I think we're still trying to spec something vague but add a bit more information and provide more of a hint what the dev is trying to do.

q+

masonfreed: Providing 2 colors and some guidance feels to me helpful even to devs. Definitely helpful to devs. If building a checkbox and looks like other checkboxes it's helpful to me.

q+

masonfreed: I hear we're not going pseudo classes for everything. Maybe that's down the road. This is low hanging fruit that solves a bunch of dev problems that want to make the controls the right color for their site.

masonfreed: I feel you need some level of intent about doing the same thing if you're going to do it.

jensimmons: Makes sense to put something in spec so impl aren't just making it up and everyone gets to a different idea. Say in general we think accent is here and other color is here so impl can have some guidance and not make it up from scratch or look at other browsers. But maybe just a gentle suggestion

jensimmons: You're asking should we try and get everyone to be definitely the same way and I don't know that we can say yes

masonfreed: Adding one more thing. Way we got here is there was concern about first mover problems. If one browser impl accent color then other browsers would be stuck matching. Work I did to go through each control was in response to this call saying let's discuss first up front.

ack TabAtkins

q+

TabAtkins: Two things. 1 to talk to myles and emilio about browsers wanting native on particulr platforms. I think that should be fine. Goal of form elements being stylable will continue to be impossible. Native form controls are weird. Spec allowing browsers to stick with native and ignore accent color is necessary and doesn't make us any worse.

TabAtkins: When talking interop, saying we need interop is nonsense. We need interop to make this a property. We need at min if it's a fg or bg color. Required to ensure element looks good against parent. This will be complex b/c things liek Chrome redesign from where checkign a checkbox swaps the bg and fg colors

TabAtkins: This means chrome cannot be using blue as fg accent and use that to draw bg. Needs to set in UA that when checkbox is checked it uses flipped. It's a work around. If we're clear that if you give 2 colors one wis fg and one is bg I think we're okay. Given there's no control what so ever right now that bit of requirements should insure enough interop even if there's a first move

TabAtkins: Means we'd have to be careful about how we spec

ack una

q-

like, `input { accent-color: blue white; } input:checked { accent-color: white blue; }` needs to be in the Chrome UA stylesheet

una: I want to speak to intent of prop. Give authors more control over form styling. Problem for 20 years. If we're giving authors more control the authros that would case want consistency across brands and OSs. My worry is it seems to be about consistency. If there's not consistency about how colors applied it doesn't solvet he issues the property tries to solve.

present+

present+

una: Even with having BG color it's different in Safari where there's a gradient. Solving those issues is key to making this something authors adopt. If we say here's the color and good luck and it's different across browser and OS it takes away the power of the property

ack gregwhitworth

una: Want to argue to authori ntention in wanting consistency. If we're introducing new properties and options it should be top of mind

gregwhitworth: I would like to 100% agree with TabAtkins and una. This was something we were hoping to tackle at joint meeting and it's b/c masonfreed hit nail on head. Need to resolve if we agree this is a problem we're solving

q+

gregwhitworth: There's a reason author is putting this in there. They're saying I need to change this for a meaningful reason. Way we start to address is recognizing there's potential buckets, potential capabilities we can unlock these things. We're going after the extreme far end to unlock everything. This property is more like intent

gregwhitworth: There is a spirit and an intent to say I'm coke and I want checkboxes to be coke-red. I love your checkbox but it's blue and it feels Chrome not Coke. I'm proving you a brand hint, please apply to your control in a meaningful way. That's the way it's spec.

gregwhitworth: Trying to thread the needle of allowing author to have limited control, but some control, while not biting entire problem. Feel it's a good first step.

+1 to CocaCola example

gregwhitworth: I agree with TabAtkins that if they're using the property you should leverage it. I guar everyone has primary, secondary, etc. colors. We should be able to commit to if they're native render or not it's not un-implable.

ack emilio

gregwhitworth: jensimmons and una hit on it. Author problem and if we feel our controls are superior to the problem author is trying to solve. Agree with TabAtkins about we should lock down. Appriciate masonfreed trying to have the spirit

+1 to gregwhitworth "please use this color in a meaningful way"; -1 to defining what "use in a meaningful way" means in terms of which parts get which color

emilio: Agree with sentiment

Important bit here is that the role of the colors *cannot* be semantic like "primary, secondary, tertiary". They *must* be functional like "foreground, background, shadow". Otherwise a page using "black white" for a checkbox, expecting a white box with a black check, and putting it against a black background, would look bad on Chrome where the bg is the "primary" color when checked.

q?

q+

+1 TabAtkins

need to ensure contrast

emilio: Concern is implementablity. We can do the work to make it work. If WK commit they can add coco APIs for Mac but no control over windows. Only alternative is re-write form controls. We may end up doing that. I don't know. If you force engines to apply it then you prevent using native form controls

q?

emilio: If you don't it's not all that useful to authors b/c they can't customize

TabAtkins: yeah, my point was that everyone does have colors in their control that will be able to map to the property value set

astearns: Compromise is for a browser using native controls without any capability of changing the browser could say they do not support on that platform. lets author know styles won't work as intended.

emilio: It's an option but pages could rely on colors to work

I disagree that it should say backwards vs. foreground. If one native control has a border and another doesn’t, saying the background should be white would be much worse on the one with no border.

wrt accent-color, I don't think making a list of "primary/tertiary/etc" makes sense. But listing colors, against which the browser will use a "pick color with most contrast against [color/bgcolor as needed for this particular use of accent coloring]", could be a good way to do this

ack jensimmons

gregwhitworth: Yeah, I was just countering your use of "primary" in your description. ^_^

astearns: There will always be browsers that won't support.

agree with jensimmons; this has been circling for twenty minutes when it's actually just a debate over the existence of the feature itself

q+

jensimmons: I'm just confused as to where disagreement is. Feels like a high level debate about if we should use must/may/should in every part of the spec. Maybe some of spec should say must, some should be may, some should.

masonfreed: For me the debate is the way prop is written is the interop version. Alternative is strip away most of that to just say accent color looks like this and browsers us as they say fit. Debate is spec as written vs another spec that reads that accent color is a hint, use as you'd like

q-

astearns: Put another way we dsicussed and asked masonfreed to make non-normative suggestions. masonfreed is coming back for validation. I think we should say yes this is what we want or no, dial back on interop

ack emilio

my main point here was that we can pick up this discussion at the Open UI + CSSWG meeting

I have this as an agenda item

as it's paramount to land on aspects of interop

whether we do or do not

ack fantasai

emilio: Assuming we spec this feature I think it should be sufficiently well spec so browsers and impl can do something consistent.

masonfreed: I'll make it easy: if the spec says "here's some colors, do what you want with them", I'll formally object to it. ^_^

Seems like dark-color, secondary-dark-color, light-color, secondary-light-color would work better

fantasai: I think I would go with saying spec shouldn't mandate use of color and instead say it's a hint. If we're switching to a mode of form control with a lot of author controls we can mandate. There is a desire for authors to influence without changing render at a fundemental level.

bradk: That doesn't work for Chrome's checkboxes vs everyone else's checkboxes.

bradk: That's what I meant by "cannot use semantic roles, must use functional roles"

q+

fantasai: Main concern should be how do we get enough contrast. Some checkmarks use fg and some bg. Need to make sure we can get enough contrast. Having examples which are here's how it's used in some browsers is good, but you're using native controls and accent color should be a hint that says I'd like to use this accent color and please use it meaningfully. But shouldn't define meaningful

astearns: So you think dial back on non-normative text of what you should do with accent color

q-

fantasai: I don't think we should have should or must requirement

astearns: It's all non-normative. So you're okay with spec as-is?

fantasai: I'm fine with it being examples

masonfreed: All non-normative examples

myles: WE said difference is today with non-normative vs deleting the examples. What's the functional difference between the two

masonfreed: Functionally means every impl can do own thing and may be completely different. Chrome will impl the way they want. If we delete all the text. It will just be a rough desc and no guidance as to how to use it.

And I"ll strongly object to a version fo the spec without guidance on using the colors

Unrelated to current topic - I've added a comment to the overflow model issue: w3c/csswg-drafts #129#issuecomment-697691447

astearns: Back to original issue, should interop be a goal? non-normative examples will likely get better interop. Removing is more likely for non-interop

No guidance = browser-specific, so this is a prefixed property, not a real property.

TabAtkins++

emilio: you're confusing me bud

TabAtkins: agreed

fantasai: I think the section labeled non-normative is written with normative language. It needs to say this is how it could be done but it could be done in a different way.

gregwhitworth: if we specify the property, we should specify what it does

gregwhitworth: (that's what I said when I last spoke)

If someone doesn't want the property *at all*, say that; trying to water down the requirements by removing guidance doesn't do the job.

astearns: My way of thought is here's an example where if form control looks like this here's what it should do. If it looks different do what you want. But if you have something liket his should is appropriate

gregwhitworth: That is regardless of my concerns about implementability in Gecko / WebKit

fantasai: In this case might want 2 examples. If it looks like this here's what changes and if it looks like that here's what else would change. So you can say your form control doesn't have to look exactly like that

gregwhitworth: But I think we decided a bit ago that debating implementability was specifically a non-goal of this issues

astearns: Can we resolve to say this non-normative section is way we want to proceed?

this issue*

astearns: Would anyone object to keep with advice on impl?

fantasai: Don't want as is, but fine with a bunch of examples

myles: Need resolutions for non-normative text?

gregwhitworth: So I think I'm not contradicting myself, but maybe I'm wrong :))

masonfreed: Looking for next steps

fantasai: Happy to give more specific feedback. We can resolve on the normative

astearns: This issue is about non-normative

astearns: myles do you object to keeping non-normative? Want more time?

I would like this to wait for the OpenUI talk; this 40min discussion did very little. :(

myles: We're kind of out of time

masonfreed: Can I get more specific feedback on the issue?

Let's not talk about this again until there's a focused topic on it

Thanks!

astearns: Anyone with specific concerns please put them in the issue and we'll do this first thing next week

Topic: edn

Topic: end

masonfreed, the issue I have with your "non-normative" section is that it's worded as a set of normative recommendations rather than illustrative examples

masonfreed, for example - The shaded background of the progress bar should be considered a "contrasting" accent, while the filled "value" portion of the progress bar should be considered "primary".

masonfreed as opposed to something like "In this example, the shaded part uses the OS theme accent color; therefore it should be affected by accent-color"

fantasai, I understand your objection, but I don't know how to improve it exactly. If you would like to propose an alternative that says "you can use the first color as the background, or the foreground, or somewhere else", then I don't see the point of having that entire non-normative section in the first place.

masonfreed, if you're not allowing for those possibilities, then your section isn't non-normative

or at least, isn't really behaving as such

fantasai - let's continue the discussion on the issue. I'm curious to hear your specific suggestions about how the proposal is written.

masonfreed: happy to make specific suggestions :)

Thanks!

masonfreed: Largely, I agree 100% with Tab's comment here - w3c/csswg-drafts #5480#issuecomment-682242811

masonfreed: I think his first two paragraphs are basically my core position

masonfreed: and my desire is for this non-normative section not to take away from that core position in any way

I think his first two paragraphs are *my* core position as well! And I believe (perhaps incorrectly) that I've written a spec that does exactly that.

I think it's important to read the non-normative text in the context of the normative text.