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

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

From: Charles McCathieNevile <chaals@opera.com>
Date: Wed, 11 Feb 2009 10:08:20 +0100
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: public-html@w3.org
Message-ID: <op.uo6jn6uiwxe0ny@widsith.local>

On Wed, 11 Feb 2009 09:46:06 +0100, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:

> 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
>>> 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
>>  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.
> 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.

Good to know. I have worked in the design of WYSIWYG editing tools for 9  
years, although generally only as a part of my job, and in some years it  
has been a very minor part of my job.

> I can tell you that situation become even worse recently.

/me not really happy to hear that.

>>  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.

I think Amaya (for all its quirks) is an existence proof that developing a  
CSS-based WYSIWYG editing tool (for HTML plus MathML plus SVG) is feasible  
- although in the case where javascript is applied the problem becomes  
much more difficult.

> 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.

Would a *recommended* way help? Something like establishing a list of  
desired repesentations, and for each one an element and *recommended*  
associated styling? This would be informative - guidance to people  
producing WYSIWYG tools that would help interoperability - and the more so  
if they were more closely involved in reviewing this document during  

I am assuming that tools have a rendering engine that is halfway capable  
(although often no more) of handling CSS, because I think that is more or  
less a necessity now. But they might not be based on an up-to-date  
rendering engine.

There are already people around who document what is actually supported in  
email clients' HTML / CSS rendering, for the use of people who send pretty  
coloured marketing email or who want to send properly structured content  
rather than plain text. Getting some involvement from this community to  
develop a document that was in synch with HTML 5 and what the rest of the  
web is doing strikes me as something that would actually be useful.

> 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.

Sure. But adding elements isn't an answer as far as I can tell, since  
people who *do* use CSS (and that's quite a lot of people now) will simply  
style more of them in more wierd and wonderful ways, complicating the  
rendering that everyone has to do.

> 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.

Hmm. Good WYSIWYG editing is indeed a hard challenge - harder than  
rendering, which is why I appreciate the input of developers of editing  
tools to this working group. However I am not convinced that CSS  
attributes are the problem on their own, nor that adding elements is a  
good solution, given that we have to deal with the whole of the web and  
not just the bits that work easily in a given type of tool.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Wednesday, 11 February 2009 09:09:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC