[whatwg] The blockquote element spec vs common quoting practices
ian at hixie.ch
Sun Feb 12 20:07:20 PST 2012
On Mon, 13 Feb 2012, Jukka K. Korpela wrote:
> 2012-02-12 23:25, Ian Hickson wrote:
> > The use case for most of the "semantic" markup is just easier
> > authoring and maintenance, in particular for selectors in CSS.
> If that’s the approach, and this reflects a consensus, shouldn’t
> this be explained in the introductory material (which is now rather
> limited and technical and does not really explain the goals and ideas)?
Generally speaking I do not include rationales in the document, as that
would basically double the length of the work. In the past we have had
people work on rationale documents, e.g.:
If you (or anyone else) is interested in further maintaining this work,
please don't hesitate to do so.
> The obvious meaning of “semantic” (and http://www.whatwg.org/specs/
> speak about semantic markup without quotation marks) is that it is
> related to meaning, not ease of authoring.
They're are not mutually exclusive. Documents that are marked up according
to the meaning of the content tends to be easier to maintain, especially
in the face of changing desires with respect to the presentation. The
concept of CSS and especially alternative style sheets is predicated on
the document markup being rich enough that specific parts, e.g. headings,
paragraphs, sections, sometimes even quotes, can be directly selected and
> If you don’t expect semantic differences as such make any difference,
> then why introduce semantic markup at all?
The basis of HTML on semantic markup far predates this effort.
> Surely it would be easier to author if you can introduce your own tags
> as you go, designing a tag set that suits a particular page, site, or
Authors are of course able to do this using just <div class=""> or even
just XML, but in general document maintenance, especially across multiple
authors over time, is significantly helped by the use of a common
> If the idea is that in collaborative environments, it is easier to work
> when everyone uses the same tags, then it’s really about setting
> design and coding practices. It would be something rather orthogonal to
> all other aspects of HTML.
> > In the case of <blockquote>, we inherited it from HTML4 and so use
> > cases weren't really a driving factor in the contemporary
> > specification's development of the feature; it was more driven by
> > consistency concerns.
> Consistency with existing practice would be achieved by describing the
> default rendering in browsers.
That's certainly part of the work required of us (and it is done).
> There’s little reason to aim at describing the semantics if it’s not
> really expected to be relevant
The semantics are definitely relevant. As I said in my last e-mail, they
are what helps ease authoring and maintenance.
> especially since we know that very often, existing pages (and existing
> authoring software) uses <blockquote> just for indentation.
Can you elaborate on your source for this? Data is always welcome. I'm not
aware of a study that shows this one way or the other.
> Designers and people who set coding standards can specify how they want
> <blockquote> to be used
If authors want to use text/html, and the HTML lexicon, but with different
meanings, they are naturally able to do so by just writing their own spec
that defines the language as they desire. There's nothing magical about
the HTML standard; it's only useful because people agree amongst
themselves to use it as their common definition of the vocabulary.
> > (Same as with, e.g., <dfn>, <strong>, and other "semantic" elements.)
> They, too, as well as <b> and <u>, have been modified quite a lot
<dfn> and <strong> haven't really been modified, merely clarified.
<b> and <u> have been repurposed.
> with elaborated explanations about their meanings, causing both
> confusion and argumentation.
I think overall the confusion and argumentation is significantly less for
all these elements than it ever was in the HTML4 days. :-)
> It would be so much simpler, and it would give the same authoring and
> maintenance ease, to describe just how browsers render them by default.
I think this rather misses the point. It's not the common default
rendering that makes authoring with these elements easy. The default
rendering is almost always overridden anyway. It's the common definition
of the elements' meanings that helps ease authoring and maintenance. An
author can join a project, and can immediately use <h1> and know that
whatever the page's styles are, they'll give <h1> the same heading style
as the main heading on all the other pages of the site. A blog author
using a default theme can use <blockquote> to indicate when she quotes
from another source, and then change to another theme with some confidence
that the new styles will also treat <blockquote> in that way. If we only
defined default renderings, there would be no way to be sure that that
Many of the new elements do the same for the most common elements in a
page design, like <footer> or <aside>, which were previously only handled
by sites defining an extra vocabulary with class names. Over time, I
expect we'll continue to take the most common class names and provide
elements for them, increasing each time the surface area that HTML covers
without authors having to agree on class names.
> > > At the same level, “credits” can be used in editing and checking
> > > tools to verify that all quotations have credits (issuing warnings
> > > about those that don’t); in automatically generating a list of
> > > references; in an optional browsing mode where credits are hidden,
> > > with a button available for opening them; in finding out (even
> > > web-wide) which documents quote a certain document.
> > Do any tools try to do any of this?
> Of course not; there is no markup for credits.
That's never stopped anyone before. People do all kinds of semantic things
without there being explicit markup in HTML, see e.g. microformats, which
defined class names for semantics that HTML didn't have, and then spawned
software that made use of those semantics. The lack of software to do what
you describe is a very good indicator that there is not a real need here.
> > If there are concrete use cases with software that is trying to
> > address the use case and authors who want to use that software, then
> > we should definitely look at the use cases. But we need to study the
> > use cases and software, if that's the case.
> So in order to have proposals for elements considered, one would need to
> present concrete cases of programs trying to work on the elements that
> do not exist.
Yes. For more details, I refer you to the FAQ:
> > The practical use of moderately simplified maintenance is sufficient
> > to justify keeping elements that are already deployed.
> Certainly. And to make this as simply and effectively as possible, the
> specification should just describe the existing markup in terms of
> browser behavior.
That would fail to achieve the stated goal, for the reasons I describe
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg