W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: [html5] proposal to add <text> element.

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Wed, 11 Feb 2009 00:46:06 -0800
Message-ID: <4992904E.5090802@terrainformatica.com>
To: Charles McCathieNevile <chaals@opera.com>
CC: public-html@w3.org

Charles McCathieNevile wrote:
> On Wed, 11 Feb 2009 02:36:58 +0100, Andrew Fedoniouk 
> <news@terrainformatica.com> wrote:
> 
>> I propose to add <text> element to the list of supported elements.
>> <text> is exactly <p> in all meanings other than default styling: it 
>> has no margins by default.
> 
> I propose not to do this.
> 
>> Having it in place will help to deal with the text in WYSIWYG editors 
>> and in other places where generic text container is required.
>> Outlook for example creates paragraphs as <div>s so in mail systems 
>> that do not use or have limited CSS support text
>> appears without "extra lines". Many pages too abuse <div> element - 
>> are using it as just a margin-less text element.
>> That is not so pretty, IMO.
> 
> The fact that some tools can't get HTML right isn't an especially good 
> reason to introduce new elements - in fact it is one of the reasons not 
> to, IMHO. After all, why complicate something that is already not done 
> properly?

I am about 7 years or so in business of designing WYSIWYG editors of
various kind. Including HTML WYSIWYG editors that also include editors
for e-mail clients. I can tell you that situation become even worse
recently.

> 
> An alternative interpretation is that the tools were developed before 
> CSS rendering was available in mail clients (which is effectively in the 
> dark ages now) - tools *could* be updated, but they may as well be 
> updated to use HTML as is, since that is better supported in things like 
> last year's copy of Dreamweaver, or next week's version of Word, or the 
> email clients that people have today - and that support in clients is 
> important to developers of tools making content for those clients.

You can give it any name you want but HTML 3.2 was the last html 
specification of html that could be edited in true WYSIWYG mode:
visual representation was near one-to-one relationship with the DOM model.

With CSS you have many possible DOM/style combinations that can
produce the same result for human eyes.

WYSIWYG editing is a task of producing DOM/style structure using visual 
representation. And mathematically speaking if you have one-result-
many-ways-to-achieve-it then the result is undetermined. Any algorithm 
making decisions will be unstable.

Take any email message or document and position caret in your editor
somewhere in the middle of your text. And now answer the question:
what will happen if you will click Enter at this point?
Will it create space there? What DOM/styling will be produced?
Will it be new <p>, <div> or <br>? What style this thing will inherit?
And so on.

Good WYSIWYG editing of html is a dream. With each CSS attribute
it become more and more fanciful. It is a bit naive I would say
to think that next version of whatever will be better in this respect.

--
Andrew Fedoniouk
Received on Wednesday, 11 February 2009 08:46:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC