Re: brainstorming: test cases, issues, goals, etc.

Ian Hickson schreef:
> On Thu, 15 Mar 2007, Laurens Holst wrote:
>   
>> Well, to me, having say a list of 30~50 individual items would seem like 
>> it would actually be fairly easy to work with, from an organisational 
>> perspective. You could just take them on one by one, because of their 
>> advanced nature most won’t get too much comments. E.g. the HTML 
>> parsing rules don’t leave much to complain about I’d say, and 
>> they’re a big chunk of the spec.
>>     
>
> Note that it really isn't that easy. For example, the HTML parsing rules 
> are deeply integrated with the handling of <script> elements, due to 
> document.write(), and also are deeply integrated with the definition of 
> innerHTML. Scripting, in turn, is deeply related to the concept of 
> scripting contexts, which depends directly on the definition of the Window 
> object and browsing contexts, which, in turn, are deeply linked with 
> session history and the History object (which depends on the Location 
> object) and with arbitrary browsing context navigation (which is related 
> to hyperlinks and image maps) and its related algorithms (namely content 
> sniffing and encoding detection, which, to complete the circle, is part of 
> the HTML parsing algorithm).
>
> How would you handle such interdependencies? (They run deep in the WHATWG 
> specification text, and are, in my opinion, unavoidable, assuming we want 
> to write realistic specifications that match existing implementations.)
>   

I don’t know the spec well enough to answer that question, but I’d say 
modularisation (if I may call it so) would make it both easier to grasp 
as individual chunks, for both the reviewing process and the 
implementing process. A ‘HTML parsing rules’ section I already seemed to 
be missing :). If there’s interconnection, one could cross-reference.

But maybe the HTML parsing rules isn’t such a good example for a 
separate ‘module’. But I do think a more structured approach than just 
importing the spec and saying ‘well, comment away’ is a good idea.

Oh, btw, I just saw this note in the document.write section: "bz argues 
that innerHTML should be called something else on XML documents and XML 
elements. Is the sanity worth the migration pain?"; my answer: no, in 
XML you have the DOM methods and innerHTML is the quickest road to 
unpredictable bugs. If it must be there, let it be there, but avoid it, 
and certainly don’t rename it because that would beat the whole purpose 
of having it in the first place. In fact, maybe it should accept HTML, 
not XML. But anyway, digression :).

Another digression, quote: "case-sensitivity is a very poorly handled 
topic right now"; I don’t know if you know this already, but in IE 
setAttribute’s name parameter does not accept the attribute name, 
instead it takes the DOM property name. domNode.setAttribute('htmlFor', 
value) → works, domNode.setAttribute('for', value) → doesn’t. Others 
affected are accessKey, acceptCharset, readOnly, tabIndex, etc. And I 
don’t even want to talk about attributes which can only be created 
functionally if an incorrect createElement parameter syntax is used, or 
crashes when you insert option elements into a select using the Core DOM 
methods.

>> Also, Web Forms 2.0 has no ‘valid’ event counterpart of the 
>> ‘invalid’ event, and the ‘invalid’ event itself is 
>> underspecified.
>>     
>
> Could you elaborate on how it is underspecified?

Well, it doesn’t say which event type interface it belongs to for one. I 
assume it’s the Event interface, like the ‘DOM0’ event types, but 
UIEvent seems more logical. The ‘(with no namespace)’ remark seems 
pointless because DOM level 2 Events has no knowledge of namespaces, and 
DOM level 3 Events as a specification does not exist, it is only a note, 
and one incompatible with DOM level 2 Events to boot (why is it 
referenced at all, it can’t be implemented!). I also think invalid 
deserves a specific subsection with some definitions a la [1] or [2] and 
links to the DOM spec. Something better than [3], which mixes event 
description with form validation process definition, and does all that 
in prose.


~Grauw

[1] http://www.w3.org/TR/2007/WD-xforms11-20070222/#evt-valid
[2] http://www.whatwg.org/specs/web-forms/current-work/#receiving
[3] http://www.whatwg.org/specs/web-forms/current-work/#invalid0

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.