Saturday 24 July 2004

My kingdom for a web editing tool

In a post titled Authoring Pain, Tim Bray points to the dearth of good writing tools for the Web:

The state of Web authoring tools is kind of like the state of what we used to call “Word Processing” twenty years ago when I was getting into this business. If everyone’s going to write for the Web (and it looks a lot of people are going to) we need the Web equivalents of Word Perfect and Wordstar and Xywrite and Microsoft Word, and we need them right now. The Atom protocol will give them a standardized way to push the content online, and the fact that it’s all open formats will make it real hard for a monopolist to scoop out the market. So, who’s building them?

My previous wiki entry, as it happens, was partly prompted by an ongoing conversation I’ve been having with Marius Coomans about Web editors. He had noted the rudimentary nature of the inline editor that is integrated with TypePad (I have a vague recollection that Movable Type has a similar editor that only works with IE). Marius suggested I try BlogJet. Which I did, for five minutes. That’s all it took to install and launch the application, connect to my Movable Type blog, create a draft post with some formatted text, examine the HTML, exit, and uninstall. This is the underlying HTML for a test paragraph that included font face, color, and size formatting and another containing a Japanese text string:

<p>Test post with <font face="Courier New">font</font>, <font color="#ff0000">color</font>, and <font size="1">size</font> formatting.</p>
<p>?????????</p>

I wasn’t surprised that BlogJet isn’t Unicode compliant; it did connect to my MT weblog with undeniable ease and simplicity; and, to be fair, I’m not the target audience for the product. But the f#&*ing <font> element!? Are these people stupid, or wilfully ignorant, or have they been asleep for nearly five years? (The <font> element was deprecated in HTML 4.01 on 24 December 1999.)

None of the above, as it happens. As we’ll see later, the BlogJet developers rely on others to fix their mistakes.

Curious, I did a Google search on “browser based editor” and tried Editlet, which boasts “100% pure XHTML output with HTML source editing”:

<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"><html><head><link type="text/css" rel="stylesheet" href="http://www.editlet.com/testdrive/dhtml/editor/css/sample.css" /></head><body><font size="3">Test post with <span style="font-family: arial;">font</span>, <span style="color: rgb(255, 0, 0);">color</span>, and <font size="1">size </font>formatting.</font></body></html>

If this is XHTML Strict, I’m Murasaki Shikibu (or the XHTML spec has been recenty relaxed to allow the <font> element). I suggested to Marius that most of the currently available web editors probably produce garbage like this.

Unabashed, he then pointed me to Blogger’s inline editor. I remembered I’d set up a Blogger account when I first started to think about weblogging in December 2001 and, much to my surprise, the username and password still worked.

Blogger had received the draft post I sent from BlogJet so I set the character encoding to UTF-8, replaced the “?????????” paragraph with the Japanese string, and saved the post. Blogger’s underlying HTML looks like this:

<p>Test post with <span style="font-family:Courier New;">font</span>, <span style="color: rgb(255, 0, 0);">color</span>, and <span style="font-size:78%;">size</span> formatting.</p> <p>
日本語のテキスト。
</p>

Amazing! Blogger’s editor has replaced BlogJet’s crappy <font> element with <span> elements and inline CSS declarations. Not elegant—in that inline CSS is almost as difficult to maintain as the <font> element—but at least the page should validate.

What I want though—and perhaps I’m in a minority, though Tim Bray’s post would suggest not—is a web-based editor that, in addition to being Unicode-compliant, will recognize my external stylesheet and give me access, via a menu, to the custom (class) styles I use to format the text in many of my entries. Ektron’s eWebEditPro does this and it produces valid, Unicode-compliant XHTML. But it’s only available in a ten user license for US$359 and it doesn’t understand any of the weblog APIs.

Google engineer Massless, in a post titled A note on the usefulness of WYSIWYG editing in the browser, effortlessly skates around the need for proper Web authoring tools:

For content creators who require more advanced styling controls and content information including positioning, page counts, floating elements, templates, varied encodings, and block-level margins and padding there are many tools available that they prefer using to a browser. We know for sure because we’ve asked and asked and asked and, to date, advanced content creators find the convenience and ubiquity of browser-use less useful than using a feature-rich client. Additionally, many advanced content creators (hint: if you’re reading this, I’m very likely talking about you :) know enough HTML and CSS that hand-coding style attributes and class selectors enables you to create content faster than when using WYSIWYG components for the same tasks…

