Opera CTO Hits Back at Microsoft's Standards Push 246
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."
fsck'n ugly (Score:5, Insightful)
Classic quote for the books, gotta love XML play (Score:5, Insightful)
CSS for Documents? (Score:5, Insightful)
Having a word processor act more like a web browser would be awesome. Ever since I started using word processors (which for me was a long time after I started using web browsers), i've always thought, why doesn't updating this style make all text with that style update? Why do I always have to change the same thing over and over again?
While turning word processors into web browsers would be stupid, things like CSS would be awesome to have in word processors.
I don't know that I agree completely (Score:5, Insightful)
Sure, it works, with enough tweaking, and CSS3, and a $350 download of a product to turn HTML/CSS3 into a PDF. This is better how? What about LyX, LaTeX, or even OpenOffice if you are just going to convert to PDF?
The whole HTML/CSS-to-print thing shoots the real argument in the foot.
I don't think he gets it. (Score:2, Insightful)
Somehow I don't think that's going to fix the problem. Oh, and pointing out that the Microsoft letter doesn't validate. Isn't that a little petty?
Re:CSS for Documents? (Score:3, Insightful)
Lyx provides a GUI front end, but you lose a lot of flexibility.
Texmacs might work for you as well, although I found it very clunky.
Re:fsck'n ugly (Score:5, Insightful)
You don't typeset with Microsoft Word, either. Which makes the entire argument specious. Word processors like MS Word and OOo Writer are for creating common documents like letters, memos, and maybe the occasional flyer. Neither one is particularly good at anything even close to professional publishing work. Even the book authors just use Word (or surprisingly, OOo Writer!) to do the text content. That text is then exported to a more sophisticated program, where the actual typesetting and page layouts are done.
I think this fellow's point is that HTML/CSS formats can store any information that a Word Processor might need to store, with no need to invoke new technologies. To a certain extent, he may be correct. Unfortunately, HTML/CSS may make a good intermediary format, but it is not particularly good from a performance or usability perspective. Then again, XML formats in general are fairly poor choices for the same reason.
I think if we want to break this conundrum, the industry is going to have to learn how to keep local data stores that are of high performance, while exporting intermediary formats when emailing or uploading to external computers. The only problem is finding a way of doing this so that it's completely transparent to users. The mythical "mom" doesn't want to worry about emailing a document in the right format, or having the right program to read the attachment she received. She just wants it to do what she tells it, with no bloody prompting with questions she has no answers for.
Validation is relevant (Score:3, Insightful)
But if the Oasis pages did validate, the basic argument goes like this: "How can they claim to care about standards if they can't even bother to support that most universal standard of standards, HTML?" And indeed, I could still make that argument -- just look at the sad, sad state of affairs that is Internet Explorer's CSS [mis]handling.
Re:Is it mature enough? (Score:3, Insightful)
Can != Should (Score:3, Insightful)
HTML + CSS vs. Word vs. OO.o seems to me to be an argument related to formatting documents, not a "book". It's not that you couldn't do it, but I'd consider using Quark or InDesign (what seems to be Adobe's successor to PageMaker) or even Tex and its variants (haven't used any Tex-based stuff, but heard wonderful things) for typesetting.
Arguments about standards aside, proof of concepts aside, I'd think that the real issue when it comes to any job is using the best tool for it. It's not a question of whether you can use these tools to typeset a book, but if you should.
The point of the proof of concept is to prove that the system is flexible or capable enough to go beyond its original intended use. I get that. But proving a chainsaw can be used to spread butter, doesn't mean it's inherently superior to a coping saw.
- Greg
to kill a mockingstandard (Score:3, Insightful)
Why not HTML for books? (Score:2, Insightful)
It would be possible to extend HTML to include such features or to create a HTML-like format that is more suitable for books (cf docbook). I agree that "word processors" today are a horrible mess, and we definately need something like a modernised LaTeX, but HTML isn't it.
Re:fsck'n ugly (Score:5, Insightful)
6000 Pages, say 30 pages/day, =200 days (Score:1, Insightful)
Oh and the spec is defined to fit an existing product, so that product fits the spec and there are unspecified patent hurdles attached to it. Wow which idiot would fall for that one.
Too true (Score:4, Insightful)
Re:How come? (Score:3, Insightful)
My speculation would be that no-one wants to sit and read a 6,000 page specification. 700 pages is far more palletable.
It's a crap way of judging the relative merits of specifications, but human nature will out.
Re:huh? (Score:3, Insightful)
If they spelled everything out without any ambiguity it would make a better standard.. but then it would be another "600 page long" standard with is what he seems to be against in the first place.
Re:I don't know that I agree completely (Score:4, Insightful)
Re:fsck'n ugly (Score:3, Insightful)
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?
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.
While I'm sure that an HTLL specification would be lengthy, I don't think it needs to embody every quirk of every version of Microsoft Word or Open Office.
Re:fsck'n ugly (Score:5, Insightful)
- position an image on page 4 of my document?
- add footnotes?
- embed fields (date, last editor...)?
- mark the embedded TOC as TOC so that it gets regenerated on reload?
etc.
And on the CSS side, there are quite a lot of shortcomings, too.
Of course, all of this would work with custom XML tags or special id/class conventions, BUT then you'd have to specify those. And getting this below 700 pages won't be easy.
So repeat after me:
HTML is *not* a description language suitable for word processing in its current state, and it is unclear it can be made so without sacrificing device indepence.
Re:CSS for Documents? (Score:4, Insightful)
Word DOS (version 4 at least) had it back almost 20 years ago. And actually it was much easier to use styles back in the DOS version. Current versions try so hard to second guess you in the quest for user-friendliness and layering features on top of features that you can change or create new styles without knowing or intending to. Old-school required you to RTFA, but then you could use styles very efficiently. Now styles are much more sophisticated, but hardly anyone uses them correctly. I get docuements from all kinds of people, including many university lecturers. None, out of hundreds over the last 15 years, has had a clue of how to style their documents. Headings are "Normal" with font commands to make them large; body text is "Heading 1" converted to 12-point Times; bulleted and numbered lists are a minefield, tables are a quagmire of hacks, spaces and tabs, etc...
Re:CSS for Documents? (Score:4, Insightful)
Every word processor I've seen like forever has support for styles. The problem is:
1) It's impossible to avoid creating a million new styles by accident. Try looking at the styles list and you'll see it's full of junk
2) It's impossible to clean up a document with such a bunch of styles, for example say you have a document which has been completely fucked up with pseudo-styles. You've set "Normal" to be what the bulk text should be, and "Headings" to what they should be. What happened last time I tried it? Well, it was impossible to easily apply it without killing any bullet lists, bold, italics or any other intended variation of the normal text. Headers and numbering went beserk. Trying to do the same with the bullet list style lead to numbers going completely nutzoid, for some reason it thought everyone in the same style belonged to the same list so later lists would start at some random number.
3) If you for some reason is stuck copying between different versions of Word (norwegian and english comes to mind) then you'll have double the number of styles, which obviously aren't in synch.
So to sum it up what I would like:
1) Don't auto-create styles
2) This sentence does not contain three styles
3) Sane "apply style" functions
- Parituclary directed at fixing a mess
4) Make styles have an ID, at least for the default ones make them international so header 1 is header 1 in every language
5) Ability to "style-lock" documents for things like company standards, you can create new styles but not just randomly change around sizes and fonts
6) More visible styles (OpenOffice does this, MS word doesn't) because people don't see them
Re:I wrote my thesis book this way (Score:3, Insightful)
Those who don't understand LaTeX are doomed to reinvent it... poorly.
Re:fsck'n ugly (Score:4, Insightful)
No offense, but I'm getting sick of this line of reasoning. You're right, mom wants the computer to read her thoughts, know exactly what she really meant when she said X, anticipate every need she might have, and pre-calculate its complexity out of existence.
In other news, my boss would like this entire website built in one hour ($40), never need support, and scale to 300,000 users.
At a certain point IT's job goes from "give every user what heshe wants" to "educate users about what is feasible in the current technological situation.
You're using the wrong tool. (Score:4, Insightful)
Re:fsck'n ugly (Score:4, Insightful)
Footnotes are easy, too: Text Text that needs a footnote.<div class="footnote">This is the footnote</div>. That's the same concept as in LaTeX, the best typesetting software out there.
Re:How come? (Score:3, Insightful)
Well, the basic parser isn't really an issue. I haven't investigated either standard in any detail, but assuming they're actual XML, or even reasonably close, there are a million libraries that can handle the parsing. Expat, Xerces, Arabica, the Qt XML parser, and the Java library XML parser come to mind.
The majority of the work is interpretting the tags and actually laying out the document in a standardized way. I can already load a Word *.doc file into OpenOffice and have it look relatively close to how it looks in Word. The reason it only looks "close" is that the Word .doc format isn't documented, so developers for competing products have to make some assumptions and ignore some stuff they can't figure out. Having a standard is supposed to rectify that.
Ideally, with a standardized format, a document would look identical in any word processor that supported all the features used by the document. That's the whole point.
Off-topic: I absolutely hate when people make statements like "I'm no programmer, but I could write that software in very little time." Contrary to popular belief, programming isn't trivial. Sure, you may be able to write the parser in very little time, but would other people want to maintain your code? Would people reading your code even be able to tell what you're doing? Would it have fewer bugs than code written by actual programmers? Would it be fast enough? Would you know what to do if it wasn't? Sorry, it's just a pet peeve.