There is no solution for the Q element
Stacey Cordoni recently posted an article on A List Apart entitled "Long Live the Q Tag". The article discusses the problems with the q
element stemming from Internet Explorer’s continuing lack of support and talks about some alternative solutions. The solution she settles on is to use q
elements with the default quotation marks removed via CSS styling and manual quotation mark characters added directly in the HTML source outside the element.
This is not an adequate solution. It completely ignores user agents that don’t support CSS or have it disabled. Text browsers that correctly support HTML and don’t support CSS would render such a quotation delimited by two pairs of quotation marks. lynx is such a browser.
I have found that there is no true solution for the problem with the q
element. Unfortunately, the problem isn’t exclusive to Internet Explorer either, as there are other user agents that fail to handle the q
element correctly. ELinks behaves like Internet Explorer in this respect.
The reality is that the q
element simply won’t behave consistently in all major browsers no matter what you do, and so its use should be avoided.
October 24th, 2006 at 14:27 UTC
Well, since I don’t run any commercial websites I can ignore the fact that 80% won’t see my quotation marks.
My philosophy is that if they want a good web experience they should switch to a (more) standards compliant browser.
Posted using Mozilla Firefox 2.0 on Windows.
October 24th, 2006 at 18:16 UTC
Wouldn’t this work (I just enclosed extra quotes inside IE conditional comments)?
Text
All reasonable browsers will never see the extra quotes, while IE will always see the extra quotes – even if CSS did not load or was disabled.
Posted using Opera 9.02 on Windows.
October 24th, 2006 at 18:21 UTC
The comment form decided to remove markup, so I would just describe it textually once again – a normal element surrounded by two extra quotes. Each quote is hidden in IE conditional comment. The string inside comment should be similar to “if lt IE N”, where N = last version of IE without proper q support + 1. N should be incremented (by server-side magick) as more defective IE versions are released, and frozed if the issue is finally fixed by MS.
Posted using Opera 9.02 on Windows.
October 24th, 2006 at 19:35 UTC
That would more or less fix the issue for IE (with a ton of extra markup required), but as I said, IE isn’t the only user agent that fails to support the
q
element correctly. lynx will still show the page without quotes, as will a number of other user agents.Posted using Mozilla Firefox 1.5.0.7 on Windows.
October 31st, 2006 at 03:26 UTC
I don’t think it matters. The standard clearly says what’s supposed to happen, and anyone who uses a browser that doesn’t support such an absurdly simple element should expect a suboptimal browsing experience.
Posted using Mozilla Firefox 3.0a on FreeBSD.
February 8th, 2007 at 02:34 UTC
One way to deal with the lack of supprt for the Q tag is with the IE extension mechanism called behaviors.
I’ve create a page with a behavior for this specific problem. I added the source and an explanation of it.
http://willcode4beer.com/tips.jsp?set=fixIEQuotes
For all of its problems, at least IE does give us the ability to fill the gaps. Of course, basic HTML support in a web browser would be nice too. ;-)
Posted using Mozilla Firefox 2.0.0.1 on Windows.