- From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
- Date: Tue, 10 Jan 2012 12:40:51 +0400
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- Cc: Matthew Wilcox <elvendil@gmail.com>,"www-style@w3.org Style" <www-style@w3.org>
10.01.2012, 06:00, "Tab Atkins Jr." <jackalmage@gmail.com>: > On Mon, Jan 9, 2012 at 11:28 AM, Matthew Wilcox <elvendil@gmail.com> wrote: > >> šHTML has a useful property whereby the DOCTYPE was hijacked to trigger standards compliant rendering modes. >> >> šSome of CSS is sub-optimally implemented from a designer/typographer standpoint and there's not much tht can be done about it by us without breaking backward compatibility. >> >> šHas thought been put into an equivalent strategy for CSS? For example, opting into which branch or module we'd like to work? >> >> šI bring this up because I think the way typography is handled in CSS is simply fundamentally flawed from a typographers perspective, and un-resquable as is. If we could wind back the clock we could fix it, but we can't. How about we reset the clock? Allowing the author to choose which versions of the spec to adhere to? >> >> šThat would allow us to, for example, re-write the way that font's are used in CSS, without breaking backward compatibility. User Agents that don't understand the trigger would simply ignore it. > > Doctype switching isn't really a "useful" property. šWe employed it as > a last resort to help with compat in the bad old days of IE > domination, when there was a major irreconcilable difference between > what IE did and what the specs wanted. šIf the modern WG was > transported back to that time we probably wouldn't have done it - more > likely, we'd have adopted IE's box model and added the box-sizing > property earlier. > > Similarly, here, if we find parts of text layout that we want to > change, we'll just add properties to allow changing it. šIf it ends up > being unfixable, we can make a new layout mode that does things right. > šThere's no reason to reach for the nuclear option of a version > switch. > > ~TJ By the way, I remember there was some initiative (probably by Mozilla) to introduce @supports at-rule (unfortunately can't find a link) that would allow to address rules to browsers that support specific CSS property. Such approach is like feature-detection JS and, unlike switching by abstract CSS version, is quite true and bulletproof way to go. Tab, could you specify is there some progress on making a spec for the @supports at-rule?
Received on Tuesday, 10 January 2012 08:43:58 UTC