Re: "/>" (was Re: several messages about New Vocabularies in text/html

Henri Sivonen <hsivonen@iki.fi> writes:

>> I'm getting a little confused.  It seems like the following is true:
>>
>> 	. <script/> is treated like <script> in all browsers -- it
>> will  match against </script>
>
> Yes.
>
>> 	. In all browsers, an unclosed script is not executed
>
> At least for contemporary values of all.

OK.  But let's be clear about how this developed.

Under the W3 specs for HTML (due to a minor oversight/error in the
sgml declaration for HTML [previously noted here]) the following
wrong-headed markup has been formally correct HTML:

        <p>This is <em/>emphasized</em> text.</p>

A formally correct parsing of it by the terms of the HTML 4.01 spec
yields:

           This is _>emphasized_ text.

(Underscores for text/plain emphasis.)

But, of course, the formally correct parsing of the all but formally
incorrect markup is not reasonable.  This spawned the need for
browsers to do the right thing and perform cleanup.

> Yes, /> needs to be honored for MathML and SVG elements but must not
> be honored for HTML elements. /> is still allowed in validation for
> void HTML elements. (So the validator complains about <div/> but not
> about <br/>.)

OK, I think.  While, as you say, using /> on an open tag may need to
be honored by browsers, it is not the right thing.  Let's be clear
about that.

Now back to
http://lists.w3.org/Archives/Public/public-html/2008Apr/0100.html
(from April 2):

> >  .  .  .  could explain succinctly why html5 source is not being
> > specified relative to an underlying, canonically related, sgml
> > document type.
> 
> Specifying HTML5 in terms of SGML would be pointless, because
>   1) Real browsers don't use SGML parsers.
>   2) SGML doesn't specify error what to do in error cases. Web- 
>      compatible error-recovery is a must.
>   3) Even as a validation formalism SGML is totally inadequate.

There is nothing new in these 3 reasons.  They all apply to
previous W3C versions of HTML.

If it is possible for the source serialization of an html5 document
to be handled by standard SGML parsers, then that source will be
more useful in various ways than if not.

I've yet to see an even partly convincing reason for cutting the cord.
Do notice the language I used: underlying, canonically related, SGML
document type.  This allows, in particular, for the possibility of
needing straightforward preliminary processing of the source
before submission to an SGML parser.

                                    -- Bill

Received on Friday, 4 April 2008 20:48:53 UTC