- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Aug 2020 19:28:46 -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.
=========================================
Form Controls
-------------
- The proposal for accent-color (
https://github.com/mfreed7/accent-color/blob/master/proposal.md )
was updated after last week's discussion to include multiple
examples of each form control.
- The current proposal's goal is to encourage all implementations to
have the same definition of what part of a form control is the
accent color given a similar layout but when creating a new
layout implementors are free to create a new definition for the
a new design while following the spirit of the requirements.
- The main concern about is that the proposed level of guidance to
standardize will limit the ability to innovate and isn't
necessary given the further level of control over form controls
being designed in the OpenUI project.
- The two viewpoints will need to be balanced to make sure that
developers have enough control that they'll use the property but
not prevent implementors from being able to iterate on their
form controls.
- RESOLVED: The group wants to add accent-color and discussion on
details will continue (Issue #5187: Allow specifying the
"accent color" of a form control element)
- The items which still require discussion will be broken into
separate github issues in order to create more focused
conversations.
CSS Cascade
-----------
- RESOLVED: Move this proposal (
https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7 )
into the spec (Issue #4470: Custom Cascade Layers)
CSS Inline
----------
- RESOLVED: Publish new WD of CSS Inline
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Aug/0027.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Jonathan Kew
Peter Linss
Alison Maher
Myles Maxfield
Tess O'Connor
Melanie Richards
Florian Rivoal
Jen Simmons
Miriam Suzanne
Greg Whitworth
Regrets:
Christian Biesinger
Hui Jing Chen
Adam Jolicoeur
Chris Lilley
Lea Verou
Scribe: dael
Form Controls
=============
Allow specifying the "accent color" of a form control element
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5187
astearns: Discussed last week, bringing it up first this week. I'm
guessing to give masonfreed a chance to give an update
masonfreed: I heard a few action items. Main one was people wanted
examples of existing form controls across browser/
platform/time periods
<masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md
masonfreed: Added to the proposal doc ^
masonfreed: You can see 5 different form controls
masonfreed: There were several questions discussed on thread
masonfreed: One was radio button. Question was on Chrome latest
there's a large center blue dot on white, rest are white
on blue. Question is doesn't that argue for single color
and allow platform to decide.
masonfreed: My view is no if color is specified we should follow that
masonfreed: Similar for gradients, what does accent color do?
masonfreed: My view that is up to implementors but try and respect
accent color. Replace gradient with flat fill or
integrate into gradient into whatever way makes sense.
masonfreed: Only other open item was back to the amount of power to
open with API. Single color or more specified with
multiple colors.
masonfreed: That's all I heard on the thread. Can open for
discussion.
fantasai: Based on what I've seen starting with one color makes
sense since not much evidence of multiple. Figuring out
how 2 colors would work together is complicated.
fantasai: In terms of handling gradients if you set appearance:none
everything is flat. If none is not set try and match
platform convention. We can encourage use of accent color
but I don't think that should disable platform styling
<hober> +1 to fantasai's points
masonfreed: single vs 2 color there are a number of controls in
proposal. Even the radio button there are at least 2
colors. If you only open one I would say you have to
specify which part you control which leaves other
uncontrolled. Devs want both controls on the thread
masonfreed: appearance:none is a big hammer. It turns off all
styling. Radio becomes an empty div. That is a complaint
that brought us to this proposal. Radio and checkbox you
do appearance:none and have to rebuild everything. This
proposal was to give some control without having to
rebuild.
gregwhitworth: I was initially going to +1 to fantasai in regards to
spirit but heard masonfreed on complexity. Maybe have
multiple colors but don't play into gradients. Where
we leverage primary|contrast proposal we provide one
color and allow UA to do what's best to keep spirit
of spec
masonfreed: You mean take current proposal and chop of contrasting
color but keep spec as to where first color should apply?
gregwhitworth: No, this started on handling of gradients, correct?
masonfreed: And radio.
gregwhitworth: Was thinking same accent color applied within mac on
focus. That's where I was using as use case to have
gradients in future. Didn't want to discount that.
gregwhitworth: Contrasting and primary I would keep. Too many
scenarios where need to exist.
gregwhitworth: Goes into try to follow this and we don't make this
normative. So Safari says background is primary stay
true to author expectation is what you recommend.
gregwhitworth: Radio, I could see Safari say primary is contrast in
Chrome. To that end I don't know how you coalesce
without lopping them off and hinder feature or get
much more prescriptive.
gregwhitworth: Basically, I don't know
fantasai: Thing with primary vs contrast the way accent color is
used varies a lot. Sometimes foreground sometimes
background.
fantasai: They are sometimes both. Back to Aqua there was a solid
color highlight with background color text because it's a
dark color vs gradient and lighter gradient is foreground
on top
fantasai: If intention is set accent colors UA should auto generate
variations on color and match against foreground or
background as appropriate.
fantasai: If you are creating variations on the color the pair of
colors may no longer contrast.
fantasai: I don't know how you would use the contrasting color in a
situation like that
masonfreed: I see that point.
masonfreed: I did include some language that UA doesn't have to use
exact color. That's one of the cases where you take it
as input to the algorithm but don't have to use exactly
that if it doesn't make sense to the gradient.
Rossen: I'm hearing strong dev need that has been sampled over long
time. And a good example of document that motivates and
explains why we need and how to go about it. I hope all
features have this level of detail and consideration when we
bring them
Rossen: Question is where do we go from here. Discussed over a few
weeks. I do see pushback for various reasons. Continuing
forward I'm trying to tease out obstacle here. What's the
obstacle or are we pushing back just for sake of pushing back
hober: Trying to answer. For me I generally like being able to
specify accent color. Very important we preserve browser
ability to adopt different designs in future and to deploy on
different platforms and meet conventions.
hober: Pushing back to preserve implementor flexibility to match
platform conventions. Platforms have color conventions and
want to be able to use those.
Rossen: How is this different than what we do with appearance today?
The cat is out of bag when introduced
-webkit-appearance:none. Agree in principle to preserve
browser innovation but I'm not sure taking away this
flexibility is warranted here. Can you expand?
hober: Don't understand your question
masonfreed: I understand what you asked hober but what do you think
in proposal is constraining the future developments?
hober: Basic, like what if browser wants to use accent for
checkmark, not background of checkbox
masonfreed: That's why I kept it non-normative. It's guidance but
not a constraint. If that makes more sense with a new
design there's a good reason so go ahead.
hober: Okay, gregwhitworth had said earlier if you didn't want to
use accent in where it's specified you shouldn't use at all.
Maybe previous call. That's different?
masonfreed: Current language is accent colors are spec, guidance for
what supposed to mean, but tried to thread needle
between constrained and open. That's the intention. Open
to clarify language
<fantasai> "However, the intention is that if the same or similar
accent parts exist on a given form element, it should be
associated with the "primary" or "contrasting" colors in
the same way across user agents."
fantasai: We need to clarify if that's intent. Text says should be
same across all browsers
astearns: Acceptable to put intent behind text in spec. Be explicit
about attempt and then put normative text so people can
interpret.
<Rossen> hober, re: "Don't understand your question" - How is
webkit-appearance:none different in terms of overriding UA
native controls compared to this proposal? (besides the
fact that we won't force authors to rebuild the entire
kitchen around the sink)
<hober> Rossen: appearance: none is an escape hatch
<Rossen> hober: yes, and if your position is to keep anyone from
escaping this hatch is a much worse option
<hober> Rossen: sorry, i'm not trying to be dumb, but i don't
understand what you're getting at.
<Rossen> hober: your pushback was about keeping the ability to ship
UAs that can continue comply with the native platform right?
<hober> Rossen: my pushback is about making sure that browsers can
change their form control designs in the future, and use the
author-provided accent color(s) in ways appropriate to their
new form control designs.
fantasai: I disagree accent color should be on same pieces across
browsers. Intent is use as appropriate, not use accent
color and try and match web os convention.
masonfreed: That sounds like a core disagreement we should discuss.
<hober> +1 again to fantasai :)
<myles> yep
masonfreed: What I was going for is if there's a very good reason,
like a brand new checkbox with a completely new thing and
no way to apply prior history you shouldn't be constrained.
But if we're all building a box with a check we should try
and be the same so dev can expect similar across browsers
masonfreed: In document all checkboxes are widely the same so we
should hope impl uniformly
florian: I think there's a tension in requirements. Desire if some
platform has check blue and another box blue and you say
make a thing pink and we can do that. But if you don't know
if it goes to foreground or background it's hard to know it
would look right against everything else on the page.
florian: Currently you know if it's foreground or background so you
can pick other colors but at the expense of forcing the
accent on a specific part. Not sure how to satisfy both
parts.
gregwhitworth: florian hit nail on head
gregwhitworth: To circle back in the proposal to masonfreed I put if
it computes to auto it's the webdev saying I want OS.
gregwhitworth: No one disagrees with hober about forward innovation.
But the second someone finds interop differences it
will get replaced. That's what we see. I get it and I
agree but I don't think it's pragmatic for use.
gregwhitworth: If we say this is limited styling and you have
outside of border have accent color the outline
becomes blue and my background is blue and I won't
like it. We can go that route but people will find a
barrier. The second we hit that people will replace it
gregwhitworth: Worried by making this so loose people will just
replace it. We can say you can spec accent color and
UA will do best and hope experience is great. We can
spec that and say we recommend using these
myles: Partially responding- I don't think that is necessarily a bad
thing. There are different classes of desire. If web author
wants form control same everywhere they have tools for that.
Modifying native form controls will be different on every OS.
Has to have flexibility
florian: Design as is has flexibility, but nudges you in a specific
direction. If you say accent color blue and you expect a
blue check you'd see that and it's fine, but the background
is blue on another browser and you can't see it against
your blue background then you can't see it.
florian: Having a nudge to say it's this part it gives you more
interop to match with the rest of the page. I would be
tempted to say spec as proposed probably gets the bias right
<hober> I don't think it's helpful to talk about this in isolation;
there are other efforts (e.g. Open UI) that will help add
form control customization knobs, so the whole "if
accent-color is too loose, people will use appearance: none"
is a false dichotomy.
fantasai: I agree with myles and hober. I think if you're
appearance:auto goal should be match platform. One thing
we can consider is to handle contrast levels instead of
specifying 2 colors say this if contrast with foreground
and this if contrast with background. Most of time not
using separately for contrast, you're matching foreground
or background.
florian: You mean specify both with expectation browser uses one?
fantasai: Yes.
fantasai: And if you give 1 you give permission to browser to modify
along brightness however it thinks appropriate. If you
give 2 you can be more precise, but you don't get to say
which part is used.
fantasai: If you want to do that more manually I think we need to
make checkboxes more stylable generally. I don't think
accent color is place to do that
masonfreed: Can we use example from dev in thread which is the time
control with glyph and background behind the glyph?
Author wanted to control the glyph and background behind
to match control. How would they achieve that with your
proposal?
fantasai: I think that gets into...if there's a time icon on my
control there's different ways to impl. glyph could be on
text input background or on a button-looking thing. I
don't know approach. They are all reasonable for platform.
If author wants to control that specifically we need a
model for that form control. I don't think accent color is
way to control because browser may not be using accent
color for that icon
masonfreed: I see that but way it is says there might or might not
be a glyph. If a glyph may not have backplate. If both
use contrast for glyph and accent for backplate. If we
impl that author would be happy. Leaves image of glyph
to UA but controls colors.
fantasai: But if button-like accent color is buttony part so
convention would be bg of icon is accent color. Trying to
say something different wouldn't work
<gregwhitworth> +1 to what fantasai said as it sounds like we need a
master switch which appearance is. We should tie the
two in some meaningful way and if appearance isn't
adjusted we can achieve what hober myles was saying
masonfreed: That's what text says. if buttony the bg should be
accent. And that's why you need contrast color to
control the stuff on the button. Lacking the contrast
color the dev would be lost and have to replace the
control.
<gregwhitworth> +1 to masonfreed point, but there in lies the
problem :)
Rossen: To hober's point earlier I agree browsers and UA should be
able to differentiate or go to native conventions. Question
is given that we have webkit-appearance as an escape which
forces devs to complain for years because they're tired of
having to use that and re-impl everything. My question is
how is this better. Is this best way can do as a
presentation platform?
Rossen: Best we can do is make it appearance:none? Seems like should
be better answer and middle ground to allow and expose these
parts.
hober: I feel like this is a false dichotomy. Talking about this in
isolation and not in context of other properties and
features. If we think about all together we can see this
question is moot. I'm not saying that the only options are
appearance:none or accent color.
<fantasai> hober++
hober: Hoping openUI will increase customizability in a number of
ways which will enable people to use more and not use escape
hatch
hober: I don't see accent color as alternative but as a complement
to those efforts. Platforms with accent color use somewhat
similar and somewhat different.
hober: Accent color on the spectrum of control is advice to the
browser. OpenUI exposing specific parts is more at the full
toolbox where we do what dev says.
<gregwhitworth> that last point that hober made is what I think we
should explore at breakout. florian had noted he
thought about this. I'll start whipping up a doc
that explores this with concrete examples
hober: If dev wants it on a specific part of a control I'm saying
use what openUI exposes for that control. Accent color is a
more general feature that should be more of a hint to the UA
to do the right thing. You should have the extra control
which is why openUI is exciting
<AmeliaBR> +1 to hober's multi-level model. accent-color as a hint
for modifying native styling, other options for more
direct piece-by-piece control.
hober: I think at root question misses the point. If accent color is
the only possible option there's a point. In a world where
we'll have other tools like openUI it doesn't hold water
<Rossen> hober: thank you for elaborating - that was the answer I
was hoping and looking for :)
chrishtr: Summary on what I see where we can maybe make progress
today. We all agree UAs should have ability to create new
UI types over time
chrishtr: I think any accent color we agree should be when possible
interop in ways it applies so there isn't first mover
advantage.
chrishtr: I think spelling out non-normative text to do so will also
help in making sure corner cases with contrast and
darkmode are taken care of
chrishtr: accent color is good to add, make sure text doesn't
prevent future design, we could encourage interop, and
have text that can work the corner cases
* fantasai disagrees with "recommend interop" given the way it's
being defined
chrishtr: Is that a reasonable thing to resolve?
astearns: I think it's more than we can currently agree on in part
because recommend interop isn't agreed on definition
<fantasai> I think that UAs should have ability not just to create
new UI types over time, but to alter the design of
existing UI types over time and across devices and
platforms
<hober> fantasai++
astearns: Have consensus this is good to add but details of what's
normative and not is good to work out
astearns: May be useful to break out current interop goals from
future proofing. As we discuss it slides between what
people want now and what people imagine in the future.
astearns: Might be good to have explicit note that this could all
change due to thing we haven't discovered. For current UA
this is level of interop to achieve
<fantasai> Yeah, I don't agree with that either :) See above
masonfreed: Should I take action to further update spec text to try
and thread needle?
astearns: I think we should have more text to keep up and more
discussion on issue. I think we could resolve this is a
thing we want to add, but not other details.
chrishtr: Could we resolve on other two points?
astearns: We've already spent 45 minutes on this
jensimmons: Briefly I think there's a lot of reason for optimism.
Desire is to make sure this will be complex enough for
future rather than drag into past. I'm personally very
interested in and haven't been able to be as involved as
I want.
jensimmons: We can get somewhere great and this is hard because it's
hard not because desire to not do it.
<fantasai> So far no disagreement that we should have accent-color
<fantasai> Just disagreement on how prescriptive its definition is
astearns: Can we resolve this is something we want to add?
astearns: Objections to continue to work on this?
RESOLVED: The group wants to add accent-color and discussion on
details will continue
astearns: Helpful to break items into separate issues. masonfreed as
you update text and look at particular items in contention
if you can raise separate issue for each so we can have
scoped discussion and resolution on pieces as we good may
be good way to make progress.
masonfreed: Will do and thank you all
<AmeliaBR> FYI, I started a twitter poll on whether authors would
actually use this with/without defined browser interop,
please retweet into your audiences
https://twitter.com/AmeliasBrain/status/1298656779274825728
CSS Cascade
===========
Custom Cascade Layers (formerly "custom origins")
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4470
miriam: Take everyone through the proposal?
astearns: Yeah. Summary would be helpful
<fantasai> Proposal:
https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7
miriam: Starting at the top, first question is where in cascade
would author custom origin layer fit. Felt it could achieve
all goals as higher then specificity. Putting it above
shadow dom creates additional problems so putting it between
solves problems
miriam: Question about shadow dom at bottom of doc
miriam: Interacting with !important we suggest layers exist entirely
within defined origin. They work like origins so reverse in
!important layers.
miriam: Normal layers styles not explicit are at the top followed by
named layers in order set up
miriam: Reversed in important so layers are at bottom.
miriam: Keeps meaning and intent of !important more clear and
working similar but internally
miriam: Talked about style attribute and suggestion is it continues
to be above these layers. Have to redefine but I think has
to anyway with scope being removed. Keeps style attribute
like other styles.
miriam: Levels for managing layers; does it happen at selector or
declaration or block or importing. Suggesting block similar
to MQ and as with existing @rules blocks can nest. Then
layering based on order of first appearance in code
miriam: Example reset-base components reset. Reset lowest, base on
top of that. Order they're first discovered is order of
layering
miriam: In terms of ordering layers there's a way to cheat and
declare them all. Could be with empty blocks but also
proposing layers shorthand to let you define. That's above
imports
miriam: Suggesting an import syntax. Way to name and group
everything inside a file. Helps with encapsulation.
Bootstrap exposes layers but we can create a wrapping layer
that keeps all bootstrap inside. Nesting doesn't impact
order, just naming
miriam: Various discussion on syntax and if it builds on @import or
unique
miriam: Nesting doesn't change order, just groups. If wrapping layer
has name can interact with nested layers by calling that
with some syntax for getting to layers within layers.
miriam: By allowing unnamed layers allow a tool like bootstrap to
have private layers. Wrap in unnamed layer and removes
ability to call them later.
miriam: More detail in the proposal
miriam: Migration path since this is between specificity and style
this can be mimicked with specificity so clearest way to
show is list of IDs.
miriam: Can be more clean using IS to get specificity of IDs. Path
to polyfill
miriam: Weakness on refactor use case. Since layers reverse in
!import not idea but doesn't seem changes are extensive.
Have to do something with !import styles in legacy to make
sure they don't override in new. Not a perfect solution but
works with a little manipulation
miriam: Questions from thread, does load order of stylesheet matter
so if a sheet is lazyload but lazyload first does it matter?
no.
miriam: Can you nest layer blocks, yes. Specificity is unchanged
inside layers. Just subsuming it.
miriam: If stylesheet is in multi layers it's in multi which is true
currently
miriam: Best syntax is open question still. Are unnamed layers
feature or a problem? Allow hiding which is risky but
powerful.
miriam: Way to revert layers? Do we want that?
miriam: How does light dom layers affect shadow dom layers with same
name. Complex but think a wrapper may be able to resolve
that powerfully
emilio: Regarding shadow dom; how does it matter? rules in different
trees are sorted different on top of specificity. I don't
know how that is a problem.
miriam: Comes into play because ordering of names determining the
layering order
miriam: If there are layers inside shadow dom named main and base
and layers outside named base and main which order are they
used?
<fantasai> +1 to scoping layers to a shadow context
<miriam> +1
emilio: I see. I think layers should scope to a tree. Inside a tree
is where you sort by specificity. Doesn't make sense to me
to have names interact between trees. I think that's what
you proposed with anonymous.
miriam: Could be interesting to let you access layers inside a
shadow dom.
emilio: Why would you want? But does seem different discussion
astearns: My proposal is get this proposal into the spec and start
opening issues to dig through
astearns: Objections to move this proposal into the spec?
RESOLVED: Move this proposal into the spec
astearns: Doesn't mean we're done, means we open separate issues to
discuss each bit instead of whole. Thanks so much miriam
for putting this together.
CSS Inline
==========
Publishing
----------
fantasai: Can I publish new WD of inline layout?
astearns: Objections?
<dauwhe> +1
RESOLVED: publish new WD of CSS Inline
astearns: Thanks everyone for calling in
bkardell: Please reply to the email about a MathML meeting!
Received on Wednesday, 26 August 2020 23:29:52 UTC