Thanks to all who commented, and apologies for taking a couple of days to replying – which only makes it all the harder!
Some random responses.
Nick Cowie – I’m not seeing box shadow in the current beta of FFox 3.1 I’m using – fingers crossed it’ll be there, that would be even cooler.
To respond to those observations about the usefulness of these tehniques or otherwise in certain contexts, with particular clients, and so on, might I in particular point out that the tutorial was much more about demonstrating a number of techniques that will certainly be of increasing use down the track, than arguing that they should be used out of the box in all circumstances right now ;-)
However, I continue to be a very strong advocate for trying to articulate to clients that it is a commonly held but ultimately futile belief or goal to strive for cross browser conformity of appearance.
The irony of course is that users never know that a site looks different in different browsers! They almost invariably use a single browser, and see the site as rendered in that browser. This is something we almost always overlook in this debate.
And, ultimately, the same page will look different across platforms regardless of whatever effort you go to – even if you render out an image and simply have the entire page as that single image.
Indeed, if sites don’t look different on different browsers, that often causes users to complain. Safari on Windows uses a different form of front rendering than the platform’s cleartype (which of course can be turned on and off, or tweaked by the user anyway) and this has caused no small amount of complaint from Windows users.
Similarly, mobile optimized versions of sites obviously look different from the “standard” version, and yet, I expect within the next 12 months that the significant majority of heavily trafficked sites will have mobile optimized sites. Given the nature of current mobile traffic, I expect a great many sites to have iPhone optimized sites. And iPhone of course supports css gradients, border-radus, text and box shadow and so on!
If I were to argue a rule of thumb for choosing whether to adopt technologies like css gradients, border-radius, text-shadow and so on it would have nothing to do with browser conformity. It would be
will the site provide all of the information and functionality to users of all browsers, regardless of disabilities?
will the site look attractive, to the users of all browsers
will the site conform to users core platform expectations? (the shiny button example probably fails that test – but as mentioned, the goal was a demonstration of a technology)
The issue of CSS versus SVG, as I see it is this. There are orders of magnitude more CSS knowledgeable developers than SVG knowledgeable developers. Most browsers already have the capacity to display SVG, but by making some widely used aspects of SVG available via CSS syntax, the adoption of vector based browser native graphics will increase enormously. That will have the attendant benefit of making developers aware of the capability of SVG, and some of the core rendering concepts, and I’d predict increase adoption of SVG.
Thanks again to you all for your comments, and it is interesting to see how what I thought would be a fairly non-contentious exposition of some cool CSS tricks ended up sparking interesting philosophical discussions.
John Allsopp
Thanks to all who commented, and apologies for taking a couple of days to replying – which only makes it all the harder!
Some random responses.
Nick Cowie – I’m not seeing box shadow in the current beta of FFox 3.1 I’m using – fingers crossed it’ll be there, that would be even cooler.
To respond to those observations about the usefulness of these tehniques or otherwise in certain contexts, with particular clients, and so on, might I in particular point out that the tutorial was much more about demonstrating a number of techniques that will certainly be of increasing use down the track, than arguing that they should be used out of the box in all circumstances right now ;-)
However, I continue to be a very strong advocate for trying to articulate to clients that it is a commonly held but ultimately futile belief or goal to strive for cross browser conformity of appearance.
The irony of course is that users never know that a site looks different in different browsers! They almost invariably use a single browser, and see the site as rendered in that browser. This is something we almost always overlook in this debate.
And, ultimately, the same page will look different across platforms regardless of whatever effort you go to – even if you render out an image and simply have the entire page as that single image.
Indeed, if sites don’t look different on different browsers, that often causes users to complain. Safari on Windows uses a different form of front rendering than the platform’s cleartype (which of course can be turned on and off, or tweaked by the user anyway) and this has caused no small amount of complaint from Windows users.
Similarly, mobile optimized versions of sites obviously look different from the “standard” version, and yet, I expect within the next 12 months that the significant majority of heavily trafficked sites will have mobile optimized sites. Given the nature of current mobile traffic, I expect a great many sites to have iPhone optimized sites. And iPhone of course supports css gradients, border-radus, text and box shadow and so on!
If I were to argue a rule of thumb for choosing whether to adopt technologies like css gradients, border-radius, text-shadow and so on it would have nothing to do with browser conformity. It would be
will the site provide all of the information and functionality to users of all browsers, regardless of disabilities?
will the site look attractive, to the users of all browsers
will the site conform to users core platform expectations? (the shiny button example probably fails that test – but as mentioned, the goal was a demonstration of a technology)
The issue of CSS versus SVG, as I see it is this. There are orders of magnitude more CSS knowledgeable developers than SVG knowledgeable developers. Most browsers already have the capacity to display SVG, but by making some widely used aspects of SVG available via CSS syntax, the adoption of vector based browser native graphics will increase enormously. That will have the attendant benefit of making developers aware of the capability of SVG, and some of the core rendering concepts, and I’d predict increase adoption of SVG.
Thanks again to you all for your comments, and it is interesting to see how what I thought would be a fairly non-contentious exposition of some cool CSS tricks ended up sparking interesting philosophical discussions.