Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 9 years ago

#17671 closed defect (bug) (wontfix)

Twenty Eleven: Quotes

Reported by: knutsp's profile knutsp Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.2
Component: Bundled Theme Keywords: has-patch 2nd-opinion
Focuses: Cc:

Description

When I use the <q> tag there are no quotes displayed. In style.css I see:

blockquote:before, blockquote:after,
q:before, q:after {
	content: "";
}
blockquote, q {
	quotes: "" "";
}

and this removes the quotes. This is not present in Twenty Ten. Removing the q selector from the above two rules fixes this.

Attachments (1)

18134-visible-quotes.diff (480 bytes) - added by iandstewart 13 years ago.

Download all attachments as: .zip

Change History (16)

#1 follow-up: @toscho
13 years ago

  • Cc info@… added

There is no way to get quotes right in all languages. Plus, some current web browsers cannot handle CSS quotes very well: Firefox and Webkit for example omit the quotes when the reader copies some text. There are issues with selections in Webkit and Opera too.

Twenty Eleven has no chance to do the right thing because q is currently broken nearly everywhere. Create a child theme with proper quotes for your target audience or better: don’t use q and insert the quotation marks as real text like you do it with question marks. This way, users with a browser that doesn’t understand q at all (IE < 9) still understand what you have written.

Recommended reading: Masayasu Ishikawa: Why the quote element doesn't add quotes by default – from 2004 but still in many parts relevant.

#2 @nacin
13 years ago

The <q> tag is inconsistent with regards to quotes in browsers. Pretty sure it's IE that doesn't surround it with quotes. Most usage typically based on the idea of using <q> for semantic reasons, and then wrapping it with quotes in HTML.

#3 @nacin
13 years ago

Thanks toscho for far more background than I had off the top of my head.

#4 @knutsp
13 years ago

I do not suggest using <q>. I'm just surprised that Twenty Eleven has decided to sabotage the use of it, even for those who want to use it anyway, and want to let the readers browser do whatever job the browser "thinks". This is like styling the <b> tag to normal font weight, because you think it's a bad tag to use in the first place. Worse even: Styling the q element invisible.

So if no one sane (and html capable) author uses <q> then why style it at all in the default theme?

Remove the q selector, and everybody is happy. If some users want to style this element away, let them make a child theme.

#5 @solarissmoke
13 years ago

  • Cc solaris.smoke@… added

#6 @nacin
13 years ago

  • Milestone changed from Awaiting Review to 3.2

Moving to 3.2 for consideration, as this either needs to be dealt with or closed as wontfix.

#7 @iandstewart
13 years ago

I rather prefer disabling quotes but attached is a patch removing q-resetting if/when we feel like it shouldn't be there.

#8 @iandstewart
13 years ago

  • Keywords has-patch added

#9 @westi
13 years ago

  • Component changed from Graphic Design to Bundled Theme

#10 in reply to: ↑ 1 @sterlo
13 years ago

Replying to toscho:

Recommended reading: Masayasu Ishikawa: Why the quote element doesn't add quotes by default – from 2004 but still in many parts relevant.

Given the context from Masayasu:

So we concluded that it would be reasonable to place the burden of
adding "proper" quotation marks on authors rather than implementors.
The I18N WG recommended that using styling would be a preferable way
and encouraged CSS implementors to support relevant feature more widely
and consistently.  Then, each author may have their own default style
rules, and may include them in their author style sheet.  We could
provide some sample style rules, but it MUST NOT be in the default
XHTML 2.0 style sheet.

I think this should be enforced.
I agree with the decision to try to make this more consistent by adding a default style in Twenty Eleven.

#11 @knutsp
13 years ago

Masayasu has a point, but then he should also recommend that unordered lists should not have bullets shown as default element indicator, since the author should have to control this. I guess there are different typical ways of presenting av list in different languages and cultures.

BUT: An author should still expect <q> elements to be surrounded by some kind of quote character in a descent browser, if he doesn't bother specifying which characher he wuld prefer. As with lists and some kind of default list element symbol.

I see no recommendations in HTML 5 for disallowing user agents to insert a quote character as part of a default style. XHTML 2.0 was discontinued, and HTML 5 is quite transitional and keeping backwards compatibility with HTML 4. From WHATWG:

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.

The Q element is not deprecated. But we, as authors, can't rely on this element always to be rendered properly in your language, or rendered at at all in some older browsers (as many other elements, CSS selectors and properties).

I see no reason why WordPress, through the default theme, should try to enforce a disputable view like Masayasu's from 2004 (that the Q element MUST NOT have a default style).

#12 @knutsp
13 years ago

  • Keywords 2nd-opinion added

Pardon me for adding another comment. But I really want to say that I respect the opinion that the Q element should not be used by authors in the current state of the web.

But this is an opinion, no matter how useful an "correct" it may be.

For a common theme author to enforce this debated rule: Yes! (take it or modify it yourself)

For the default theme of WordPress: No! (leave it undefined, without an opinion and without a style)

#13 @aaroncampbell
13 years ago

It seems like Twenty Eleven is just doing it's best to make a poorly supported element work the same cross-browser. I'm for keeping it the way it is and setting this ticket to wontfix.

#14 @markjaquith
13 years ago

  • Milestone 3.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This ticket was mentioned in Slack in #polyglots by sergeybiryukov. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.