On Wed, 28 Jul 2004, Jukka K. Korpela wrote:
> > >
> > > - - The markup language specification should define the meanings of
> > > elements and attributes, not the way they are processed.
> >
> > It should do both, if it wants interoperability.
>
> So you mean XHTML should be both declarative and procedural? That leads
> to more problems than I can imagine.

I didn't say that (I'm not even sure what you really mean).

But there are plenty of things in HTML for which the processing model must
be well defined: in a <script> element, what should UAs do if they find
non-text nodes? Should they concatentate all text nodes and ignore other
nodes? Should they concatenate all the text node descendants of element?
What about unexpected children of <col> elements? What order should
overlapping shapes in <map> elements be taken? What should a <tfoot> do if
it is found after a <tbody>? How should the label for <option> elements be
determined, where there is/isn't an optgroup, or is/isn't a label
attribute? What should nested <em> tags mean? What about nested <strong>
tags? What about if <em> and <strong> elements are mixed?

Note that most of those actually _aren't_ defined by the HTML4 specs.


> > > Do you mean [the summary element] should be treated as a <caption> of
> > > second grade?
> >
> > No; I mean it would be rendered instead of the table content. That, at
> > least, is my reading of the spec's vague definition.
>
> That's interesting; I could not have imagined such an interpretation.
> [...]

Yeah, your interpretation makes more sense.

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