- From: Robert J Burns <rob@robburns.com>
- Date: Wed, 18 Feb 2009 14:47:47 -0600
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: HTML WG <public-html@w3.org>
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