So, it became evident during testing trials at Google of WYSIWYG editing that a large set of people have learned a minor set of HTML for basic expression needs, and have grown so accustomed to using them that a WYSIWYG mode which didn’t easily allow these people to compose using that markup presented large and sometimes unacceptable interruptions to their content creation task. Furthermore, having a place for them to enter a “source mode” only frustrated them further as they wondered where the styling went. You see, some of us know some HTML but not all, and with broader expression available to them, these new-to-them tags presented challenges that were, at times, more annoying to them than if WYSIWYG didn’t exist.

These two paragraphs can be paraphrased as:

We decided to take the Microsoft approach by dumbing the application down to the level of the lowest-common-denominator user.

Unfortunately, they didn’t fully understand the Microsoft approach, which is to dumb the application down by hiding the advanced features—not by eliminating them altogether. Admittedly, this is a formidable user interface challenge but, given that the Blogger makeover is so impressive, it shouldn’t be beyond their formidable abilities. (After all, Ektron have already figured it out with eWebEditPro.)

I’m an advanced content creator who, like Tim Bray, wants the convenience and ubiquity of browser-use together with the advantages of a feature-rich client.

I have feature rich clients coming out of my ears: Microsoft Word, Dreamweaver, TopStyle Pro, CSE HTML Validator. My current workflow is:

  • Write the entry in Microsoft Word (the outliner is passable, the spell check is useful, I love Document View, and it’s easy to add hypertext links).
  • Copy and paste the text into Dreamweaver, where I do the more complex formatting.
  • Validate Dreamweaver’s XHTML with CSE HTML Validator.
  • Paste the validated XHTML into Movable Type’s blog entry text area.

This is, frankly, bullshit. And, I’m beginning to think, part of the reason that lately I haven’t been posting more frequently—writing an entry of even moderate length is unnecessarily painful.

Why can’t Tim and I have a decent WYSIWYG browser-based editor? Or, speaking for myself, even a standalone application with the features I’ve listed? (And, before anyone says “ecto”, I don’t have a Macintosh, I don’t have the ready cash to buy one, and I have no intention of ever installing the .Net Framework, which the Windows version of ecto requires.)

Am I alone in this? Are the rest of you quickly and easily creating validated, Unicode-compliant XHTML weblog entries without the slightest fuss or bother? If so, please leave a comment and put my out of my misery…

P.S. Don’t mention Textile, either. I tried it and I didn’t like it.

Permalink | Technorati

TrackBacks

Ping: http://weblog.delacour.net/cgi-bin/mt-tb.cgi/255

It started with Scriping News then Kottke which I accepted without question (for some reason) but now it's getting out of control. Web site blocking in the corporate environment is fair enough, after all who wants their employees gambling, looking...

Posted by notestips.com by Mike Golding on 27 July 2004

Jonanthon Delacour wrote about his frustration of the lack of web based WYSIWYG editor for bloggers. At the end of the post, ecto (both Mac and Windows versions) is mentioned. The quote that catches my eyes: "and I have no

Posted by ecto on 28 July 2004

No easy solution

Posted by Random Neural Misfirings on 28 July 2004

Tim Bray: The state of Web authoring tools is kind of like the state of what we used to call “Word Processing” twenty years ago when I was getting into this business. If everyone’s going to write for the Web

Posted by Preoccupations on 28 July 2004

Comments

Tried WordPress?

Posted by chutney on 25 July 2004 (Comment Permalink)

What about Markdown?

http://daringfireball.net/projects/markdown/

A simplified text markup system, similar to Textile, it's key difference is that it allows you to drop in X/HTML for tricky tasks where nothing else will do (which somewhat parallels the approach of Google/Blogger's new WYSI-mostly-WYG editor).

Posted by dave on 25 July 2004 (Comment Permalink)

Dave, your comment appeared not long after I'd received an email from John Gruber explaining the features of Markdown. I've long been an enthusiastic user of John's SmartyPants so I'm going to install Markdown and give it a spin.

Interestingly, one of Tim Bray's email correspondents (Tim's updated his post) suggested that a standard XSLT export filter for Open Office might do the trick. That would offer the advantage of using a real word processor to do the writing.

Chutney, either you're being ironic or my post wasn't as clearly written as I'd hoped. I'm looking for a web writing tool, not a content management system. WordPress's inline editor is a nicely-designed code editing environment that doesn't address any of the concerns I discussed in my post. WordPress + PHP Markdown + PHP SmartyPants might do the trick, though. On the other hand, so might MovableType + Markdown + SmartyPants.

