- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Mon, 19 Jul 2004 12:33:11 -0400
Dean Jackson wrote: >>>I really don't think you should add new elements like <output> to the >>>XHTML namespace. The reason the namespace is there is precisely so you >>>don't have to do this. >> >> I'm not convinced of this. If that were so, you'd have to create a >>new namespace every time you wanted to expand functionality. Over time, >>that would create a massive number of namespaces and cause significant >>confusion. > > I don't suggest you create a new namespace for every rev. > Just one to identify the elements added by WHAT. > I assume that WHAT will try to avoid any conflicts with itself. > (and note that I'm not sure that WHAT's extended <input> element > should be in the XHTML ns or something else) Correct me if I'm wrong, but the element <input> is already in the XHTML namespace. What we're doing is extending the functionality of an existing element. Therefore, a new namespace doesn't make sense, especially in light of the fact that we're extending an existing standard rather than creating a new one. (It's my understanding that in XHTML 2.0, they're removing all forms markup entirely in favor of XForms.) >>To me, namespaces are for separation by category or type, not >>by revision or extension. > > Exactly. The category and type of <output> is different from > elements in XHTML. How so? Because it has new functionality? That cannot be the threshold for creating new namespaces. > It is also defined by someone else, and owned > by someone else. I don't think you should add elements into > a namespace that someone else defines. If a standard has only one namespace, and you want to add extensions to that standard, would you not naturally add those extensions to the namespace. This is especially true with a specification like Web Forms 2.0, where the bulk of the extensions are in attribute form. > This is another reason for strong branding around HTML 5. I'm not following you. On one hand, you want everything branded under HTML 5.0. On the other, you want namespaces. Are you asking for an "HTML 5" namespace that will be separate from XHTML? > No, I was saying that the W3C goofed up and regret the mistake. > That's partly why I suggest a new namespace. Please provide a reference to support this assertion. I'm not suggesting you're wrong with regards to the W3C's position on namespaces, but it would benefit the mailing list to have this documented. > If you don't make your own namespace, then you might as well > have no namespaces. You have the root tag (<html>), what else > do you need? (I also think namespaces are not so friendly for > authors, but I'd like to see some way to know if my content is > W3C+WHAT HTML, W3C HTML or W3C+WHO HTML). For XHTML, the namespace is defined in the <html> element like this: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> This is the same for XHTML 1.0, XHTML 1.1 and XHTML Basic. Only XHTML 2.0 differs, and it won't be using HTML forms markup at all. It is stated in the working draft that it will not be backwards compatible. I suppose we could clone XHTML, add HTML 5.0 features, and call it something else, perhaps "XML-HTML 5.0" or "XHTML 1.5". I don't think W3C would appreciate that, though. WHAT WG features are intended to be integrated into HTML and XHTML 1.x anyways, so why fork development? XHTML won't be backward compatible anyways, and it's still in draft, so there's on reason WF2 and other specs can't find their way into XHTML. Anything else would require the use of multiple namespaces, which means a lot of elements that start with "what:" or "html5:". >>>Tim Bray also suggests that you fake the namespaces in HTML >>>(ie <what:output>). I'm with him on this. >> >> What (no pun intended), are we going to do about the people who are >>switching from HTML5 to XHTML? Do you expect them to have memorized what >>namespace every element is in? > > Why do they have to memorize a namespace for every element? > If their content uses <what:output> then all they need to > do is add xmlns:what on the root element. Clearly, the content won't contain that for two reasons. The first is that Microsoft HTML namespaces are not a standard, they're just something MS decided to stick in IE. Therefore, using "what:" may not parse on some user agents, and the elements will not degrade gracefully. Second, as stated before, many have trouble with namespaces, and I would suspect that webmasters with little or no exposure to XHTML would have the most difficult time with it. > I'm suggesting you prefix all your new HTML elements with "what:". > As Tim said, Microsoft have done this without problem in IE for 5 years. I see no reason to base WF2 on a proprietary Microsoft technology, no matter how long Microsoft has supported it. Namespaces are just one more thing that HTML user agents have to code for. > Yeah, it's really ugly. That's why I suggest the alternative: WHAT > should clearly specify HTML 5 (or HTML WHAT) as well as an XML > version. WHAT WG specifications have their own doctypes, so I don't understand what you want here. > I think kludging into existing specifications is going to > confuse more people (more than the number of people hand-converting to > XHTML). It's no more confusing than going between two versions of HTML. In fact, it is going between two versions of HTML, if all goes well. >>This will significantly add to the XHTML >>learning curve and make hand conversion of HTML to XHTML more complicated. > > I really doubt it. They are going to have to put an XHTML ns > declaration in there anyway. So what? They copy-paste that right out of the specification. What does that have to do with using two namespaces at the same time? Or are you proposing the cloned namespace idea? > I don't think this will be any harder > than fixing unbalanced content. Do you really think this is a bigger > complication? I don't know what you mean by "unbalanced". > Remember that hand converters are going to cut and paste a bit > of text (because no one can remember namespace URIs). Having > one or two NS declarations in that text isn't going to make > the task any harder. Having or remember which elements for which you put the "what:" in front of the name is going to make it harder. > Moving from HTML to XHTML isn't easy, and I really don't think much of > the existing web will ever move (in fact, I doubt much of the existing > web will change to anything -- be it to valid HTML, WHAT HTML or > XAML). Content on the web changes all the time. While it's true that content that has remained on the web unchanged for long periods of time will likely stay that way, I don't see that representing most of the web. The biggest reason content hasn't changed much, though, is because markup support in IE (and even many modern browsers) hasn't changed in years, and that's largely due to the W3C HTML Working Group becoming the XHTML Working Group without bothering to change their name. They abandoned HTML, then failed to add new features to XHTML because they believe that these features are better implemented in other XML-based languages. (XForms and SVG are excellent examples of this.) I'm not saying that it's a bad idea from a technology standpoint, but it forces a situation where everyone has to convert their content to a completely new system, and if there isn't a good enough reason to do that, people are just going to stick with what they have.
Received on Monday, 19 July 2004 09:33:11 UTC