- From: Brad Kemper <brkemper@comcast.net>
- Date: Wed, 28 Nov 2007 10:23:47 -0800
- To: Alan Gresley <alan1@azzurum.com>
- Cc: www-style@w3.org
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