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

[Uschi Renziehausen]

Hi Masi,

Martin Kutschker wrote:
> Uschi Renziehausen schrieb:
>>
>> 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.
> 
> Interesting feature request, but probably not the needs of the 
> mainstream users.

I am not sure what you mean by the "main stream users". Those 
authors/site developers/extension developers who are not aware of the 
fact that decent markup is needed for usable and accessible websites? 
There is a wiki page on user target groups: 
http://wiki.typo3.org/index.php/Usability_Target_Groups

Apart from that, the sentence above was not meant as a feature request 
but as an attempt to find a formula for what the "Enable people to 
commununicate" of the TYPO3 mission statement implies if it comes down 
to the RTE. It is of no use to have new out of the box templates for T3 
(see http://wiki.typo3.org/index.php/Content_Rendering_Schemes) if the 
RTE spoils it all when used by authors who do not know how HTML is done! 
It has to become intuitive for them.

> 
>> 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)
> 
> How is this different from hitting return? "return" => DIV/P (depending 
> on setup), "shift return" => BR. I don't see any value in "adding DIV".
> 

If there is one thing that is wrong with those default transformations 
than it is this mixing up <div> and <p>. This is from the olden times 
where we all were not aware of semantics and css and had to struggle 
with NN 4.x. The point is that <div> in xhtml 1.x is the only way to 
wrap two ore more block elements. It is good for dividing a pages 
contents into sections or pullout boxes. Seen technically, a div should 
behave like blockquote and not like p. For RTE Textarea that means: When 
I am inside a <div> and I press ENTER, this will produce a <p> inside my 
<div>. For transformations that means: <div> != <p> (leave it alone).

There are lot of other issues concerning transformations, by the way.

>> - Make it easy for authors to add <blockquote> (we could call it 
>> 'Quotation block')
> 
> But only you don't misuse i as "indent". AFAIK there is already a 
> request for supporting better cites (blockquote, q elements and cite 
> atribute).
>

Might be so, but I am looking for a unified way to be able to choose the 
elements authors might need for a certain purpose. Otherwise we will end 
  up with a button for each and every element and a feature request as 
well. I will try to think over this more carefully.


>> Currently it is only possible to hide items of the paragraphs selector 
>> box, you cannot add to them.
> 
> Yep, that's missing.
> 
>> 2) Do not abuse blockquote for indentation
>> Currently increasing indent is done by wrapping the element in 
>> question by a blockquote.
> 
> Is this till done in HTMLarea? Anyway, I recall that the underlying APIs 
> of IE and Mozilla/Firefox add the blockquote when asked for indenting :-(
> 
>> 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>
> 
> Only if you set up the remapping.
> 
>>     <span> - only if RTE.classesCharacter is defined.
> 
> Normally not a problem. Except when you want to add oter attributes. Is 
> this what you want?

This was just a list to point out, that currently an author without 
knowledge of html is restricted to these inline elements. And yes, as 
stated further down i want to be able to set those attributes that apply 
to an element.

> 
>> 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)
> 
> [ No, "cite" means "Zitat" and is no abbreviation. ]

cite is a verb an means "zitieren". The wording problem here is perhaps 
restricted to German, because "Zitat" is ambiguous. It means "quotation" 
(which is the quoted text) and "citation" (which is the author, work you 
are quoting) depending on the context.

> 
>> samp - Example
>> dfn - Definition
>> span - Span
>> var -  Variable
>> code - Code
>> kbd - Keyboard
> 
> Could simply be added to the current list (Paragraph, H1 .. H6).

No, because the paragraph list is for block elements! If you do it this 
way, you will
- prevent authors to comprehend that there are basically two types of 
'formats', block and inline.
- produce a long list which will then be hard to scan for authors.

> 
>> 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.
> 
> I don't understand.

<dfn class="myClass">lorem ipsum</dfn>
instead of
<dfn><span class="myClass">lorem ipsum</span></dfn>

> 
>> 4) Direct access to important attributes
>> - lang (accessibility issue!)
>> - title
>> - id
> 
> Have a look at the bug tracker. This has IMHO already been filed.

I will.

> 
>> 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
> 
> Nice idea. But don't forget to add a "turn all TDs of this row/column to 
> THs" (and vice versa).

Thank you for reminding me :)

> 
>> 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.
> 
> No. Just because I want a cell to be in thead that doesn't mean I want a 
> th. So a checkbox should make this conversion optional.
>

Hm, may I ask why you would want anything but th in thead? If this 
checkbox is added, then either it should be hidden or checked by 
default. Quite a lot of users (all target groups this time apart from 
website visitors) might not be aware, that they cause accessibility 
issues when not marking up tables properly.

> I'd start adding the issues (separately!) into the bugtracker instead of 
> putting it on the wiki. Ok, everything execpt the definition list 
> thingy. I think this needs to be refined a bit.
>

I will. Perhaps you have any suggestions about how those dl-thing could 
be dealt with?

> Masi

Prosit, Uschi