Re: HTML 5 and XHTML 2 combined

>
> <submit submission="submit" href="http://en.wikipedia.org/wiki/HTML
> "><label>Go!</label></submit>
>
You are also able to do make elements with double functionality in today's
HTML 4/XHTML 1 mark-up:
<input type="submit"
onclick="window.location='http://en.wikipedia.org/wiki/HTML';"
value="Go!" />
But as Philips says that doesn't have to mean, it's well-formed.

2009/1/9 Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>

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


-- 
Hilsen
Molte

CosSinCalc
http://cossincalc.com