A Quickie on the Q Element

Posted July 18th, 2007 by Mike Cherim

adding a script to the page load to fix one instance of one small problem for one browser made me frown

I’m utterly swamped right now, but as I get a breather now and then — which is a few hours at a time — I still want to write short posts (or are they articles?) to let you know I’m alive. One of the things I’m doing is building a rather large site using WordPress as a content management system (CMS). I can’t show you anything yet, but it’s a good one I think. On this site I have an instance where I use the <q> element to markup an inline quote. I don’t use it often so I wanted a simple solution to the matter of that element not being supported by Internet Explorer (IE) — including IE7 if you can believe that. I started thinking about the situation.

The matter at hand

Barring Internet Explorer, all visual browsers that I know of will by default render content in the form of simple unencoded quote marks before and after any content marked up with the q element. If you were to write that in a cascading style sheet (CSS), you might write this:

 /* Unencoded plain-quote method used by browsers */

 q:before, q:after {
   content : "\"";
 }

But you don’t have to do this because better browsers kindly do the heavy lifting for you. So, barring Internet Explorer, writing this:

<q>This is an inline quote.</q>

Will produce this (IE users wouldn’t normally see this but I used " to make it visible):

"This is an inline quote."

Or this if I let WordPress convert the quotes into “curly quotes” (IE users won’t see this because I’m using <q> only and WordPress is making them fancy):

This is an inline quote.

Bummer. We need a solution.

A solution?

Nope, sorry, no solution here. You can’t style the quote element by adding the styles above to your style sheet because Internet Explorer ignores the element altogether. Moreover, IE doesn’t support content either. It’s a double whammy.

Ways to deal the problem

There are many clever ways of dealing with the q element, though none seem effective in all situations. Here are the ones I could think of.

Ignore it. Put text quotes in for visual purposes and forget the q element altogether. It’s tempting. Not a completely accessible solution, though if well written it might very well be quite clear in meaning, in context. Understanding is the important thing, right?
Ignore IE. Put the q element in place and try to write the surrounding inline text well so as to indicate it’s a quote and will be understood by IE users. Heh, ignore IE, I like the sound of this one but I’ll keep thinking about it.
Embrace IE. That is, by adding the q element for “accessibility” reasons or “semantics” in addition to quote marks. For all those compliant browser users out there (me) they’d get double quotes. Thus, to use this method you’d have to use the CSS above to specify no content before and after. That’d be fine and good for all visual browsers and you do retain semantic meaning, but double quotes with styles off doesn’t sit well with me. There has to be something better than turning off the default functionality of standards-compliant browsers.
Scripting. There are JavaScript solutions out there such as Gez Lemon’s Fixing Quotes in Internet Explorer and Paul Davis’s Fixing the Quote Tag <Q> in Internet Explorer. Don’t get me wrong, both are excellent solutions, but I’ve only used the q element in one instance. The site I’m making is 250-plus pages not including the fifty or so blog articles, so adding a script to the page load to fix one instance of one small problem for one browser made me frown. Of course I could add some more scripting to load the script to that one page but enough is enough. I want easy. Easier anyway. (Note: Between user agent detecting and independent, dynamic content manipulation, there can be reasonable server-side scripting solutions used to add quote marks for IE users. Perfect? I don’t know.)
Down and dirty. Another solution is to introduce additional mark-up for IE, but to ignore the notion of IE getting actual quote marks. Just add a classed span inside the quote, like this:
<q><span class="q">This is an inline quote.</span></q>

Then in the style sheet don’t bother doing a thing with the q element and instead just style the span with color and an italic font-style, for example. If well written, to be read and understood as quoted text, without quotes, IE users should get it. It must be written well, though as not every IE user will see it with styles on. Everyone else gets the goods in a very proper way.

What I did

The last method, Down and dirty, is what I ended up doing on the above-mentioned site. It’s a cross between ignoring IE, and adding a little something for that browser user. I decided this was a simple enough method and I’m okay with ignoring IE to a point. I can’t forsake it quite yet if you know what I mean. I wrote the surrounding content well, colored the text, and italicized it. And in everything but IE it’s also visually quoted. I think I’m okay with that. I did try to weigh all the options.

I don’t know if I missed any of the solutions out there aside from other JavaScripts and server-side solutions as I mentioned were possible. Otherwise I’m tapped out. Do you know of any other methods of beating the lowly Q into submission?

Filed under Coding & Markup, Do It CSS Style —

27 Responses to: “A Quickie on the Q Element”

Koen Willems responds:
Posted: July 18th, 2007 at 11:07 am →

I use just one little line of JavaScript, which (of course) doesn’t work with nested ’s.
It suits me fine.

function styleQ() {
    document.getElementById('content').innerHTML =
    document.getElementById('content').innerHTML.replace(/<(Q)([>])/g,'u201c<$1$2').replace(/</(Q)>/g,'<$1>u201d');
}

Alex Jones responds:
Posted: July 18th, 2007 at 1:55 pm →

So, out of curiosity, why did you choose to go with the complicated method instead of just placing the quotes around the quoted text? When you mentioned this option, you stated that it isn’t very accessible, but it seems to me that it is very accessible, as the quote character(s) is standard and both widely used in every medium, and expected by readers.

I can understand wanting to style quotes, but I don’t believe it outweighs the impact on a significant portion of readers who will see styled text sans-quotes - that’s a pretty major cognitive jump to expect them to make. It’s also hard to trust that all future content will be written in a way that the user can infer that th next bit of text is a quote even though it isn’t surrounded by quotation marks. On the plus side, inline quotes will likely stand out much more from the surrounding content than is normally the case.

I may just be missing something here..?
Mike Cherim responds:
Posted: July 18th, 2007 at 2:07 pm →

I guess because I’m under the impression using the q element is important and recognized by the various user agents, more so than text quote marks. So instead of “ignore it” I chose ignore IE, but with added text styling for IE users. To me this has always been one of those situations that seems to have no clear answer or solution.
David Zemens responds:
Posted: July 18th, 2007 at 3:52 pm →

Another interesting article, Mike, with another great tip thrown in. I wrote an article titled over at my 1955 Design blog about a frustration I recently had with Internet Explorer. It’s nice to see that I am not the only one who has those troubles…which of course, I already knew.

Long live Mozilla Firefox.
Paul Davis responds:
Posted: July 18th, 2007 at 5:54 pm →

Mike, great article and thanks for the mention.

One thing that the readers should consider is, beyond simply using the quote tag to add quotes, the tag supports a “cite” attribute that should point to the URL of the site being quoted.
This can be thought of like the sources you had to put in your school papers.
Unfortunately, none of the browsers do anything with it. You would think that if the cite attribute is a url that, some browser, any browser, would give a way to use it.
I made a script (http://willcode4beer.com/tips.jsp?set=blockquoteHover) to show it as a pop-up but, I should not have had to.

My attempt to deal with the tag on IE was to use behaviors (using CSS to run javascript). Its obviously imperfect because it fails to provide consistent styling of the quote tag if it is styled (for Firefox and Opera).
In a perfect world, all of the browsers will support ‘content’ in CSS. Of course, this still means IE would suffer on non-English web sites.

Then again, if we didn’t have to do all of these crazy hacks, web dev would not be nearly as fun
;-)
Mike Cherim responds:
Posted: July 18th, 2007 at 7:03 pm →

[…] the tag supports a “cite” attribute that should point to the URL of the site being quoted. — Paul Davis

Right you are, Paul. Lots of people get that wrong and put a name in the attribute, which of course belongs in a cite element. I know one piece of software that at least recognizes it. I think it’s WebXact’s testing tool in that it’ll point it out if you mistakenly put “John” or something in the cite attribute on blockquote or q, it’ll tell you it can’t resolve the web address “John.”
Joe Dolson responds:
Posted: July 18th, 2007 at 7:38 pm →

[…] the tag supports a “cite” attribute that should point to the URL of the site being quoted.

That is, of course, if the source has a URL. Citations of print publications or sources are rather a separate beast. It is definitely irritating to have these attributes (q is certainly not the only offender) which are not made available in any default way to the user agent. Frustrating.

Nice article, Mike - I’ve generally gone in the direction of ignoring the q element, personally. I tend in general to aim in the direction of simplification when support is lacking…

Particularly irritating that this is one of the many areas in which IE7 wasn’t fixed…we’ve got a LONG ways to go before we’re going to escape these kinds of clumsy work-arounds. Sigh.
Jermayn Parker responds:
Posted: July 19th, 2007 at 12:04 am →

Personally, I would ignore the q tag and just put in ” around the quote. BUT if that was not an option I would do the ‘down and dirty method’ (or should I be quoting that with “”???)
John Faulds responds:
Posted: July 19th, 2007 at 1:18 am →

FWIW, I usually go for the embrace IE option.
matthijs responds:
Posted: July 19th, 2007 at 3:53 am →

For your Encoded plain-quote method and Encoded method to render typographer’s “curly quotes”, I think you should remove the quotes around the encodings. As it is now, the encodings are literally displayed. So it should be:
/* Encoded plain-quote method */ q:before, q:after { content : "; }
(hope that displays well.)
Paul Davis responds:
Posted: July 19th, 2007 at 5:10 am →

Joe,
Great point, when you are citing print, that could be the opportunity to put your amazon/b&n referral url.
;-)

just kidding (not really)
You bring up a very good point though. Its another little thing left out of the specification.
Mike Cherim responds:
Posted: July 19th, 2007 at 8:55 am →

I think you should remove the quotes around the encodings. As it is now, the encodings are literally displayed. — matthijs

Thanks for pointing that out. It made me do some more experimentation on a plain web page without the influence of WP (and I have changed the original post to reflect my findings). My other two examples, as you pointed out were indeed wrong. To do my experiment I had to first specify no contentto “reset” it, then I re-specified the content.

The findings were both “encoded” examples I had — the ones using " and “/” didn’t work with or without the content being quoted in the CSS. If quoted it rendered literally, unquoted it didn’t do a thing; (same with your example) it rendered nothing for me. The unencoded example didn’t render either with just a quote mark for the content. But if I quoted it and escaped the middle quote as per my original example it renders the quotes as it’s supposed to. Thus I have to stick to this one, anyway:
```
 /* Unencoded plain-quote method used by browsers */

 q:before, q:after {
   content : "\"";
 }
```
This seems to work well.
Alex Jones responds:
Posted: July 19th, 2007 at 10:35 am →

Hey Mike, not to be a stick in the mud, but you said “I guess because I’m under the impression using the q element is important and recognized by the various user agents, more so than text quote marks. So instead of “ignore it” I chose ignore IE” - IE is (sadly) the most popular user agent out there, and it doesn’t recognize the q element. So, the largest portion of the audience won’t see anything, at least until the folks in Redmond fix the issue. While its great to target standards-compliant browsers, we still have to acknowledge and work with Internet Explorer’s faults for the vast majority of our sites. I think your Embrace IE solution is the best method to address all of the user agents in a way that is semantically correct and accessible. That’s the great thing about CSS, you can specifically use its attributes how you want - the browser defaults aren’t necessarily correct as can be seen by the popularity of style sheets that reset all elements.

Anyway, this is a really good article, so please don’t take my comments as negative. You’ve gotten me thinking about CSS and presentation which is always a good thing.
Mike Cherim responds:
Posted: July 19th, 2007 at 2:27 pm →

Gosh, Alex, you’re such a stick in the mud… just kidding! Good points about catering to IE due to the vast number of users. Embrace IE isn’t bad, the double quote marks bothered me, though. I did consider ubiquity of IE when I created styles for the span so I could keep the q without going with double quotes. What I did was something to this effect (minus the blockquote of course):

As we wrote in our 2006 catalog, You’re never too old to learn, and we meant it.

The context should make it clear it’s a short (inline) quotation, and the font-style and color should help set it apart for IE users — to make it more distinct. The only part they’re lacking are the actual quote marks. Meanwhile, if certain assistive technologies (AT) do process the q element, and they’re not piggybacked on IE, they will get the goods in a way they, too, would understand. If ATs don’t recognize the q element, though, it really should be deprecated as a worthless element, meaning if it has no semantic value to ATs, I can’t see the point and simple quote marks would rule the day.

That was my thinking anyway
Alex Jones responds:
Posted: July 19th, 2007 at 3:19 pm →

I can see your point, but the colored text looks like a link to me when I view your example in IE. I don’t think I was quite clear in my last comment - I liked the Embrace IE with the additional modifications to strip the auto-generated quotes, so all browsers displayed a single set of quotes, instead of two.

I look forward to seeing the site in question so I can see the quotes in context.

Cheers!
Mike Cherim responds:
Posted: July 19th, 2007 at 4:53 pm →

I was originally going to do that, removing the auto-generated quotes with a simple CSS entry, but without styles I’d get them back. I do wonder how that’d sound with a screen reader, not sure if it reads them. Some punctuation is read while some is not.

I agree that some users might be fooled into thinking that was a link even though it’s not underlined like my other links. Looks like there’s no grand solution
Alex Jones responds:
Posted: July 20th, 2007 at 10:29 am →

I just discovered something interesting in relation to this post… I’m tracking this discussion via co.mments.com, which I am ultimately consuming via RSS. In RSS, all of the styling was lost, so your example (posted 7/19 @ 2:27) has absolutely no context at all. I hadn’t even thought about the implications of syndication (that’s a fun phrase to say).
Mike Cherim responds:
Posted: July 20th, 2007 at 3:34 pm →

Hmm. I can understand the styling being lost since I offer no style sheet for the XML, but I don’t know why you’d get no content. Weird.
Alex Jones responds:
Posted: July 21st, 2007 at 8:33 am →

I get the content Mike, just not styling, so the context is lost.
Mike Cherim responds:
Posted: July 21st, 2007 at 9:21 am →

I see what you’re saying. So it’s not just IE without styles, but in the feed output as well. Good point. Chalk one up to plain old quotes (or the Embrace IE option I guess). Thanks for explaining that, Alex.
Alex Jones responds:
Posted: July 22nd, 2007 at 9:41 am →

No problemo Mike, sorry to rain on the q parade. Please keep up the good work - I always enjoy reading your posts.
Stevie D responds:
Posted: July 23rd, 2007 at 8:06 am →

Two points:

1. I applaud the use of [q] elements despite them not working properly in IE. If we all bowed down to Redmond and avoided them, Microsoft would see no reason to build support for them in IE8. If more and more pages do start using [q], Microsoft are more likely to support it.

2. You can hack IE more easily to display quotes as images.

[q][span]This is a quote[/span][/q]

Then in an IE-only stylesheet, you can put
q {padding-left: 4px; background: url(quote.gif) no-repeat top left;}
q span {padding-right: 4px; background: url(quote.gif) no-repeat top right;}

This gives IE users the quotes around the text without any complicated scripting and without messing it up for other browsers. If you wanted curly-quotes, you could set different background images for [q] and [q][span].

IE5 ignores the padding so you get quotes overlaid behind the text rather than around it, but hard luck!
Alex Jones responds:
Posted: July 23rd, 2007 at 10:25 am →

Stevie, while I understand your position, having held it in the past, and not being much of a fan of IE now, history hasn’t shown that widespread use of an element will get it added to Internet Explorer. IE 7 was a major step forward, but a quick combing of the Web will show how many features that we in the community begged for have been left by the wayside (the full CSS 2 spec would have been great).

Add to that, the fact that IE 8 is likely to be years away, so I don’t think that’s a valid reason to implement a method that ignores 80%+ of the people visiting a site. Implementing something purely because it is a standard isn’t necessarily a good thing - those decisions should always be made in balance with how the content or service will be presented to the person consuming it. Additionally, the solution that you proposed, is not very friendly to alternate user agents like screen readers or feed aggregators.

The more I think about this, the less I like the idea of content relying on the browser to insert quotes around the q element. Why should this one type of sub-string / set of punctuation marks be treated differently by default? By the same token, exclamatory or interrogatory sentences should receive special styling by default and all parenthetical statements (like this one) should be encased within their own tags which auto-insert the parenthesis or brackets. Well, I won’t continue to veer away from the topic, though I think this may kick off a post of my own.
Stevie D responds:
Posted: July 23rd, 2007 at 11:06 am →

Additionally, the solution that you proposed, is not very friendly to alternate user agents like screen readers or feed aggregators.

Alex, I don’t see what the problem is with my method. It works for any user agent that supports the [q] tag, and it works for IE as well. If catering for screen readers is important, you shouldn’t be thinking about visual presentation but about using aural stylesheets, where you could set an alternate voice or azimuth for anything in a [q] element. I would have thought screen readers should deal with this better than text surrounded by " marks - how do most screen readers denote that?

If there are lots of other user agents out there that don’t support [q], apart from just IE, maybe that method isn’t the way to go, but I would be very surprised if that was the case.
Alex Jones responds:
Posted: July 23rd, 2007 at 4:57 pm →

Hey Stevie - the thing is, screen readers, and feed aggregators already deal with quotes, and odds are good, that like IE, the q element isn’t reliably supported. The problem is the “supports the [q] tag” part - that tag isn’t supported by a large enough percentage of programs that deliver the content to justify using it.

My key point, is that developing something that doesn’t adequately support IE, which has far and away the largest user base of any user agent, is to ignore the needs of the people to whom we are delivering our content and services. It’s easy to hate Internet Explorer, I’ve cursed Microsoft and the IE team many many times, but we can’t let our frustrations as developers ruin the experience for our end-users. Otherwise, we’re returning to those horrible days with all those damned “Works best in ____” badges, instead of providing progressive enhancements. If you want to improve the display of quotes - sweet, I think that’s cool, and as I mentioned above, I can’t wait to see what Mike produces, but if you want to rely on something that will make it harder for a large group of the audience to consume, I see a problem.
Mike Cherim responds:
Posted: July 23rd, 2007 at 6:41 pm →

Wow, this post has taken on a life of its own. This is good, all this discussion about this obscure element. Making me think all the more.

The q element isn’t supported by IE, but I think it is with most other UAs in that it’ll be identified as an inline quotation and content quotes will be added before and after, visually encapsulating the text. Thus the best address, the safest one, is to keep the q element while still giving IE users some sort of visual queue, like quote marks, indicating that the text is a quote. But in doing so I do think we should avoid double quotes and the loss of the element. Aural style sheet support is pretty sketchy or so I’ve been told. And a lot of screen reading software can only be as good as the user agent it’s paired with. This means that no matter what we try is going to be flawed, or so it seems.

Thus, changing the styling of a nested span for IE — being careful to ensure the text isn’t a link lookalike as Alex noted — while foregoing the quotes such as I attempted I think can be effective (again the text must be clear that the writer is quoting which isn’t that hard to do).

Using the nested span background image suggestion Stevie D offered would work in that capacity, too, I think. The images idea is faulted only by the fact it wouldn’t be available if styles or images are off (for IE users). (In the CSS the browser styling would have to be turned off to avoid double quotes with styles on for other UAs.) That said, if the usage is limited, maybe an embedded image would be a good solution. But…

Always a “but” on this one I think. (By the way, the use of quotes for words such as I used in the preceding sentence I think is okay, but is it? Is this actually an inline quotation? There must be some sort of line drawn, somewhere. Just wondering.
Alex Jones responds:
Posted: July 24th, 2007 at 9:23 am →

The nested span will work, though you may want to be careful about people who need to resize the text on a page - 10pt quotes around 16pt text isn’t too pretty.

I still hold to the belief that the punctuation should be included as part of the content and not added by the browser. Having the quotes as a part of the content works, it works in all mediums without any special hooks or reliance upon the user agent. If it is important to use the q element, cool - use CSS to negate the default styling of the user agents (as we do when resetting margins etc.) and rely on what has always worked. Then, you can rely on the q and span tags to provide some additional styling hooks in order to improve the presentation of the quote without negating the ability of the end-user to quickly scan the content and understand its meaning, especially when they use a UA that doesn’t include or support your CSS. Relying on the user agent to apply punctuation or other default styling is just risky, and as is obvious in this specific instance, unreliable.

Another Option - Purely Speculation
sIfr may provide the ability to introduce resizable quotes, come to think of it. While it introduces another level of complexity to the development process, the latest version degrades nicely and may well address a most of the affected users. It is likely overkill for this use, but I wanted to throw it out there anyway.

Where the Line is Drawn
That’s a damn good question - I guess I would leave the “but” exactly as you have it - unstyled.