Posted by Jonathon on 25 July 2004 (Comment Permalink)

Actually, Markdown is included as part of the Wordpress installation, as an optional plugin to the editing interface. This is detailed at http://www.michelf.com/projects/php-markdown/

Posted by Shelley on 25 July 2004 (Comment Permalink)

Oops, hit return too soon. Too bad you don't have my newly designed Advanced Editing comments feature that I just incorporated into my Wordpress weblog; if you did, I could have edited that last comment.

(My, aren't I starting to sound quite the little fan.)

What I was going to add is that Markdown is great for valid XHTML and formatting, but I've just started using HTMLPad because of the built-in spell checker. That's the kicker for me now.

It creates the text, spell checks, cleans and tidies, and then validates. However, it doesn't use an external stylesheet and you still have to copy to your weblog tool. But getting closer.

Posted by Shelley on 25 July 2004 (Comment Permalink)

I would be content with a word processor that just saved in garden-variety HTML with CSS 1, 2, and 3 for styling. CSS 2 and 3 support paged media and other things needed for word processing. For online use, the browsers don't need that stuff and would just ignore it. And my stuff would be human-readable and in a standard format that is so widely adopted that it will be supported for decades. This page discusses some of these things: http://muux.com/wp/

Posted by Kresten on 25 July 2004 (Comment Permalink)

Kresten, the XHTML/CSS word processor you describe sounds like it would meet almost all of my needs. I'll be interested to see if the idea takes off...

Shelley, John Gruber had already won me over to Markdown, which I liked as soon as I understood how it works. I was worried that using it in MT would lock me into staying with MT but Michel Fortin's PHP Markdown and PHP SmartyPants plugins mean that I'm free to move to WordPress if I wish.

Unfortunately, HTMLPad doesn't seem to understand Unicode so that nixes it for me. UltraEdit looks OK though...

But wait! My favorite text editor, TextPad, turns out to be Unicode-compliant -- I don't need to use the localized Japanese version. And it integrates seamlessly with CSE HTML Validator. Maybe I can do everything in a text editor, like the really cool people!

Posted by Jonathon on 25 July 2004 (Comment Permalink)

But Jonathon, all the _really_ cool people have a Mac.

Posted by Shelley on 26 July 2004 (Comment Permalink)

Jonathon asks:

"Am I alone in this? Are the rest of you quickly and easily creating validated, Unicode-compliant XHTML weblog entries without the slightest fuss or bother?"

Um, no. I use Dreamweaver, but mostly I hand-code everything. For me, that's easier than trying WYSIWYG my way through.

Posted by Lisa on 26 July 2004 (Comment Permalink)

"What I want...is a web-based editor that, in addition to being Unicode-compliant, will recognize my external stylesheet and give me access, via a menu, to the custom (class) styles I use to format the text in many of my entries."

Program
http://www.nvu.com
Screenshot
http://www.alanwood.net/unicode/utilities_editors.html#nvu
Author interview
http://mozillanews.org/?article_date=2004-05-26+21-38-02
Author site
http://webperso.easyconnect.fr/danielglazman/weblog/dotclear/index.php

Free, cross-platform, open-source Nvu gets you there. Stylesheets via menu and Unicode support are no problem. It aspires to be a true WYSIWYG editor without being dumbed-down. It sports real-time, mutually updating, WYSIWYG and markup views. It offers a site FTP capability too.

Nvu is stand-alone, but based on Mozilla, so it's arguably "browser-based." What it lacks in the present 0.3 incarnation is XHTML. Many users are asking for that, and it will come. The author is a true web standards guru and has corporate backing from Linspire. It is not a hobby project.

Posted by Mark on 26 July 2004 (Comment Permalink)

Shelley, usually it's me who is accused of deliberately stirring up Mac "controversy" but this time I'm not going to bite.

Lisa, I would never have believed it a week ago but I'm about to go back to handcoding too (using Markdown, though).

Mark, thanks to the pointer to Nvu. I'd checked Alan Wood's Unicode editor page and can't understand how I missed Nvu. It looks really promising but the lack of XHTML support is a deal breaker. I read the interview with Daniel Glazman and saw the requests for XHTML support in the comments. It'll be great if, as he hopes, Nvu can become the companion standalone editor to Firefox and Thunderbird. I'll keep following Nvu's progress.

Posted by Jonathon on 26 July 2004 (Comment Permalink)

The Nvu author sits on W3C standards committees and works on XHTML. It's hard to picture Nvu not doing XHTML in the near future.

Because XHTML 1 is really just XML-ified HTML, it's fairly simple to post-process Nvu markup with any number of tools to make XHTML. Anyway keep an eye on it!

Posted by Mark on 26 July 2004 (Comment Permalink)

Hi, all. I'm Massless. This looks interesting.

------------
"I’m an advanced content creator who, like Tim Bray, wants the convenience and ubiquity of browser-use together with the advantages of a feature-rich client. ..Why can’t Tim and I have a decent WYSIWYG browser-based editor?"
------------

I think it's a great question. Part of the answer must necessarily lie in the "browser-based" part of the requirement which means relying on vendors to help supply the tools to making wysiwyg work well. I've talked specifically with Mozilla and Safari developers about wysiwyg in their browsers, and it looks like their development and support for rich editing will continue quickly. However, a big challenge lies in supporting MSHTML as Internet Explorer looks likely to have slow feature development for some number of years until Longhorn ships.

------------
"Amazing! Blogger’s editor has replaced BlogJet’s crappy element with elements and inline CSS declarations. Not elegant—in that inline CSS is almost as difficult to maintain as the element—but at least the page should validate..."
------------

True that. It was a particular requirement that I and Google support fought for. It should be noted, however, that Blogger's editor is in early development and that we hope to allow varying control over what level of validation you'd like a wysiwyg editor to provide.

------------
"...inline CSS is almost as difficult to maintain as the element—but at least the page should validate."
------------

Yep. Inline CSS presents varying problems. But solving the problem currently means solving several other problems. First, inline-styling is what Mozilla's Midas (the wysiwyg component) returns by default. The second is identifying at what point a user is requesting a semantic idea that's represented in markup and what point they're requesting a specific font-styling and expect a certain result. In various contexts this distinction can be important. (For instance, environments where an tag has CSS that instructs the browser to *not* make child text italicized.)

------------
"These two paragraphs can be paraphrased as:
We decided to take the Microsoft approach by dumbing the application down to the level of the lowest-common-denominator user.
Unfortunately, they didn’t fully understand the Microsoft approach, which is to dumb the application down by hiding the advanced features—not by eliminating them altogether. Admittedly, this is a formidable user interface challenge but, given that the Blogger makeover is so impressive, it shouldn’t be beyond their formidable abilities."
------------

Which I take primarily as a note that I should write with brevity. :) But, seriously, Jonathan, I think your attempt at reducing a portion of my post misstates some things.

