[whatwg] Comments on Web Forms 2.0

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'