[whatwg] Comments and questions on Web Apps 1.0

Henri Sivonen hsivonen at iki.fi
Sun Jul 27 07:16:41 PDT 2008


On Jul 26, 2008, at 01:44, Ian Hickson wrote:

> On Fri, 17 Mar 2006, Henri Sivonen wrote:
>> 2.2.8.
>> Is localName supposed to return in lower case? Would make sense.
>
> I've removed localName from the list of attributes that do case- 
> fixing.

Thank you!

>> 2.3.1.
>> Since blockquote is so abused that it is useless for AI, allowing
>> attribution within the blockquote would be practical.
>
> Attribution isn't part of a quote. How would you distinguish quoting  
> an
> attribution from quoting text with an attribution from quoting text  
> that
> happens to have its attribution?

Quotation marks:
<BLOCKQUOTE><p>“There’s just no nice way to say this: Anyone
who can’t make a syndication feed that’s well-formed XML
is an incompetent fool.——Maybe this is unkind and elitist
of me, but I think that anyone who either can’t or won’t
implement these measures is, as noted above, a bozo.” –
<A HREF="http://www.tbray.org/ongoing/When/200x/2004/01/11/ 
PostelPilgrim">Tim
Bray</A>, co-editor of the XML 1.0 specification</p></BLOCKQUOTE>

>> 2.3.2.
>> "The SVG specification defines the SVG foreignObject  element as  
>> allowing
>> foreign namespaces to be included, thus allowing compound documents  
>> to be
>> created by inserting subdocument content under that element. This
>> specification defines the XHTML html element as being allowed where
>> subdocument fragments are allowed in a compound document."
>>
>> What about Atom-style fragments without the html element?
>
> What about them?

Fixed in the next paragraph already--presumably in response to similar  
feedback from gsnedders.

On the topic of foreignObject: Shouldn't HTML5 actually *disallow*  
<html> as a child of <foreignObject> and make the content model of  
foreignObject equivalent to the content model of <body>? The commented  
out SVG-in-text/html functionality doesn't support <html> as a child  
of <foreignObject>.

>> 2.3.4.
>> "When an element has an ID set through multiple methods (for  
>> example, if it
>> has both id and xml:id attributes simultaneously [XMLID]), then the  
>> element
>> has multiple identifiers. User agents must use all of an HTML  
>> element's
>> identifiers (including those that are in error according to their  
>> relevant
>> specification) for the purposes of ID matching."
>>
>> What does this mean in terms of document conformance?
>
> n/a (is the current text ok?)

It's OK for the multiple ID issue. However, this sentence is known to  
be confusing: "The value must be unique in the subtree within which  
the element finds itself and must contain at least one character." It  
should say that the ID must be unique within all nodes that are  
inserted into a document, a document fragment or an interconnected set  
of nodes that live outside a document or document fragment.

(I think I should remove xml:id support from Validator.nu anyway.)

>> 2.4.5.
>> "To set metadata with meta elements, authors must first specify a  
>> profile that
>> defines metadata names, using the profile attribute."
>>
>> In my opinion, it would be useful to predefine the traditional  
>> names and
>> Dublin Core.
>
> This can now be done in the wiki.

I'd like to withdraw my suggestion to predefine Dublin Core. DC  
metadata in HTML is worse than useless: Some DC metadata elements  
duplicate HTML and HTTP information but as "invisible" metadata and  
the others are too vaguely defined to be useful on the Web scale.

>> 2.9.10.
>> I suggest the definition of i be changed to "The i element  
>> represents anything
>> that is italicized in conventional typography." That's pretty much  
>> the only
>> real world-compatible definition.
>>
>> Also, I suggest b be included in the spec and defined as "The b  
>> element
>> represents anything (except headings) that is set in bold face in  
>> conventional
>> typography."
>
> Is the current text ok?

Yes, except the advice "The i element should be used as a last resort  
when no other element is more appropriate. In particular, citations  
should use the cite element, defining instances of terms should use  
the dfn  element, stress emphasis should use the em  element" may not  
be respectful of the authors' time in the absence of concrete benefits  
for justifying the advice (other than future potential for  
unconventional styling).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/





More information about the whatwg mailing list