1 - You've assumed Microsoft was a model for this approach which is incorrect. Though there's no one model we have, Dreamweaver or Homesite would be more appropriate to use as a reference.

2 - You've asserted that Microsoft's approach is to hide advanced features, which gets into the tricky areas both of identifying what's an advanced feature and identifying when something is hidden. I ask the following questions because I'm genuinely curious, particularly if there's something I can further understand in improving our interfaces. In Longhorn, is the sidebar an advanced UI feature? Is a toolbar menu or button a hidden property? (i.e. is the File menu hidden?) Are Minimize or Maximize advanced features? Are they accessible? Is the Control Panel hidden? (Click on Start, then on Control Panel in Windows XP and Longhorn.)

3 - Blogger didn't eliminate any advanced features of its implementation of wysiwyg. They just haven't been released yet. :) The event model and the interface is about to get significantly more complex and much more work has to be done before the next upgrade.

------------
"effortlessly skates around the need for proper Web authoring tools"
------------

What do you mean?...I think that skating took a lot of effort.

*rim shot*

Pay your waiter, folks, It's a down economy. No, really, what do you mean? I didn't mention or discuss the *need* for proper Web authoring tools...I just mentioned what people *told* us they preferred. As in the following from the same post:

"there are many tools available that they prefer using to a browser. We know for sure because we’ve asked and asked and asked ..."

But I'm in your camp. Which I think puts me also squarely in the "advanced content creator who wants the convenience and ubiquity of browser-use together with the advantages of a feature-rich client" space and I want the following in a wysiwyg browser editor:

- Syntax coloring when editing HTML

- line numbers

- customized tags and markup snippets

- CSS imports (i believe some editors out there support this already)

