Re: WYSIWYM editors

Dave Raggett schreef:
> I appreciate your desire to make it easier to add WYSIWYG editors 
> within blogs, wikis etc. but think that the problem needs a little 
> bounding and this will depend on the context and target audience etc. 
> For very simple word processing features, there is a reasonable body 
> of shared experience on what to expect from wysiwyg editors, but HTML 
> in general offers so many opportunities that implementers are unlikely 
> to agree on the details. For instance, how would you approach the UI 
> for microformats? 

*cough* you mean RDFa? ;p.

Just kidding. Anyway, the current systems for entering rich text 
employed widely on the web consist of entering codes to fully express 
what you want to say. That just needs to improve, in my opinion, because 
it’s annoying. Scripting solutions work, but are not the final solution, 
if you ask me. They are complex, and require a lot of cross-browser 
testing, and if your browser is not included in their testing list 
you’re out of luck. As for what features they offer, I don’t think you 
even need to look as far as microformats, but even simple things part of 
HTML like marking up abbreviations. In a minimal UI, that doesn’t seem 
like something that would be there.

I think it would be best to leave the exact workings and features up to 
the implementation, however it would be good if the the specification 
would stress the importance of allowing to input text using the semantic 
elements, perhaps offer a few ideas to make this most intuitive to the 
user, and not with <br>, <font> and <b>. This would hopefully stimulate 
convergence on a UI that offers more or less the same editing 
functionality accross implementations.

Furthermore, there should I think be a requirement in the specification 
that implementors provide a way to manually add and modify markup in the 
edited text, so that there is always the opportunity to add or modify 
information in a way that is not supported by the editor.

One final key thing is I think to have script access to the DOM of the 
richt editing control, and also to parts of its interface (where care 
should be taken not to enforce a certain type of interface). That way, 
web site owners who want to provide a way to enter e.g. XFN or FOAF can 
do so.

Adding say buttons to the control’s toolbar might seem the most obvious 
thing to do, but I think one needs to look very much at alternative 
approaches. Some examples: dates can be detected and marked up as such, 
or only offer an hCalendar interface when one is detected. Abbreviations 
can be detected, too, although their meaning is something relatively 
domain-specific. Better typographical characters (‘, ’, “, ”,—, etc) can 
also be fixed up on the fly. When a post is edited, the backend could 
automatically compare the original post with the new post and insert 
time-stamped <del> and <ins> annotations (hiding the <del> items per 
default). These things improve the markup greatly, and don’t burden the 
user at all.

Maybe especially because these things can use a way to be marked up in 
an innovative way, something more advanced than having a toolbar button 
for every HTML feature, it would be better if the user agents did not 
provide means for them if they think they cannot implement said markup 
in a user-friendly way. That way, the community of blog-, forum-, wiki- 
and CMS-developers can experiment with various ways of doing this 
through script.

Just one more interesting thought I had… This might be the feature that 
the common end-user can ‘connect’ with most of all. Editing text is just 
a pain at the moment, and I’m sure many users would appreciate it if 
that would improve. I can see how they would actually start write to web 
site maintainers to ‘check out HTML5, because it lets us write posts so 
much easier’. And it would be relatively simple, just adding an 
attribute (esp. if your backend can already accept HTML). Many other 
things in HTML5, like the forms stuff, is also great of course, but 
would be much more subconscious, people wouldn’t notice it as much, I 
think, because it doesn’t directly address one of their annoyances, but 
rather improves the workflow.

Well anyway.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.