[whatwg] Comments on Web Forms 2.0
ian at hixie.ch
Tue Dec 28 05:53:03 PST 2004
On Tue, 28 Dec 2004, Henri Sivonen wrote:
> On Dec 9, 2004, at 03:19, Ian Hickson wrote:
> > On Mon, 6 Dec 2004, Henri Sivonen wrote:
> > > > This is incorrect, U+FEFF is a valid character in its own right
> > > > (albeit deprecated in favour of U+2060) and is only the BOM if
> > > > found at the start of a string.
> > >
> > > Isn't it the point of deprecation that implementors may opt not to
> > > support deprecated stuff?
> > It depends (the word "deprecate" doesn't imply this on its inverse;
> > you have to check with each instance of a deprecation to find what the
> > case is). However, in many cases, as, I believe, with U+FEFF,
> > deprecation is intended to discourage potentially harmful or confusing
> > use, without breaking backwards compatibility with existing content
> > (and thus still requiring it of implementations).
> According to http://www.unicode.org/faq/utf_bom.html#38 a data format or
> protocol may choose to ignore the BOM in the middle of a string.
HTML doesn't choose that, though, so that isn't relevant to us. (Thanks
for the pointer, though.)
> Anyway, I'm still uncomfortable with using a deprecated character that
> has a very special other meaning as a magic marker in WF 2.0.
I'm not overjoyed with it myself, but I haven't got any better ideas. The
current system works quite well, and certainly works better than the ""
prefix that I first suggested. Do you have a better idea?
> > > (Still, limiting the choice of syntactic sugar in the submission
> > > format has the feel of Appendix C to it.)
> > There aren't really any restrictions beyond not breaking XML 1.0 rules
> > and being compatible with both non-namespace-aware and namespace-aware
> > parsers. Which, of the remaining restrictions, did you want to remove?
> In principle all restrictions on the choice of syntactic sugar, but I
> guess it is now good enough for practical purposes.
As far as I can tell the only restrictions now are about not using a
prefix, which we need to have to handle non-namespaced servers easily.
> > > > The spec doesn't say what the recipient is supposed to do with
> > > > _recognised_ elements or attributes, either. What servers do is
> > > > pretty much up to the servers, not much we can do about it.
> > >
> > > Attempts to influence the ad hoc works of the ViewSourceClan might
> > > indeed be futile. However, what you write in the spec could
> > > influence what the developers of server-side frameworks (eg. Struts)
> > > do.
> > It could, I guess. Did you have any particular ideas in mind? I don't
> > really know what to add.
> I had a general "must ignore unknowns" rule in mind. For unknown
> elements, treat as if the start and end tags were not there. After this,
> ignore text children of the submission element. Ignore unknown PIs.
I've added a note that gives a suggestion on how to handle unexpected
content. Let me know if you think that's ok. I don't think making it
normative makes any sense; it's not like we can do anything to ensure
compliance anyway, so making it law would only serve to create a
generation of law-breakers (as it were).
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg