Re: HTML 5 and XHTML 2 combined

On 9/1/09 18:50, Philip TAYLOR (Ret'd) wrote:
>> Is there a major semantic advantage to [allowing] "href" anywhere?
>
> That depends on one's perspective. From my perspective,
> it adds orthogonality to the language, which I regard
> as a Good Thing [tm]; in addition, it allows documents
> to become simpler : one no longer need wrap <A> tags
> around an element in order to permit it to function
> as a hyperlink.

I'm not sure what "orthogonality" means in this case.

"href"-on-any-element produces more compact markup and DOM. I'm not sure 
it's less of a cognitive burden for authors however, especially given 
"a" is one of the few pieces of HTML ordinary authors tend to know. Even 
if it is, I don't think it's a "semantic" advantage because the 
information encoded is the same.

> I am sure that it would, but if the benefits outweigh
> the disadvantages, then it is not unreasonable to
> ask that browser vendors invest the necessary effort.

Agreed. Personally, I don't think it is worth the questionable benefits 
of compactness if graceful degradation in existing popular browsers is a 
design goal, however.

> More to the point, what benefit (if any) is gained
> by having nested links ? Just because something
> is syntactically possible does not mean that it
> should necessarily be exploited. Indeed, the
> specification might well state that documents with
> nested links are ill-formed.

Indeed, it _could_. The XHTML 2 draft on the other hand states:

"If elements contained within an element using an href also use an href 
attribute, the User Agent must provide a mechanism for actuating any of 
these "nested" URIs."

http://www.w3.org/MarkUp/2009/ED-xhtml2-20090109/mod-hyperAttributes.html#s_hyperAttributesmodule

>> Or elements that are both hyperlinked and have some other functionality?
>>
>> <submit submission="submit"
>> href="http://en.wikipedia.org/wiki/HTML"><label>Go!</label></input>
>
> Although I /think/ I understand your question, the above
> code looks ill-formed to me, and I will therefore defer
> answering until you have had time to clarify whether this
> is the example you meant to adduce.

Sorry, that should have read:

<submit submission="submit" 
href="http://en.wikipedia.org/wiki/HTML"><label>Go!</label></submit>

> I'm not sure we are discussing the same thing here. I am arguing
> that HTML 5 should stop carrying with it the baggage of earlier,
> arguably poorly thought out, standards and should rather have the
> courage to propose how things will be expressed /in the future/.

Okay. While that's a perfectly reasonable goal for _a_ language, I think 
that's irreconcilable with the stated goals of the HTML5 project:

* http://dig.csail.mit.edu/breadcrumbs/node/166
* http://www.w3.org/TR/html-design-principles/#degrade-gracefully

> By definition, this will require browsers to parse (and process)
> HTML 5 documents differently to how they parse and process documents
> conforming to earlier standards (and, of course, how they parse
> and process documents that lack a DOCTYPE directive and which therefore
> cannot be safely assumed to conform to any standards whatsoever).
> By so doing, HTML 5 could define the <IMG> element to be a container
> (in HTML 5), even though it was not a container in previous specifications.
> If you accept this premise, then I do not think that the snipped
> series of options is relevant (but please correct me if I am wrong).

If one did want to create a markup language that cast graceful 
degradation in older user agents to the winds and you wanted to do so 
using the text/html media type, switching rendering modes based on some 
characters at the start of the document would be an approach.

But I don't really see the point of creating such a language in 
text/html rather than XML, since I think the main advantage of text/html 
is the ability to deliver accessible content to today's user agents, 
potentially mixed with third-party text/html content (ads). If you 
aren't creating a language that degrades gracefully, then that 
disadvantage disappears.

If one's willing to create such a language in XML, then that would seem 
much more compatible with the stated goals of the XHTML 2 project and 
related technologies than the HTML5 project; I don't see how one can 
turn HTML5 into that project without destroying it.

The only strong considerations I can see against XML are:

1) Draconian error handling (some people don't like this). If you don't 
like draconian error handling, the XML5 project ( 
http://code.google.com/p/xml5/ ) might be a good focus for activity as a 
precondition.

2) It's complex. I think that problem is best approached by looking 
beyond the angle-bracketed world of SGML, HTML, and XML entirely and 
taking inspiration from languages that attempt to be friendly to hand 
authors like POD, BBCode, Textile, and Markdown. If you're going to 
define new parsing rules, might as well make them focused on what human 
authors require rather than being influenced by the historical vagaries 
of HTML and SGML.

--
Benjamin Hawkes-Lewis

Received on Friday, 9 January 2009 19:43:32 UTC