- 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