Re: Substantive comments on Proposed XHTML Module: Web Forms 2.0

Hi Ian, 

This message is just a reply to your previous comments, and not a 
comprehensive re-review of the latest draft. Having said that, when I do 
refer to the current draft, I'll mean the version dated 15th January 2004. 
Original section numbers still refer to the draft of 25th December, numbers 
following in brackets, where used, refer to the current draft. 

>> # Abstract
>> # 1. Introduction
>> # 1.1. Relationship to HTML
>> [Applicability to HTML user agents]
> Agreed. I have added new sections and expanded the existing ones.  Please
> let me know if the new text is clearer or still needs work, in your
> opinion.

That's much clearer now (though the title of the document is still 'Proposed 
XHTML Module: ...'; I suppose that can't be helped). 

>> I would then add, as the first 'requirements' bullet point in the
>> Introduction, "Applicable to both HTML and XHTML User Agents",
> I disagree that this should be a design requirement. There are some
> features in particular which only apply to XHTML (and can't apply to HTML
> since the parsing rules there are much less tractable).

Agreed, on reflection. It's not so much a requirement as a pre-condition or 
assumption, anyway. In any case, the changes to the rest of the introduction 
mean that this isn't important now. 

>> # 2. Extensions to form control elements
>> You mention that empty <form> elements can now be contained within the
>> <head> element of XHTML (and presumably, HTML?) documents, though you do
>> not later describe the modified content model for <head>.
> Fixed.

I was expecting to see this in the table in Appendix A, but I see you've 
just added it to the prose following. I guess that's ok, because the text in 
the prose couldn't easily be expressed as a table. 

However, you do introduce the table with 'Specifically, the Forms Extensions 
Module supports:', which did seem to me to suggest that the table was a 
comprehensive list. 

>> You also mention nested forms a few times, but you don't describe what
>> the expected behaviour (or indeed, the point!) of a nested form would
>> be. [...]
> This should be clearer now.

The behaviour is clearer, but there's still no rationale. Is this change 
purely to relax where <form> can appear? A nested form does not have any 
semantic value or additional behaviour - is it just that it's harder to 
prevent nesting than to allow it? 

>> # 2.1 Extensions to the input element
>> # time input type
>> Why does the 'time' type only contain hours and minutes, and not seconds?
> Because in my experience, almost all sites on the Web that have time
> fields only ask for hours and minutes. Indeed the only site I can recall
> seeing with a seconds field basically forced it to 00!

Ok then, conversely: Why does the 'datetime' type contain a seconds field? 
:) 

>> # email type
>> Strictly speaking, removing the FWS and CFWS tokens from the addr-spec
>> grammar prevents odd, but valid, email addresses such as "foo
>> bar"@example.org from being valid, from what I can see.
> Good point. I've made the exclusion slightly more surgical so as to not
> exclude any valid addresses but still exclude comments.

Ok, but note that now the range of valid email addresses doesn't actually 
match anything in RFC2822, so the text 'An e-mail address, as defined by 
[RFC2822] [...]' isn't entirely accurate. 

>> # 2.5. Extensions to existing attributes
>> # maxlength attribute
>> I can see why the decision was made, but it does seem odd to prevent
>> maxlength from applying to the integer input type.
> Allowing it wouldn't allow anything that "max" and "precision" don't
> control, and would be somewhat strange.

Agreed completely, though 'precision' wasn't in the version I originally 
reviewed ;) 

>> [maxlength should apply to the email type]
> Ugh. I guess. Do I have to support that? I don't want people being
> "helpful" and adding limits for no reason.

Yes please. For example, bugzilla seems to limit email addresses to 25(!) 
characters. If they converted to using <input type="email"> they'd still 
want to enforce this limit on the client (as well as the server, of course - 
the client just allows immediate user feedback). 

>> # readonly attribute
>> [...]
> There is no such thing as a readonly check box or radio button. Look in
> any GUI manual.

Yes, I got confused between readonly and disabled. Ignore that. 

# select editable 

I said earlier that I wouldn't re-review the new draft completely, but I 
have noticed that you've removed the 'editable select'. That's a pity, as I 
thought that was one of the more promising parts of the draft - did you run 
into a problem somewhere? 

>> # 5.5.7. [5.6.7] For javascript: actions
>> # For the POST action
>> Are there security considerations in allowing the form data to add
>> variables to global scope? For example, non-replaceable properties.
> I am not aware of any.

There shouldn't be, now; the clarification you made clearly states that the 
form data object is added to the scope chain, and not, as I originally 
thought, replacing the properties in the 'default' global scope. 

>> # 6.1. [6.2] Seeding a form with initial values
>> Is it allowable to specify that we can process only certain 'subsets' of
>> XML? See TAG issue xmlProfiles-29:
>> http://www.w3.org/2001/tag/issues#xmlProfiles-29
> That isn't specified, is it? The UA is expected to be a fully conformant
> XML UA. Or did I accidentally profile XML...?

Ah, no, you didn't. I thought you were prohibiting PIs and CDATA blocks, but 
you're not, you're ignoring them, so that's ok. 

>> # 6.2. [6.1] Filling select elements
>> Should the UA also ignore PIs and so on, as per 6.1, when reading XML
>> for the contents of select elements?
> The current algorithm does actually say this. :-)

I assume you're referring to step 3 ('All nodes outside the select are 
ignored [...]'). I'm not sure how an XML file can ever have nodes 'outside' 
its root element, but then I'm not an expert. Perhaps some clarification 
here? 

What is the point of 'select.data = select.data;' in the example? Is it a 
mistake, or is there some magic I'm missing here? 

>> How should an author determine whether the client UA supports this
>> specification? The natural way would be to provide a feature to be
>> tested via the hasFeature method of the DOMImplementation interface,
>> though that assumes that the client has scripting capability.
> This is a good question. I don't know. Ideally a UA needs to be detected
> on the server side ("does it support data= or not?"). I have no answer for
> this at the moment. Suggestions welcome.

Well, maybe DOMImplementation.hasFeature? ;) 

I know it's not perfect. See for example, this quote from, er, yourself: 

# This is exactly the problem that DOM authors that use hasFeature()
# have run into. UAs claim to implement, say, DOM2 Core, but don't
# support getAttributeByNS() correctly.
# -- http://lists.w3.org/Archives/Public/www-style/2004Jan/0001.html 

However, it is a good start. If hasFeature() returns false, it's reasonable 
to assume that the UA doesn't support the spec, since hasFeature() is one of 
the easiest things to implement. Detecting bugs in implementations can then 
be left to browser sniffing scripts (client- or server-side). 

I don't think we need to announce support for this spec via the HTTP 
headers, and I can't think of many other options. 

> [...] When the draft is next stable, I'll mention it on my blog
> (and hopefully other, more public places) again.

I'm planning to do another comprehensive review once the draft is next 
stable. 

Regards,
Malcolm

Received on Tuesday, 20 January 2004 09:54:50 UTC