- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Sat, 14 Feb 2009 20:04:51 -0800
- To: Charles McCathieNevile <chaals@opera.com>
- CC: public-html@w3.org
Charles McCathieNevile wrote: > > 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 .... > >> 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. Imagine that you have following document: <body>Hello |world</body> where '|' marks caret position. What would you recommend to do when editor will receive ENTER key? What markup you suggest to be created? > > 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. Think about such input element as: <richtext>some fragment</richtext> that is kind of WYSIWYG editor - input element that posts markup *fragments* to the server. Imagine that this input element is used in, say, WordPress for editing text of an article. Or in the New Message form of phpBB. I mean that there are cases when WYSIWYG editor should be used to produce only pure markup. It may not be really 100% WYSIWYG. The only requirement - it should not emit any style information. At current stage of HTML/CSS technologies it is not realistic to think that web site (system of related dynamic(?) web pages with common styling) can be created in solely WYSIWYG tool - without any knowledge of CSS. Many attempts were made and no one really succeeded. For reasons I've already mentioned. The only reasonable case of WYSIWYG editing is, as I said, html fragment editing - creation of content portions of html pages - BB messages, blog posts, wiki, etc. Thus the <richtext> should use simplified HTML - something close to bbcodes, textile, wiki-markup, etc. Actually existence of such pseudo-markups is just a proof of the fact that html is not suitable for WYSIWYG editing as it is. > > 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. There are two types of e-mail messages: conversation messages and informational messages (e.g. flyers/advertisements) Informational messages are just web pages packaged as mime messages - for reading only. These are not for editing so let's put them aside of the WYSIWYG problem(s). I am speaking about conversation messages that imply editing - replies. Highly desirable to use WYSIWYG while editing of these messages. It is 21st century and we still doing plain text messaging on public-*html* mail list. Shame on us? (Yeah, why do I need to put '*' to mark <strong> spans?) To be short :) It should be some subset of HTML that should be suitable for human. Let it be not 100% WYSIWYG but it should provide at least basic things. Not each ENTER pressed means end-of-paragraph. Far not each block of text could be considered as a paragraph. That is why I am speaking about the <text> that will allow to throw away that ugly <br> semantic value of what is just below the zero. > >> 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. So what all of us are doing in this mail list? Let's focus CSS then. <div>,<span>,<input> and <p> are there from the very beginning. You do not need rest of elements when you have CSS. Let's start teaching CSS in school and forget about <figure>, <aside>, <menu>, etc. Vocabulary and intrinsic styling of html shall motivate people to use proper markup. Currently it is significantly more reliable to put <div> instead of <p> just to wrap single sentence of text - create block of text. Especially if you don't know upfront on what site/UA this text will meet its reader. > >> 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. > WYSIWYG editing per se is not a hard challenge - there are plenty of good WYSIWYG editors. They simply use are not using HTML and its DOM. Problem arises when people start using their output as a content of the Web. Search on "cleaning word markup" and you will find many of those. Problem is that these "pure markup and styling" what the Web needs are designed without WYSIWYG editing in mind. Try to imagine wording of human in front of WYSIWIG editor with styles like p:nth-child(3) { color:red; font-weight:bold; } loaded. Shall we do something to help people that are far from the CSS to create Web content in more human friendly environment? That is the question behind the <text>. Cool, eh? -- Andrew Fedoniouk. http://terrainformatica.com
Received on Sunday, 15 February 2009 04:05:35 UTC