Re: ISSUE-4: Versioning, namespace URIs and MIME types ISSUE-60

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>