- form controls

- minimize and maximize of editing-size and real estate

- built-in spellcheck

- import and export to other web (and native) applications

Now that's not very complicated, is it? There's likely to be an overwhelming number of cross- browser, perfect-for-integration-into-my-application solutions that meet these requirements, aren't there?

*sighs*

Maybe for 2.0... :)

(Side note: I wish a Big Co. who's had to solve some of these problems before would make their cross-browser client-side solutions either available as open-source projects or readily documented and do the rising-tide-lifts-all-boats thing. Something like the System R / IBM relationship with early relational database development.)

Posted by massless on 26 July 2004 (Comment Permalink)

Chris, thanks for taking the time to make such a comprehensive and good-humored response to my post. Clearly you've understood that, beneath my rhetorical exaggerations (about Microsoft's development strategy, for instance), I very much admire what you've achieved so far with Blogger's editor.

I take your point about "relying on vendors to help supply the tools to making wysiwyg work well" but, with the Internet Explorer team having only recently awoken from their long period of hibernation, I'd hate to think you were relying on them to support rich editing when they already have so many other problems to address.

Perhaps Google's implementing the features you list at the end of your comment for Mozilla and Safari users only might be a way of applying the blowtorch to Microsoft's belly? Though I imagine the politics of that decision would be difficult to defend.

As for "asking users what they want", this may be heresy (or politically incorrect) but my experience is that only a tiny minority of users can offer useful responses to that question. I recall a speaker at a conference some years ago -- it might even have been Donald Norman, though I can't be sure -- saying that if you asked the average user what he or she wanted in a product, most would ask for something that was 10% faster, and 10% cheaper, and that weighed 10% less than what they were currently using. I believe that true innovations come from the individual or a small team -- Blogger is an excellent example of this. I may be mistaken but I very much doubt that Evan Williams asked users what they wanted in a blogging tool. And even the most sophisticated weblog software available now owes an enormous debt to Evan's vision.

Anyway, I'm pretty happy with the features you've listed at the end of your comment. The only question is: how long before you ship?

Posted by Jonathon on 26 July 2004 (Comment Permalink)

Forget transparent CSS handling. Simply having WYSIWYG _HTML_ handling is enough of a problem.

Our existing goal of WYSIWYG is entirely paper-oriented. Paper is the ultimate WYSIWYG technology, and the yardstick against which all others are judged. Writing for the web--especially "advanced content creation"--is qualitatively different. How do you write an HREF attribute wizzywiggily? Or a TITLE attribute? Or distinguish between CODE and SAMP tags? You don't, because they have no inherent WYSIWYG value. If all you are interested in is WYSIWYG, then hey, FONT tags are great. If you're interested in semantically correct markup, you need something different. There's too much going on behind the scenes that could not be translated to paper.

Now, that "something" could be a hell of a lot better than what we have now, which is either writing inline HTML or pseudo-HTML. And I only have some nebulous ideas about what that something should look like. But WYSIWYG is a red herring when it comes to web writing.

Posted by Adam Rice on 27 July 2004 (Comment Permalink)

You might consider cuneAform.

http://cuneaform.mozdev.org

It claims XHTML. It offers either client or server side editing, but I know very little else about it. Free, open-source.

As far as converting HTML to XHTML, it's
easily done with HTMLTidy.

http://int64.sourceforge.net/tidy.html
http://tidy.sourceforge.net/

Posted by Mark on 27 July 2004 (Comment Permalink)

Hi! We're not stupid, not wilfully ignorant, and no, we haven't been been asleep for five years. We just have an Internet Explorer engine for WYSIWYG editor. However, future versions will fully support XHTML.

Posted by Dmitry on 27 July 2004 (Comment Permalink)

Aren't you a bit downsizing the full implications of the point arised by Tim Bray? You referred to editing improved tools and ubiquity of the web as the elements we should make live togheter in order to open a whole new field to content creation. However this could result in just a demand of better client for the user to interacte with current publishing platforms.
As important as these aspects are it's seems to me that saying so leave behind a crucial piece of the ideal paradigm of publishing throught the web: the logical organization of documents.
Here lies the great oppurtunity the web has over desktop wordprocessors, which grew on the premise of giving users full control over their personal work, but at the price of semantically poor fragments of information, scattered around and unrelated one each other.
I agree that instruments to produce proper code while offering at same time an appealing experience will give a boost in this direction but there's so much more to work on, than just validating markup in an input textarea.
Hope I didn't go off the trail.

