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

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 Friday, 30 January 2009 23:48:32 UTC