- 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
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.
Sure.
> 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
development.
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.
cheers
Chaals
--
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