- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Jun 2021 13:06:41 -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.
=========================================
Counter Styles
--------------
- RESOLVED: Make all predefined symbolic counter styles not
overwritable (Issue #3584: overriding symbolic counter
styles)
- RESOLVED: When you extend a predefined symbolic you are extending
the version defined in the spec (Issue #3584)
- RESOLVED: Leave the spec as it is and have browsers fix the bug
(Issue #5906: Change how 'pad' descriptor handles
negative sign to match implementations)
- RESOLVED: Accept the PR linked in the issue defining how counter
style scoping works with shadow dom (Issue #5693: Clarify
how @counter-style name lookup works with shadow DOM)
Media Queries
-------------
- RESOLVED: Add 'custom' value to prefers-contrast for defined color
schemes that are not more or less (Issue #6036: Remove
(prefers-contrast) as a boolean, and replaced by a new
color reduction media query)
Informal spellings in specifications
------------------------------------
- RESOLVED: We consider informal spellings to be typos to be fixed
when found and avoided if possible (Issue #5850)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0000.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Oriol Brufau
James Craig
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Una Kravets
Daniel Libby
Ting-Yu Lin
Alison Maher
Morgan Reschenberg
Melanie Richards
Florian Rivoal
Alan Stearns
Miriam Suzanne
Regrets:
Brian Kardell
Lea Verou
Scribe: dael
astearns: Is jcraig on?
[silence]
astearns: If he does show we need to change the order to get to item
#6
astearns: Any other changes people would like?
Counter Styles
==============
Overriding symbolic counter styles
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3584
TabAtkins: In current spec I went conservative with locking down
styles so could not be overwritten.
TabAtkins: After prodding I added a few things in addition to
decimal. For example, disc. Emilio is asking for others
not to be overwritable. Rendered specially by browsers so
requires a bit more work.
TabAtkins: I'm happy with this. You can make your own and give it
your own name. Need sign off
astearns: Yes, there is the out of making your own. Do you think
there is a compat problem where we will remove people's
overrides?
TabAtkins: I strongly doubt. If you're doing a counter style named
square that is not squares you're bringing it on yourself
astearns: Your special squares is the thing. Going back to normal
boring squares is not that terrible
astearns: Any concerns with the change?
astearns: Proposal: Make all predefined symbolic counter styles not
overwritable
TabAtkins: All predefined symbolics
astearns: Objections?
RESOLVED: Make all predefined symbolic counter styles not overwritable
TabAtkins: What if you extend these?
TabAtkins: Two major options
TabAtkins: First is that whenever you extend a predefined counter
style the thing you are extending is the spec version, not
what browsers do. Means you might get slightly different
glyph
TabAtkins: Still approximately the same
TabAtkins: Other is doing more subtle thing where certain descriptors
cause revert to version in spec. That still has
complications
TabAtkins: Proposal: if you extend a predefined symbolic you are
extending the version defined in spec not as rendered in
browsers
fantasai: Reasonable you might want to extend with some such as
speak-as without effecting rendering
TabAtkins: Symbolics with speak-as; the best you can do it make them
read decimal of counter. Doing that one something that
doesn't render a number doesn't sound good
TabAtkins: Decimal is fine. Predefined symbolics where in spec you
can render in other ways
fantasai: So this is just circle, disc type ones?
TabAtkins: Yeah
oriol: This is how FF and Chromium render so it is fine
astearns: Proposal: When you extend a predefined symbolic you are
extending the version defined in the spec
astearns: Objections?
RESOLVED: When you extend a predefined symbolic you are extending the
version defined in the spec
Media Queries
=============
Remove (prefers-contrast) as a boolean, and replaced by a new color
reduction media query
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6036
astearns: There are new proposals at the end of the issue
alisonmaher: Previously resolved to remove prefers-colors:forced.
This issue was a follow up to prop a new MQ to capture
intersections under reduced complexity. Various
proposals including adding back forced
alisonmaher: Summarizing various options
alisonmaher: If middle range is not a valid contrast preference one
option is a new MQ to capture intersections
alisonmaher: Could leave spec as is and add examples to handle
<astearns> +1 to adding examples of mid-range things, regardless of
outcome today
alisonmaher: If middle range is valid, other options
alisonmaher: If add back prefers-contrast:forced it captures the
users in the middle range, but author confusion
alisonmaher: Another is adjust the cut off between more and less to
get middle range. Might also add confusion
alisonmaher: Another option is add a third value of middle to capture
the preferences. Allows express neither high nor low,
but not no preference
alisonmaher: Personally leaning toward a new value, but curious rest
of the group's thoughts
florian: Thanks for bringing this. Middle value, probably name is a
big part of usability. Naming aside, is this supposed to be
same semantics as forced?
alisonmaher: Different. Forced value matched no matter the contrast
preference. Middle would only match for users in the
middle range. Only in forced color mode for now, but
could make sense for future values as well
TabAtkins: This is reasonable to me. Fills in the case. Forced but
not high nor low. That's the spot we wanted addressed. Use
this as a boolean to indicate general contrast preference.
This is fine
fantasai: My concern a little bit, don't know all usage, but this
would be interpreted as I want grey on grey text, but not
too grey. Not quite black on white, but more between and
author would be encouraged to include that.
fantasai: Reason we had that is for causes when someone wanted a
contrast in hue that was not low or high for luminosity.
fantasai: If you were going to have fuchsia on blue it's got a strong
hue contrast, but not strong luminosity. That's presumably
middle but isn't want people would picture. I think adding
a middle value would add confusion
fantasai: I think anyone pulling out prefers-contrast:middle would be
confusing
alisonmaher: Are you saying naming is confusing or it wouldn't make
sense to query a middle value?
fantasai: Kinda both. How is author supposed to respond to
prefers-contrast:middle?
alisonmaher: Not sure use cases. Making sure if a user in that range
we would capture in prefers contrast boolean. Not sure
us cases to target middle by itself
fantasai: We're trying to capture contrasts not high nor low but
specific. I think middle is not a good representation of
that
astearns: But there is A preference, just not high or low. Middle
expresses the not high or low but may not be expressing the
chosen colors
jcraig: I've caught up on the thread and thanks to alisonmaher about
correcting my misunderstanding earlier. As far as I
understand only current impl where this matches is impl with
forced color that are not high or low contrast
jcraig: I believe were we landed on in issue #5433 is this middle
range may have people matching but doesn't represent anything
sufficiently about contrast so keeping out of contrast was
preferably. But forced colors would remain about forced colors
<astearns> other discussion:
https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-785251576
jcraig: This group is matchable if you have not prefers-contrast:more
and not prefers-contrast:less.
jcraig: I think goal of group was to get to something like prefers
reduced color complexity. If we're trying to do that we need
to name it something obvious to the author. I don't think
middle is for a preferred reduction in complexity. Feel it's
muddling
jcraig: Is the goal that the group wants to get rid of forced-colors
media preference?
alisonmaher: Main issue comes down to do we agree middle range is a
contrast preference? Different resolutions depending on
the answer
astearns: Are you looking to removed forced colors MQ?
alisonmaher: No. But seemed like matching the middle range in the
boolean is of interest.
florian: I think I agree with fantasai that middle is the wrong name
if we have it. Unusual or unspecific that indicates that
there is a preference is better. That people would query
that specifically, I suspect for boolean is more likely but
either way you could query.
florian: It's possible to query the middle value which is why I like
both old and new
<TabAtkins> My q+ was to suggest "complex", yeah
<fantasai> lol, I'd have suggested "simple"
<Rossen> Have we considered naming it "custom"
<fantasai> The preference isn't complex. It's for simple color
contrast.
<fantasai> Just different from either high or low
<fantasai> Rossen, that could work...
<dbaron> I think it would help with the naming to understand who the
users are who have this type of preference, and why they
have it (and perhaps how essential it is to their ability to
use the web).
<TabAtkins> The only purpose of this third value is to handle pages
with reduced color palettes that can't otherwise be
categorized as high or low contrast.
florian: As to why reopen I thought I had lost the battle and gave up
but immediately after it was closed there were questions on
how to deal with this and fremy posted good examples.
florian: Crux of the issue is it's 1 to 1 with prefers reduced
complexity. Important thing is how it will be used. Typical
thing in context of the boolean query for prefers-contrast
without a specification of high or low is to reduce color
complexity of the page. Seems odd to have a query for that
but fails to capture a set of the users
florian: When query with intent of reduce complexity this almost
always gets you there, so why not make sure it gets all the
way
florian: Given it was re-raised and you agreed it was 1 to 1 with
reduced color I thought why not
jcraig: Main goal is to get back to previous value of boolean match?
florian: To me, yes. If you use first contrast as a boolean it would
be useful if it matched odd contrasts. Not sure what you
would use that to match and not want these people
jcraig: My recollection is I do agree there could be a correlation
between a desire for reduced complexity and forced colors.
Thought we settled that should be something as a clearly
named MQ. Could be if you have high or low contrast it would
also match prefers-reduced-complexity
jcraig: It could match @media for prefers contrast and prefers
reduced complexity. Today should be able to do it with @media
prefers-contrast or forced-colors
fantasai: To go back to what is goal of issue- make sure everyone
with any color contrast preference get captured under
prefers-contrast:true. Low and high preference are captured
under low and high keywords. We want anybody with a
contrast preference that's neither low nor high luminosity
are also captured under yes so they are captured
fantasai: That's separate...you will often implement that as reducing
color complexity but this is the question about what does
prefers-contrast mean
florian: It's a question of constituency priority. Put users first.
Author thinking about the problem with all angles could get
there however I think it is typical for authors to not think
of every case and hope it's useful. I don't think anybody
has example of piece of style you would write under boolean
prefers-contrast that wouldn't be useful to people with
unusual scheme.
florian: Small group, but it is useful. If authors are writing and we
could make it apply as useful I think we should. I don't
think we should add intent-based queries with feature-based
queries.
florian: If there are cases of adding the boolean that shouldn't
catch these people then the argument falls apart. But the
argument that you could target isn't a good reason to
exclude these people
jcraig: Answering alisonmaher from earlier I think she asked earlier
do we agree middle is a contrast preference. My opinion is
no. fantasai earlier mentioned prefers-contrast more would
have a luminosity contrast value and less lower. Middle is
luminosity value that doesn't represent contrast in either
direction
jcraig: May also be color preference with hues, but that's
circumstantial. May or may not be contrast preference in hue,
but no preference in luminosity. So I don't think this
represents a preference. To help users have to help authors
understand what they're trying to do for the users
<Morgan> +1 to jcraig's opinion
astearns: I wanted to ask...I think we have a problem coming up with
a name for the value because don't have a good idea of what
contrast preference is expressed by having forced colors
astearns: Agree it would be nice to include people that have chosen
forced colors in a prefers-contrast MQ because they have
expressed preference in colors with some contrast. Can we
define it to return true if forced colors is on and not add
value?
TabAtkins: Violation of current data model. Not impossible, but seems
weird. Only reason trying to do something special is we
can't think of a name and I'd like to have a name. But
this is not impossible. This MQ does a slightly different
thing with boolean than everything else
florian: Kind of disagree with jcraig that we should name different
to cover everyone. Query specifically for high or low
contrast makes sense. If we have those individually and the
boolean people will sometimes use high or low or sometimes
the color and that seems problematic.
florian: I think bias to easily discoverable doing the right thing is
how we get the platform to be usable
dlibby: Back to color preference with hues as separate from contrast.
Wanted to check thoughts on forced-color affecting
prefers-contrast. That statement feels at odds with
agreement. To extend forced-color effects prefers-contrast in
most cases preference is to have it apply for all cases in
the boolean context
Rossen: I put this in IRC; can we align with calling it 'custom' and
stray away from middle or not? Values can be higher or
highest and what it comes down to is we're trying to say we
know how to capture high and low and in between is a custom
value that we want to allow authors to take advantage of. As
far as naming goes 'custom' makes sense to me
<TabAtkins> I'm happy with "custom"
<fantasai> +1, wfm
<florian> I'm happy with custom.
<dlibby> custom sgtm too
florian: works for me
astearns: Lots of +1 on IRC
jcraig: I'm not convinced it's necessary, but not strong enough to
object. 'custom' is a better name than middle. If that
satisfies desire to keep boolean and embed reduced complexity
inference I think it's probably okay. I can live
astearns: For my clarification, this 'custom' value would return true
if forced colors were active?
jcraig: And the resulting contrast does not match more or less. More
or less defined with luminosity contrast
astearns: Add a 'custom' value that matches if forced-colors is
active but it's not more or less
jcraig: I wouldn't leave it to be forced-colors. Has to do with
defined color scheme. Custom color scheme that doesn't match
more or less.
astearns: Yeah, any sort of defined color scheme that's not high or
low
astearns: Objections?
RESOLVED: Add 'custom' value to prefers-contrast for defined color
schemes that are not more or less
Counter Styles (continued)
==========================
Change how 'pad' descriptor handles negative sign to match
implementations
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5906
TabAtkins: It was brought up that browsers do not impl the spec with
regards to pad descriptor and negative
TabAtkins: Pad is defined that if you have negative...pad 8 if your
counter doesn't use 8 we pad it with more.
TabAtkins: If you have a negative sign we consider that part of
counter value so add less pads.
TabAtkins: Intention is that assuming you use monospace fonts if you
have positive or negative number you have same length of
counter style representation
TabAtkins: Browsers currently have it that any negative value is
longer than pad. Suggestion is change spec to current
compat. I would prefer not to. I don't believe there's
impl complexity there. Seems accidental. Doubt there's
compat constraints
TabAtkins: If people agree like to resolve to not change and have
browsers fix. Would like to hear if anyone disagrees
astearns: Anyone with preference to change spec?
heycam: Question. Are people using pad solely to make sure same
number of characters for layout or also because want same
number of digits for something semantic like an order number?
TabAtkins: If you're using counter mechanism to do semantic leading
0s you're really messing yourself up. I doubt it. Web is
big, but not a supported use case
oriol: No strong opinion on this. Would not mind no change. Seems a
bit inconsistent to me. Prefix and suffix can add content that
is not counted for padding.
oriol: Maybe more consistent to say we don't include any of the extra
things, prefix, suffix, or negative sign. Maybe in future
authors can select which they want to include for generating
padding
TabAtkins: Reason no prefix or suffix they're added unconditionally.
Doesn't matter the value, they're added. You get the same
for spacing regardless of value
TabAtkins: Also, prefix and suffix only added when done with default
but negatives can be part of counter function. A little
more important for that reason
TabAtkins: Main reason is negative sign is conditional and if you
want a particular width you need to adjust for it
oriol: Counter function not including prefix and suffix is good
point. Fine with your proposal
fantasai: Reminding people you can pad with spaces as well. That's
one case where you're going for layout consistency
<TabAtkins> Padding with spaces.... don't work well with negative
signs, fwiw
<TabAtkins> `- 5`
astearns: I facetiously asked in IRC if anyone was using pad, but
made me wonder if there are usage of pad that rely on
current browser behavior and would no longer work with spec
TabAtkins: I doubt there are. I don't know of if there is measurable
usage. I doubt there is a subset that requires a negative
value to be one character longer
astearns: And fantasai your point about spaces I didn't get an idea
as to if leaving spec changes it?
fantasai: Leaving spec is appropriate
astearns: Prop: Leave the spec as it is and have browsers fix the bug
astearns: Objection?
RESOLVED: Leave the spec as it is and have browsers fix the bug
Clarify how @counter-style name lookup works with shadow DOM
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5693
TabAtkins: We talked previous week about the small change to name
defining constructs to work with scoping. This is a
request for approval to edit counter styles so that it
works with the scoping machinery. Define counter style in
outer page you can reference it within shadow dom. If you
define it within the same name it stays in the shadow and
overrides
TabAtkins: If you define it in the outer, inherit into a shadow, and
redefine you get what you think you should use. Nothing
novel, but spec needed a change to hook into that and I
wanted approval because it is normative
<TabAtkins> https://github.com/w3c/csswg-drafts/commit/29a198d657494c855d79e0a3c7a3817d3ae42c11
astearns: Proposal: Accept the PR linked in the issue defining how
counter style scoping works with shadow dom
astearns: Objections?
RESOLVED: Accept the PR linked in the issue defining how counter
style scoping works with shadow dom
Informal spellings in specifications
====================================
github: https://github.com/w3c/csswg-drafts/issues/5850
florian: Keeps coming up and never had central discussion. Mostly
manifests in TabAtkins using spellings he believes are
appropriate but many don't recognize.
florian: Double question. Are they appropriate and, given they're not
recognized, as should specs stick with mainstream?
florian: I suspect would like spec to stick to mainstream
florian: As a non-native speaker I didn't find them confusing but
given my exposure to standards is a large part of how I
learn English what I see in specs I assume to be normal. I
think it's unpleasant for non-native speakers to assume
things are mainstream when they are not.
florian: When you're a non-native speaker people look at you weird
and think you don't speak properly. Probably not the goal of
this, but a risk
TabAtkins: There has been speculation as to what my goals are. I
don't have any and that's how I write. It's not easy for
me to train my fingers. Happy if people want to run spell
check. We don't do it in general.
TabAtkins: This is just how my fingers spell the words. It was
intentional on my part, but not a drive on my part to make
changes to English.
astearns: So you say TabAtkins you are fine with corrections. If
people point out discrepancies will you make edits?
TabAtkins: I suspect if I say yes someone will go through and tell me
to make changes and I'd rather they put in a PR
astearns: Oh yes. But I think I have seen I have this PR, please give
review, and some comments are a misspell, I would
appreciate if you made those changes
TabAtkins: Sure. It's fine.
iank: I wanted to quickly say I somewhat worry if we have a hard and
fast rule about the type of English will be a barrier for
people writing spec. Specifically non-US-English speakers
TabAtkins: There is a W3C rule that we write in American English, but
that's the whole rule
astearns: Fine for spec writers to use the skills they have and if a
typo is pointed out we can fix
fantasai: Should make an effort not to make typos
smfr: I think we spec undergo transition is a good time to do
editorial pass and make sure spec is generally American
English. Just like a privacy and security review
astearns: Makes sense
fantasai: Sounds like converging that non-standard spellings are
typos and should be handled as such
astearns: Yep
florian: Works for me. Wanted to avoid having the discussion 23 times
and do it once centrally
astearns: Proposal: We consider informal spellings to be typos to be
fixed when found and avoided if possible
RESOLVED: We consider informal spellings to be typos to be fixed when
found and avoided if possible
astearns: Thanks everybody and we'll talk next week
Received on Thursday, 3 June 2021 17:09:15 UTC