- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Jun 2023 16:33:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA?`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA?<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/8636<br> <emilio> TabAtkins: we agreed last week to change the ready-made counter-style doc into a registry<br> <emilio> ... and require must level support<br> <emilio> ... r12a commented and they want to make sure that people that want minor tweaks can copy and paste<br> <emilio> ... 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<br> <emilio> ... I agree with them, given how counter-styles work we don't restrict authors in any way<br> <r12a> q+<br> <emilio> ack r12a<br> <emilio> r12a: don't want to repeat the thread<br> <emilio> ... if myles and jensimmons think we can keep up with all the changes and are prepared for the other stuff that would be necessary<br> <emilio> ... getting stuff into the counter-styles spec or the registry is the easy part<br> <emilio> ... 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<br> <emilio> ... if they feel comfortable that it can be done then that's fine<br> <emilio> ... the thing about this doc is that it was designed to be very flexible so that we could change it easily<br> <emilio> ... it was never intended to be an exhaustive resource<br> <TabAtkins> q+<br> <emilio> ... having the registry makes it a lot more formal<br> <emilio> ... I don't have experience maintaining/running one<br> <florian> q+ to make a brief point about registries<br> <emilio> ... but if it makes it more formal we kinda have an additional problem which is what counter styles / languages do we want to support<br> <emilio> ... there are 7k languages in the world<br> <emilio> ... so those worry me a bit<br> <emilio> ... if other people think there are no major issues and that can be handled then that's great<br> <emilio> TabAtkins: that doc was extracted from the spec<br> <jensimmons> q+<br> <emilio> ... the intent was to always making it required<br> <emilio> ... it was removed because browsers didn't want at the time to carry a couple hundred of styles<br> <emilio> ... as we need to adopt more we can continue to support new communities and languages<br> <emilio> ... shouldn't make perfect the enemy of good and we can make good for a bunch of people<br> <miriam> ack florian<br> <Zakim> florian, you wanted to make a brief point about registries<br> <emilio> florian: I think the question is more about whether browsers should ship it, not about registry<br> <emilio> ... registry we can worry about separately<br> <miriam> ack jensimmons<br> <emilio> jensimmons: I appreciate the perspective from r12a and your context. Maybe this doc has been pretty good but not perfect guidance<br> <emilio> ... to go from that to putting it in browsers that might be a different story, maybe it's a bit more intimidating<br> <emilio> ... I do feel like that phrase (don't let the perfect be the enemy of good)<br> <florian> q+<br> <emilio> ... I'd like browsers shipping more of these by default<br> <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<br> <emilio> ... I also think this could create a bit more attention about this<br> <emilio> ... and I think we would be in a better place than now<br> <emilio> +1 TabAtkins, was thinking the same<br> <emilio> 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?<br> <emilio> ... if we're outfashioned by a decade that's not concerning, but maybe some are plain wrong<br> <emilio> ... specially some of the rarer languages<br> <r12a> q+<br> <emilio> ... on one hand it is great to get more languages<br> <miriam> ack florian<br> <emilio> ... 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?<br> <emilio> TabAtkins: we'd still recommend people use these I'm not sure that'd be worse<br> <emilio> florian: when we do that people do it deliberately<br> <emilio> ... but that takes less review to give it a go<br> <emilio> TabAtkins: and when we find errors, which we probably will more often if it's in browsers<br> <emilio> ... updating is a copy/paste operation<br> <miriam> ack r12a<br> <emilio> ... so it's trivial<br> <emilio> r12a: we tried to make them as accurate as we can but there've been changes to popular languages<br> <emilio> ... like hebrew / greek<br> <emilio> ... also name changes e.g. serbian recently<br> <emilio> ... we've made a bunch of changes to separators<br> <emilio> ... can't answer to how many are good or bad, we try that all of them are ok<br> <emilio> plinss: also languages change<br> <emilio> ... so we'd need to update in the future<br> <emilio> r12a: most of the newer styles are defined by you, maybe with some tweaks from the document, but it wouldn't change underneath<br> <emilio> ... if we decided that the best separator for ?? was this separator or other people's list would change<br> <jensimmons> q?<br> <jensimmons> q+<br> <emilio> ... currently you copy it and it stays the same until we decide<br> <emilio> plinss: I don't see it as precluding that, you can always copy it if you care about it<br> <miriam> ack fantasai<br> <Zakim> fantasai, you wanted to comment on back-compat<br> <emilio> fantasai: from a compat perspective there are some changes, for separator changes it's aesthetic and it probably doesn't have much impact<br> <emilio> ... number changes are harder<br> <emilio> ... I think we're fine with these having minor changes<br> <emilio> ... 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<br> <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 @charset approach<br> <jfkthame> q+<br> <miriam> ack jensimmons<br> <emilio> jensimmons: I think there are some interesting points made here, might be helpful to go back to the issue<br> <fantasai> s/are harder/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/<br> <fantasai> s/charset/counter-style/<br> <miriam> ack jfkthame<br> <emilio> TabAtkins: yeah if there are no major objections to the resolution we should continue no change<br> <emilio> jfkthame: this is a bit parallel to a recent change in CLDR which affected date formatting in some languages<br> <r12a> q+ to talk about publicising the counter styles<br> <emilio> ... it caused a fair amount of compat pain<br> <emilio> ... I could see that happening around this<br> <emilio> ... sites are sometimes fragile to this stuff<br> <miriam> ack r12a<br> <Zakim> r12a, you wanted to talk about publicising the counter styles<br> <emilio> r12a: if something changes about the UA the author can still reverse it manually<br> <emilio> ... people brought up that not many people knew about it, but it'd be useful to point to it from mdn<br> <emilio> miriam: let's take it back to the issue then<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8636#issuecomment-1601165146 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 June 2023 16:33:05 UTC