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

I just want to prefix this by saying that I'm not trying to make any 
recommendations here, I'm just trying to explore options. Some people have 
misinterpreted my earlier comments -- I'm not suggesting that we 
necessarily take the WHATWG work as a base, and I'm not saying we should 
_not_ take the WHATWG work as a base. I have offered to be editor in the 
case where the WHATWG work is indeed taken wholesale (so that I can ensure 
the two stay identical), and I've committed to ensuring that the WHATWG 
work, if not taken directly by the HTML WG, remains nonetheless compatible 
with the HTML WG's work. I haven't volunteered to act as editor for HTML 
WG specifications if the WHATWG work _isn't_ used, because I couldn't do 
it. My full time job is to edit the WHATWG spec, I would not physically be 
able to do that job twice over and still get to sleep.

Anyway, moving on:

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


> Just from the top of my head, e.g. a declarative way to show error 
> messages in arbitrary locations, instead of having to use Javascript. Or 
> to show them in two locations, both at the invalid controls and in a 
> summary at the bottom close to the submit button, with links to the 
> invalid controls. Backbase has customers who want that.

Certainly there are many features that were not included in the WF2 draft; 
the specification intentionally limited the number of new features so as 
to not make the specification intractable.


> 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?

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'