[whatwg] Comments and questions on Web Apps 1.0

[Henri Sivonen]

Based on the 2006-02-24 version.

1.1.
Mac OS X not MacOS X

2.2.5.
'Should textContent be defined differently for dir="" and <bdo>?  
Should we come up with an alternative to textContent that handles  
those and other things, like alt=""?'

Messing with the Core API seems like a bad idea. Having an  
alternative that handles alt would be useful to have, though.

2.2.7.
"For example, if an HTML implementation also supports SVG, then the  
Document object must implement HTMLDocument and SVGDocument."

For text/html?

2.2.7.
What does "when used as global attributes" mean in this foreign  
namespace context?

2.2.8.
"The nodes representing HTML elements in the DOM must implement, and  
expose to scripts, the interfaces listed for them in the relevant  
sections of this specification. This includes XHTML elements in XML  
documents, even when those documents are in another context (e.g.  
inside an XSLT transform)."

I can see why implementing the interfaces in XSLT transforms is  
allowed but why required?

2.2.8.
Is localName supposed to return in lower case? Would make sense.

2.3.1.
Since blockquote is so abused that it is useless for AI, allowing  
attribution within the blockquote would be practical.

2.3.2.
I suggest making the allowed inter-element whitespace consistent with  
the definition in XML and adding tab.

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?

2.3.3.2.
The spec should probably say here that structured inline content is  
mostly incompatible with the HTML serialization.

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?

2.3.4.
"defines rendering in terms of those property."

properties

2.3.4.
"The value must be a list of zero or more words (consisting of one or  
more non-space characters) separated by one or more spaces."

Firefox and Opera allow any whitespace (space, tab, CR and LF). Are  
spaces before and after allowed (works in Safari, too)? Anyway,  
considering all non-space characters part of the class names is not  
interoperable.
http://hsivonen.iki.fi/test/wa10/datatypes/class.html

I'd prefer separated by one or more whitespace characters with zero  
or more whitespace characters before and after allowed. (In general,  
whenever there's a list of something in an attribute value, this kind  
of conventional separation would be preferable from my point of view.  
Less need for custom datatypes. :-)

2.4.
"The profile attribute must, if specified, contain a list of zero or  
more URIs (or IRIs) representing definitions of classes, metadata  
names, and link relations."

Separated how? Do the URIs/IRIs have to be absolute?

2.4.
Is the whole profile thing useful? Wouldn't it be enough to go with  
class names that are announced at microformats.org, tantek.com, etc.  
and do away with namespace-esque profiles that authors don't seem to  
care to use anyway?

2.4.
Do hCal and hCard class names require a profile if used inside the  
calendar and card elements?

2.4.
"So as to avoid this problem, authors are encouraged to avoid using  
multiple profiles."

That doesn't look like practical advice.

2.4.4.
"One element can create multiple links (of which some might be  
external resource links and some might be hyperlinks). User agents  
should process the links on a per-link basis, not a per-element basis."

Does that refer to multiple rel values?

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.

2.4.5.
"and the http-equiv attribute must be listed first in the source."

That requirement violates the general convention that the source  
order of attributes does not matter. Firefox, Safari and Opera work  
either way. (Can't test IE.)
http://hsivonen.iki.fi/test/wa10/encoding-detection/c-iso-8859-2-with- 
reversed-attribute-order.htm

2.4.5.
"In XHTML, the XML declaration should be used for inline character  
encoding information, if necessary.

Authors should avoid including inline character encoding information.  
Character encoding information should instead be included at the  
transport level (e.g. using the HTTP Content-Type header)."

Since XML is mentioned, it would be good to mention that on the XML  
side, using an application/* type without the charset parameter and  
leaving the detection to the XML level is the best practice.

2.4.6.
Is rel='alternate stylesheet' without a title non-conforming?

2.5.9.
Are header and footer required to be the first and last element child  
of section if present?

2.5.11.2. & elsewhere
Minor typographical nit: hyphen instead of en dash used in "h1-h6".

2.9.1.
Just noting that media, type and hreflang that are pertain the  
resource identified by href are specced to be allowed without href.

2.9.1.
"The value must be a valid RFC 3066 language code. RFC3066 "
[] missing around RFC3066.

2.9.1.
ping attribute: again, why spaces instead of XML-style whitespace?

2.9.1.
If the server sends an entity body in response to a ping, the UA may  
close the connection, right?

2.9.2.
Should probably say something about the default rendering of q.

2.9.3.
In my opinion, marking up names of people and works in the same does  
not fit conventional presentational practice. On the other hand,  
using cite only for source citations causes different titles of works  
to be marked up differently. Using <cite> as a generic "title of  
work" could be marginally useful for styling. Is there any evidence  
that the way <cite> is currently defined is useful for any application?

I still think <cite> fails the "explaining to mother" test.
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005- 
August/004649.html

2.9.5.
"Changing the importance of a piece of text with the strong element  
does not change the meaning of the sentence."

This looks a bit weird after reading the examples for <em>.

2.9.6.
"The small element does not "de-emphasise" or lower the importance of  
text emphasised by the em element or marked as important with the  
strong element."

How does that relate to practice?

2.9.7.
"Should we just repurpose u or b for this semantic instead? What  
would they stand for?"

I think u would suit the purpose. It could stand for underline. :-)  
The UA style sheet rule could be prescribed so that authors would  
know how to turn the underline off and use another kind of highlight.

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

2.9.11.
What's the use case of the t element?

2.9.18.
"For example, it would be inappropriate for the sup and sub elements  
to be used in the name of the LaTeX document preparation system."

I have a CSS implementation of the LaTeX logo that could be used as  
an in-prose example in that sentence. See the footer of http:// 
hsivonen.iki.fi/os-x-browsers/

2.9.18.
"Mathematical expressions often use subscripts and superscripts.  
Authors are encouraged to use MathML for marking up mathematics, but  
authors may opt to use sub and sup if detailed mathematical markup is  
not desired. [MathML]"

It would be useful to have some guidance for XHTML5 and MathML  
integration. Should the math element in the http://www.w3.org/1998/ 
Math/MathML namespace be considered strictly inline content  
regardless of the mode or display attribute? It probably should. (It  
would be semi-plausible to consider display math block and structural  
inline content, but the MathML spec implies that those attributes are  
presentational and CSS can be used instead.)

1.14.1.
"When the src  attribute is set, the script element refers to an  
external file, which must (if it uses a supported scripting language)  
be downloaded and executed."

Does disabling scripting make the scripting language unsupported for  
the purposes of conformance requirements or should the spec state the  
obvious here?

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