W3C home > Mailing lists > Public > www-html@w3.org > January 2009

Re: HTML 5 and XHTML 2 combined

From: Philip TAYLOR (Ret'd) <P.Taylor@Rhul.Ac.Uk>
Date: Fri, 09 Jan 2009 18:50:18 +0000
Message-ID: <49679C6A.4080505@Rhul.Ac.Uk>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
CC: www-html@w3.org

Benjamin Hawkes-Lewis 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.

> Some browser vendors think it would be complex to overload elements with 
> additional functionality:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-August/007179.html

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.

> What would be a good interface for nested links?
> <span href="http://en.wikipedia.org/wiki/HTML"><span 
> href="http://en.wikipedia.org/wiki/Hypertext">HyperText</a> Markup 
> Language</span>

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.

> 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.

[Long snip,  all pertaining to nested links which do
not necessarily follow from the proposal to add "href"
to the set of standard attributes inherited by all

> With respect to "img" alternative text, HTML5 has to define how to 
> serialize an HTML5 DOM parsed out of XML to text/html.
> If HTML5 allowed content of the img element to be used as alternative 
> text in the XML serialization, how would you suggest the following DOM 
> be serialized in text/html?

[Snipped series of possibilities]

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/.
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).

Received on Friday, 9 January 2009 18:51:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:21:06 UTC