[whatwg] The blockquote element spec vs common quoting practices

[Jukka K. Korpela]

2012-02-12 23:25, Ian Hickson wrote:

> The use case for most of the "semantic" markup is jsut 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)? This could 
even help to clarify the discussion but especially it would guide authors.

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. If you don’t expect semantic 
differences as such make any difference, then why introduce semantic 
markup at all? 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.

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. There’s little reason to aim at 
describing the semantics if it’s not really expected to be relevant – 
especially since we know that very often, existing pages (and existing 
authoring software) uses <blockquote> just for indentation.

Designers and people who set coding standards can specify how they want 
<blockquote> to be used

> (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, with 
elaborated explanations about their meanings, causing both confusion and 
argumentation. 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.

>> 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. (And in reality no markup 
for quotations either – no markup element that programs could reasonably 
expect to mean “quotation”, unless you count <q> – which is probably not 
used against its basic defined meaning, but it isn’t used much at all.)

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

> 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. Surely it does not ease authoring or maintenance to 
invent new meanings and new rules for markup that is currently in use – 
if the semantic definitions are not expected to be notified and used by 
browsers, search engines, etc.

If the semantics are not supposed to be “real,” it would be much better 
to leave things open. If the specification would not designate any 
element as suitable for quotation, still less the right element for it, 
designers and authors would answer the question themselves, in their own 
coding rules and standards. It would be *easier* without a fairly 
complex part of a specification telling all kinds of things about the 
elements, possibly reflecting the design and coding ideas of some 
working group or editors.

If no software is expected to treat <blockquote> text so that the 
semantics “quotation from an external source” is relevant, then it is 
completely immaterial whether one puts the references or credits inside 
or outside the element (if one uses <blockquote> for a quotation). Any 
rule on this would be just a rule for rule’s sake and would make life 
more difficult to people who take the specification seriously and face 
situations where the references would better go inside, or go outside, 
as the case may be.

Yucca