- From: Robert J Burns <rob@robburns.com>
- Date: Wed, 18 Feb 2009 12:53:56 -0600
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: HTML WG <public-html@w3.org>
- Message-Id: <E090534C-7FFF-446A-B083-5A03D7186331@robburns.com>
Hi Boris, I think you're taking this way off-topic. On Feb 18, 2009, at 11:52 AM, Boris Zbarsky wrote: > Robert J Burns wrote: > >> What I am saying is that authors should produce documents that are >> conforming and that they should not re-implement an entire UA in >> javascript just to display an image (this is good and sometimes >> overlooked advice for scripting in general; let the browser be a >> browser). > > Then question remains: how _should_ a site handle the situation > where it's got an image element, a URI to show in it, and alternate > text? > > In particular, how should it handle this situation if it wants to > have a basic library for doing various DOM manipulations so the > various people doing the authoring don't have to reinvent the wheel > all the time and if it has pages in both XHTML1 and XHTML2? This is a topic for the XHTML2 WG not for us to address. I would imagine that an author targeting XHTML2 UAs would simply author content to an XHTML2 UA. If the author needed to reach XHTML1 UAs, they would author content to the XHTML1 conformance criteria. Similarly an author that wanted to target HTML4 UAs would author content to HTML4 conformance criteria and an author who wanted to target HTML5 UAs would author to HTML5 conformance criteria (and give up on proper parsing and rendering in non-HTML5 conforming UAs). Again this is not the topic of the thread though. > > >> The serialization issues already exist due to different >> capabilities of XML and text/html parsers. > > While true, it's possible to create an XHTML1-conformant image that > serializes as text/html, while it's impossible to do so for an > XHTML2-conformant image. OK. Its also impossible to create an HTML5 serialized document that uses new non-vlid elements that will parse correctly in IE6. That's the same type of backwards compatibility problem and not really relevant to the current topic. > > >> This seems like another red herring introduced into a discussion >> which is supposed to be about conflicts (specifically name >> collisions that are not addressed by context), between XHTML1, >> XHTML2 and XHTML5. > > I don't see how it's a red herring to point out specific issues that > are conflicting. Its not, but you haven't pointed out specifics. The red herring is discussing serialization issues which exist for HTML5 already and is a fine topic, but unrelated to the present topic. >> And I would never suggest authors assume UA error handling will "do >> the right thing", especially for an author trying to use a non- >> conforming document > > Please indicate to me how the document could possibly be made > conforming here if all you have are the HTMLImageElement, the URI to > show, and the alt text for the image. See below. > > >> Once an author steps outside conforming authoring practices the >> need to test against targeted UAs. Again, I don't know what these >> issues you're raising have to do with the original topic of >> conversation. > > See above. The naming conflict means that it's impossible to author > conformant content in some situations. No, I don't see that. Can you provide a specific example. What naming conflict? We haven't identified a naming conflict. What could possibly be making it impossible to author conformant content. That's a decision an author makes to author conforming content or not to author conforming content. >>> My concern is that an author who wishes to produce a conforming >>> document via DOM APIs and include images in it might not be able >>> to do so as the situation stands. >> Well, we haven't found any conflicts for the conforming document >> situation. > > Again. You have an HTMLImageElement, a URI, and some text that is > alternate text for the image. How do you put those together in a > conforming way? Conforming to which: HTML5 or XHTML2? For HTML5: <img src='image' alt='alternate text' > For XHTML2: <img src='image' >alternate text</img> or <p src='image' >alternate text</p> This last example would not have the HTMLImageElement interface, but could still be manipulated through the DOM. Presumably the HTMLElement interface would provide a 'src' DOM attribute in XHTML2 that behaved identically to the HTMLImageElement interface in HTML5. Regardless other DOM methods could be used to mutate the document. Boris you're again taking one thread and making it into a completely different thread. You do this more than anyone I've encountered on this list. Some of this is relevant to HTML5 so I think its worth addressing, but the current topic is about sharing the same HTML namespace and identifying any conflicts with that. These conflicts would be name collisions where the same name could represent multiple different semantics and no context provided any means to discern those semantics. Again, please take a look at the earlier message[1] to understand the current topic. Take care, Rob [1]: <http://lists.w3.org/Archives/Public/public-html/2009Feb/0451.html> Message follows: Hi Robin, On Feb 18, 2009, at 7:42 AM, Robin Berjon wrote: > On Feb 17, 2009, at 20:12 , Robert J Burns wrote: >> On Feb 17, 2009, at 3:31 AM, Ian Hickson wrote: >>> On Tue, 17 Feb 2009, Robert J Burns wrote: >>>> On Feb 16, 2009, at 9:35 PM, Ian Hickson wrote: >>>>> >>>>> Given the following function in a script: >>>>> >>>>> function test(imp) { >>>>> // imp is a DOMImplementation object >>>>> var doc = imp.createDocument(null, null, null); >>>>> var e = doc.createElementNS('http://www.w3.org/1999/xhtml', >>>>> 'img'); >>>>> return e; >>>>> } >>>>> >>>>> ...browsers are required, for compatibility with legacy content, >>>>> XHTML1, >>>>> DOM2 HTML, and DOM2 Core, to return an element that, when >>>>> inserted into a >>>>> document, displays either an image as indicated by its "src" >>>>> attribute, or >>>>> text as indicated by its "alt" attribute. >>>> >>>> But that element has neither value set. I'm not following your >>>> example. >>> >>> The element has to be an element that acts as above for any >>> subsequent >>> value set, changed, or removed for those attributes. >> >> So the script is a total distraction. You're simply saying that an >> 'img' element has to behave in a way that conforms to the >> implementation conformance criteria of HTML5. OK, fine we all knew >> that. For XHTML2 it would have to behave in a way conformant to the >> XHTML2 implementation criteria. > > That's not what was said. The point here is that HTML5 has a > requirement that code such as the above, which works today in HTML4 > and XHTML1, keeps working as is and producing the same result. Since > there is no way above to tell whether the img element is an XHTML1 > or XHTML2 object if XHTML2 takes over the namespace, there is no way > in which a browser could guess which behaviour to use. > > If you don't understand this from the short and abstract example > above, consider a more concrete if longer one: I understand from the short example. And I also understand the longer example you provide. The scripting is simply a distraction. If the author is authoring to HTML5 then the author would not append child elements to the img element. So now you're producing invalid HTML5. If the author is producing XHTML2, then the author would not provide an alt attribute. So you're also producing invalid XHTML2. So for an author providing both an alt attribute and child elements and an implementation that tries to be both an HTML5 UA and an XHTML2 UA, that UA would have to decide on its own error handling of this situation. Note that this particular example is also due to Ian ignoring my earlier advice that HTML5 should provide error handling for this specific case[1] (I would give the same advice to the XHTML2 WG if I served on that WG). However, its fair to imagine that there are other situations than simply this one and other situations that may not be anticipated. This means that either HTML5, XHTML2, another specification or the implementation itself would need to negotiate these issues and specify error handling. However, the context provides all the information necessary to know how to process the document in the situation of a fully conforming document. In the case of an errant document, then the implementation has to decide on the error handling. However, that is due to incomplete error handling from HTML5 due to not heeding my earlier warnings about this. > <svg xmlns='http://www.w3.org/2000/svg' width='320px' height='480px' > viewport='0 0 320 480' onload='test()'> > <script> > function test () { > var img = document.createElementNS('http://www.w3.org/1999/xhtml' > , 'img'); > img.setAttributeNS(null, 'alt', 'Dahut Numero Uno'); > img.textContent = 'Alternative Dahut'; > document.getElementById('fo').appendChild(img); > } > </script> > <foreignObject id='fo'/> > </svg> > > Today that shows "Dahut Numero Uno". If the UA suddenly supports > XHTML2 instead of XHTML1, then it'll display "Alternative Dahut" > instead. All of a sudden, my content is broken. If the application > supports both, it has no way of guessing (and the only safe strategy > for an implementer here is to default to XHTML1). Certainly the UA can determine which type of document it is for conforming documents. For this non-conforming document the UA has to determine the error handling itself (because HTML5 decided not to specify error-handling in this situation). > Because of this, if XHTML2 wishes to use same namespace as XHTML1 > then is MUST be 100% compatible and not cause content to break. If > it really intends to be a rethink of XHTML that starts off from a > new, purportedly saner base, then it really MUST use a new namespace > lest it break content (and incur both wrath and abandon). No, this is not a conflict between XHTML2 and XHTML1. It is a lack of error-handling specified in XHTML2 (if we leave HTML5 aside for the moment and cast stones at XHTML2 instead). > You'll note that this has nothing to do with HTML5. Only because we have set HTML5 aside for the purposes of casting stones at XHTML2. > Reusing the same namespace for incompatible content is a really, > really terrible idea irrespective of whether HTML5 exists, or is > being worked on, or uses that same namespace. I've been asking for someone to demonstrate an example of incompatible content and this is not one(we're looking for genuine name collision where context is insufficient to determine semantics). i've yet to see an example. I too have been looking into the issue myself and I haven't been able to come up with one. > The reason HTML5 gets to use the namespace is because its absolutely > core design orientation is that it will be backwards compatible, no > matter how distasteful some corners of the specification need be. These claims are repeated again and again, but as far as I can tell XHTML2 is more backwards compatible than HTML5 (due to the case of the redefined presentationally related elements I've mentioned before). Obviously I'm only speaking in terms of vocabulary here, XHTML2 is not backwards compatible in the sense that it can be used with a text/html parser. > Furthermore, if the XHTML2 WG has had a change of heart and wishes > to be backwards compatible, then it needs to rethink its charter, > and rather than duplicate the work that was chartered to be done > here, either merge into this group, or focus on specifying how > XForms, XML Events, etc. can integrate into an (X)HTML5 based > framework (thereby inheriting work on making BC possible). I think that would be unwise, since HTML5 is much more suited as a Browser Interoperability and Behavioral Specification than as an HTML vocabulary specification. The changes to the HTML vocabulary in the current HTML5 draft are really not appropriate for HTML authoring. > To put it in a nutshell: > > - if XHTML2 uses the same namespace > then it needs to be backwards compatible to not break content > > - if XHTML2 is backwards compatible > it is duplicating the work being done here, and another > arrangement or merger should happen > > - if, on the other hand, XHTML2 is starting from scratch and not BC > then it has no reason whatsoever to use the same namespace, and > good reasons not to It is not at all clear what you mean by backwards compatible here. I've been asking for examples of backwards incompatibility and have yet to see one. Certainly the example you've given represents a lack of clearly specified error handling in XHTML2. However, since HTML5 also fails to provide error handling in this case (despite my repeated pleas to do so), I don't see how we can hold this against the XHTML2 WG. Take care, Rob [1]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/0752.html>
Received on Wednesday, 18 February 2009 18:54:35 UTC