Re: 3.6. The root element

On Mon, 30 Jul 2007 19:37:00 +0200, Robert Burns <rob@robburns.com> wrote:
> I think the problem Ben is pointing out is that the last three  
> paragraphs of the root element subsection (one normative paragraph and  
> the two "green" notes are very unclear. (for authors and UAs). I think  
> those should be rewritten into a single coherent paragraph that  
> addresses the attribute names "xmlns" or "xmlns:*".

It seems you're misunderstanding what this is about as well. The draft  
points out that for _HTML documents_ (solely text/html) the HTML element  
may have an attribute xmlns specified that has the literal value  
http://www.w3.org/1999/xhtml. The note then goes on to point out that this  
xmlns attribute, when specified, is different from the identically named  
attribute in the XML serialization.

It would be nice of course if everyone reading the draft would understand  
this immediately and if there are suggestions that would enable that I'm  
sure the editor would consider them. Personally I'm not really sure how it  
can be made more clear.


> Instead of just not requiring those attributes, we could also require  
> those attributes have author specified values. We could give advice to  
> authoring UAs that they should retrieve the values from these either  
> from their own preferences or from the system preferences for the  
> author. Every author has a primary language set in their operating  
> environment or in their authoring tool environment. That language has a  
> directionality. Those attributes can easily be set from that  
> information. Providing a dialog on "new" can also help the author change  
> those values on a case-by-case basis.

That is exactly why we should not do this. Most things I write are either  
in Dutch or English. If some editor picked my system preferences I would  
always write in English. (In case the suggestion comes up, I'm not  
switching the language of the spell checker (if enabled at all) each time  
I write something.)


>> Specifications are meant to cover the nasty little details. If a  
>> specification were just an authoring guide it wouldn't be of much use  
>> to picky authors who'd like to know how things are actually working.  
>> You'd just have another HTML 4.
>
> Certainly, specifications cover the nasty details. However those details  
> can be covered from multiple perspective. Right now the draft only  
> presents those nasty details from the UA perspective and not the author  
> perspective. We should not shy away from presenting both perspective.

Actually, what was discussed at the top of this e-mail (and what I was  
referring to) is an authoring detail.


> For example, in the microsyntaxes section the current draft explains to  
> a UA how to parse out various data types given a string. We should also  
> provide normative language for authors to create such a string that will  
> contain the authors intended data types. This doesn't have to be written  
> in less detail.

The draft does define what constitues a valid time string for instance in  
as much detail as how the UA has to parse them as it uses the same  
algorithm to do so. I suppose tutorials or maybe an introductory section  
in the specification can make this easier to comprehend.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 31 July 2007 09:05:24 UTC