Opera CTO Hits Back at Microsoft's Standards Push

Michael writes "Opera CTO Håkon Wium Lie hit back today at Microsoft's push to fast track Office Open XML into an ISO standard, in a blistering article on CNET. He also took a swipe at Open Document Format: 'I'm no fan of either specification. Both are basically memory dumps with angle brackets around them. If forced to choose one, I'd pick the 700-page specification (ODF) over the 6,000-page specification (OOXML). But I think there is a better way.' The better way being the existing universally understood standards of HTML and CSS. Putting this to the test, Håkon has published a book using HTML and CSS."

Comments

Is it mature enough?

[Goalie_Ca]

HTML and CSS are quite capable of rendering and displaying webpages. What happens with a simple thing like a file header showing page number and author name. Footers with footnotes? How about dealing with table of contents etc. How would a page in a document be broken down? Anyone who's tried to print HTML knows there are many issues with layout. What's sad though is that even HTML and CSS is not supported the same in all browsers.

I'm a latex junkie. Latex though is a PITA to create templates and styles for. Someone willing to take up the task to modernize latex or completely replace it?

Re:Is it mature enough?

[tomstdenis]

The trick to using LaTeX safely is automation. The less TeX twiddling you have to do manually the better.

For me, I write my user manuals [for my FL/OSS projects] in LaTeX because the layout is much better, and the process much simpler than wrestling with a word processor.

Why anyone writes books in anything else is beyond me.

My first book [math text] that was published was all LaTeX, and while it wasn't all super simple the vast majority of the layout and setting work was handled by TeX itself. My second book [crypto text] was written in Word [required by publisher] and the tables were not set properly, equations look like shit, etc.

Word processor == memos, letter home to Grandma.

Typesetter == Papers, Books, Print material

Tom

Re:CSS for Documents?

[Antique Geekmeister]

Indeed: LyX is extremely handy for providing to undergraduates or research assistants whose thesis advisors insist on using TeX or LaTeX, who lack the time to learn yet another language. LyX is the difference between having slightly more elegant .tex files, and getting an hour more of sleep a night when writing your thesis because you can edit in a GUI and don't have to debug your .tex files.

I am finding myself wishing that OpenOffice had pursued putting a vastly better interface on TeX and LaTeX, rather than writing their own standard. It would probably have been faster and certainly would have been a lot more stable. Microsoft couldn't have even thought about it: its clean, open standards would not have lent themselves to the proprietary "extend" part of Microsoft's "embrace and extend" approach, or Microsoft's software licensing models.

Open Office Herecy (sold here)

[IBitOBear]

I use OpenOffice. I support Open Document Format over MS/XML and .doc.

That said, ODF it kind of blows. Really.

I write novel-length "books" and it is FREAKING IMPOSSIBLE to do some very basic things in any/every ODF based word processor I have tried to date.

Exercise for the Interested:

Make a "Book" with an automatic table of contents, said table to contain an "Authors Note", "Prologue", auto-numbered chapters 1 to N with their associated chapter titles (where the actual chapter number is the chapter number internal variable), and finally "Epilogue" all at the same level of the index.

This simple task is essentially impossible. The flaw is caused by the fact that everything goes through the "styles" and the styles don't inherit their list membership properties. You should be able to make a style "TOC Entry" that is assigned to a particular table of contents level (e.g. level 1) then make a sub-style "Chapter Heading" based on "TOC Entry" but with the chapter numbering magic attached, and in so doing, create "different styles" that go to the same level/point in the list.

Exercise for the Interested:

Make a "Book" with each chapter, and the prolog, and the epilog in separate sub documents. The linkage thing is a mess, it is hard to move "the pile of files" around especially if you want to use subdirectories (etc). If you have a custom style in the master document style list you have to _USE_ it in the master document if you want it to be pushed into the created sub-documents. Once the sub-documents are created it is a royal pain (read effectively impossible, or "supremely hidden feature required") to update those styles in those sub documents if you change that style.

Exercise for the Interested:

Put three separate "outlines" into one ODF Document. In ODF the outline is a function of the style headers, they only exist as implications of structure instead of first class abstractions. This is largely the fault of Microsoft Word, since the Word folks totally messed this up when they supplanted WordPerfect (which did this inset outline/object sort of thing right).

ODF was, IMHO, poisoned by the slavish attempt by someone trying to make a Word killer instead of a "good word processor."

And there are stacks more of these issues.

And all that said, I *STILL* use ODF (Open Office etc) because I CATEGORICALLY REFUSE to _RENT_ the right to access my own work from a third party. Microsoft has plainly stated that such rental model is their intended business plan, which makes them a non-starter.

