- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Sep 2020 19:06:04 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Scoping
-----------
- RESOLVED: Change the spec to match current web behavior so
fallback content is not matched by ::slotted() (Issue
#5482: Consider aligning ::slotted() for fallback
content with implementations)
- RESOLVED: Add more examples to this section of the spec (Issue
#5482)
accent-color
------------
- In discussing issue #5480 (Should interoperability be a goal for
the `accent-color` spec?) there were two viewpoints to consider;
implementors and authors.
- From an implementor point of view there were still concerns
expressed about the implementability of the accent-color
property. It's important to continue allowing browsers to
ignore accent-colors if necessary.
- From an author point of view this spec should be understood as
allowing them to provide browsers a hint as to the colors
they prefer. Providing that hint does require a level of
interoperability where similar form elements display the
accent-color similarly so authors can ensure proper contrast.
- There was general agreement that if we're doing an accent-color
property there does need to be examples in a non-normative
section which gives guidance and will allow authors to have some
consistency in usage. However, there wasn't broad agreement that
the non-normative section as written was what the group wanted
to resolve on so discussion will go back to github with a
request for specific feedback on how to improve the text for the
non-normative examples in the spec.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0028.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Christian Biesinger
Mike Bremford
Oriol Brufau
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Daniel Hobert
Dael Jackson
Brad Kemper
Jonathan Kew
Una Kravets
Daniel Libby
Rune Lillesveen
Chris Lilley
Alison Maher
Myles Maxfield
Melanie Richards
Devin Rousso
Jen Simmons
Miriam Suzanne
Greg Whitworth
Zheng Xu
Regrets:
Tantek Çelik
Brian Kardell
Florian Rivoal
Lea Verou
Scribe: dael
astearns: I think we have enough to 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
jfkthame: Partly but happy to leave another week
astearns: Any other changes?
CSS Scoping
===========
Consider aligning ::slotted() for fallback content with implementations
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5482
rune: Case is none of browsers implemented what's in 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 implementations
or if we should try to agree all implementations should move
to what spec says.
rune: Started as a bug reported by Salesforce. Bug was a corner case
in WK which makes Salesforce think they implemented
incorrectly, but mostly in agreement with Blink and Gecko.
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.
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?
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 indicates 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
implementing to support it. We can fix by browsers
match spec or we add new functionality to ::slotted()
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 re-slotted as
fallback.
rune: I don't think we would like to change Blink implementation
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
smfr: I don't know status, guessing low priority for us
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
preference that current browser is probably right because
usually want fallback styled differently.
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 algorithm 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
targeted the slot. If they set the border it 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
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.
<TabAtkins> https://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.
* smfr would like the bugs.webkit.org bug for this
<gregwhitworth> smfr: https://bugs.webkit.org/show_bug.cgi?id=169948
<smfr> ty
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 slotted
identical style you need to spec 2 selectors. If style
differently you need to add a bunch of rules which is tricky
for specificity.
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 because
don't know dom hierarchy of nested slot. Could be wrong.
rune: Share understanding with emilio. You're correct about case
where you cannot target
emilio: Like current because if you want style and slotted children
the same it's way easier to do than if we impl what spec
says.
TabAtkins: I propose 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 default style the default content it works
for us
astearns: Proposal: 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: Objection 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 what
should not
gregwhitworth: Leo on our side is good with tests and I can loop him
in if you need help on adding tests
accent-color
============
Should interoperability be a goal for the `accent-color` spec?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5480
<masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md#motivation-and-intent
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
masonfreed: I think if you as a dev want to make form controls match
platform it's easy, don't specify anything for form
controls and it matches. If you specify colors you're
trying to change away.
emilio: I feel a bit the same as myles. If we try and spec form
controls...dev may specify accent-color because 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.
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.
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
implemented intentionally and some don't. 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?
jensimmons: I think there's 2 ways to look at this. One is what
we're discussing from implementors. From author PoV is
the other.
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 background is blue I
expect that everywhere. But when it comes to saying
accent-color: blue it's implied 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 interoperable in a way that pixel perfect
designs would imagine
masonfreed: I appreciate 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 backgroundy and
foregroundy thing. I think we're still trying to specify
something vague but add a bit more information and
provide more of a hint what the dev is trying to do.
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.
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 implementors
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 implementors 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.
TabAtkins: Two things. 1 to talk to myles and emilio about browsers
wanting native on particular 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
minimum if it's a foreground or background color.
Required to ensure element looks good against parent.
This will be complex because things like Chrome redesign
from where checking a checkbox swaps the background and
foreground colors
TabAtkins: This means chrome cannot be using blue as foreground
accent and use that to draw background. 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
is foreground and one is background 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
<TabAtkins> like, `input { accent-color: blue white; } input:checked
{ accent-color: white blue; }` needs to be in the Chrome
UA stylesheet
<gregwhitworth> +1 TabAtkins
una: I want to speak to intent of proposal. Give authors more
control over form styling. Problem for 20 years. If we're
giving authors more control the authors 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 solve the issues the property tries to solve.
una: Even with having background 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
una: Want to argue to author intention 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 because masonfreed hit nail on head.
Need to resolve if we agree this is a problem we're
solving
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 [in OpenUI].
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
specified.
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.
<bradk> +1 to CocaCola example
gregwhitworth: I agree with TabAtkins that if they're using the
property you should leverage it. I guarantee everyone
has primary, secondary, etc. colors. We should be
able to commit to if they're native render or not
it's not un-implementable.
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. Appreciate masonfreed trying to
have the spirit
<fantasai> +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
<TabAtkins> 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 background is the
"primary" color when checked.
<fantasai> +1 TabAtkins
<fantasai> need to ensure contrast
<gregwhitworth> TabAtkins: yeah, my point was that everyone does
have colors in their control that will be able to
map to the property value set
<fantasai> 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
<TabAtkins> gregwhitworth: Yeah, I was just countering your use of
"primary" in your description. ^_^
emilio: Agree with sentiment
emilio: Concern is implementability. We can do the work to make it
work. If WK commit they can add coco APIs for Mac but
there's still 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
emilio: If you don't it's not all that useful to authors because
they can't customize
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
astearns: There will always be browsers that won't support.
<bradk> 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.
<bradk> Seems like dark-color, secondary-dark-color, light-color,
secondary-light-color would work better
<TabAtkins> bradk: That doesn't work for Chrome's checkboxes vs
everyone else's checkboxes.
<TabAtkins> bradk: That's what I meant by "cannot use semantic
roles, must use functional roles"
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.
<TabAtkins> agree with jensimmons; this has been circling for twenty
minutes when it's actually just a debate over the
existence of the feature itself
masonfreed: For me the debate is the way proposal 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
<gregwhitworth> my main point here was that we can pick up this
discussion at the Open UI + CSSWG meeting
<gregwhitworth> I have this as an agenda item
<gregwhitworth> as it's paramount to land on aspects of interop
<gregwhitworth> whether we do or do not
astearns: Put another way we discussed 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
emilio: Assuming we spec this feature I think it should be
sufficiently well specifies so browsers and impl can do
something consistent.
<TabAtkins> 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. ^_^
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 fundamental level.
fantasai: Main concern should be how do we get enough contrast. Some
checkmarks use foreground and some background. 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
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 implementation can do own thing
and may be completely different. Chrome will implement
the way they want. If we delete all the text. It will
just be a rough description and no guidance as to how to
use it.
<TabAtkins> And I'll strongly object to a version of the spec
without guidance on using the colors
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
<TabAtkins> No guidance = browser-specific, so this is a prefixed
property, not a real property.
<emilio> TabAtkins++
<gregwhitworth> TabAtkins: agreed
<gregwhitworth> emilio: you're confusing me bud
<emilio> gregwhitworth: if we specify the property, we should
specify what it does
<emilio> gregwhitworth: (that's what I said when I last spoke)
<emilio> gregwhitworth: That is regardless of my concerns about
implementability in Gecko / WebKit
<emilio> gregwhitworth: But I think we decided a bit ago that
debating implementability was specifically a non-goal of
this issues
<emilio> this issue*
<emilio> gregwhitworth: So I think I'm not contradicting myself, but
maybe I'm wrong :))
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.
<TabAtkins> 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 like this should is appropriate
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
astearns: Can we resolve to say this non-normative section is way we
want to proceed?
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?
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?
myles: We're kind of out of time
<TabAtkins> I would like this to wait for the OpenUI talk; this
40min discussion did very little. :(
<TabAtkins> Let's not talk about this again until there's a focused
topic on it
masonfreed: Can I get more specific feedback on the issue?
astearns: Anyone with specific concerns please put them in the issue
and we'll do this first thing next week
<masonfreed> Thanks!
After call conversation
-----------------------
<fantasai> 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
<fantasai> 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".
<fantasai> 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"
<masonfreed> 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.
<fantasai> masonfreed, if you're not allowing for those
possibilities, then your section isn't non-normative
<fantasai> or at least, isn't really behaving as such
<masonfreed> fantasai - let's continue the discussion on the issue.
I'm curious to hear your specific suggestions about how
the proposal is written.
<fantasai> masonfreed: happy to make specific suggestions :)
<masonfreed> Thanks!
<fantasai> masonfreed: Largely, I agree 100% with Tab's comment here
- https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811
<fantasai> masonfreed: I think his first two paragraphs are
basically my core position
<fantasai> masonfreed: and my desire is for this non-normative
section not to take away from that core position in any
way
<masonfreed> 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.
<masonfreed> I think it's important to read the non-normative text
in the context of the normative text.
Received on Wednesday, 23 September 2020 23:06:57 UTC