Preston L. Bannister { random memes }

Got the “status as Invited Expert in HTML Working Group” email. This I will let expire. Spent my time tilting at windmills, and do not see any point in continuing.

The HTML Working Group at W3C is … far too much noise. The HTML5 “standard” is going to be a bloated monster, and there is no chance I can change that. Time to stop the pretense of trying.

Not that all the work is bad, or that there is any shortage of well-intentioned folk. What the group lacks is any sense of minimalism, and enough strong voices able to say “no”. What we will get is going to be even harder to digest than HTML4. This is sad. Future developers are going to have an even harder time, for no good reason.

The wildcard here is that the mainstream browser implementations may not follow all the half-thought ideas thrown in by the HTML5 Working Group. No idea how this will work out.

At the core HTML is pretty damn simple – or could be. HTML4 got stuffed with a bunch of half-thought notions, most of which have since proved of no value, and were ignored by developers. Ideally we would learn from experience, omit the fuzzy disused bits, and trim HTML down to the useful core. There are well-known (though not universally known) means to achieve this aim. This is not going to happen.

I cannot keep up with the herd of Energizer-bunnies eager to make their mark, and with too-limited experience.
Time to stop pretending.

At one time I had hoped there was a small chance I might be able to nudge the HTML working group in a constructive direction. Over time, what I found is that there are a small number of individuals that are able to invest an inordinate amount of time to this same working group, and I cannot possibly invest the time to construct thoughtful responses to the flood ill-considered notions.

There is almost no chance I can move the working group is a useful direction. Time to disconnect.

This is all rather discouraging. The HTML working group will proceed. Some of the work is worthwhile. Much (measured by volume of email list traffic) is not. What mix will make it into the generated proposed “standard” is sure to be a mess. Not sure how to change any of this.

My status as an “Invited Expert” is up for renewal. With extreme reluctance … my judgement is that I cannot make a useful contribution, and should disassociate from the HTML working group. Of course, they will continue on the present course, in my absence. My withdrawal makes no difference of significance. There is a fair chance the body of work from this working group will be adopted, imperfect as it is. The existing body of work is … badly skewed by an imperfect process.

Nothing meaningful I can do. The result will be a mess, and will create a mess for years after. Time to disengage.

Funny bit – I do not see a way to force a disconnect.

Asked GMail to search my email for: w3c “summary attribute”
I count 534 messages.

Asked GMail to search my email for: w3c “alt attribute”
I count 1769 messages.

If the result was brilliant, the counts would be worthwhile.
I do not think brilliant results can come out of those discussions.

Sam Ruby: Contributions Welcome.

Yep. I think Sam in the HTML5 working group is a very good thing.

For the record, I think that making Sam Ruby a chair of the HTML5 working group is a good sign, in a dismal process.

Credit Sam with pointing out bits that are just wrong. The DOCTYPE section is a good/bad example.

A DOCTYPE is a mostly useless, but required, header.

DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.

To a web developer the DOCTYPE header is essential to insure a specific interpretation of HTML. If you think that HTML4 is better than HTML3 (or earlier), then the DOCTYPE is pretty damn important. In some ideal (non-existent) world, the first specification of HTML was perfect, and all browser implementations perfectly implemented the HTML exactly as in that same specification. In that world the DOCTYPE header would not be needed. In the real world, the DOCTYPE header is extremely useful, because it allows the web developer to invoke the better behaviors offered by later browser implementations, when those later implementations improve on what came before.

Seems I wrote about the DOCTYPE a year ago. My opinion has not changed.

Somehow the W3C HTML working group has walked through the looking glass. The difference between compatible and incompatible is “mostly useless”. Good is bad, and the trivial is vitally important.

Have doubts about that last? The HTML working group is still arguing over the alt attribute – a stupid waste of time. (If it would do any good, I’d be far more diplomatic.)

The constant references to XML and SGML in the HTML5 spec need to be removed. HTML is not XML. HTML is not SGML. HTML is not and never will be either XML and SGML. An appendix describing a mapping to XML would be useful. A history section describing the relationship to SGML and XML would be informative. Pretty much every other reference is a waste of time.

The massively verbose sections on parsing are a waste of time. The HTML standard is defined in terms of ASCII, and ASCII only, which makes much of the following needlessly verbose.

A DOCTYPE must consist of the following characters, in this order:

1. A U+003C LESS-THAN SIGN (<) character.
2. A U+0021 EXCLAMATION MARK (!) character.
3. A string that is an ASCII case-insensitive match for the string “DOCTYPE”.
4. One or more space characters.
5. A string that is an ASCII case-insensitive match for the string “HTML”.
6. Optionally, a DOCTYPE legacy string (defined below).
7. Zero or more space characters.
8. A U+003E GREATER-THAN SIGN (>) character.

In other words, <!DOCTYPE HTML>, case-insensitively.

