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

Allan Sandfeld Jensen wrote:
>>The way I see it (and I think expressed at the time of the discussion
>>of the linked post) was that any UA which incorrectly matches
>>!required on a buggy property, that match is also a bug. There's
>>nothing which can be done to avoid that happening in lazy
>>implementations, sadly. I don't think that disrespect for "!required"
>>is a problem any worse than what we have now without "!required",
>>though.
> 
> Yes. It seems it could work very well with unimplemented properties, but with 
> unimplemented values, it seems many browsers parse them and then ignore them 
> if not implemented (basically they have been planed implemented but never 
> completed). I know for a fact there have been several such cases in 
> Konqueror.

If a value is unknown, the entire property should be dropped. I think 
the CSS spec is quite clear about what a browser has to do when it 
doesn’t know a value, and this is important and in the browser’s own 
interest to do properly for both backwards- and forwards-compatibility.

That it sometimes goes wrong is for certain (think position: fixed in 
IE), however even though a browser might get it wrong sometimes, I think 
in the majority of cases the browsers will know correctly whether a 
property is supported or not. That’s enough to make it work. Even with a 
few cases where it incorrectly passes the test, it is still a great 
improvement.

The possibilities Emrah mentions are *very* interesting. And, of course, 
let’s not forget that this is a very often requested feature, designed 
in a way that doesn’t require people to make use of browser-specific 
hacks, instead giving them a good alternative with real support checks. 
Theoretically ;p.

Barry wrote:
> Laurens, I know nothing about XML. All I know is that conditional
> comments greatly help me with HTML.

That’s only because they are currently implemented in the major browser, 
which by happenstance also has the most need for 
browser-(version)-specific hacks.

In any case, the abovementioned solution (or a version of it) is a GOOD 
solution, ‘the right way to do it’. It allows you to add style based on 
what is supported, and also allows you to create code that is 
future-proof. Once a certain set of necessary features is supported, it 
can show the whole thing!

Browser sniffing is the BAD solution, which unfortunately is sometimes 
necessary. What I mean with this is, with browser sniffing, you create 
code with loads of hacks for IE6, but when IE7 is released, there is no 
way to tell what it will support. So either you check for IE6 and IE7 is 
fed your ‘standards compliance’ version which will probably still not 
work, or you check for IE in general (although history tells us that 
each version requires different hacks) and IE7 is fed the hacks for IE6 
and misrenders things as well.

But then again this solution absolutely doesn’t prevent browser 
sniffing! - in the contrary, it makes browser sniffing easier (and 
CSS-based instead of HTML-based - separation of code and content IS 
important!) if that is what you want.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Received on Monday, 4 April 2005 19:16:58 UTC