- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 06 Jul 2005 09:37:27 +0200
* Ian Hickson wrote: >> 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 intent is for it to go to http://example.org/y/. I'd suggest to include an example to this effect. >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. You could add a note that any string that matches the IRI token is valid even if the string fails to satisfy other applicable requirements such as scheme-specific syntax constraints, e.g., per RFC 2616, http://x:y@ example.org/ is not allowed but would be valid for the purposes of the specification. If that's desired. >> 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. http://www.w3.org/TR/charmod/#sec-Checklist has a list of requirements, it'd be a good idea to review the draft against it if you haven't done so already. >> 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? I think media ranges are quite useless for e.g. http://validator.w3.org since it basically supports any XML document and text/html documents... It seems the draft considers accept="*/*" invalid yet implementations must assume this value if the value is invalid. It also does not define whether parameters like ;charset=... are allowed. It would be good to have a clear production rule here. >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. I'd suggest to include such examples in the document. -- Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de 68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
Received on Wednesday, 6 July 2005 00:37:27 UTC