W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: [css3-selectors] Native alternative to modernizr

From: Daniele Grillenzoni <daniele@l33t.it>
Date: Tue, 04 May 2010 04:12:45 +0200
Message-ID: <4BDF829D.5000409@l33t.it>
To: www-style@w3.org
On 03/05/2010 17.34, Simon Fraser wrote:
> On May 2, 2010, at 9:12 AM, Daniele Grillenzoni wrote:
>> So what about having a pseudo-class that matches when the browser supports a given keyword? If it's necessary it could be limited to the root element, but it would really be a relief and spare us the need for many current css hacks.
> This has been discussed before a number of times, most recently here:
> <http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html>
> Simon
I skimmed the whole thread, and the main problems were due to an 
excessive specificity of the filter, which in turn requires a much more 
complex syntax. I kind of foresaw that supporting vendor prefixes will 
end up spawning a plethora of soon-to-be-outdated css files all over the 

I think that the core functionality (whether it is implemented as media 
query or pseudo class) has potential, but it has to be "dumbed down" in 
order to stay inside the "css is not a programming language paradigm.

I briefly discussed this on #whatwg and addressed some of the criticism 
of the "maybe it's too simple" approach 
http://krijnhoetmer.nl/irc-logs/whatwg/20100502#l-323 (<Lachy> The 
problem is that the level of support for a feature is not always a 
binary decision)

Again, consider that the current alternative to this is having nothing 
or rely on JavaScript, this feature is welcome (or we wouldn't have a 
library such as modernizr) and a way to implement "edge" stuff in a 
defensive way might even help early adoption of further innovation (I'm 
thinking css layouts, whenever those get implemented).
Received on Tuesday, 4 May 2010 02:20:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:45 UTC