Re: Block-based parsing; allow lies

>
> Kornel Lesinski wrote:
>> Vendors could use that intentionally to help authors avoid known  
>> rendering bugs (iframe {z-index} could fail in Opera, div  
>> {background-attachment:fixed;} in IE, etc.)
>
> This is _exactly_ where this scheme fails.  It's not that IE/Win doesn't
> implement "background-attachment: fixed".  It does.  It just does it  
> wrong.
> Therefore, if this block-based parsing happened, a block conditioned on
> "supports background-attachment: fixed" would be parsed in IE.
>
> This has been raised several times already, but people seem to keep  
> dismissing
> it as a concern for a reason I don't understand....

So good that you gave this as an example..
So, IE currently does not parse background-attachment: fixed? Yes it does.  
It even shows it in currentStyle function. Does it adhere to it? No. Ok.  
Now why should it be an extra problem if it claimed support for property  
X, and parse the block? How could this create an extra problem? Here's a  
long scenario, please read if you have the time.

e.g. Imagine: We want yellow text supported by an olive shadow that is  
very readible in our imaginary design. It is still readible when there is  
no shadow, but not as much. So it should be green, in that case. However,  
green + olive shadow is not as readible as either plain green, or yellow  
with shadow, or yellow alone. So "It should have been green in the first  
place" is not an answer.
(don't mind the syntax)

**Scenario A - we don't have "required":
h1 {color: yellow; text-shadow: olive 0.3em 0.3em 3px;}

h1 text is displayed in yellow, with drop shadow supported or not.

**Scenario B - we have "required"
h1 {color: green}
@required {h1 {color:yellow; text-shadow:olive 0.3em 0.3em 3px;}}

Scenario option 1) Browser cheated:
    h1 text is displayed in yellow. What happened? Anything different from  
scenario A?
Scenario option 2) Browser does not cheat and has no support for shadow
    h1 text is displayed in green, which is more optimal.
Scenario option 3) Browser is old.
    h1 text is displayed in green, which is more optimal.
Scenario option 4) Browser has support for shadow:
    h1 text is displayed in yellow with supporting shadow for even more  
readibility.

So how would @require hurt us more than the current situation does?  
(Please no lessons on color contrast, this is just an example.) Just  
because the browser cheated, did not mean @required weren't useful for  
people browsing with standards compliant browsers. Oh, and it is 100%  
future proof, as things would only get better with better standards  
support. What is not future proof is not having @required;
What happens without @required?:
->Browser detection using UA string, extracting the version number of the  
browser would be a nightmare and we all know it is not dependable, and  
when browser properly starts supporting the property, guess what, the new  
features are not being used, so the detection has to be constantly updated
->Selector hacks -> Things can and will get hectic when the browser starts  
supporting the selectors, or stops supporting a non standard selector  
(e.g. * html)

What happens with @required?:
->I can make my design stand-out using new CSS features, while making sure  
I am providing an optimized experience for older UA's. Without "required",  
I don't have *as many* options as I would have with it, do I? (and it is  
not all that bad to have more options on the plate)
->Given enough time, all browser who claim support will support the  
properties more ideally. In the year 2012, my CSS would work, without me  
updating the browser detection algorithm for new UA's, or updated UA's  
with proper support (who used to cheat or not)

-- 
Emrah BASKAYA
www.hesido.com

Received on Wednesday, 14 September 2005 16:47:52 UTC