[html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML)

[Robert J Burns]

Hello 4All,

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:

1) separate wiki pages for each module
2) separate HTML4All HTML recommendation prose sections
3) DTD (this is for better backwards compatibility with existing UAs  
that handle DTDs)
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.

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.

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.

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:

1) HTML over email
2) HTML visual editing
3) HTML accessibility guidelines
4) Interactive web browsing UAs
5) Common DOM interfaces (and also interfaces for document, window,  
node, etc.)

A few things to note about this exercise.

Backwards Compatibility:
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.

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.

Attribute Globalization:
On another topic, I note two of the, likely, more controversial pieces  
in this HTML specification:

• globalization of the href attribute providing activated hypertext  
linking on any arbitrary element
• globalization of the src attribute providing embedding on any  
arbitrary element (though this does provide better alt text  
capabilities within the text/html serialization)

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.

Namespaces:
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:

<html>
<p aria:anariaattribute='anariavalue' >some content ...</p>
</html>

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.

Adoption
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.

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).

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]).

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.

Next Steps:
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.

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 <!DOCTYPE  
html> when the specificity was unnecessary.

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).

Take care,
Rob

[1]: <http://html4all.org/wiki/index.php/HTML>
[2]: <http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20090108/036ce75b/attachment-0002.html>