Posted by Antonio on 27 July 2004 (Comment Permalink)

At some point web browsers need to support a Save feature. None of us can do any serious work in a web browser until we can save the work as we go, yes? The web browsers themselves are dangerous and buggy and crash. I'm sure all of us have had the experience of writing something brilliant and then, before we can hit the submit button, the browser crashes and takes our work with it. Often this is quite painful. The best love letter I ever wrote my girlfriend vanished when the browser crashed, so she never saw it. And of course, I didn't have the energy or inspiration to write it again from scratch. There is no point coming up with a tool that integrate into the browser unless there is a way to ensure that one can save the work.

I've lost much good work due to the bugginess of web browsers. I've often wondered when the major browser vendors will realize people are trying to write important stuff using those tools. We need more word processing features built into the browsers.

Posted by Lawrence Krubner on 27 July 2004 (Comment Permalink)

Of course, you're not alone. Here's my long time take on the same subject:

http://www.padawan.info/weblog/authoring_pain.html

I see you've found eWebEdit pro, unfortunately it is awfully expensive and tied to Redmond's monoculture.

You should also check Macromedia Contribute, it's not matching your dreams yet, but they surely have got a few things moving in the right direction.

Posted by padawan on 27 July 2004 (Comment Permalink)

"But WYSIWYG is a red herring when it comes to web writing." Adam, a couple of days ago I would have disagreed with you but now, since absorbing the feedback to this post, I find myself firmly in your camp.

Mark, thanks. I checked out cuneAform but the website didn't provide enough information to make me feel comfortable about installing it. I'll keep an eye on how it progresses.

Dmitry, thanks for the clarification. As I made clear in my post, I was very impressed with how easily BlogJet connects to one's weblog. With XHTML (and, hopefully) CSS support, BlogJet should be a impressive product.

Antonio, you didn't go off the trail at all. I've already suggested that this conversation has clarified my true concern: not a WYSIWYG tool so much as a process that allows me to focus on writing properly structured documents.

Padawan, thanks for the pointer -- you've been thinking (and writing) about this for a long time! I've also been disappointed by Ektron's decision to tie themselves so strongly to Microsoft. I'm familiar with Macromedia Contribute and agree with you that it is "one of the best editors for content workers out there." But, at US$149 a seat, it's clear that Macromedia don't see frustrated webloggers as a potential market. It'll be interesting to see where they take it, though.

Posted by Jonathon on 27 July 2004 (Comment Permalink)

> at US$149 a seat, it's clear that Macromedia don't see frustrated webloggers as a potential market

That is correct, they're targeting companies who can afford this for their content workers but would not pay the full price of Dreamweaver (nor would they have the use for it anyway). Note that a company such as mine can get *much* better price than that, actually way cheaper than eWebEdit pro.

I'm keeping an eye at Contribute because the concept is really interesting (browse site > click "edit this page" > save... and its ability to get properties from your CSS file). I'm also keeping an eye on Nvu, but Daniel doesn't have exactly the same agenda in mind (if I understood well what he told me, plus he has a corporate client to serve, bloggers don't pay his bills ;-).

Posted by padawan on 27 July 2004 (Comment Permalink)