Then there is the response from Ian Hickson. To be clear – I give Ian a lot of credit for tackling a large and difficult job (though Google’s apparent sponsorship dilutes that just a bit), and for trying to be moderate in dealing with the HTML5 working group. Credit aside, it seems that Ian does not have the right mindset (in which he is not at all alone).

For example:

Regarding the alt=”" attribute: we don’t want to say that alt=”" should be optional, because that would be an accessibility nightmare. It isn’t optional, it shouldn’t be optional.

In reality the alt attribute is optional. You cannot force web developers to use the attribute, or to use the attribute well. Web browsers cannot reject HTML documents that lack alt attributes. Few web applications will be written for accessibility, and the treatment of the alt attribute in the HTML5 standard cannot change that. Better to fit the spec to reality, than insist on a fantasy.

Also:

Regarding the extensibility mechanisms — HTML5 already has literally over half a dozen extensibility mechanisms: [link]

The existing support for extensibility in HTML is lame. What we need is something simpler and more fundamental. Here I have to admit weakness in that I have no particular skill as teaching. If you do not already deeply get why Lisp and Scheme are remarkable, then I cannot offer an adequate explanation. (Who does?)

I wish Sam luck. Boy does him ever have a big job in front of him.

Sometimes the best thing to do when presented with an unsatisfactory solution, is to walk away from the problem for a while. The continuing arguments in the HTML@W3C arena of accessibility proved an example. After reading through many of the arguments, I was left distinctly unsatisfied with the solutions offered. I had questions and arguments, but nothing better to offer.

The core problem is that I (and the vast bulk of web authors and developers) will never spend very much time writing for accessibility. As a consequence I (and the larger “we”) will always be unskilled in this domain. We need help. What we need is some means that makes writing for accessibility … accessible. Arguing over individual attributes is a waste of time. What we need to understand is the impact of the page as a whole.

Someone (months back) suggested I download one of the specialized browsers, and play with it for a while. Not a bad idea, but not a very good one either … to be honest … the larger “we” will never spend enough time to really make good use of this approach. Someone who has used such browsers for years will have a skills and most likely a different approach that I cannot acquire in a few hours poking around.

We need a bit more leverage. We need to be enlightened.

1. The first missing bit is a “best practices” document – something that captures the expertise of skilled disabled-human readers, and captures the most effective implementations of specialized browser software.
2. The second missing bit is a visually-oriented test browser that offers a clear presentation of the structure of a page, as seen by a “best practices” browser. Such a test browser would strip out any visual elements, recognize any added bits added for accessibility, and visually highlight the organization and navigation associations – perhaps green background for the main (hinted?) path, and red background for islands of unlinked or ungrouped text – so that the visual aspects of a page are discarded, and the non-visual structure of a page becomes visual. The test browser might well just be an add-in for an existing mainstream browser.
3. The third missing bit – only possible after we have the first two – is a clear definition of how to apply minimal additional hints (via styles, attributes, or whatever is needed) so as to make a web page and web application more accessible.

Arguing over attributes – an aspect of the third part – is backwards, and a waste of time without clear understanding and realization of the first two parts.

Creating the first part could be a problem as the software vendors in that domain are likely small, and treat their algorithms as proprietary. Also as the market size is small, the products offered may not be very good, and thus not a good source of enlightenment. The size of the “practices” document should be small. If you present the larger “we” with a 100-page document then approximately no one will ever read the document. Guidelines must be clearly and concisely expressed in a single page of text (with larger explanatory material available to read as needed), if the guidelines are ever to be read by a significant percentage of authors. This is a pretty good test. Writing short, concise, and clear is only possible when you have a good comprehension of the subject. Writing large, fuzzy texts is easier, but less useful. If the field in question is filled with large/fuzzy ideas, you end up with large/fuzzy texts.

The fact that the second part – the visually oriented “test” browser – does not exist is a pretty good litmus test. That lack is a strong hint that this aspect of design is not yet well and properly understood. (Of course that existence of the “test” browser is a threat to small proprietary software vendors, as a subset of the “test” browser could serve as a generic browser for the disabled.)

There is in fact a future mainstream application for this area of study. As use of the internet becomes pervasive, rather than something done always done as a sole activity, then non-visual usage becomes more important. Imagine you are driving a car, riding a bike, or walking down the street. You will want to make queries without staring at a screen. (Running into a tree or a car is at least embarrassing.) This growing/future need could prove a boon to accessibility, if authors and designers are offered a clear and efficient path.

The argument over whether accessibility-oriented attributes should be required for HTML5 conformance is a waste of time. Testing for accessibility is semantically remote and distinct from the concerns of a well-structured HTML page. Better to channel that time and energy into defining and building better tests and development aids.

[Yes, I read some of the ARIA documents. Unless I really do not understand, this is not going to happen
... as described above.]

