First, let me say that I am not entirely convinced by the argument
that I am about to make, but neither am I convinced that these
four elements should be treated specially.
<CODE>:
========
This one is fairly easy to imagine. An author wants to show
a bit of shell script that contains an awk fragment:
<CODE> cat foo | sort -u | awk <CODE>'{ print $1 }' </CODE> </CODE>
The browser could format the nested <CODE> the same as the outer one,
or could chose to add emphasis to the traditional monospace face.
Yes, this is a bit contrived, but since I am the technical publications
architect and strategist for a UNIX Development System, I figure that
I have artistic licence.
<SAMP>:
=======
This one is a bit harder to justify. In fact, I can't.
So, maybe nobody else could justify it either and wouldn't
bother to code a document that way.
On the other hand, since <SAMP> is a "sequence of literal characters",
maybe it should not be allowed to contain anything except #PCDATA.
<KBD>:
======
OK, I can't justify this one either.
So, maybe nobody else could justify it either and wouldn't
bother to code a document that way.
<KEY>:
======
I would imagine that nested <KEY> would be used to code tuplets,
like <Ctrl>D as <KEY><KEY><Ctrl></KEY>D</KEY> or <Alt><Ctrl><F1>
as <KEY><KEY><Alt></KEY><KEY><Ctrl></KEY>F1</KEY>.
A browser could format the nested <KEY>s in a tighter sans-serif face.
>
> Does this make sense:
>
> <code>This <code>is <code>an example</code></code></code>
>
> Code inside code, hmmmm. Saying browsers should just ignore it is not
> a decent argument. I'd like to here why the above should be valid.
> I can't see a logical distinction from a CODE element, that is
> contained within a CODE element, and a non-nested CODE element.
>
> Now this seems perfectly fine to me,
>
> <code>Hit <key>Q</key> to quit</code>
>
> since KEY has a logical distinction from CODE. I'm saying that each
> element above should not contain itself.
>
> --ewh
>