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

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

From: Robert J Burns <rob@robburns.com>
Date: Sun, 15 Feb 2009 15:43:40 -0600
Cc: "Philip TAYLOR (Ret'd)" <P.Taylor@Rhul.Ac.Uk>, Andrew Fedoniouk <news@terrainformatica.com>, public-html@w3.org
Message-Id: <7192C971-3D43-4267-815A-6365609C3F22@robburns.com>
To: Leif Halvard Silli <lhs@malform.no>
Hi Philip and Leif,

On Feb 15, 2009, at 11:34 AM, Leif Halvard Silli wrote:

> Philip TAYLOR (Ret'd) 2009-02-15 17.24:
>> Returning from the digression (to the use of
>> HTML and RTF for e-mail) to Andrew's deeper
>> point :
>> Andrew Fedoniouk wrote:
>>> Having it in place will help to deal with the text in WYSIWYG  
>>> editors
>  [...]
>> If you want WYSIWYG editing, then I seriously suggest
>> that you should not be considering HTML at all, at
>> least in terms of what you eventually serve to your end-
>> reader; by all means use HTML and CSS as intermediates,
>> but then render the resulting code within a constrained
>> environment and serve the results using a page-description
>> language such as Adobe PDF.
> For a person like Andrew, which is in the business of making HTML  
> WYSIWYG editors, this is a fruitless point, I guess.
> A good WYSIWYG editor may help many to write /more/ structured.
> And, knowing that you use SeaMoneky: I use Thunderbird, and one  
> reason for doing so is because it lets me use a WYSIWYG HTML editor  
> during writing. Thunderbird will convert this to text when it sends  
> it out, though (depending on the configuration, of course). E.g. it  
> has a useful conversion from WYSIWYG HTML lists to text lists ...  
> And also from STRONG (or bold) to *bold* etc.
> Regardless of editor: one has to know what one is doing.

I think part of the problem here is the misuse of the term WYSIWYG  
which has unfortunately taken hold specifically in the area of HTML  
editing. What I would call this is GUI / Visual editing and not really  
WYSIWYG. WYSIWYG is more a term applied to rendering and  
rasterization. The editing of HTML however, can most certainly be  
visual in terms of selectable objects (elements, ranges, etc.) that  
have semantics applied to them (or un-applied from them) with menus,  
toolbars, and keyboard commands etc.

In other words editing where the pre-parsed text source is not edited  
directly, but instead the user interacts directly with DOM objects. We  
never called that WYSIWYG editing before, so I'm not sure why it now  
gets called that with HTML (which as you say is not necessarily though  
can be WYSIWYG).

Having said that I very much disagree with what Andrew is saying about  
visual editing of HTMl content. I've suggested in the past that we  
include a chapter to guide visual editing tools, but that has been a  
low priority. My understanding is that HTML began as a visually edited  
platform using NextSTEP tools somewhat like todays cocoa text system  
in Mac OS X.

The problem is not that HTML cannot be edited visually without  
resorting to source editing. Instead the problem is the attempt to  
treat the editing the same as non-hierarchical rich text formats (such  
as RTF).  With those RTF-like tools there is no hierarchy within a  
document. Instead various substrings are simply assigned styling  
attributes. In other words, those formats do not have a paragraph with  
a bold run of text in the middle, but rather the paragraph starts with  
a run of Roman text, followed by the bold text and then the plain  
Roman text again. So converting from an RTF-like format to HTML  
requires some heuristic analysis to produce a hierarchical HTML  
document. Going the opposite direction is much simpler since there's  
actually more information encoded in the hierarchy than in the RTF- 
like format (i.e., the hierarchical relations are expressed in the  
document rather than inferred by heuristics).

The various plain text syntax that have been invented are an utter  
disaster. We should never look to those to highlight worthwhile use  
cases. Compare Apple's wiki software with MoinMoin or MediaWiki and  
you'll understand what I mean.

I'm not at all clear what the proposed 'text' element seeks to  
address. A major problem already is that users have a variety of  
structural text containers to edit within so adding another seems to  
me to add even more confusion.

Take care,
Received on Sunday, 15 February 2009 21:44:52 UTC

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