W3C home > Mailing lists > Public > www-style@w3.org > April 2005

Re: Targeting CSS3 only (evil?), either with pseudoclass or an extra syntax for properties.

From: Emrah BASKAYA <emrahbaskaya@hesido.com>
Date: Tue, 05 Apr 2005 13:03:34 +0300
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <opsoq7j8jt8nstxa@lomarnona>

I understand you so well, if CSS hacks weren't there, people wouldn't be  
able to adopt CSS for the single reason that if they did it the W3 way,  
their page would indeed break on the most popular browser-like application  
on the web. I have lately done a webpage which uses full CSS and if it  
weren't for the hacks, it wouldn't show correctly in linux browsers or  
alternative browsers. Thankfully, I first did a standard-compliant CSS  
which did work for all but the popular one, then I fixed it with CSS hacks  
(or could simply use the html conditional comments its vendor provides).

But what I say is browser sniffing feature should be provided by the  
browser vendor itself and not by W3 as a CSS feature. In the end, it is  
browser vendors to decide whether they will adhere to CSS browser sniffing  
if put in the CSS specs anyway, and some may choose to ignore it  
completely stating they are fed the wrong CSS on purpose (Remember the  
issue with an alternative browser in a popular internet page sending  
flawed code on its pages to that specific browser, almost made one think  
it was done on purpose.) So given the current market share status, it is  
highly probable that the alternative browsers would prefer to stay  
anonymous or spoof as the popular one not to be forced a specific CSS  
targeting only itself which may lose a lot of customers if some pages  
deliberately sent it flawed css, but it would prefer to render a generic  
CSS which is also being fed to other alternative browsers (but not the  
most popular one as it provides a clumsy CSS implementation but still can  
be sniffed with a feature its vendor provided). Also unlike the most  
popular one, the alternative browsers fix their CSS bugs very fast, and  
all the latest alternative browsers seem to do a very very good job  
displaying standard CSS the same way, and their users are able to adopt  
new versions very quickly, as they are not part of the OS. One specific  
hack for a version e.g 1.45 might not work for 1.46 as the bug might fixed  
and more standart compliant. So then we need to sniff its version and  
build number. That is not the case with the popular browser, as its vendor  
doesn't like to change how it works for years.

On Tue, 5 Apr 2005 01:11:39 -0400, Barry <wassercrats@hotmail.com> wrote:

> Emrah BASKAYA wrote:
>> W3 is trying to put out some standards so it would contradict its own  
>> vision to allow specific browser sniffing.
> Look at it as a bug management issue. Browsers will always have bugs,  
> and conditional comments can help web developers deal with them. If  
> conditional comments make some browser developers lazy about standards,  
> we'll still get something in return. I don't think they'll use their  
> lazy-time playing tennis. The worse that would happen is we would have  
> working *html that was more difficult to create. That's better than  
> having to use a different design to circumvent a problem, or using a  
> browser detection script.


> I've been reminded of that publically and privately, but that's where  
> the verbosity that I mentioned comes in, and there would be no guarantee  
> that there would be a unique combination of unsupported features in any  
> particular browser. I don't want to search for a distinguishing set of  
> features even if they exist. There seems to be disagreement about that  
> method from others on this list too.
> Support for conditional comments is probably very easy to add to a  
> browser and it could be helpful. I don't understand why more browsers  
> don't support them. __________ NOD32 1.1046 (20050405) Information  
> __________
> This message was checked by NOD32 antivirus system.
> http://www.nod32.com

Received on Tuesday, 5 April 2005 10:03:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:17 UTC