(iBlog) Semantics and Style
I’ve now spent some time evaluating iBlog. Overall it’s a nice little application that makes simple things even simpler and easily allows more advanced manipulation of the presentation of blog content.
The application is very straightforward to use. And works very intelligently with Apple’s .Mac iDisk (the only way I’ve tried it so far, though it does support many other uploading mechanisms). I did have some problems with my Apple iDisk when I tried to keep an offline synchronization. Turning that off has been my quick fix for the problem.
Creating blogs, categories and entries is rather simple. I did encounter one problem: I wanted to be able to change the category of an entry (especially a draft entry), but as far as I could tell that’s forbidden.
Another small UI issue: I wanted to be able to move between title, abstract and body fields through tabbing (and not insert tabs into my html entries).
Third, I wanted it to present paragraphs with vertical whitespace separation (and possibly indents) so that I wouldn’t feel obliged to add inappropriate line breaks in between my paragraphs. That way the html transformation process could simply involve the marking of empty returns with <br /> and those with content as <p> - </p> pairs. As it stands now, all returns involve line-breaks and paragraphs are represented as an ad hoc div element. I talk more about the motivation for better semantic html and the problems with iBlog below.
Finally, I wanted to be able to write entries that left the body blank, including only an abstract and a title. In this way, my blogs act in a mixed mode where I could include complete blog entries on the main page when they were short enough. On the other hand, long blog entries could be separated between an abstract entry and a separate “read more” page. Obviously short entries would hide the “read more” link. One might even do this hiding of the link with css, though I haven’t checked the document to found out. That said you’re welcome to read more on this entry.
My Motivation
Before, I begin in on the details below, let me say that iBlog mainly serving as a tangible example for this discussion. My exploration of iBlog actually began as I was searching for an WYSIWYG HTML editor that treated semantics seriously. I mistakenly thought I would find a long list of candidates fitting that description. I expected to include Macromedia Contribute, Microsoft Word, Mozilla (and all its relations) and, I thought, many other minor freeware and shareware applications. Everything, I’ve evaluated so far has fallen flat on this simple requirement. Each application misses the mark by an enormous margin. Even BBEdit (though not WYSIWYG in one sense) does nothing to embrace the spirit of the of the W3 specification for HTML that separates semantics from style. Open a document in any of these applications and what you see are ad hoc style tools: bold, italic, underline, point size, etc. Nothing for just writing meaningful content like: emphasis, quote, definition, abbreviation, citation, paragraph, heading, etc).
Now, many may say that these applications were never targeted for that purpose. Well yeah… but why? I understand when I first sat down in front of a mac with such a vivid WYSIWYG display of my content, I couldn’t help myself. I started changing the fonts on each and every word, adding bold to these characters; adding italics to those; trying to see who the whole flyer looks in a 72 pt cursive font. However, at some point that fascination wore off and I wanted to actually get some work done. And it’s clear I’m not alone. The W3 specification for CSS1, CSS2, HTML 4.0.1, XHTML 1.0.1, XHTML, 1.1 and the proposed XHTML 2.0 show there are a group of intelligent and dedicated souls out there who have spent a great many hours tackling this issue.
One side of this coin has found a large audience: CSS is a buzzword if every their was one: and this is a buzzword that deserves to be too. However, the flip side of the coin — semantic html — has not been embraced to much extent at all. Take a look at the various analyses of mozilla and it’s Gecko rendering engine on its css support. It’s quite good. But look at the Mozilla composer and try to find support for semantic HTML composition: it’s there, but it’s rather buried. Macromedia Contribute is even worse (and I thought that would be precisely what it was designed for: contributing meaningful content). When Contribute includes semantics it actually places it in its “Style” menu.
Whether for this blog, for my dissertation, for submissions to academic journals or correspondence to my friends, I want to write meaningfully. And I want my writing to be repurposed easily and quickly. Like everyone else, if I write something here on my blog and someone else reads it and wants to put it into print (are you listening New York Times), I want that to be a simple and straightforward process. I want to easily transform my dissertation from the horrendous single-sided, double-spaced, letter-size format required by my University into something more appropriate for such an important tome (or is it tomb?).
The W3 organization has shown us the way. There’s certainly room for refinement and even dramatic additions to the current HTML specification. However, as it stands now it is an excellent specification that, when combined with CSS, XSL-T and XSL-FO, provides everything most of us need to write, edit, publish, display, print, and recite our ideas in a meaningfully rich manner.
I read these various related specification and wonder why anyone feels the need to create their own proprietary document format? Now, I understand these are recent developments and the specification had many shortcomings in the prior decade. But, now I want to just compose everything in HTML and automate a richly cooperative workflow. The W3 has provided us with the specifications to do that, we now need the implements to bring it to fruition.
My Vision
What I want to see is a new word processor (or content processor or semantic processor) that brings these semantic elements to the forefront. As I write this entry, I want to select emphasis when it’s appropriate (the item could provide an indication that the current stylesheet calls for emphasized words to be presented in italics). I want to use headings (rather than bold text and extra line breaks). I want to be able to create structured lists of items (rather than lost of tabs and spaces before my text). All of this is the meaning I want to place in the document. Instead I find my self hacking together text to look like the meanings I want to write.
To complement the focus on meaning, I want it to also provide access to style. Accordingly, the application would link to a default set of named stylesheets providing cascading stylesheet rules for the presentation of the content in the Application’s window. By selecting a named style set from a menu, the application could dramatically change the presentation of my document: or even repurpose the document for another publishing outlet. That would invoke a feeling reminiscent of the thrill I described above in first using a WYSIWYG word processor: to see the content of my document dramatically restyled according to the styles defined by professional typesetters and graphic designers. Cascading Stylesheet editing would also be provided through a nice intuitive GUI. For an example of how this could be done see CSSEdit. However, it could be taken even further by grouping style elements into logical categories (as CSSEdit allows).
And none of this would preclude direct style manipulation of text or graphics within the document. When selecting the complete text of an element, a H1 header element for example, a particular id or class could be assigned to the element, a new stylesheet added to the document and a new rule added for the element of this newly designated class. Alternatively, the user could be prompted to change all the headings of the current level (e.g., h1 as opposed to h2 through h6) and consequently simply adding an element selector rule to the ad hoc stylesheet.
In addition, a user might make an arbitrary selection of inline content and want to manipulate it’s style. In this case an HTML span element could be assigned to the selection an id or class assigned to the span and the appropriate style declaration added to the ad hoc stylesheet. Similarly, when multiple complete block elements are selected (e.g., several paragraphs) a div element could be added as the parent of those selected block elements: assigning id, class and style declaration just as above. Or the selected block elements could simply be classified (add the same class) to them and then add the appropriate corresponding class declaration to the stylesheet.
Providing this in a word processor means I would use the same application without filtering or translating to create properly abstracted content and style whether it was intended for print, projection, recitation, or visual browsing.
Objections
Some object to this vision because they say such an application does not respond to how people think. That is certainly true for some users: and not true for others. Of course applications also transform the way people think. I know they have for me. By flagrantly flaunting style in a users face they start to think about adding bold, italics, increasing the font size, double-underlining the text before they even start to think about what the text will say. We sometimes start to think of our role in using a word processor as selecting how content should appear rather than what it should contain.
But even as an individual consumer application user, I want the ability to easily compose semantically rich documents and leave style to the professionals. That’s not to say if I were designing a one page letter-size flyer I wouldn’t revert to my old ways, but overall that’s not how I approach writing. For collaboration, cooperation within formal or informal organizations the need change our ways of thinking is even more important. When a journal welcomes or solicits content, that content has to meet certain semantic, structural and style requirements. Even after this the content often must undergo lengthy and often cumbersome transformation to reach it’s final published state. Semantic HTML could go a long way toward improving this situation. XSL even promises the ability to automate the preparation of XHTML content for advanced page layout previously unavailable except through various proprietary schemas.
My Hope
Now what’s needed to make all this happen is framework providing a text system for manipulating HTML, XHTML, CSS and XML object model through the direct manipulation of an editable web view. In many ways, I think this is the same thing Apple’s Cocoa text system currently provides but for a rtf text storage system. My hope is that we will see Apple change or enhance the Cocoa text system to facilitate this kind of interaction with the HTML DOM. If this happened we might see a proliferation of applications that did html right (segregating semantics from style).
Apple’s text system is amazingly elaborate as it is. However some notable omissions include support for tables and support for stylesheets. Providing this updated text system would do just that. Whether this new text system could serve as a drop-in replacement for the existing one would be a long-shot, but by providing careful polymorphism with the methods and instance variables of the existing text system along with a similar treatment for things such as font metrics, Apple might just pull it off. What I’m suggesting is that XHTML become the native text storage system for Cocoa while providing continued support for RTF, plain text and .doc through filters.
Conclusion
Whether provided through next-generation Cocoa frameworks or not, a text system and derivative applications that treated the divide between semantic html that has been provided in the latest html and xhtml specifications on the one hand and on the other hand style sheets like those contained in the css2, css3 and xsl specifications would be an enormous help in providing authors, editors and publishers the tools they need to streamline the complete publishing workflow. If done correctly, very little would need to change in an application like iBlog, except that the first two buttons in it’s button bar, Bold and Italic, would be replaced by emphasis and strong emphasis. The underline would probably best just disappear. Finally, the other semantics available in HTML should be exposed to the user (e.g., lists and headings).
