[TYPO3-hci] Concentrate on the editors 2: RTE improvements

[Uschi Renziehausen]

Hello humans :)

Some philosophy first: A good website is made up of (quality) content, 
that is easy to perceive for the 'readers'. When it comes to content 
production, one of the most important tools for authors is the RTE. 
Therefore, as a (newbie) site developer it is my duty to make it 
comfortable and easy for the authors to get their content right. The 
readability of content is improved by semantically 'correct' markup, 
which then can be styled for the various media. This is a key point that 
each and every author, who wants or has to publish for the web, will 
have to understand! This should not be too difficult, as long as the 
wording is reasonable.

I will also have to teach authors how to use the RTE, and I have to keep 
the learning curve low. As was pointed out in the Mambo thread, you can 
only teach well what you know well. Therefore, I started to work a lot 
with the RTE as I will do as an author, and came to the following 
conclusion:

Currently the GUI of the RTE is not optimized for it's main purpose: 
writing content for the web. What you get as default formatting (markup) 
options is taken from the typical setup for word processors (be that MS 
Word or OO Writer), and those in turn are optimized for creating 
(SMALL!) print documents like letters. They are secretaries' friends, 
but once you want two write e.g. an academic article or book, you will 
be very unhappy with these settings. Everything you need is there, but 
most of it is safely hidden away from you, and even if you happen to 
find what you need, you have to klick five times to get there OR you 
become an expert user and learn how to manipulate your toolbars/shortcuts.

Now, with the configuration of your word processor, you are usually left 
alone, but, fortunately, with the config of your RTE you are not, if you 
have a site developer/admin, who cares for your needs.

Currently, the only way to get my content right, is using the Quick Tag 
Editor. But the Quick Tag Editor is only usefull for those authors, who 
know HTML, and then it is not very comfortable, if you have to open up 
the QE first. Nevertheless it is my 90%-button! I know, that there are 
also the User Elements, but then again: extra klicks for the authors, 
and, furthermore, why should site developers need  to do a lot of work 
just to create standard html elements?

So the major objective would be:
Optimize rtehtmlarea for what it is used for: producing nice html-code 
without having to code!

I know this is not the right place for RTE feature requests, but I put 
down some details here in order to clarify what I mean and to find out, 
what others think of these ideas.

1) Direct access to all common block elements via paragraph selector list
- Make it easy for authors to add <div> (we could call it 'Box' on the 
surface)
- Make it easy for authors to add <blockquote> (we could call it 
'Quotation block')
Currently it is only possible to hide items of the paragraphs selector 
box, you cannot add to them.

2) Do not abuse blockquote for indentation
Currently increasing indent is done by wrapping the element in question 
by a blockquote.
This is bad, because not every indented block contains a quotation. 
Perhaps it would be a good idea to let site developers define a class 
for indenting left which than can be applied to a wrapper div? Then it 
is up to the css how the indenting is done (padding or margin, em, px?).

3) Direct access to more inline elements:
Currently only the following inline elements can be accessed directly:
	<b> - remapped to <strong>
	<i> - remapped to <em>
	<sub>
	<sup>
	<span> - only if RTE.classesCharacter is defined.

My approach would be:
A select list like the one for block elements. What is in there by 
default should be configurable (addItem, removeItem). By default one 
could imagine:

q - Quotation inline
cite - Citation (do not know whether this is correct english)
samp - Example
dfn - Definition
span - Span
var -  Variable
code - Code
kbd - Keyboard

Also, the selector box for inline classes should react in a similar way 
as for classesParagraph, means: when my cursor is inside a dfn, the 
class should be applied to the dfn-element.

4) Direct access to important attributes
- lang (accessibility issue!)
- title
- id

5) Save several klicks for the table editor

5.1) The create tables dialogue
- if classesTable is defined, let users choose them on creation of table
- three options concerning thead/th/scope
   * make first row thead (all cell types automatically set to th and 
scope to col)
   * make first col th (all cell types automatically set to th and scope 
to row)
   * make first row thead and first col th (all cell types of first row 
th/scope=col, all cells of the first default to th/scope=row with the 
exeption of the first one in the first row)
- add the caption and summary fields

5.2) The row properties dialogue
In the row properties dialogue I can choose whether the row shall become 
part of thead, tbody or tfoot.
So if I choose thead, the cells should be turned into th/scope=col 
automatically. Otherwise I need as many clicks as I have cells in that 
row + choosing the right scope.

6) A way to create definition lists
Some ideas how that could work:

A button like we have for <ol> and <ul>
Pressing that button will activate it and will create <dl><dt>|<dt></dl>
Pressing that button in active state will move the cursor below the </dl>
Pressing enter from inside <dt> will add <dd>|</dd>,
pressing enter from inside <dd>|</dd> will create <dt>|</dt>
I suppose a second button is needed for toggling between <dt> and <dd> 
if one needs to <dd>s.


Prosit, Uschi