Future of web standards

Ivan Herman and Mike Smith from W3C are touring eastern Australia from
12 to 20 May, presenting on the future of web standards, HTML5, XHTML and Semantic Technology. There are industry public and research presentations in Brisbane 12 May, Sydney 13 May, Canberra 15 May, Hobart 18 and 19 May, Melbourne 20 May. The tussle between XHTML (lead by the academics) and HTML5 (promoted by the browser writers) is an interesting one. The semantic web has similar issues.

Web Browser Support for Print and Screen Presentations

Robert O'Callahan, from Mozilla.org, gave a brilliant talk in Canberra, 4 August 2007 about the development of the Firefox. This was a mix of the business and politics of web browser competition, the social aspects of how to do open source development with a global community and the very technical details on how to do better code.

Some of the points I found of most interest were about the value of "Fuzz Testing", the way Firefox is very popular in vertical slice of Central Europe, running from Finland, down to the Mediterranean (for no obvious reasons, which must be a good topic for someone's PHD).

I asked Robert about HTML 5 versus XHTML 2. The W3C's approach of revising XHTML has not found favor with web browser developers at Mozilla, Apple or Opera. The issue, as I see it, is that the browser developers want to built features for interactive applications into their browsers, so that so many non-standard plug-ins and extensions are not needed. But I want to be able to do plain, old fashioned web based static documents which scale and print well. This is so I can use web pages in place of Powerpoint and PDF. I can't see that this would be very difficult to implement.

At present web browsers do not do a good job of printing, tending to break images and paragraphs across pages and not supporting new CSS features for formatting pages. Also web browsers do not do a good job of supporting CSS features for screen presentations.

As a result I have to do three versions of each document: HTML for online viewing, Powerpoint (or Slidy web pages) for a presentation and PDF for printing. If browsers supported formatting just a little better, then I could do it all with HTML, perhaps with just the one HTML file.

Many do not bother with separate versions of documents, and so there are vast numbers of PDF documents clogging up corporate and government web sites. These documents are hard to read on screen, large to download and hard to read by those using accessibility aids and on hand held mobile devices. Most of the documents use no fancy formatting and if the browsers supported web standards just a little better HTML versions would display and print adequately.

Robert argued that doing page breaks and layout well were very difficult problems. But , I don't want it done really well, just a little bit better. How hard it be for the web developer to avoid breaking up and image or a paragraph across a page boundary?

Another quibble I had was the insistence of web developers to include a requirement for quirks and backward compatibility in the HTML 5 standard. As a web author I don't need to know about strange things people did with HTML in the past. Browser developers may well choose to support features and quirks which old versions of HTML had, but I should not need to know of them, as I will not be using them.

If this old baggage has to be in HTML 5 for some reason, then we need "HTML 5 Lite", with them left out (just as there is XHTML Basic). This is not because we want to stop browsers rendering old documents, but have something simple for web designers to use.

I did make an attempt to put some of these points in the relevant W3C forums, but was essentially told: "We browser developers will dictate what the web standards are from now on.".

Web and ODF documents in PDF?

Getting acceptance for new document formats from users is difficult. If someone gets a file with an ODF or some other extension they have never heard of it will be a worry for them. But if they get a PDF file that is okay.

Perhaps PDF can be used as Trojan horse (in a nice way) for this. Some versions of PDF (such as PDF/UA) have provision for embedding data files. This could be used to include a Open Document Format (ODF) or web document and its associated formatting and images inside the PDF document.

The OpenOffice.org office suite could be modified to package an editable version of documents in a PDF file (and an equivalent addon provided for Microsoft Office). OO already creates PDF versions of documents, so to this could be added an option to include a copy of the original source document. The person receiving the document would see the PDF rendering by default, but would have the option to work on the original editable file and be offered a link to download a copy of OO, or a conversion tool for Microsoft Office, if needed.

Most of the space taken up by word processing documents is in the images, not the text. It should be possible to share the images between the PDF rendering and the ODF document. As a result adding the ODF document to the PDF may not make the document much bigger.

ODF is better than not having a standard format for office documents, but is not perfect. My preference would be to use XHTML 2 for word processing documents, so they could be directly rendered by web browsers. Word Processing programs are rapidly becoming just a way to create not very good web content and it would be better if they created well formatted web format documents directly.

Compatibility with existing products is a legitimate concern when setting a standard. As an example this was a major consideration in the standard for shipping containers, with discussion of what adaptors would be needed.

Standards based on something which has been shown to work are better standards. But this does result in some quirks, as an example shipping containers are stronger than they need to be (increasing costs) due to the need to meet some old European railway standards. The cords for some computers are rated to withstand high temperatures as the standard they are made to was designed for electric kettles. Putting office documents inside PDF files would be a bit like a computer cable you could use to boil water, but at least it would work.

HTML 5 V XHTML 2 web schism

The HTML 5 Editor's Draft, 28 June 2007, was prepared by Ian Hickson at Google and David Hyatt at Apple:

"This specification defines the 5th major revision of the core language of the World Wide Web, HTML. In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability."

HTML 5 appears to be a philosophical split from XHTML 2. Whereas XHTML 2 is for representing documents on screens and print, HTML 5 seems to be for interactive computer interfaces. For example:

"XHTML2 [XHTML2] defines a new HTML vocabulary with better features for hyperlinks, multimedia content, annotating document edits, rich metadata, declarative interactive forms, and describing the semantics of human literary works such as poems and scientific papers.

However, it lacks elements to express the semantics of many of the non-document types of content often seen on the Web. For instance, forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well, and are not covered by XHTML2. "

Much of the philosophy of HTML 5 seems to be embedded in the Apple iPhone. But that device can use ordinary old HTML web pages with CSS to adapt web pages for iPhones and other smartphones.

Also the tone of the document, especially the editor's comments, seem to be much more confrontational, than XHTML's academic style. The HTML 5 editors are essentially saying that they are going to produce a usable standard and so everyone either needs to get on board or get out of their way. An example is:

"Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions."

Much of what the authors are saying makes sense, but the way they are saying it is likely to not go down well in consensus based forums.