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

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