Neal said:
How I read it is that UAs are required to allow the non-semantic use
of blockquote.
An interesting interpretation. In what sense are they required to "allow"
it? They are not allowed to crash when they see it?
Or do you mean
that browsers are not allowed to speak "quote" before a <blockquote>
element and "unquote" after it? Or otherwise indicate it as a block
quotation?
The only explicit thing mentioned is "don't put quotes
around it"
It's a "should not", not "shall not" or "must not". I think you know that
makes a big difference in standards parlance (W3C recommendations are not
standards, but they make big and partly serious attempts at looking like
standards).
Nevertheless, it _is_ absurd indeed, and shows where we end up when we
start mixing semantics and "I use this because both browsers show it the
way I like" authoring, making concessions to the latter.
I guess they really didn't think about Braille rendering, for example (or
much else for that matter), when they wrote that "should not". How can
you indicate quoted text as quoted in Braille without using quotation
marks of some kind? (I count words like "quote" and "unquote" as
quotation marks of a kind in this context.)
but that would hardly be correct style for an indented quote.
That's a matter of style actually, and HTML specs should take no position
But I suppose the fact that it's deprecated in favor of stylesheets
simply means that old documents which use blockquote in this manner
aren't suddenly wrong.
That's further handwaving and pointless compromise. (Compromise: a
decision that combines the drawbacks of all proposed solutions.)
They were always wrong, and the absurd babble tries to make them less
The specs do mention the elements involved as definition list,
definition term and definition description. Then they come out with
this:
"Another application of DL, for example, is for marking up dialogues,
with each DT naming a speaker, and each DD containing his or her
words."
... which makes no sense if we consider what a definition is.
Exactly.
But it's in the specs, so it's technically allowed. Bizarre.
It's a note about "application of DL", which is hardly a normative
statement that would affect the defined meaning of DL. Just as they
haven't changed the meaning of BLOCKQUOTE by the babble about indents,
though they surely make clear there were mixed ideas in the working group
about all this.
Similarly, if they said that another application of BLOCKQUOTE is
indenting text (as they effectively say, more or less), would that change
the meaning of BLOCKQUOTE? To what?
Note also that the Note: sections are described as informative, but
the above isn't explicitly informative or normative as far as I can
see.
It describes a usage, instead of saying "shall", "should", or something
else in normative terms or giving a definition. Thus, the content of the
statement makes it descriptive. Whether it's informative is moot, but
it's surely not normative.
Why include this sentence at all unless they meant to encourage
creative use of this markup for non-definition content?
Because the working group had mixed opinions and they decided not to
decide, in order to produce a "specification" fast enough. W3C
specifications are not standards.
3.2 and 2.0 don't include any language in describing dl's which
allude to anything other than standard terms and descriptions - so
why was this added? I'd sure love to know that story.
I don't know the story; I just made an educated guess. Some people in the
working group didn't care about semantics (and effectively wanted to
define BLOCKQUOTE as 'indent', DL as 'indented list with non-indented
parts indicated as DT'), some did (and wanted to keep the semantic
definitions*), and they were forced to reach a "consensus". But I think I
don't want to know the dirty details of the story.
*) I guess there was no argument over the _names_, which clearly
associate with the semantic definitions. The tag names were already part
of the HTML tradition and hard-wired into existing documents and existing
browsers.
