Recommend against using the <q> element (or fix its behavior)

[jyasskin]

What problem are you trying to solve?

The <q> element adds language- and nesting-appropriate quotation marks around its contents and provides a place for the markup to include a URL for the source of the quotation. However, these benefits are undermined by UA behavior around <q> elements. In particular:

1. The quotation marks are not included when text is copied. If you try to copy This sentence includes This is a quotation but stop copying before this, you'll get If you try to copy This sentence includes This is a quotation in Chrome and If you try to copy "This sentence includes "This is a quotation"" (note the extra closing quotes that weren't in the copied text) in Firefox. It would be possible to fix this, but [css-content] Provide a way to generate copyable content w3c/csswg-drafts#8046 hasn't seen movement in the last 1.5 years.
2. The quotation marks are not included in searches. Search this issue for copy "this and notice the lack of search results. This is confusing when you're a user. This would, again, be possible to fix, but [css-pseudo-4] The browser cannot search the content, is it intentional? w3c/csswg-drafts#6222 also hasn't seen movement. (Firefox can find the quote by itself, but not with any context around it.)
3. The cite attribute is a usability footgun for authors: it makes authors think they've cited their source, but UAs don't actually show it to users, so users can't see the citation. The spec alludes to this, saying "User agents may allow users to follow such citation links, but they are primarily intended for private use (e.g., by server-side scripts collecting statistics about a site's use of quotations), not for readers.", but this was added in 2012 in e0e4b51 because cite hadn't been adopted by UAs and Hixie didn't want to remove the uses inside HTML, not because Hixie presented evidence people were actually running server-side scripts on it. This seems like an inversion of the priority of constituencies, valuing theoretical purity over users.

To avoid the <q> element, authors can insert their own quotation marks, and add a citation link that users can actually see. This may be slightly more difficult, since the curly quotes that <q> inserts aren't on most keyboards, but many editing tools can infer those, and the benefit to users as described above seems to win over the pain to authors. There probably isn't a significant localization loss in inserting quotation marks manually since the author has to translate the text itself too.

Since <q> is widely used across the web, it's probably impossible for browsers to actually drop support for it; the only change this issue asks for is for the spec to discourage authors from using it. If people are especially enthusiastic, perhaps we could move it to Compat.

What solutions exist today?

Authors can follow "The use of q elements to mark up quotations is entirely optional; using explicit quotation punctuation without q elements is just as correct.", but just saying it's "optional" doesn't focus well enough on the harm to users that comes from using this element.

How would you solve it?

No response

Anything else?

No response

[annevk]

Aside: the Compatibility Standard is not a good final home. Like the Quirks Mode Standard, it defines some aspects of reality that for one reason or another couldn't be defined closer to the algorithms they are amending in the moment, but ultimately they should be defined as part of those algorithms. (Example: webkitMatchesSelector() is better defined directly adjacent to matches() in the DOM Standard than in a wholly separate document.)

As for the topic at hand: I would be inclined to wait for the generated content issues to be addressed. Making q non-conforming will not make those issues disappear and those issues have also come up in other contexts. It seems inevitable we'll have to contend with them at some point.

[jyasskin]

Thanks for the point about the Compatibility Standard. I've struck that suggestion from my original comment.

Do you think there's space to add a warning for authors, even if we don't declare it non-conforming? It'll be easy enough to remove the warning again if and when the generated content issues are fixed.

I see that https://drafts.csswg.org/css-ui/#propdef-user-select includes (inside a note) "To the extent possible, authors should avoid using generated content for non-decorative purposes, and should prefer including all the content in the DOM.". We could help authors follow that suggestion by mentioning the possibility of using <style>q{quotes:none}</style> and putting their own quotation marks outside the <q> element.

[annevk]

That sounds very reasonable to me. Thanks for thinking of it!

[kslstn]

@jyasskin@hachyderm.io I thought I agreed, but here are some concerns I have:

1. I'd expect screenreaders to handle <q> better than the many combinations of quotation marks that authors may (incoherently) add to a text.
2. Website (backends) can be configured so they introduce <q> tags where required, after which authors can see that these are applied correctly in the browser. What I'm saying is, a CMS or build system can try to parse the text and replace quotation marks with <q> tags, so then in CSS quotation marks can be added to consistently across all pages for each text's language. Arguably, such a parsing step could just as well apply the desired quotation marks instead of <q> tags, but the tags would enforce consistency in the code, whereas it would be harder to build and maintain parsers that replace typographic symbols with other typographic symbols.
   This is not a hypothetical issue: I manage a website with only two languages, but the various authors use different quotation marks, sometimes even within one text, because some text editing applications replace straight quotes with fancy ones where others don't. Some authors aren't even aware of the inconsistencies as they're focusing on words, not typography.
3. If inline quotes require styling beyond pseudo elements (f.e. background colors), without <q> elements like <em> or <mark> or <span> would have to be added. Depending on the content and the styling these may not convey the same semantic meaning.
4. Regarding 1 ("It would be possible to fix this, but css-content hasn't seen movement in the last 1.5 years."): once this would be fixed, the recommendation against using <q> would have to be lifted again. It often takes years (if not decades) for two recommendation changes to land with HTML authors—we still see <i> for icons, many people are even discovering <q> today. HTML is confusing enough as it is—in my opinion there already are too many elements that don't behave like one would expect (f.e. ' or '<input type="number">. Instead of recommending against the tag completely, we can warn HTML authors about the shortcomings instead.
5. Regarding 3 ("The cite attribute is a usability footgun for authors"). I consider this an argument for recommending against the cite attribute, but not necessarily against the elements it can be applied to.

[alanpoulain]

I would like to emphasize this issue: using <q> is very problematic for the end user since the text copied is different from the text displayed.
However, the WCAG and the RGAA (the French equivalent) recommends to use this element.
It means that if you don't use it, you lose some accessibility criteria and if you do use it, all the users are penalized because of its weird behavior.

@jyasskin you said:

Since <q> is widely used across the web, it's probably impossible for browsers to actually drop support for it

I'm not sure about this affirmation: it's really hard to find a content website using it, maybe you could give some examples, they will highlight how the <q> element is problematic.

Ideally, I would like to see this part of the standard removed:

Quotation punctuation (such as quotation marks) that is quoting the contents of the element must not appear immediately before, after, or inside q elements; they will be inserted into the rendering by the user agent.

It will allow us to clear the quotation marks rendered by the browser, and add them inside the <q> element:

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

[prlbr]

Ideally, I would like to see this part of the standard removed:

Quotation punctuation (such as quotation marks) that is quoting the contents of the element must not appear immediately before, after, or inside q elements; they will be inserted into the rendering by the user agent.

It will allow us to clear the quotation marks rendered by the browser, and add them inside the <q> element:

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

This change would make use of the <q> element across the web more inconsistent, which would make it harder to fix technical shortcomings then.

I would also advice against assuming CSS support. A browser that doesn't recognize your CSS (because the browser can't or doesn't want to, e.g. because it offers its readers a standardized, book-like "reader view" of webpages) would display nested quotes then, yours inside the <q> and additional ones representing the <q> element.

[alanpoulain]

@prlbr You have a point. However, the <q> element is not usable right now, so I see two possibilities:

• Add to the standard what Firefox is doing (badly): when the text is copied, the displayed quotes should be added automatically by the browser and must respect the quotation marks used.
• Add a new HTML element fixing the shortcomings of the <q> element: quotes must not be added automatically by the browser.