In my opinion, having used both Word and OpenOffice for years; and having used Word Perfect and wordstar before them, ODF is a "workman like effort" to create a document format suitable for "normal business purposes". There is a reason that the legal profession never moved over to Word, and they likewise will not move to ODF, when you need to get to a tightly proscribed document format, both Word and ODF have a "you can't get there from here" fundamental limitation. Both formats simply refuse to represent some things because the designers "know" that a different format is better. Neither ODF nor Word has any allowances for _art_, professional or poetical.

So, governments should use ODF because it is "no worse" than Word in terms of the ability to represent the documents it can represent, and given that congruence, the shorter, 100% open standard is, or should be, a hard minimum requirements.

In terms of ODF being the be-all and end-all of document representation, I'd have to say "hardly!" I looked into the OpenOffice code base a while back to see if adding/changing the format to allow for "a book" would be reasonable. It didn't appear to be. Too many of the original StarOffice assumptions about document structure seemed pathologically uninspired. It was like looking at a big pile of Visual Basic. Everything in the standard is way too global, nothing "nests organically" it all nests pedagogically. (Every

output, at most

[Anonymous Coward]

HTML/CSS is at most only an output format, i.e. one uses it as the final presentation format, like PDF or ps. To actually write and edit something (even through some GUI), then save, reload and make significant changes is absolutely horrible with it. This was supposed to get better when CSS was introduced, but somehow the format specification failed miserably (IMHO, of course).

I'm not a fan of the two mentioned formats either, way too much bloat. somehow that seems to be normal with xml based formats (but that's probably just a pet peeve of mine).

Google docs

[edxwelch]

He wants HTML/CSS documents? Isn't this what Google docs do?
Anyways sounds like a good idea to me. I often have to share documents and I don't like to have to force people to install a specific application just to read them.

Re:fsck'n ugly

[lahvak]

The M in HTML stands for MARKUP. And it means it. HTML is NOT a layout language. Never has been, and apparently never will be despite unending attempts to use it for page layout. In fact, HTML documents look different in every browser -- which is not, I think, a characteristic that most users are going to desire for a large subset of documentation. How, for example, can you specify a an OCRable form, if the rendering program is free to move the damn boxes around?

I think that's why he says HTML/CSS. HTML takes care of the markup, while CSS supposedly takes care of the layout. I am not absolutely convinced that it actually works, but notice that the basic idea behid LaTeX is exactly that. LaTeX is supposed to be really just a markup language (I know it doesn't actually work that way), and document styles and packages are supposed to specify the layout.

If someone would like to propose an standards based HTLL that focuses on document layout, they have my support. I don't care if it is XML based. Just that it works, is reasonably concise, everyone uses it, and that it replaces PDF as a vehicle for specifying documents that need to be rendered pretty much exactly as the author specified them.

The question is, do we really need to replace PDF? I think the article was about replacing wordprocessor formats, not PDF. They are two very different things.

Re:fsck'n ugly

[TheRaven64]

I had a little go at using HTML for this kind of thing a few years ago. One thing that you might not be aware of is that CSS has a few things related to pagination. While you can't say 'put this image on page 4,' you can say 'if you need to put a page break in, put it before or after this div, so that this text and this image are on the same page.' For the table of contents, I wrote some ECMAScript that scanned the DOM tree for h1-4s and built a set of nested lists to display it, with links to the real headings. It didn't print the page number because, although this is possible with CSS it wasn't implemented in any browsers when I tried it. The embedded fields are already supported by meta tags in the document head. Footnotes, however, are a tremendous pain to get right with HTML.

I just dug out the template I wrote, and the pagination and ToC worked fine in Safari. The auto-numbering of headers, however, didn't. This is due to a lack of support for counters in generated content, and the same problem with Mozilla was a significant reason for abandoning the whole idea in the first place; the only browser everything worked in was Opera.

Another significant reason for abandoning this idea (not entirely relevant when talking about document formats being generated by tools) was that HTML is a huge pain to type, and XHTML is even worse. Something semantically equivalent to XHTML but using S-expressions would have been fine, but typing XHTML just involves spending far too much time hitting > and < keys (not to mention the redundancy of close tags having the full tag name). I turned to LaTeX, which is easier to type and also (being a Turing-complete programming language) much easier to extend than HTML.

Re:Um... NO

[monomania]

Isn't the idea of an "office" document a fiction? The idea that these disparate representations or methods of manipulating data (spreadsheets, publications, A/V presentations) should (or even could) be subsumed within a common file format is rather boffy. The whole paradigm is derivative of the way applications that fulfill these functions have been bundled. If MS had dubbed their flagship application product "MS Adminstrative Assistant" we'd all be referring to to a common format for 'Administrative Assistant' documents. I still don't buy this model...We took the wrong fork in the road some miles back. Is it too late to ask for the RIGHT directions?