Yes, more delays.
Rather than another long-winded post, I figured that this time I’d just give an example of how HTML approaches things compared to Word. Hopefully this will illustrate why I’m such a strong proponent of the former.
Specifying an image in HTML
<img src="filename.png" width="66%">
Specifying an image in docx (method 1)
<w:drawing> <wp:inline> <wp:extent cx="5270500" cy="3513667"/> <wp:docPr id="1" name="Picture 1"/> <wp:cNvGraphicFramePr> <a:graphicFrameLocks noChangeAspect="1"/> </wp:cNvGraphicFramePr> <a:graphic> <a:graphicData uri="http://schemas.openxmlformats.org/drawingml/2006/picture"> <dpct:pic> <dpct:nvPicPr> <dpct:cNvPr id="0" name="image"/> <dpct:cNvPicPr/> </dpct:nvPicPr> <dpct:blipFill> <a:blip r:embed="rId1"/> <a:stretch> <a:fillRect/> </a:stretch> </dpct:blipFill> <dpct:spPr> <a:xfrm> <a:off x="0" y="0"/> <a:ext cx="5270500" cy="3513667"/> </a:xfrm> <a:prstGeom prst="rect"/> </dpct:spPr> </dpct:pic> </a:graphicData> </a:graphic> </wp:inline> </w:drawing>
Specifying an image in docx (method 2)
<w:pict> <v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter"/> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0"/> <v:f eqn="sum @0 1 0"/> <v:f eqn="sum 0 0 @1"/> <v:f eqn="prod @2 1 2"/> <v:f eqn="prod @3 21600 pixelWidth"/> <v:f eqn="prod @3 21600 pixelHeight"/> <v:f eqn="sum @0 0 1"/> <v:f eqn="prod @6 1 2"/> <v:f eqn="prod @7 21600 pixelWidth"/> <v:f eqn="sum @8 21600 0"/> <v:f eqn="prod @7 21600 pixelHeight"/> <v:f eqn="sum @10 21600 0"/> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/> <o:lock v:ext="edit" aspectratio="t"/> </v:shapetype> <v:shape id="_x0000_i1025" style="width:96pt;height:64pt" type="#_x0000_t75"> <v:imagedata r:id="rId4" o:title="min"/> </v:shape> </w:pict>
I’ve spent several years building a web-only HTML first word processor. In the process I’ve learned a lot of things about creating maintainable formatted documents with media content, and in the process I’ve come to respect docx a great deal.
Your comparison above is very (very) flawed. For one, where is the data for that image, and how is it stored? With HTML, you must take care to keep an image with a document, which means either embedding it, or finding a good permanent hosting solution. Embedding it is messy, but often required if the documents will be downloaded, emailed, or made into PDFs.
Additionally, what you are looking at above contains most of the styling information for the image, which you’ve left off entirely. Either you will have an external CSS sheet with a fair number of rules, many directed only at that one image, or you will have an embedded style sheet, or perhaps even an inline style sheet.
Then you have to consider cross browser display rules, and your style sheet gets messier, and your end result is probably equal to if not larger than the above docx methods, and no where near as tidy.
And anyone can see just how quickly the HTML method can go bad. Go play with Google Docs, insert an image, move it around, insert a page break, god forbid add a block indent. Where is your cursor? Why is that image in the wrong place? Why is everything broken? (and that’s within a browser they produce and within which they’ve stuffed extra code to make their editor better!).
You’re certainly correct that I’ve glossed over the issue of packaging here, and in fact this is one of the biggest problems with HTML as far as representing a complete document is concerned (and one of the main advantages of docx). Currently when users create a document containing images, the directory is littered with a bunch of jpg/png files, which makes transporting documents around very inconvenient. Ideally I’d like to see a standard packaging format for HTML. EPUB looks good in this respect, though I’ve yet to explore it in detail.
The styling hasn’t been much of a problem in my experience. I do actually wrap all images in figure elements (which is currently the only supported placement option; I’ll be adding inline support int he future), and I add a CSS rule for figures that says they have a margin-left and margi-right value of ‘auto’ (to center them). However this only needs to be done once for the document, and applies to all the figures. Numbered captions also of course require extra markup & CSS rules (using CSS counters), but the same is true of those in docx.
HTML lacks other features like an explicit notion of headers, footers, footnotes, different cross-references types, table of contents etc. I’ve been able to “fake” the latter two through custom style names and javascript code, and while these are displayed fine in browsers they won’t be recognised for their semantic meaning by any other HTML editors as they’re not covered by standards. So this is another area where docx stands out.
LaTeX addresses most of these issues by providing explicit macros for all these things with an equally simple syntax. It’s main drawbacks are that it’s a procedural rather than declarative language, requires complex software installation to render properly (though this point can be fixed, as the Texpad app for iOS shows), and also lacks a packaging format.
My chief complaint with docx is the sheer amount of markup required to do simple things like images and lists – the above examples contain essentially the same information but in dramatically less code. I realise DrawingVML and VML are basically equivalent to SVG in terms of being a generic vector drawing language, but I think a simple way of embedding image files would be much better for this particular case. I also view the whole notion of OPC relationship files as an unnecessary level of indirection, and think that the document should just list the relative path within the package to the image file.
I’d be interested to hear more about your experiences building a HTML-based word processor – what is your app called?