Re: Proposal of @ua

On Nov 27, 2007, at 5:54 PM, Alan Gresley wrote:

> The type of examples that would sway me to support you are test  
> cases showing where some browser is going wrong.

[...]

> This is why I'm wondering about why you are having troubles and  
> with what properties. Since I have used simple cascading to feed  
> Safari a different rule. This test case works in all browsers that  
> I can check on apart from IE5.5. The fix for IE5.5 is just an escape.
>
> /* for Safari */
> div#container {
> bac\kground: url(b) top left, url(c) bottom right;
> }
>
> Now I have my CSS working in all browsers that I can check on.

Ahh, but see, you are relying on a parsing bug in order to give an  
older browser different style properties. While that is good enough  
for older browsers, one of my primary points is that such parsing  
bugs are fixed with each new release, and such options will no longer  
be available for cases where overriding a previous declaration is  
insufficient. And generally speaking the hacks are also harder to  
read understand what they are for (by a different author, or when you  
revisit them a year later).

A secondary point I made is that the conditional comments in IE,  
while a step in the right direction, are not that viable, because  
they entail changing the HTML on every page (and the site I work on  
has hundreds), instead of the CSS file that is shared with all those  
pages. And when a new version comes out, I will have hundreds of  
places to add a CC for IE8, instead of just editing the CSS file.

The other thing wrong with CC is that it requires a separate @import  
file for each version on each page (or worse, separate embedded CSS).  
So I can't keep all of the "navigation bar" CSS together in the same  
area of the same file, or all the "page header" CSS together in the  
same area of the same file.

>> My premise is that moving forward there will still be a need for such
>> hacks or filters. That we will never reach the utopian world in
>> which all implementors are supporting all the same rules and all in
>> the same way, and in fact the need will actually grow as new advanced
>> layout methods and such are introduced, and as CSS continues to
>> advance with new properties that are today still in their early
>> stages or as yet undreamed of. But the effects of the "hacks" will be
>> nearly impossible to achieve without explicit support from the
>> implementors for an official way to include.
>
>
> More reason for test cases. In some way we can help in improving  
> the support of CSS by implementors. I dare say thats where my  
> future lays. Considering that Safari 3..0.4 (beta) on windows  
> passes the acid test 2 and now joining Opera and Gecko 1.9 is said  
> to pass the acid test 2. This is a little milestone of CSS. and for  
> me is an acid test 2 Utopian dream come true.

Acid 2 is a milestone, but I would hardly call it a Utopia. It  
measured common parsing and rendering problems with browsers claiming  
to support CSS1. Improving support of CSS implementations is  
certainly a positive thing, and is why I joined the list, but new  
features continue to be added, and they do not always allow a  
graceful degradation into alternate methods of creating similar effects.

In your example, you mentioned multiple backgrounds, so I will give a  
fictional example using that:

Suppose you want to create a block that has separate images in each  
of the corners in order to create a rounded corner effect, with some  
sort of fancy border related to your brand. You realize you can use  
border-image for this, or (second choice) multiple backgrounds  
attached to the sides and corners, or (third choice) fall back to a  
regular solid border with border-radius. You decide that for browsers  
that can't support any of these effects should just have regular  
square corners and a solid border, but that is the least desirable  
outcome.

Now suppose it is 2009, and:
- rendering engine "A" supports border-image, multiple background  
images, and corner-radius.
- rendering engine "B" supports border-image and corner-radius, but  
not multiple background images.
- rendering engine "C" supports multiple background images and corner- 
radius, but not border-image.
- rendering engine "D" supports corner-radius, but not the other 2  
properties.
- each of these 4 browsers represent about 24% of your customers,  
while the other 4% use a variety of other browsers with unknown  
capabilities.

With some sort of media query that allowed detection of either the  
rendering engine or feature support, you would be able to route the  
the most appropriate rules to the rendering engines that could do the  
best job with them.

The cascade alone would be ineffective, because you could not specify  
a positive corner-radius without giving it to everybody, but you  
don't want corner-radius to render if one of the other two renders.  
You also want background-image and border-image to be mutually  
exclusive, because some of your images involve transparency and  
wouldn't look right if both were employed.

Because it is 2009, all the parsing hacks have been rendered  
ineffective in all 4 of the browsers mentioned.

Feature detection in a Media Query might work, but because it is 2009  
and not 2012, there are still various rendering bugs that come up.  
Rendering engine "A" needs the border-image specified in a certain  
order in order to work at all, but rendering engine "B" has ugly  
white fringes around each image unless the images are specified in a  
different order. Using multiple background images in rendering engine  
"A" causes the element to be drawn in front of everything else,  
messing up your design in other ways. Rendering engine "C" doesn't  
support transparency when using multiple background images, so it may  
need a different set of (less desirable) images (that problem was  
fixed in late 2008, and your "C" users are split between two  
different versions). So it would really help to know which version of  
which rendering engine the page is being sent to.

This example is not meant to be a criticism of these particular  
features, but is just a hypothetical example of the types of things  
that authors may need to deal with. If history is any example, we  
will need to deal with issues that are similar in character, even if  
we don't know yet what exactly they will be.

Received on Wednesday, 28 November 2007 18:24:11 UTC