- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Jun 2023 19:51:26 -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.
=========================================
TPAC
----
- The group would like to do a joint meeting with WHATWG at TPAC.
Counter Styles
--------------
- After last week's resolution for issue #8636 (Should "Ready-made
Counter Styles" be supported by UA?) there were additional
concerns raised in Github about if the anchoring document is the
appropriate reference. The group discussed further and decided
to keep the resolution as is for now since it is better than the
current state even if it's not perfect.
- RESOLVED: Accept edits from the issue (Issue #8870: Korean counter
styles fallback)
- RESOLVED: Accept edits (Issue #8186: Setting
`CSSCounterStyleRule.name` should ignore symbolic
counter styles)
- There was interest in solving for issue #7959 (Support
automatically localized counters), but some concerns that with
the hundreds of languages this would cause lots of problems as
well. A more detailed proposal will be created to see if the
concerns can be addressed.
- Issue #8596 (System for cjk-earthly-branch and cjk-heavenly-stem)
is due to outdated tests and doesn't need a fix.
- RESOLVED: Change fallback for cjk-earthly-branch and
cjk-heavenly-stem to cjk-decimal instead of decimal
(Issue #8975: Fallback for cjk-earthly-branch and
cjk-heavenly-stem)
- RESOLVED: Republish CR [of Counter Styles]
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jun/0004.html
Present:
Rachel Andrew
Tab Atkins
Rossen Atanassov
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Daniel Holbert
Richard Ishida
Jonathan Kew
ChangSeok Oh
Florian Rivoal
Vitor Roriz
Jen Simmons
Miriam Suzanne
Bramus Van Damme
Chair: miriam
Scribe: emilio
TPAC
====
Joint tpac session with whatwg
------------------------------
TabAtkins: They would like to do a joint session for things that
cross over html
TabAtkins: UA CSS, position, ...
TabAtkins: Is there interest in that?
<fantasai> wfm
Rossen: Why shouldn't we? We work on pretty close stuff
<florian> +1 to give it a go
TabAtkins: Topics would include declarative shadow dom, reorder
API, [missed]
miriam: Also importing into layer with <link> too?
<bramus> Here’s the link to that issue Miriam mentioned, @TabAtkins:
https://github.com/whatwg/html/issues/7540
TabAtkins: sure, it's a gdoc now but should be a public issue soon,
like next week
Counter Styles
==============
Should "Ready-made Counter Styles" be supported by UA?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8636
miriam: Given the new comments, left there in case we want to revisit
TabAtkins: We agreed last week to change the ready-made
counter-style doc into a registry
TabAtkins: and require must level support
TabAtkins: r12a commented and they want to make sure that people
that want minor tweaks can copy and paste
TabAtkins: Counter-argument from myles and jensimmons is that most
people can do that with the UA sheet and most people
don't know that document or the spec exists
TabAtkins: I agree with them, given how counter-styles work we don't
restrict authors in any way
r12a: Don't want to repeat the thread
r12a: If myles and jensimmons think we can keep up with all the
changes and are prepared for the other stuff that would be
necessary
r12a: getting stuff into the counter-styles spec or the registry is
the easy part
r12a: We also have to have tests and check that the stuff is
supported and which ones are supported by which browser and so
on and change browsers to implement as needed
r12a: If they feel comfortable that it can be done then that's fine
r12a: The thing about this doc is that it was designed to be very
flexible so that we could change it easily
r12a: it was never intended to be an exhaustive resource
r12a: having the registry makes it a lot more formal
r12a: I don't have experience maintaining/running one
r12a: but if it makes it more formal we kinda have an additional
problem which is what counter styles / languages do we want to
support
r12a: There are 7k languages in the world
r12a: so those worry me a bit
r12a: if other people think there are no major issues and that can
be handled then that's great
TabAtkins: That doc was extracted from the spec
TabAtkins: the intent was to always making it required
TabAtkins: it was removed because browsers didn't want at the time
to carry a couple hundred of styles
TabAtkins: as we need to adopt more we can continue to support new
communities and languages
TabAtkins: shouldn't make perfect the enemy of good and we can make
good for a bunch of people
florian: I think the question is more about whether browsers should
ship it, not about registry
florian: registry we can worry about separately
jensimmons: I appreciate the perspective from r12a and your context.
Maybe this doc has been pretty good but not perfect
guidance
jensimmons: To go from that to putting it in browsers that might be
a different story, maybe it's a bit more intimidating
jensimmons: I do feel like that phrase (don't let the perfect be the
enemy of good)
jensimmons: I'd like browsers shipping more of these by default
jensimmons: I also think this could create a bit more attention
about this
jensimmons: and I think we would be in a better place than now
<TabAtkins> I also suspect that testing all these is best done by
auto generation - throw a parser at it, create a
standard set of tests out of it. That way we can (a)
actually test the ones that exist and (b) keep up with
updates easily
<emilio> +1 TabAtkins, was thinking the same
florian: I think it'd be good to ship more than what we're shipping
now, but I wonder how many of these are known to be good
enough?
florian: If we're outfashioned by a decade that's not concerning,
but maybe some are plain wrong
florian: specially some of the rarer languages
florian: on one hand it is great to get more languages
florian: Do we have any way of knowing which counters are known
good, which ones need tweaking, and which one are a first
try but not known good?
TabAtkins: We'd still recommend people use these I'm not sure that'd
be worse
florian: When we do that people do it deliberately
florian: but that takes less review to give it a go
TabAtkins: And when we find errors, which we probably will more
often if it's in browsers
TabAtkins: updating is a copy/paste operation
TabAtkins: so it's trivial
r12a: We tried to make them as accurate as we can but there've been
changes to popular languages
r12a: like Hebrew / Greek
r12a: also name changes e.g. Serbian recently
r12a: we've made a bunch of changes to separators
r12a: can't answer to how many are good or bad, we try that all of
them are ok
plinss: Also languages change
plinss: so we'd need to update in the future
r12a: Most of the newer styles are defined by you, maybe with some
tweaks from the document, but it wouldn't change underneath
r12a: if we decided that the best separator for ?? was this
separator or other people's list would change
r12a: currently you copy it and it stays the same until we decide
plinss: I don't see it as precluding that, you can always copy it if
you care about it
fantasai: From a compat perspective there are some changes, for
separator changes it's aesthetic and it probably doesn't
have much impact
fantasai: number changes can be more problematic, especially if
there are cross-references to it; but then, if there are
manual cross-references, the author is more likely to
notice if there's an actual error and switch the style
fantasai: I think we're fine with these having minor changes
fantasai: if we're not fine with those to exist in documents we
should wait until the counter styles are more stable
before baking them in
<r12a> I take the point that if things change in a way that the
author doesn't like then they can still change it for
themselves using the @counter-style approach
jensimmons: I think there are some interesting points made here,
might be helpful to go back to the issue
TabAtkins: yeah if there are no major objections to the resolution
we should continue no change
jfkthame: This is a bit parallel to a recent change in CLDR which
affected date formatting in some languages
jfkthame: it caused a fair amount of compat pain
jfkthame: I could see that happening around this
jfkthame: sites are sometimes fragile to this stuff
r12a: If something changes about the UA the author can still reverse
it manually
r12a: People brought up that not many people knew about it, but it'd
be useful to point to it from mdn
miriam: Let's take it back to the issue then
Korean counter styles fallback
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8870
TabAtkins: Real quick rubber-stamp. Several years back we agreed
that Korean falls back to cjk decimal but I did it wrong
TabAtkins: and accidentally default to decimal now
RESOLVED: Accept edits from the issue
Setting `CSSCounterStyleRule.name` should ignore symbolic
counter styles
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8186
TabAtkins: Again obvious bug-fix, I had two places which reference
the special counter-styles
TabAktins: didn't keep them in sync
TabAktins: so cssom had a shorter version of the list
TabAktins: I've made the list a defined term and reference in both
places
TabAktins: only needs sign-off
TabAktins: also impls do this correctly
RESOLVED: Accept edits
Support automatically localized counters
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7959
TabAtkins: r12a do you think that this is more of a topic to be
discussed or something to be introduced?
r12a: We could discuss the concept, my take was similar to the
ready-made counter-styles
r12a: I'd think it'd be something that authors would define rather
than something built-in
r12a: would you like to introduce this?
<r12a> https://github.com/w3c/csswg-drafts/issues/7959#issuecomment-1592610379
TabAtkins: Somebody filed it requesting that for a few different
categories we have an automatically-internationalized
version
TabAtkins: e.g., `digits` would be `decimal` for english, french...
but map to something else for other languages
TabAtkins: Same for letters which could map to hiragana in japanese
TabAtkins: Before we accepted moving counter styles into the
registry this was a lot harder to do
TabAtkins: r12a proposed a new at-rule mapping lang to digits
TabAtkins: Does this sound worth pursuing
r12a: The registry doesn't really need to enter in
r12a: Needs to work with author styles
r12a: Just a clarification
<TabAtkins> My thought was just that, since we'd be supporting a ton
of these, we'd also have a UA stylesheet registry with a
bunch assigned. Authors would still be able to extend/
override it.
jensimmons: I really like this idea
jensimmons: so many languages have translations
jensimmons: so even if they are not published in different languages
jensimmons: I'd love for it to be in some ua default
jensimmons: but if it can't be it'd probably end up in some kind of
reset/framework sheet
<TabAtkins> (I'm just gonna say that this was noted as actually
being helpful for Wikipedia; they currently manually set
a bunch of counter styles for the different translations)
<fantasai> https://github.com/w3c/csswg-drafts/issues/7959#issuecomment-1592298287
fantasai: There's some complications here
fantasai: see linked comment
fantasai: (a) you don't always want to translate the counter style,
e.g. western digits might be used in other languages
fantasai: (b) some languages have multiple styles which might be
designer-preference or so
fantasai: so I'm skeptic of adding something built-in
fantasai: it'd be relatively straight-forward to do this using
`:lang()`
fantasai: what we don't have is a way to set a default counter-style
for the counters function
fantasai: if we have that e.g. via a `counter-style` property then
it'd be really easy to make this mapping in the stylesheet
<TabAtkins> "relatively straightforward" is still hundreds of
selectors, fwiw
<TabAtkins> and there are two types at least - numeric and writing -
so a default counter() style won't satisfy it
florian: I'm nervous, I really like the vision of the international
way, but this makes me nervous because it heightens the
worry of the previous issue
florian: if you copy and paste it you check they're right, if you
turn them on you likely at least checked
florian: it increases the chances of a wrong counter style appearing
in the page if you need to do neither
florian: other concern is getting the mapping wrong
florian: e.g., Japanese might not want to automatically switch to
hiragana, I don't think it should be default, that would be
jarring
florian: if we were doing a couple or ten languages then we can
probably figure it out
florian: but if we want hundreds, how often would we get it wrong in
a way that's worse
TabAtkins: if this is just a matter of UA rule then it is fixable
TabAtkins: as we discover that they're wrong we can just get them
fixed
TabAtkins: as the way it'd be designed you could override any of the
mappings
<TabAtkins> I'm happy to separate the "define the at-rule" part from
the "and then put a default version of it into the UA
stylesheet"
r12a: What florian and fantasai were worried about is if this is
baked into the browser
r12a: proposal so far is to make it an author controlled rule for now
r12a: I think that should be less problematic
florian: What I'm about to say depends on whether this is
auto-turned-on or not
florian: do authors need to opt in?
TabAtkins: Proposal is to define some new at-rule to define mapping
from "generic family" to concrete style
TabAtkins: then there's the question of "should we have a default in
the UA sheet"
florian: The latter makes me very nervous
florian: e.g., English is a roman-alphabet language, so suppose
someone thought that it would be appropriate to use roman
numerals, and then shipped it out across the Web. That
would be very disruptive
<fantasai> +1 florian
florian: sure, we could fix it--and for English it would happen
quickly--but for a less common language, it could take a
long time to bubble up
florian: and in English we'd notice fairly easily
florian: but maybe not for smaller languages
TabAtkins: I don't think we'd auto-apply it to ol
TabAtkins: but if auto-applying the mapping is controversial let's
discuss that separately
fantasai: I think we need a more specific proposal
TabAtkins: Assuming there's no objections I think we should pursue
this idea
[more discussion about auto-applying vs not]
jensimmons: You wouldn't be declaring the whole counter styles, but
you'd define the mapping to language and you'd have to
use it in your list-style
florian: As long as we don't auto apply <ol> in numeric types
florian: I'm fine
<TabAtkins> `@generic-counter-style digits { en-US: decimal;
...}`rather than `ol:lang(en-US) { list-style-type:
decimal; } ...`
jensimmons: Instead authors would need to opt-in into this
generic-digits
fantasai: Two thoughts. How much of this could be done using our
existing mechanism using lang selectors with a
`counter-style` property
fantasai: Other question is, even with a new opt-in keyword for this
and deployed that what I'd expect to see is that a lot of
people that are authoring pages would use it and then get
wrongly translated things in other languages
TabAtkins: Let's push that topic out
TabAtkins: not discussing applying anything automatically
fantasai: Not talking about that, just about any thing in the UA
sheet
fantasai: if only for authors, do we need a new mechanism, or can we
use :lang()
TabAtkins: Let's stop discussing the second point. Can authors do
this today? yes
TabAtkins: see example above
TabAtkins: This would be essentially just sugar over that
TabAtkins: Possibly a bit more efficient for browsers (less
selectors?)
TabAtkins: but yeah it'd essentially be just sugar over selectors
r12a: I don't think that's quite right
r12a: in the labeled-digits example you can just use in the
stylesheet to use digits
r12a: so I think it's a little extra
TabAtkins: No you can always just apply the language selectors you
want yourself
TabAtkins: nothing fundamentally new or magical about it
<r12a> generic-counter-style: "digits" {
<r12a> 'ar':'arabic-indic',
<r12a> 'bn':'bengali',
<r12a> 'my':'myanmar',
<r12a> 'az-arab':'arabic-indic',
<r12a> 'suz':'my-own-sunuwar-style',
<r12a> .... }
miriam: seems like back to the issue for the full proposal
System for cjk-earthly-branch and cjk-heavenly-stem
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8596
vitorroriz: Some years ago the spec changed alphabetic to fixed
vitorroriz: so just wanted to make sure it's fixed indeed
TabAtkins: Yeah tests were just wrong
vitorroriz: I fixed them
TabAtkins: Great, nothing on the spec needs change
Fallback for cjk-earthly-branch and cjk-heavenly-stem
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8975
fantasai: Seems reasonable, we should make the change and republish
<TabAtkins> seems reasonable to me too
miriam: Objections, anyone need more context?
emilio: Would like someone familiar with cjk to look at it, but
otherwise seems fine
TabAtkins: All fall back to cjk-decimal because of full-width, same
applies to these
<fantasai> +1 TabAtkins
RESOLVED: Change fallback for cjk-earthly-branch and
cjk-heavenly-stem to cjk-decimal instead of decimal
RESOLVED: Republish CR
Received on Wednesday, 21 June 2023 23:52:07 UTC