<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello 4All,</div><div><br></div><div>I've been adding much summary information to the HTML page I started on the HTML4All wiki [1]. The page content has grown substantially, but I want it to be a quick stop to find this summary information and then provide more detailed information in:</div><div><br></div><div>1) separate wiki pages for each module</div><div>2) separate HTML4All HTML recommendation prose sections</div><div>3) DTD (this is for better backwards compatibility with existing UAs that handle DTDs)</div><div>4) other schema definitions for better forward compatibility (XSD, RelaxNG, etc.) The main objective in providing these schema definitions (lowercase 's' and 'd') is to give authors a way to check their conformance against the machine checkable portion of the recommendation.</div><div><br></div><div>We might break this main page into parts eventually also. I welcome anyone else to get involved with the editing. I've tried to follow all of the conversations of this group and the HTML WG, but I likely missed entire proposals and threads. I think at this stage we should be collecting together all of the proposals and only decide if or how to pare them down once we can look at all of the features side-by-side. Another improvement we can make over the WhatWG black-hole approach to deciding these matters.</div><div><br></div><div>Following the HTML5 draft, I expect to focus most of my attention on two chapters: 1) "Semantics and Structure of HTML Documents" and 2) "The Elements of HTML". I want to do that in a way that as much as possible is serialization independent. However, unlike the HTML5 draft, it is not my goal to sweep under the rug the deficiencies in text/html. So whenever we simply cannot support a feature in text/html, I will clearly state that, but don't want to therefore drop it from the XML (or any other) serialization.</div><div><br></div><div>There are other topics that have been raised here that do not relate specifically to the vocabulary of HTML that I think might be worth getting their own chapter, but they are lower priority in mind view. Some of these other chapters might include:</div><div><br></div><div>1) HTML over email</div><div>2) HTML visual editing</div><div>3) HTML accessibility guidelines</div><div>4) Interactive web browsing UAs</div><div>5) Common DOM interfaces (and also interfaces for document, window, node, etc.)</div><div><br></div><div>A few things to note about this exercise.</div><div><br></div><div>Backwards Compatibility:</div><div>It is remarkable that WhatWG ever claimed XHTML2 is not backwards compatible. There are far fewer proposals in XHTML2 that break backwards compatibility than those in HTML5 (aside form the text/html verses XML serialization issue, but if that's all they mean they should say so). Even the XHTML2 approach to globalize attributes would be much better adopted for the text/html serialization where newly introduced elements (as opposed to attributes) automatically break backwards compatibility.</div><div><br></div><div>Another thing I notice from putting all of these features in one place is that WebForms can be made to work much more like XForms (while still being backwards compatible with legacy HTML forms) and XForms can be handled in text/html by adding new elements, using existing HTML elements with new attributes and providing a new LINK rel type to the XForms back-end content model that cannot be handled in the HEAD element in legacy UAs.</div><div><br></div><div>Attribute Globalization:</div><div>On another topic, I note two of the, likely, more controversial pieces in this HTML specification:</div><div><br></div><div>• globalization of the href attribute providing activated hypertext linking on any arbitrary element</div><div>• globalization of the src attribute providing embedding on any arbitrary element (though this does provide better alt text capabilities within the text/html serialization)</div><div><br></div><div>I will be working to add these capabilities, as well as the others, to the open source rendering engines. They do not really degrade too gracefully in legacy browsers (depending on what the author wants to accomplish), but in the long-run we could be targeting only browsers that handled the features just fine.</div><div><br></div><div>Namespaces:</div><div>Adding default xmlns and xmlns:* declarations on the root HTML element ensures that many namespaces can be used with prefix only, easing the migration by authors to namespace aware documents. This means in HTML4All document could simply include the following:</div><div><br></div><div><html></div><div><p aria:anariaattribute='anariavalue' >some content ...</p></div><div></html></div><div><br></div><div>among other things. This makes the most common uses of namespace extensibility quite easy for authors to use and understand. There may be other namespaces we should include default prefixes for, that have slipped my mind. Of course in the short run, authors may need to add those prefix to namespace URI mappings manually for legacy support (including in the peculiar ways IE requires prior to IE8), but again our children will never have to deal with these complications.</div><div><br></div><div>Adoption</div><div>While embracing W3C recommendations is radical enough compared to the WhatWG approach to try to dumb down HTML, the actual backwards compatibility issues involved with HTML4All introduced elements are small indeed. The HTML4All HTML introduces about as many new elements (10) as it recommends WhatWG not introduce (10). However in every case except one (SUBTEXT), these elements degrade gracefully in non-supporting browsers. In other words they provide nice new features for authors and users in supporting browsers but they are perfectly usable on their own (without wrapping them in other elements or adding scripting functionality) in non-supporting UAs. The one exception – the SUBTEXT element – would require a delayed adoption by authors or the use of a DIV or SPAN element wrapped around the SUBTEXT element (and some author provided CSS) until IE support materialized (which is the only browser where it won't work today with CSS alone). The other proposals that have been made (and I have tried to track them all) do not involve new elements and so they degrade gracefully on their own. </div><div><br></div><div>It is also remarkable that when one approaches the enhancement of HTML from authors' and users' needs rather than implementors' needs, most of the changes WhatWG proposes simply don't make the cut (and the proposals WhatWG cuts are the features authors and users need; though the FIGURE element does stand out as an exception and an excellent new WhatWG proposed element meeting the needs of authors and users).</div><div><br></div><div>This is only focussing on HTML4all originating proposals. There are adoption issues with other newly proposed elements for text/html serializations: in particular the XForms, HTML5/WhatWG, and XHTML2 proposed elements. These have far greater problems than the HTML4All proposed elements in terms of correct and consistent parsing in legacy browsers using the text/html serialization. The introduction of namespaces might address this problem by, for example, introducing XForms as a namespaced extension to HTML for proper parsing in IE (plugins already exist once it is parsed correctly). I include the prefix 'x' as a default XForms prefix so that any XForms element can be included for proper namespaced parsing such as x:select1. Other transitional options exist (such as the proposal for a legacy-bridging interim markup[2]). </div><div><br></div><div>While the differences between WhatWG HTML and HTML4All are small in the actual number of elements and attributes introduced into the vocabulary, the benefits for authors and users (including disabled users) are immense.</div><div><br></div><div>Next Steps:</div><div>I plan to get these summaries linked up with other pages in the coming weeks to provide more detail. For those of you who have been following these discussions over the last few years, you might already be familiar enough with these proposals to make sense of it from the summary alone. While many of these proposals have been authored largely by only a few of us, many other HTML4All members have been involved in the conversations that shaped the proposals (on this list, on the public list, within the HTML WG and in many private conversations). So I think of this as very much a group effort.</div><div><br></div><div>My main focus will be on the pars of HTML that differ from HTML5 (data module, phonetic attributes module, mandatory alt and role, etc.). This includes the specification of a DTD and other schema definitions for HTML. It might even be worthwhile to rework Henri's open source conformance checker to work with HTML4All's HTML. Incidentally the specification of a real DTD means also that HTML4All HTML also solves the XSLT DocType problem that has consumed unwarranted debate within the HTMLWG, though authors would also be free to use the <span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 10px; white-space: pre; "><font class="Apple-style-span" face="Helvetica" size="3"><span class="Apple-style-span" style="font-size: 12px; white-space: normal;"><!DOCTYPE html> when the specificity was unnecessary</span></font><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; white-space: normal; ">.</span></span></div><div><br></div><div>I think we have it in our power to produce this specification and make at least one UA (or even a few) work for our specification. Whether the World adopts what we do here is not up to us and we can't really do anything about that: anymore than the HTML WG or WhatWG can control it for their recommendations. As I'm sure many of us share the same outlook, what I think we want is an HTML that we can make use of in our own communities. If that's usable on the world wide web than all the better. But if it only works correctly in the best of breed browsers and degrades gracefully in all of the others than that's OK too (from my point of view, at least).</div><div><br></div><div>Take care,</div><div>Rob</div><div><br></div><div>[1]: <<a href="http://html4all.org/wiki/index.php/HTML">http://html4all.org/wiki/index.php/HTML</a>></div><div>[2]: <<a href="http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup">http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup</a>></div></body></html>