Cart
[Home] [By Thread] [By Date] [Recent Entries]
Dave, I think there's no question about control, sadly. I can see some disadvantages with predefining namespaces by default, chief among them being things like determining whether <html:input> vs. <xforms:input> was in force in a given document for the <input> element. My suspicion is that the answer from the WHATWG side was that XForms is not considered to be a a part of HTML 5, therefore, no ambiguity arises. I'd say that what we have here is a schism. The HTML side doesn't like namespaces in part because they add to the complexity of JavaScript code (and JavaScript code doesn't have an intrinsic notion of namespaces, something which would have been rectified with ES4 before ES4 was wiped out as part of Harmony). The presumption throughout on the HTML side is that as a language it is near perfect, and only needs a few minor tweaks before it is completely self-sufficient. For those of us who DO actually work with XHTML content with mixed namespaces, this is a horrendous assumption of course, but this also reduces HTML to yet another XML dialect, so yes, the control issue is paramount. The question, though, is what to do about it. There are times that I feel that the W3C has become a harried parent facing a couple of spoiled petulant teenagers, and rather than laying down some discipline the parents give in to their every whim ... and then are surprised when they wreck the family car. That namespaces need to be fixed is a known problem, and should have been resolved several years ago, but to give in to a perfectly reasonable suggest to expect well-formedness simply because a few programmers are afraid of a little extra typing seems to me to be just lazy. Kurt Cagle Managing Editor http://xmlToday.org On Wed, Jul 8, 2009 at 2:43 PM, David Orchard <orchard@p...> wrote: One of TBL's suggestions that I thought was excellent was that the
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