Tuned out from HTML@W3C working group for a few months. (I was very busy at work, and participation in the working group is entirely a free time activity.) Ran across this long and apparently continuing argument that seems to boil down to whether <img> tags should be required to have an alt attribute to be accepted as HTML5 conformant. One or more of the guys associated with accessibility at their place of work seem to be arguing for mandatory alt usage.

Just to be clear, if the writer is not attempting to make a document accessible, then all we need for HTML is:

    <img src="a.png">

The above is an image with no extra information for accessibility.

All of the following is a waste of time:

    <img src="a.png" noalt>
    <img src="a.png" alt="">
    <img src="a.png" alt=".">
    <img src="a.png" alt="*">
    <img src="a.png" alt="boilerplate-put-in-only-because-it-is-required">
    <img src="a.png" alt="not-very-meaningful-text">
    <img src="a.png" alt="downright-misleading-text">

The above is ritualistic waste – about the only good it will do is give global warning a tiny boost, and perhaps delay the next ice age.

Frankly, I do not care about accessibility. Except when I do.

When I do not care about accessibility, if an HTML5 conformance tester bugs me until I waste time putting in bogus attributes, I am going to regard HTML5 conformance as a somewhat bogus waste of time. The vast majority of web pages have been and will be written from this frame of mind. Any attempt to force accessibility on this population is going to fail. Worse – attributes added for HTML conformance, but lacking meaningful human-semantic value, are likely to make pages a bit less accessible.

When I do care about accessibility, I need help – big time. Somehow I doubt that just filling in a few attributes is going to do the trick. I have never been part of an organization big enough to have folk dedicated to accessibility. That means I am pretty much on my own. Sure, I could go through and mindlessly fill out a bunch of alt attributes. I am sure this will make some bureaucrat happy, but I doubt the result will be very good. What I really need is something that will let me test the page as a whole, and give me some insight into how alternate browsing tools present the page.

Also it always kind of bugged me that the text inside an alt attribute could not be styled. Seems like the text should be treated like other text. Sometimes a little emphasis in the right place goes a long way.

This argument is a waste of time. Requiring alt attributes when the writer is interested in accessibility is a waste of time. Making HTML documents non-conformant because they lack meaningless boilerplate is a waste of time.

A test for accessibility (usable without expertise in accessibility) is a great goal, but pretty near independent of what should be the main concerns of the HTML working group.

Accessibility is a noble goal. You cannot force people to be noble.

There is once again talk about versioned web pages. Unfortunately there is also the same continuing confusion between theory and reality.

A List Apart: Articles: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
The DOCTYPE switch is broken

Back in 1998, Todd Fahrner came up with a toggle that would allow a browser to offer two rendering modes: one for developers wishing to follow standards, and another for everyone else. The concept was brilliantly simple. When the user agent encountered a document with a well-formed DOCTYPE declaration of a current HTML standard (i.e. HTML 2.0 wouldn’t cut it), it would assume that the author knew what she was doing and render the page in “standards” mode (laying out elements using the W3C’s box model). But when no DOCTYPE or a malformed DOCTYPE was encountered, the document would be rendered in “quirks” mode, i.e., laying out elements using the non-standard box model of IE5.x/Windows.

The above referenced article goes on to describe a hideously complex new version mechanism, which if adopted is pretty much guaranteed to cause grief. We do not need anything so complex. DOCTYPE works, but what DOCTYPE means may not be what you expect.

This topic is very old and very familiar when developing distributed applications. If you have two independent machines with a network in the middle, sooner or later you are going to be running different software versions on the two (or more) machines. This forces you to think through the issues, and after twenty-odd years working on distributed applications, on this topic I have no doubt as to what works.

What you have to do is version the data. In a distributed application, this is the data that goes across the web. A single version number is sufficient. Note that this version number is not the version of the application.

The DOCTYPE version is all and exactly what we need. In theory the DOCTYPE was meant to indicate exact compliance with a particular W3C specification. In reality DOCTYPE means something else.

Up until the release of IE7, a web page that declared <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> was tested and worked under IE6 (at a very high probability), and may have been tested on other then-current browsers. The DOCTYPE does NOT indicate that the page works in an HTML 4.01 compliant web browser. There was (and is?) no browser that exactly implemented HTML 4.01, so exact 4.01 compliance in the web page is impossible to assert. Lacking a reference implementation of the HTML standard, web developers can only test against the most widely-used web browser(s).

In effect the DOCTYPE string is the version on data – but only vaguely related to the W3C specification.

On the release of IE7, the Microsoft folk fumbled. In changing the interpretation of web pages (no matter how well-intentioned) they changed to meaning of the data. When you change the meaning of the data, you MUST bump the version number.

If you lose the confusion between theory and reality, the DOCTYPE is all we need to exactly version the data (HTML).