Re: Who is the Intended Audience of the Markup Spec Proposal?

Hi Ian and Mike,

A few more things I meant to raise regarding this draft. An important  
thing needed in a document conformance document is a normative  
description explaining to authors how to create content for the  
'progress', 'meter', 'time' and other such elements. As it stands now,  
the browser interoperability draft covers how to process the contents  
of these elements, but there needs to be document conformance norms  
that ensure the contents of those elements meets the needs of the  
processing algorithm. An author needs to understand that they cannot  
author an element such as, for example,

<time>4th day of the 3rd month last year</time> and expect it to be  
parsed correctly (just a quick example off the top of my head, if the  
processing algorithm miraculously handles this case I could likely  
come up with another one).

For those newly introduced elements in particular, authors need clear  
guidance on how to use them. My preference would be for us to drop  
these heuristic algorithms from the HTML5 draft and simply rely on a  
rigidly defined syntax for these particular specific data elements,  
but if we keep the heuristics authors need clear guidance on how to  
use them and how to use the alternate non-heuristic approach.

Take care,
Rob


On Jan 30, 2009, at 5:47 PM, Robert J Burns wrote:

>
> Hi Ian and Mike,
>
> On Jan 29, 2009, at 3:15 PM, Ian Hickson wrote:
>
>>
>> On Thu, 29 Jan 2009, Michael(tm) Smith wrote:
>>> [snip]
>>
>> Assuming the above audience statement, I have the following review
>> comments:
>>
>> * I don't think we need to include the obsolete elements, since  
>> they're
>> not needed for conformance (by definition).
>
> However, I think as Roy has suggested calling out specific elements  
> and attributes as deprecated will help authors (some of whom will be  
> familiar with previous HTML specifications).  It would also be  
> helpful to explain to authors what HTML5 norms expect to replace the  
> usage of those now deprecated features. For example (since we've  
> been discussing the name attribute) explaining that 'id' should be  
> used instead of 'name' in those places where 'name' is deprecated  
> (perhaps calling out the 'param' and 'meta' elements and other  
> places where it still applies).
>
>> * I don't think we should include <canvas>, since just saying the  
>> element
>> exists doesn't really help authors without its API.
>
> Mike has already addressed this and I agree with him. Just like any  
> other element, it is important for authors to understand the  
> semantics of the element independent of the other norms required to  
> use that element for its intended purpose. Normative and informative  
> references should be made to guide authors to resources to fully use  
> the 'canvas' element.
>
>> * The comments I gave in
>>    http://lists.w3.org/Archives/Public/public-html/2009Jan/0386.html
>> ...apply; my preferred way of addressing those comments would be  
>> making
>> the draft non-normative and then using formalisms only where it  
>> helps,
>> instead of attempting to be comprehensive.
>
> I think the formalisms are useful and highlighting norms that are  
> not expressed in the formalism helps authors supplement the machine  
> conformance checking with the greatest ease. An index of  
> specifically  non-machine norm criteria would be helpful as well.
>
>> [snip]
>>
>> * The spec has some implementor-specific terminology like "view" and
>> "browsing context".
>
> Those are important parts of the document conformance criteria. If  
> the target attribute accepts the name of a browsing context, how can  
> the draft explain the semantics of the target attribute without  
> discussing browsing contexts. The processing of browsing contexts is  
> left to the implementation norms, but the norms surrounding the  
> invocation of a browsing context has to be discussed among the  
> document norms. Informative (non-normative) examples of browser  
> context processing would also be helpful here (e.g., "a browser  
> MIGHT" as opposed to may, should or must).
>
>> * The spec doesn't define for authors how relative URLs are resolved.
>
> I agree this is important. Or from an authoring perspective it  
> should describe how to construct a relative IRI reference that will  
> be resolved as the author intends.
>
>> * I like the way all the information one needs about an element is  
>> all in
>> one place (including text/html-specific things like optional end  
>> tags).
>> I think it would be helpful to also include the element-specific  
>> APIs,
>> so that authors don't have to go to yet another reference for those.
>
> I agree with this too. Especially since so many elements have very  
> similar DOM interfaces, calling out the differences takes very  
> little exposition (colSpan long for colspan content attribute). And  
> for those elements where the DOM interfaces that are more elaborate,  
> these elements also usually have significant reliance on the  
> interfaces (e.g., 'form', 'canvas', 'input', though less so 'table'  
> and table related elements). The data types for DOM attributes also  
> help understand the meaning of corresponding content attributes  
> (such as the content attribute defer='defer' as a DOM boolean  
> attribute).
>
> Take care,
> Rob
>

Received on Saturday, 31 January 2009 00:19:44 UTC