Typographically speaking, I think I’m more in favor of hung quotes than ones that flow with the text. But that’s not what I want to discuss.
From a CSS-purist point of view, I would argue that it’s most important to consider the semantics of the blockquote element. As Martin mentioned, the blockquote element alone conveys the fact that the contents have been quoted. Thus, having quotation marks inside the blockquote is redundant.
whiteinge made the following observation: If blockquotes are not immediately apparent as a quotation it is the fault of the typographer… This distinction between the content and its typography is part of what makes (X)HTML+CSS so powerful—its ability to separate content and presentation.
Whether a blockquote should have quotation marks or not has nothing to do with the content of the quotation itself; the marks are decorations used by typographers to set the quotation apart from normal text. The presentational nature of such decorations, be they special colors, italics, margins, or quotation marks, means that they should exist in the CSS.
Quotation marks exist as boundaries to the content of a quotation. There are CSS pseudo-elements that exist to create exactly these items: :before and :after. If you read up on the W3C docs on generated content, you’ll find that the current recommendations for generated content deal specifically with ordinary text, numbering schemes, and the correct presentation of [ta-da] quotations.
I would argue that the semantically correct way to display quotation marks around blockquote elements is to use CSS blockquote:before and :after rules. The problem is that not all browsers support these rules. IE ignores them completely. Firefox doesn’t support them fully (positioning is missing, which limits what you can do). I don’t know about other browsers, as I don’t have access to them.
Right now, you can’t use :before or :after and expect them to display correctly across all browsers. In some circumstances, that can be okay, but how much cutting-edge CSS to use and which browsers to support is a different debate that I won’t get into here. You can sleep peacefully, though, knowing that your markup is semantically sound, you’ll be able to change the presentation of your site at a whim without changing its content, and that, maybe someday, browser makers will fully support CSS generated content.
Mike S.
Typographically speaking, I think I’m more in favor of hung quotes than ones that flow with the text. But that’s not what I want to discuss.
From a CSS-purist point of view, I would argue that it’s most important to consider the semantics of the
blockquoteelement. As Martin mentioned, theblockquoteelement alone conveys the fact that the contents have been quoted. Thus, having quotation marks inside theblockquoteis redundant.whiteinge made the following observation: If blockquotes are not immediately apparent as a quotation it is the fault of the typographer… This distinction between the content and its typography is part of what makes (X)HTML+CSS so powerful—its ability to separate content and presentation.
Whether a blockquote should have quotation marks or not has nothing to do with the content of the quotation itself; the marks are decorations used by typographers to set the quotation apart from normal text. The presentational nature of such decorations, be they special colors, italics, margins, or quotation marks, means that they should exist in the CSS.
Quotation marks exist as boundaries to the content of a quotation. There are CSS pseudo-elements that exist to create exactly these items:
:beforeand:after. If you read up on the W3C docs on generated content, you’ll find that the current recommendations for generated content deal specifically with ordinary text, numbering schemes, and the correct presentation of [ta-da] quotations.I would argue that the semantically correct way to display quotation marks around
blockquoteelements is to use CSSblockquote:beforeand:afterrules. The problem is that not all browsers support these rules. IE ignores them completely. Firefox doesn’t support them fully (positioning is missing, which limits what you can do). I don’t know about other browsers, as I don’t have access to them.Right now, you can’t use
:beforeor:afterand expect them to display correctly across all browsers. In some circumstances, that can be okay, but how much cutting-edge CSS to use and which browsers to support is a different debate that I won’t get into here. You can sleep peacefully, though, knowing that your markup is semantically sound, you’ll be able to change the presentation of your site at a whim without changing its content, and that, maybe someday, browser makers will fully support CSS generated content.