The Q tag, cross browser compatibility and the Content property
After browsing Eric’s site the other day, I came across a thread notifying readers that he had put together an amended reset stylesheet to help in the battle for cross browser compliancy. A List Apart also describes the same solution in more detail.
One thing that caught my eye was a declaration that Eric had input on from Paul Chaplin. The purpose of this particular declaration was to remove the quote marks that standards compliant user agents automatically generate around a Q tag using the :before and :after pseudo elements; the author then has a ‘blank canvas’ to work with where he/she can manually input the relevant ampersands into the markup.
Although this method does mean that cross-browser compatibility is achieved, it is by no means an elegant solution. Yes, there is simply no other way to achieve this in IE6/7 but think about this; after reading the W3C guidelines concerning the Q tag, you’ll see it mentions that it is the user-agent’s responsibility “… that the content of the Q tag is rendered with delimiting quotation marks”. The fundamental problem I have with Eric’s method is that you are having to use a fairly advanced pseudo element and property(that only user agents that abide by the Q element spec support) to go and remove their correct default behaviour- in a nut shell, bringing standards compliant browsers inline with IE6/7 when it should be the other way round.
I’d personally not use such a style reset, but be more in favour for ignoring IE6/7’s needs for authors to include additional markup in the form of ampersands, and rather include a conditional IE style declaration that indicates to those IE6/7 users that it is indeed a short quote – perhaps italic font style? Think of it as an element of progressive enhancement if you will.
Thanks for your article – it was interesting to read.
From a purist’s coding point of view I totally agree with what you’re saying, however you know as well as I do that the vast majority of users still use IE, (roughly 75% – depending on who’s providing the stats), and I doubt that will change anytime in the near future. We can still dream though
As much as I applaud your stance on web standards I think you need to remember that coding with web standards is not an end in itself but rather a means to an end and that end is to create the best web user experience possible for everyone who chooses to view our websites no matter what browser they choose to use. Most web users don’t really care what coding techniques we developers use but rather whether they can use a particular website or not.
As much as developers like you and I need to strive to produce near ‘perfect’ code, we need to keep the end user in mind and be careful not to alienate the very people the end result was intended for.
Keep up the good work and enthusiasm – you never know…..one day all browsers may see the ‘light’ but until then lets not forget why we do what we do
Brett, good point you raise, and thanks for the comments. I totally agree with what you say with regards to web standards and achieving a usable end product, and there’s a thin line between coding purity and cross-browser compliancy. However I personally think that in the context of my example, there’s some room to manoeuvre.
The main point of my article was to make readers aware more than anything, that the technique described by Eric, a) goes against the W3C guidlines, and b) plays around with the correct, default behaviour of standards compliant browsers- certainly not best practice. At the end of the day it’s down to the individual developer as to what he/she deems to be an acceptable balance between coding purity and cross browser compliancy