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 https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/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 e0e4b51a5 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]

@[email protected] 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.