- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Jul 2020 19:21:15 -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.
=========================================
Opportunity for data-driven decisions
-------------------------------------
- There is a page to vote on and suggest statistics to be gathered
as a part of the HTTPArchive Web Almanac. Group members are
requested to participate and suggest items which would help in
specification writing:
https://leaverou.github.io/mavoice/?repo=leaverou/css-almanac&labels=proposed%20stat
CSS Pseudo Elements
-------------------
- Examples were added for using ::first-letter and spaces (Issue
#5154: ::first-letter should include space separators). There
are also examples where a space is used to ensure only a
punctuation mark and not the letter receive the ::first-letter
style so a switch may be required.
- This will be added to the F2F agenda since not everyone interested
was available for today's call.
CSS Values
----------
- RESOLVED: Reject [phi] for now and if data shows up from
HTTPArchive that it is fairly common we re-open and put
it in (Issue #4702: Math Constant phi for Golden Ratio)
Form Controls
-------------
- masonfreed presented the study and conclusions for controlling the
color on form controls:
https://lists.w3.org/Archives/Public/www-archive/2020Jul/att-0000/Accent_Color_for_Form_Controls.pdf
The conclusion was that there would need to be two colors
exposed; foreground and background.
- There was concern that range and progress bar were excluded from
the proposed spec text and investigation will be done as to how
they can also respect the new values.
- The proposed properties include 'foreground' and 'background'
which implies that a certain level of contrast should be
encouraged. This may be good, but needs to be thought through
more since not all form controls have contrast right now.
- The proposed spec text is vague in terms of details due to the
current incompatibility around form controls. However, the group
felt it should be more specific so that discussions do happen
prior to one browser implementing and everyone getting locked
into that approach.
- There was interest in having the openUI group also define what is
foreground and what is background. Several members of the group
expressed an interest in seeing a demo/overview of the openUI
work.
- An additional concern was to make sure whatever is specified will
be able to accommodate future innovations in look and
functionality of form controls.
- masonfreed will add to the proposed spec text more specificity
about implementation and than bring it back to the group.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0015.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Christian Biesinger
Oriol Brufau
Hui Jing Chen
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brain Kardell
Peter Linss
Alison Maher
Myles Maxfield
Tess O'Connor
Florian Rivoal
Devin Rousso
Jen Simmons
Sam Sneddon
Alan Stearns
Miriam Suzanne
Lea Verou
Greg Whitworth
Regrets:
Tantek Çelik
Adam Jolicoeur
Cassondra Roberts
Scribe: dael
astearns: We can get started
astearns: One extra item on the agenda from leaverou
astearns: Anything else people would like to change?
astearns: I encourage people to tag issues with Agenda+ F2F and
possibly a milestone for next week.
astearns: I expect we can handle more than we have.
Opportunity for data-driven decisions
=====================================
github: https://github.com/w3c/csswg-drafts/issues/5343
leaverou: I think most of you know HTTPArchive. It crawls websites
and stores data. It publishes web almanac with websites
using tech
leaverou: Each chapter is collaborative. For this year I'm content
lead for CSS chapter. Bunch of people in the group. We
need to finalize what metrics. I thought it would be good
to ask group if any stats useful for specs
leaverou: Primary goal is state of CSS in 2020. But there's a big
overlap between stats answering that and stats for spec
editing.
leaverou: It's an opportunity to get this data with very little
effort. I'm throwing it at the group. Any ideas post in
the repo I created (
https://leaverou.github.io/mavoice/?repo=leaverou/css-almanac&labels=proposed%20stat
)
leaverou: If it's accepted we get the data in a month or so
leaverou: You can see in repo what proposed statistics are there
astearns: Thanks leaverou. Please take a look at her list and make
suggestions
CSS Pseudo Elements
===================
::first-letter should include space separators
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5154
astearns: Last week asked for examples. They were.
astearns: One concern from plinss that there may be case of
languages where people add space to make sure punctuation
doesn't get added with first letter
astearns: I think I have seen examples of this with block quote and
just quotation mark is the first-letter. Probably added a
space to make sure first letter isn't ::first-letter styled
astearns: I think plinss is correct we can't make this change and
need a toggle to opt in
astearns: Any disagreements?
plinss: I think that behavior is not the norm. Maybe we enable and
toggle is to opt-out
astearns: Certainly possible. Could enable, not worry about toggle
until we get bug reports when browsers change
astearns: We left with tantek wanting examples. Unfortunately he has
a conflict today
plinss: Part of why I brought that up was to push back on tantek
wanting examples. I was partly bringing up for a requirement
to add counter examples
astearns: Sounds like you're in favor of the change
plinss: Yes but I think tantek should be heard
astearns: Other comments? I'm guessing we should push to next week
when tantek is available
astearns: Okay, we will do that.
<tantek> If we already have compat between Gecko and Blink *not*
including the space then you've got a compat issue
potentially too
<tantek> so I'll push back until someone provides a print example
showing a real world need
<tantek> whether or not WebKit implements it
CSS Values
==========
Math Constant phi for Golden Ratio
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4702#issuecomment-660684501
TabAtkins: I expect this to be short. Christoph has been asking for
phi to list of constants
TabAtkins: I'm against. phi is largely numerology. In cases where
it's used, 1.6 is very close to phi. There's virtually no
instance where you need precise. Exact spirals maybe but
I haven't seen that in CSS
TabAtkins: I suggest resolve not to add phi. Unofficially I doubt
any other constant will rise to importance of add to CSS
hober: Preface by saying I'm not dying on this hill. Fine to not
add. There is a reasonable argument that CSS is used to
create compelling visual designs. Having this built in would
allow people to do that.
hober: Agree with TabAtkins phi isn't interesting mathematically.
But CSS isn't MATLAB. We're trying to provide practical tools
for designers. There's a long tradition of golden ratio in
design
TabAtkins: Interesting that's the exact reason I think we shouldn't.
Math reason is good, but design with golden ratio in
practice you can use 1.6. Anything that specifically
wants an exact value where I've seen examples they're
happy to round to whole pixels so they're looking for
something around there. They're not looking for
mathematical properties, they don't factor in
TabAtkins: It's unlike pi where imprecise shows up when you're doing
circular.
gsnedders: I agree with TabAtkins that precise doesn't matter. But
we have enough people that want to use phi where sake of
clarifying what people want to do the constant is useful
leaverou: There have been studies on this and people gravitate to
different ratios than phi. It's been experimentally
proven. If I remember people gravitate to 1.4 or 1.7.
leaverou: Also unlike pi and e phi can be computed relatively
easily. pi for example we can't do that easily. phi anyone
can define their own variable and compute it to use in
stylesheet
leaverou: Also, I've never seen a phi variable in a stylesheet. If
needed wouldn't we see in wild? I haven't seen in Sass or
CSS variables
TabAtkins: Right, where I have seen pi
jensimmons: I agree with TabAtkins that it's okay if people use 1.6
and don't need precise. I agree with leaverou that this
fetishization of golden ratio is ridiculous. But I think
it's interesting to add. It is humans writing this. It's
not that it's not possible to calculate. But it's giving
people a tool and saying here it is. If it's hard to
impl whatever. But it's simple. It's a human question,
is there a nudge to say to humans you should think about.
jensimmons: I have not seen people put golden ratio specifically.
But I have seen complicated Sass frameworks deeply based
on ratios. This is age of floats. But there is interest
in this kind of space
TabAtkins: If I recall Boulton work was exponential work. Ascending
series, not just golden
jensimmons: Both. Golden and a bunch of others
TabAtkins: You brought up it's not difficult to impl. You're
completely right. None of the constants are hard to add.
Implementation effort is more or less nill. Because of
that I want to be more principled to make sure there is a
need in the design community.
TabAtkins: I don't think we'll get much value from many constants so
we want to have a bar
plinss: Maybe similar to how we handle additional names colors
plinss: It's morally equivalent to adding a named color. We're
giving names to numbers.
TabAtkins: Yeah, they're not hard to put together. Yeah. We have
extra hard line against named color because that's
horrible. Named constants isn't as bad, but I agree it's
pretty similar
plinss: There are useful named colors; black, white, red. But we
don't want to add every named color
jensimmons: Agree we shouldn't go nuts with this. But I think reason
behind this is golden ratio is taught in art schools. I
could see a lot of discussion on this once it ships. I
don't feel that way about any other mathematical number
astearns: I agree us doing it could push more use of phi. I'm not
sure that's our place. I think we should be responding to
more use. More interest in having it if people noticed it
showing up in a lot of sass variables or custom properties.
astearns: Wary of let's put it out there and let people use it.
gregwhitworth: Doing a quick scan it doesn't look like it's in JS;
phi. I think this is a great candidate for what
leaverou brought up of finding stuff up based on
data. We should find out if there's common math eq in
calcs.
gregwhitworth: If it's not in JS I question strong case of adding it
TabAtkins: I don't take 'is it in JS' too strongly. We do more than
JS does with math. It's used in design less than
computing so not surprising. The database approach is
right. leaverou's casual investigation hasn't shown it,
but we could look in HTTPArchive. If you see 1.618 show
up a bunch it indicates people are using golden ratio
TabAtkins: A lot of cases it would show it it will have fairly
simple patterns
TabAtkins: Proposal: reject for now and leaverou would you take this
on for HTTPArchive data?
leaverou: Sure. I was planning on popular variables already
TabAtkins: Proposal: Reject for now and if data shows up from
HTTPArchive that it is fairly common we re-open and put
it in.
astearns: Objections?
RESOLVED: Reject for now and if data shows up from HTTPArchive that
it is fairly common we re-open and put it in
Form Controls
=============
Allow specifying the "accent color" of a form control element
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-656913918
masonfreed: Proposal is add ability to specify accent color for form
control elements.
<masonfreed> https://docs.google.com/document/d/1yHQUshdC3hKrDRG-xDtUPYVIcc_JNUglK0KMVoqRyCo/edit#heading=h.p0f1fs5x6ado
masonfreed: These are the ones that can't be styled, particularly
color. Looked at most form control elements. Put
together a study
masonfreed: Conclusion I came to is it seems we would need
foreground and background color. Many form controls
accent have 2 colors. Absent that we would need magic to
ensure contrast
masonfreed: In many cases it seemed like magic that would get in the
way for devs.
masonfreed: Motivation for us is Chrome recently changed from gray
to blue and that caused a lot of problems for devs that
had a theme on their site.
masonfreed: Not full styling but this seems to eliminate a lot of
problems
masonfreed: I did propose some spec language.
accent-color-background and -foreground. It's
necessarily vague because implementation varies across
browsers. Even if implementation is different across
browsers there's still value in being able to say here
is what I would prefer.
TabAtkins: Overall I like the idea. Similar to explorations a few
years ago where we suspected we could boil down color
choices
TabAtkins: On studies, checkmarks you have background as background
behind glyph. Screenshot has white checkmark and blue
background, but I think usual is dark glyph on light
background. Might be fine.
TabAtkins: More important is range inputs. Color of progress bar and
range input sounds like something to put under control of
page. But that's not being colored by either property you
provide. You give reasons, particularly for range inputs,
but it does worry me that's a missing thing
TabAtkins: I think it's really the only missing thing
masonfreed: On checkbox and radio. It was modern chrome. Impl differ
quite a bit and across platforms on same browser. That
was a more motivating case for both.
masonfreed: On range control, it's a general question. This isn't an
exhaustive list. Can't tackle all. Range control has
prefixed pseudo-elements. Though controlling turns off
default.
TabAtkins: My concern is if we add these range inputs won't be
sufficiently styleable. That's my only concern
masonfreed: I don't disagree. Perhaps that future improvement
TabAtkins: I'm happy with this and works for other control. I
support pursuing and see if we can solve range
astearns: I wanted to voice concern that these are vague in
application where UAs decide how to apply them. Understand
form controls are impl differently. May not be initially
ways of making this interop apply
astearns: Do you think that's set in stone or is making these colors
available and seeing differences sparking further interop
in form controls?
masonfreed: This isn't a fix for complete interop. It's a good
project which is being pursued. I see this as currently
form controls are not interop at all. Causes many
problems. Adding this mandate (since it's not well
specified)....currently colors are out of control of
authors. It moves us in direction of interop since there
is more dev guidance in the impl.
astearns: Yeah. Wanted to make sure not painting into a corner. This
isn't permanent bandaid and allows things to heal
underneath
masonfreed: Completely agree.
myles: A few minutes ago they said chrome switch from gray to blue
caused problems. Surprising that a browser made a change
which caused problems and fix is adding css properties. Some
thought to maybe that change to all websites in browser needs
work
masonfreed: I think this points to a current interop problem. Most
of the complaints were around a color change to blue
which existed in other browsers, incl Chrome on Mac. To
me what that means is they weren't testing on other
platforms or browsers since it was already blue. Making
this exposed would hopefully eliminate interop problems
dbaron: I do share some of astearns concerns. What I wanted to raise
is when TabAtkins went through list of controls, especially
range and progress. My understanding of description is what
is nominally foreground and background would we set to same
for range. I think this pic shows they're the same blue.
dbaron: Risky in that one of the things we try and do in css is push
that foreground and background should have contrast. We
should avoid situation where we want them not to contrast.
I'm worried about defining range in a way that foreground
and background used but not contrasting
masonfreed: Two comments. In document I call out thumb being
foreground and filled in as background. The screenshot
there is chrome current impl which has no contrast. That
is very different across browsers. I think it calls out
you want 2 colors so dev can choose different or
identical. Spec 1 color and an algo to choose contrast
precludes dev not wanting contrast
dbaron: In this case 3 colors on range. Question is which 2 can devs
spec with foreground and background
masonfreed: Agree. Ambiguous. That's the TabAtkins point range may
need additional work. I don't think try and spec exactly
which piece is foreground and which background. Point of
study is what do these typically look like in order to
have guidance. I don't think we should spec all pieces
now
dbaron: I think if you don't spec whatever first impl does everyone
has to copy. I think better to spec and discuss.
<astearns> +1 to spec where we can rather than leaving ambiguities
masonfreed: I see point but I point to current form control which
have been different for decades. I see point, it is
possible. Long term is expand and spec all parts and
allow complete style. I go back to this is a bandaid
between now and when that's real
emilio: Point out dbaron point where this cannot be left out to
whatever. We will have to copy 1st impl.
emilio: If I understand this is for native form controls, like
appearance:auto. Right?
masonfreed: Yes
emilio: Browsers don't always have control over those colors.
Example is range on linux and mac for FF the control are
drawn by the OS so this is not really impl right now. Want
to move to a place where we may not have native styling, but
right now couldn't impl
masonfreed: Take your point. Until recently on Chrome checkboxes on
mac not styled. That's more about why this should be
guidance for impl
emilio: But then not useful to authors. What authors could do is say
if browser supports I'll use it if not appearance:none. Not
sure to what point authors would bother.
masonfreed: Valid point.
<fantasai> Would like to note that locking down the exact UI of
every form control on every device forever just because
authors want to style them pixel perfectly on the devices
they care about is not good for users.
<Rossen> Trying to align styling of form controls is not a new
thing... certainly not new in terms of resolving against
it, see
https://lists.w3.org/Archives/Public/www-style/2019Jul/0002.html
jensimmons: I want to say thank you for going and doing more research
jensimmons: I like seeing you figured out we need 2 properties.
That's great, that's what we need.
jensimmons: As a front end dev the idea of these properties existing
is super appealing. I can just, universally or dark-mode/
light-mode, I can quickly change accent colors.
jensimmons: I think we believe there needs to be interop on this. I
understand desire to do something quickly and not have
to do deeper dive. Given reality of how tricky forms are
in browsers it's a rats nest.
jensimmons: One of the things about how modern css is specified we
learned the hard way what happens when underspecifying.
Form controls are bad because they were underspecified a
while ago. We can't repeat same mistake if we want to
get out from under.
jensimmons: Feels like if these properties went to world without
spec as to what part gets colors we wouldn't get same
from all browsers and situation could get worse. This
shouldn't try and fix everything and I appreciate desire
to do something quicker than openUI project.
jensimmons: I think right depth in technical debt is go through each
thing and define exactly what is foreground and
background. I don't know how to proceed without that.
Doesn't have to be worst thing every, but make it clear
that checkmark is foreground and behind is background.
If browsers aren't same it's not useful
jensimmons: Whatever browser ships first defines it is what happened
with css1 and 2 and then we end up stuck with things we
can't ever change.
astearns: If we do run into scenario where people have to copy 1st
impl it goes into spec, just too late.
<TabAtkins> light/dark mode is a lot different from "here's two
precise colors i need you to use"
gregwhitworth: I wanted to say I feel like people are alluding to.
We left style out of openUI charter because we didn't
think anyone would want to talk about interop
styling. I think people over there would be happy to
say what gets foreground and what's background. We
can take masonfreed's work as an initial stab.
gregwhitworth: I went and looked at browsers and saw
overlap...someone mentioned contrast...most component
libraries do magic.
gregwhitworth: I'd like to involve openUI in standardizing. In
addition we should provide that magic. CSS1 we
prevented all magic. We went the other way where we
have no magic. I propose language where if you
provide one browser does math to get contrast min so
we get browsers able to do contrast
gregwhitworth: Other argument where I'd like other browsers to weigh
in on route we didn't necessary do this for all
browsers. We didn't go through all controls where if
we're in dark this button gets a dark border. I'm
getting some conflicts but happy to peel onion. I
would love for us to be consistent if possible
florian: Conflicted. On one hand I agree with jensimmons and example
where range sometimes they contrast and sometimes not and
we should be deliberate and design. However, I don't
believe we can. OSs not only have different colors but
different structures. If you look at scrollbars they have
different parts from now and 5 years ago. If form control
looks completely different between browsers I don't see how
we crack this. All while agreeing with jensimmons
<TabAtkins> I think the properties currently hit a good mix of
specific and generic that'll be useful *and*
future-safe. dbaron's concern about range fg/bg is the
only one I'm really concerned about.
<fantasai> TabAtkins, clarify "currently"? what's proposed? or
what's implemented? :)
<TabAtkins> (I think we might be able to address it by instead
saying that Chrome *just* uses the foreground color.)
<TabAtkins> what's proposed
chrishtr: I don't think this would result in a disaster. Form
controls being very different is a big problem. I don't
think this adds to problem but subtracts.
chrishtr: Addresses main problem that color scheme doesn't match.
chrishtr: I think not a good idea to wait on complete solution
because will take long time. Could be reasonable to try
and approach where we write more specific suggestions in
spec that state things like on checkbox rec that
foreground is the glyph.
chrishtr: Then bring it to the group and see if it's reasonable set
of defaults for most browsers. Avoid problem of one
browsers chooses and make it more collaborative.
astearns: Sounds like a good next step.
<masonfreed> I'm happy to take an action item to recommend the added
spec recommendations suggested by chrishtr
fantasai: Same concerns as florian. I understand problem we want to
solve. Concern about idea that goal is make form controls
unified for now and in future. Lots of improvements to
form controls over time. I think it would be a little bit
inappropriate to say now is the best form of UI. I don't
want to lock into where we spec exactly what form controls
look like and in 5 years someone makes s new select box
style that's not compat. That's my concern.
<TabAtkins> That's also my concern, fwiw, and I think this proposal
specifically does *not* run into that.
jensimmons: I think we have a lot of agreement. We don't want to
over-control form controls because it needs to be
possible to invent new display. We know defaults are
different for very good reasons. There's a happy medium.
What chrishtr said is right that limit to what we can
thread the needle. I think everyone is saying things
that are true. We want to keep this scoped and tight so
it doesn't take forever but not create bigger problems.
astearns: Out of time. Everything we didn't get to goes on the
agenda next week
astearns: If you intend to only attend some meetings next week
instead of all please tag what you want to participate in
astearns: Thanks everyone and we'll talk more next week
Received on Wednesday, 22 July 2020 23:21:59 UTC