- From: Florian Rivoal <florianr@opera.com>
- Date: Wed, 18 Jul 2012 17:51:00 +0200
- To: www-style@w3.org
On Mon, Jul 16, 2012 at 10:21 AM, Sylvain Galineau wrote: >> I suppose this all boils down to why we don't want to define this >> normatively. >> If we think it'd be harmful for browsers to ship with these definitions >> built-in >> then I'm not sure why we'd want to tell authors to use them. Authors can check that the proposed list do what they want, and are free not to use them if they don't, and to publish fixed versions if they find a fix. If they're built into the browser, and turn out to be wrong, we may be stuck with wrong definitions using a valuable part of the name space. On Mon, 16 Jul 2012 19:40:24 +0200, Tab Atkins Jr. wrote: > The argument is that there's no need to clutter up browser code with a > hundred or so counter styles when any given user will only need the > common ones plus one or two of the uncommon ones. > > I disagree, but the argument is reasonable. That's part of the reasoning. Here's a longer list of reasons: - No need to clutter up the browser with a lot of counter styles now that we have a mechanism to let authors do it - We should not take the risk of hardcoding in browsers something that is improper for languages that we have little expertise about, since correcting the mistake would at best be slow, and at worse impossible, if content started depending on it. - There are a lot of languages in this world, and if we can't possibly address them all. But if we start addressing more than the few that have to be supported for backwards compatibility reasons, we risk facing a long list of requests for adding more, with no clear cirteria to determine what to leave out and what to take in. - The generic mechanism introduced makes it possible to have an independent group (or several) producing style sheets meant for authors to embed, version them, in a much more flexible way that what could be done if hard-coding in browsers is the goal. Florian
Received on Wednesday, 18 July 2012 15:50:25 UTC