- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 6 Jul 2005 02:11:36 +0000 (UTC)
On Tue, 5 Jul 2005, Bjoern Hoehrmann wrote: > > As promised, I had a quick look at "Web Forms 2.0" as of July 3 2005, > <http://www.whatwg.org/specs/web-forms/current-work/>. Just some rough > notes though, hopefully they are of any use. Indeed they are! Thank you very much. A diff of the changes from the version of the 3rd to today's version is available at: http://www.whatwg.org/specs/web-forms/current-work/diff-2005-07-03 > The document fails to discuss how web forms are to be implemented in an > environment that supports e.g. XHTML + SMIL Unfortunately I am not familiar with SMIL and have no idea what needs to be said to address this. I couldn't find anything in SMIL 2.1 that said how specification authors were to specify how their spec interacts with SMIL, either. > for example, it is unclear which attributes may be target of which kind > of animation I have no clue. What's the simplest answer that is still useful? > how linear and paced interpolation of conceptually numerical values is > to be performed Can SMIL address DOM attributes separately from content attributes? Can it treat attributes as strings yet still do numeric manipulation on them? (e.g. to increase a "title" attribute's value from "0" to "100".) What is the simplest answer here? Since some of the attributes have different types at different times it seems like it might be best to just say that they are all strings; is that possible? > how presentation values affect the processing model (e.g., if the input > name attribute can be animated, would submission use the presentation or > the underlying value?) What is a "presentation value"? Web Forms relies on HTML4 for the definition of "control name" and "control value"; those are defined in terms of the element's attributes (which is what you get if you use getAttribute(), and what CSS matches against). Does SMIL define how animation interacts with these DOM Core features? > and how timing attributes affect the processing model (e.g., can a form > control that is not active be successful?) SMIL can't discuss this, so > this must be defined either by the markup specification or some third > compound document specification. "Sucessful" is defined exactly: http://whatwg.org/specs/web-forms/current-work/#successful ...so this seems well-defined to me. (Namely, SMIL doesn't affect this.) > Note that there have been attempts to define this to some extent for > features in HTML 4, > > http://www.w3.org/TR/1998/NOTE-HTMLplusTIME-19980918 > http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ > > and there are implementations for parts of these. I couldn't really see answers to any of your questions in those documents, unfortunately. They mostly seem to be about how to add SMIL attributes and elements to HTML. > Section 3.6.1 item #16 is > > An added event in the http://www.w3.org/2001/xml-events namespace, > which bubbles but is not cancelable and has no default action, is > fired on the repetition template with the repetition block's DOM > node as the context information. > > It is unclear why the event is not a form event as discussed in section > 4 of the draft; I've clarified what the list of form events is supposed to be and added a note saying that repetition events aren't form events. (Not that it makes that much difference in WF2.) > it is further not clear which interfaces event objects of this type > would implement Clarified. > or how the context information should be set. Clarified. > The note in section 4.3. includes a data: URL with illegal syntax, URLs > must not include unescaped "<" or ">" characters. Fixed, but now it's a lot less clear what is going on. :-) > The note in section 3.6.4. appears to state conformance requirements; > that part of the document should either be normative or rephrased to use > more appropriate terminology. Made normative. > Section 2.16 notes > > The form element's action attribute is no longer a required attribute. > Authors may omit it. When the attribute is absent, UAs must act as if > the action attribute was the empty string, which is a relative URI > pointing at the current document (or the specified base URI, if any). > > The implications of this are unclear. For http://example.org/x/ > > ... > <form action="" xml:base="http://example.org/y/" ... > ... > > where will the submission go to? The intent is for it to go to http://example.org/y/. > Note that the term "relative URI" is not defined in RFC 3986, the > correct term would be "relative reference". Also note that RFC 3986 made > "clarifications" to the relevant algorithm, RFC 2396 did not really > define the target URI in this case, it just defined the resource as > same-document reference which was commonly taken to mean the document > URI, while per RFC 3986 the target would be the base URI. Ok... How should I fix this? I've tried to clarify it, let me know if my attempts were good enough or if you think it should be changed further. > Validation requirements for type="url" seem to be undefined. The draft > notes that only strings matching the IRI production are allowed, does > that mean that non-conforming IRIs that match that production are > allowed? (E.g., RFC 3987 also requires that IRIs are in full logical > order). Is there any way for the UA to tell if the IRI is not in logical order? I don't really know what to change to satisfy your comment here. The value format for type="url" is defined (the IRI token); processing is defined in terms of whether values match the format. > The XML reference is outdated. Fixed. > The Unicode reference is probably outdated. Fixed. (Boy is that one complicated.) > The CSS3UI reference is outdated. Fixed. > The reference to charmod is outdated. Fixed. > The document does not conform to http://www.w3.org/TR/charmod/ (e.g., > content is not required to conform to charmod in order to conform to the > specification). Fixed. Well, that is fixed. I don't know if there are any other problems. > Section 2.6 notes > > Authors who wish to allow for any input so long as a particular string > occurs somewhere in the input should put .* at the start and end of > their pattern. If the input is expected to allow newlines, then > [\x000000-\x10FFFF]* or [\s\S]* or some equivalent should be used > instead, since the dot character in JavaScript regular expressions > does not include newlines. > > I do not know about JavaScript regular expressions, but in ECMA-262 the > [\x000000-\x10FFFF]* is not suitable here, \x can only be followed by > two hex digits, so this should probably be [\u0000-\uDBFF\uDFFF] (as the > \u escape is limited to four digits, so you need to use surrogates). Fixed. (Just removed that suggestion and left only hte \s\S case.) > Section 2.15 notes > > MIME types may have a subtype of *, ... > > They may not; HTTP uses the term Media Range for this. Fixed. > The draft is unclear about whether e.g. "application/xml" matches > "image/svg+xml". Yes. I'm not sure we want to define this at this time, at least not in this spec. What do you think? > The document lacks a section on security considerations. There are a few > security notes in the document, but in general the discussion is very > incomplete. RFC 3552 provides guidelines for writing such text, in > particular, it should be pointed out which security considerations are > not discussed in the document because they are considered out of scope. Fixed. Any other suggestions you may have for that section are most welcome. > Section 2.4 notes > > Only absolute URIs and IRIs match the IRI token mentioned above. > Relative addresses are not valid values for this input type. > > This is incorrect, the IRI production extends beyond absolute IRIs, in > particular, absolute IRIs do not allow fragment identifiers while IRIs > do. It is unclear whether user agents may accept user input with > relative references or suffix references (e.g., "www.w3.org"); if this > is not allowed, or if implementations use incompatible algorithms to > turn such strings into IRIs, the input type is quite useless. Fixed. Let me know if that is clear enough. > Section 1.11. notes > > If extensions are needed, they should be done using XML, with elements > or attributes from custom namespaces. The use of extensions must not > contradict nor cause the non-conformance of functionality defined in > the specification. > > It is unclear what this means. Pity. It is lifted almost directly from the W3C QA Spec Guidelines, according to a comment I left in the source. :-) > The intent could be that implementations that ignore the extensions must > behave in pretty much the same way as implementations that process the > extensions; this is neither useful nor will extension writers care much > about this requirement. No, the intention is that extensions must not cause UAs to do things which directly contradict what the spec says. Like, it would be ok to include a new DOM attribute that returned the time it took the user to select the current value (say), but not ok to define a new control that would appear in the .elements array. > It is unclear how one would extend e.g. the input type attribute One would not. > There does not seem to be information about how display:none affects the > processing model, it is not clear whether user agents must not process > element with display:none in a special way or whether this is considered > out of scope of the draft. Some markup languages suggest that display: > none elements must be processed pretty much as if they were absent, so > if there is no such special processing, this should be pointed out. I see no reason to assume that display:none does anything. But I have added a note in section 8 about it. > The IDL fragments and interface definitions in the document are very > difficult to read, it would be much better if these used the DOM Level 3 > markup and style By and large I thought this was what I had done. Indeed much of the IDL is directly copied from the W3C DOM2 HTML specs. > linking interface member definitions from the IDL will also make the > document much easier to use. Yeah. Ok. Done. It's not perfect, because this spec doesn't define everything itself. It'll be better for WA1. > The bold/yellow background color style for subheadings in the IDL is > awful. Fixed. > It's not clear why the RFC1866 reference is normative. Mistake. Fixed. > The draft's use of U+FEFF is scary and IMO inappropriate. What would you suggest instead? U+FEFF has the nice property of being defined as being droppable at the start of a string, which is exactly what we do here, we drop it at the start (after taking its presence as a sign that we should avoid that attribute). I don't know of any other way of getting the same effect in a backwards-compatible way. > Its use of %% in data: submission is scary aswell. Yes. Do you have a better way of doing this? > Section 6.1. is non-compliant, select.data must be a URI or IRI but it > isn't (unless there are complex error correction mechanisms involved > when settting data, in which the example would still encourage in- > appropriate use) Fixed. > It's not clear whether the draft really does not normatively depend on > "Web Applications 1.0", it seems at least to make assumptions that are > not guranteed by the specification or its normative references, but I > did not study this in detail. It is intended not to rely on WA1, but eventually will be folded into it. Do you have any specific dependencies in mind? > (Note that "Web Applications 1.0" breaks in IE6 and FireFox, missing > sub-sections, content shifted outside the viewport, etc. might be due to > the use of incorrect HTML...) Odd, works for me. Can you reload and see if it got fixed recently? I've been editing that document a lot, you may just have hit a bad version. Thank you again for your comments. They have been invaluable. If you have any further comments, please let me know. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 5 July 2005 19:11:36 UTC