[whatwg] The blockquote element spec vs common quoting practices
Jukka K. Korpela
jkorpela at cs.tut.fi
Sun Feb 12 14:17:06 PST 2012
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.
More information about the whatwg