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

Hi Boris,

Thank you that is much clearer to me now.

On Feb 18, 2009, at 1:44 PM, Boris Zbarsky wrote:

> Robert J Burns wrote:
>> You never did provide such an example, despite my repeated requests  
>> to do so.
>
> Again.  I'm implementing an editor widget.  I would like both XHTML2  
> and XHTML1 documents to be able to include it.  I would like to  
> create valid markup for the editor controls.  I want to have some  
> graphical buttons (for inserting headers, indent, outdent, etc,  
> etc).  I want to make those buttons accessible via setting their  
> alternate content.  I create the editor UI via script (in fact, my  
> whole product is just a JavaScript file that the including page can  
> reference; it can then point me to a particular place in the  
> document and say "put an editor here".
>
> See also http://www.fckeditor.net/ (which I've explicitly mentioned  
> in this thread).

I'm not familiar with fckeditor and even if I was that wouldn't have  
been sufficient for me to understand what you were saying until now.  
You could have used my own application (in development) as an example  
since it faces the same issues but I wouldn't have known what you  
meant without the same level of detail.

> If XHTML1 and XHTML2 don't share a namespace, I can simply use  
> whichever one I want for my images; as long as I match up my  
> namespace with the way I set up the alt text it all works.

However there are countless other similar issues that would be  
encountered by sharing the same namespace with other vocabulary  
differences. For example HTML5 puts everything in the same namespace  
across HTML2 through HTML5. If there are vocabulary differences, then  
someone has to handle those differences regarldess of namespace  
sharing. Also if the namespace were changed with every iteration, it  
wouldn't really solve the problem (and create many other problems).  
You'd still have to deal with the differences in vocabulary, but now  
you would have a namespace URI to use to characterize each subtle  
distinction in vocabulary.

> If they share a namespace, then I need to detect what sort of  
> document (or part of document if being used in an SVG foreignObject)  
> the editor is ending up in and tailor my alt text setting accordingly.

This would be something someone along the route would decide. I don't  
see this as being a difficult problem. Regardless of namespace,  
someone along the route has to decide what vocabulary to produce. This  
could be the original library creator who decides to only support  
XHTML2 or only HTML5 or only HTML2. Or the library creator might  
support all of those vocabularies and then provide a method or  
function call for the web site consumer of the library to use to  
decide which vocabulary and which serialization to use. The web site  
consumer of the library could pass along this choice to the end-user  
of the tool and let them choose which vocabulary to produce and which  
serialization to use (if serialization is relevant). When the web site  
or user changes the vocabulary the toolbar might change to reflect the  
new vocabulary (adding 'time', 'meter' and 'progress' for example).

Regardless of where the decision is made in the chain, once a decision  
is made the form of the vocabulary is determined. If XHTML2 is  
selected then whenever the DOM is mutated to add alternate text that  
alternate text is added inside the 'img' element. If instead HTML5 is  
selected then whenever the DOM mutates the alternate text, it is  
mutating the 'alt' attribute value.

If the target browsers do not support one or the other then it would  
be the responsibility of the site author or the end user to  not  
select an unsupported browser (perhaps this could be done through some  
sort of UA sniffing though not necessarily or only the UA string).

> That is, I have to guess what the UA will detect my nodes as.  Given  
> that UAs are likely to have different detection heuristics (such  
> detection actually getting specified would be a miracle), I'm more  
> or less screwed.

I wouldn't suggest this get handled at all by UA heuristics. The  
library might provide heuristics to detect the UA (e.g., the browser),  
but the browser should not be trying to detect what the end user or  
the site author want to produce. So in terms of a browser implementor  
its not even something to worry about.

Take care,
Rob

Received on Wednesday, 18 February 2009 20:48:28 UTC