Re: Why HTML should be taught as HTML without pretending it is XML

Hi Lachlan,

On Jul 18, 2007, at 2:57 AM, Lachlan Hunt wrote:

>
> Karl Dubost wrote:
>> If Web designers say, we will come up with an HTML 5 profile that  
>> we consider needed for our activity, it can perfectly become an  
>> "HTML 5 profile for Web pro" specification for this market. I  
>> would say that Web Designers on the list have to organize  
>> themselves and propose a profile which is compatible with HTML 5  
>> and can be a subset in the syntactic rules.  It can be a different  
>> document.
>
> In general, I don't have a problem with coding conventions.  They  
> exist for a variety of other languages, such as C++, Java, PHP,  
> etc. and even Canonical XML exists for XML.  Perhaps it would be  
> useful to produce a Canonical HTML specification.
>

On Jul 17, 2007, at 10:20 PM, Karl Dubost wrote:
> I would say it is ok
> 	- for browsers to recover bad markups
> 	- for Common authors to not be beaten on the fingers for every  
> details
> 	- for Professional to have a strict way of authoring which  
> benefits the industry
>

If I understood Karl correctly, I got the impression he was saying  
that independent of the first point (that wa want browsers to recover  
and to recover  in the most interoperable way possible) we should let  
authors use whatever syntax meets the conformance criteria AND that  
as specification writers to set a good and clear example with our own  
source. Let me qualify that further because i can tell many on this  
list like to set a good and clear example by leaving out what is  
perfectly proper to leave out. (Here I may be depart from what I read  
Karl saying, but)  I think we shouldn't use all of those nifty little  
shortcuts of leaving off quotation marks and leaving off optional  
close tags  just because we can. It doesn't really set a positive  
example, because its not the type of coding one can learn through  
example (its just too complex and intricate to learn it from reading  
someone else's source).

The other issue  I see is that we have two separate serializations  
which often require us to throw complicating caveats into every  
sentence we write. In portions of the draft not dealing specifically  
with syntax, it helps us to provide a syntax (in our examples, for  
instance) that — as much as possible — is serialization agnostic. I  
think that's easy enough to do by including all optional closing tags  
and always quoting attribute values.

The one place where the syntax differences does not meet is on the  
issue off elements with empty content models. There HTML must not be  
closed and XML must be closed. PhillipTaylor (name collision :-) )  
has brought up the compelling problem of including the self-closing  
tags for these elements creates the impression that an author can use  
that syntax whenever an element is empty. That's definitely a problem  
with that syntax. On the other hand, if authors can be made to  
understand the difference between an element that just happens to be  
empty and an element that must be empty, then that syntax seems like  
a great way to unite the two different serializations into one syntax  
that works either way.

HTML5 has an opportunity to pave the way here: especially with  
specifying its own DOM. This will tend to minimize the differences  
further between deploying XML or text/html because the DOM will work  
the same either way in HTML5 conforming UAs. The differences in  
deploying these serializations declines greatly. We're left with a  
few implied elements (that if you stick with an XML mindset you  
shouldn't even expect them), the CSS root selector(?), and the use of  
<noscript>. I''m sure there are some more I'm forgetting, but they  
are quire minor. If there's anything we can do to improve those  
without breaking backwards compatibility, we should seriously  
consider it. HTML5 could actually make XHTML's appendix C work.  
That's an interesting prospect.

On Jul 18, 2007, at 2:57 AM, Lachlan Hunt wrote:
> However, I would recommend that if such a document is produced, all  
> guidelines should ideally be backed up with good justification, and  
> not simply be a matter of personal opinion.  For example, I would  
> object to a guideline that required trailing slashes for empty  
> elements since the only valid justification for it is based on  
> personal preferences.

In some sense we should all admit this is all a matter of personal  
opinion. There's no way we can come up with definitive reason to use  
exemplary  code (in the way I described it). My sense of exemplary  
code has to be, in some sense, based on my own personal opinion. I  
can explain the reasons why I think the syntax should be the way I  
recommend. You might explain why you want it another way. Ultimately  
there may be no technical criteria we can apply to adjudicate which  
syntax to use. It will have to be decided through the consensus  
building procedures developed by the W3C. I don't feel all that  
strongly about these issues,so I wouldn't expect it to come to that.  
However, it does seem like there are some pretty strong feelings on it.

Take care,
Rob

Received on Wednesday, 18 July 2007 09:47:15 UTC