[whatwg] The blockquote element spec vs common quoting practices

[Ian Hickson]

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.:

   http://wiki.whatwg.org/wiki/Rationale

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 
styled.


> 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 
> application.

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 
vocabulary.


> 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.

Yes.


> > 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 
would happen.

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:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F


> > 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 
above.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'