Padawan, I should have also added -- when talking about Contribute in my previous comment -- that I didn't think about Contribute when I wrote this post because of its focus on editing static pages. Like many webloggers who think about this issue, I assume that the content will be in a (MySQL) database. I doubt that it would be much of a technical challenge, though, for Macromedia's engineers to get Contribute to talk to a MySQL via the Atom API (if they haven't already done so).

Posted by Jonathon on 27 July 2004 (Comment Permalink)

There's presentational markup (like or ) and semantic markup ( or ) and it's the semantic markup that is difficult to handle. I wrote about this last year (http://boston.conman.org/2003/11/19.2 )—the hardest part of writing for me is linking. This is a hypertext medium and I can either stop and make the links as I go along, thus loosing momentum, or keep going and hopefully remember to go back to add the links I intended.

I'm not looking for friendly (heck, I know vi although it took the better part of two years) but powerful and nearly invisible to use (after training). I also don't care for WYSIWYG—that's what style sheets are for (I agree with Adam, WYSIWYG is the least of the problems).

(Also, there are bugs in your commenting code and with preview mode. One, URLs end with a space and it was rather difficult to work around—when previewing, the textarea has blossomed with an [A] tag that was impossible to edit; I had to rip out the tag and start over with the URL, remember to include a space at the end. The other problem is that I had originally included some text like <B> (I just now had to convert it back to use entities) but in the preview mode they got sucked out because the entities were converted, which turned it into HTML, which was then stripped on subsequent previews. Nice that you convert entities to their actual character equivilents, but the preview mode returns the munged text to edit, not the original text. Which really, kind of illustrates the point of your post, doesn't it?)

Posted by Sean Conner on 28 July 2004 (Comment Permalink)

> I didn't think about Contribute when I wrote this post because of its focus on editing static pages.

He he... see:

http://www.padawan.info/web/when_dynamic_content_looks_static.html

and

http://www.padawan.info/web/make_my_day_please_integrate_contribute_and_movable_type.html

Posted by padawan on 28 July 2004 (Comment Permalink)

Sean, interesting post (the November one you linked to). I agree with you that the hardest part of hypertext writing is linking. I've switched to using a text editor with John Gruber's Markdown plain text formatting syntax and I have to say I like the way he's handled linking. Markdown offers either inline linking (link text in square brackets, URL in parentheses immediately after) or reference-style linking (link text in square brackets, ID in square brackets immediately after, ID/URL defined at the end of the document). I prefer the reference-style linking because it leaves the document cleaner and easier to read and edit.

I've reproduced your bug -- it seems to occur when the hypertext link is enclosed in brackets or parentheses. I'm surprised you were trying to use tags and entities, since the comment window quite clearly states that HTML is not allowed.

Padawan, the "making dynamic text look static" trick took my breath away -- particularly seeing that Adobe GoLive already works with WebDAV. Who knows where this is heading?

Posted by Jonathon on 28 July 2004 (Comment Permalink)


Try this-
http://extensionroom.mozdev.org/more-info/webdeveloper


"Mozilla's layout engine is designed to work with the CSS formatting model."
-- http://www.mozilla.org/docs/web-developer/faq.html

Posted by Mark on 29 July 2004 (Comment Permalink)


http://www.gadgetopia.com/2004/07/07/WebDeveloperExtensionReVisited.html

"You can open the stylesheet for the current page in a sidebar, make changes to the CSS, and the page changes in real time.

You cannot believe how handy this is. Play all you like, and watch your changes happen...

Add Web Developer's ability to display the CLASS and ID of every element on the page, and you never have to touch the HTML to re-do the style....

This is as close to CSS heaven as I've come."

Posted by Mark on 29 July 2004 (Comment Permalink)

I'll have to check Markdown then.

But I wasn't trying to use HTML, since you explicitely disallow it, but I do use entities quite often, for dashes, quotes, elipsis, etc., and those you didn't mention at all as being disallowed. The problem I'm having with entities is that yes, I can add them in, like &amp; then hit “Preview” the text shows up, but in the edit box, the entities have been replaced with actual characters, not entities. Normally that might not be a problem, unless you are trying to present HTML tags and previewing the post.

The linking thing—include a link, say, http://weblog.delacour.net/cgi-bin/mt-kansou.cgi?entry_id=970 and hit “Preview”—the edit box contains <A HREF="…"> … </A>. And that made it rather difficult to edit. A mess actually. Ideally, what you want is to pass back exactly what the user submitted into the edit box on preview mode, and that's not what's happening here.

Posted by Sean Conner on 29 July 2004 (Comment Permalink)

Sean, my apologies -- I checked a couple of other Movable Type based blogs and they don't exhibit the behavior you describe, which is really irritating.

I think it might be a consequence of some hacks I implemented earlier in the year to protect myself against spam and crap-flooding. I'll see if I can locate the problem but, if not, an upgrade to MT 3.10 or a switch to WordPress should set things straight again.

In the meantime, I'll be interested in your impressions of Markdown.

Mark, after all these years I think I'm pretty difficult to impress but the WebDeveloper extension is amazing. The two features you mention -- editing the stylesheet for the current page in a sidebar and displaying the CLASS and ID of every element on the page -- just blew me away. And can I mention displaying the image dimensions and access keys, generating the speed report, and the various validation options? Magic! Thanks for the pointer and the recommendation.

Posted by Jonathon on 29 July 2004 (Comment Permalink)

This discussion is now closed. My thanks to everyone who contributed.

© Copyright 2007 Jonathon Delacour