Re: The Conflicting Notions of Ease of Use and Need for Authoring Tools

Hi, Daniel,

my two cents:

Neither HTML/XML nor CSS were designed for WYSIWYG authoring purposes.
They are pure programming languages.

Human, editing  HTML/CSS in WYSIWYG mode, does not operate by such entities 
as "cascading"
or "element containment". Flat screen - flat document - flat representation.

The last version of HTML which had DOM compatible with WYSIWYG was HTML 3.2 
(without CSS).
Since then HTML/CSS are not a tool/technology for anyone.

NVUs (and not only) problems you've mentioned mean that WYSIWYG HTML editors 
are doomed to produce "styled markup garbage". It's a pity but reality.

Human oriented WYSIWYG web content editing should use completely different 
idiom. But this is another story.

IMHO of course.

Andrew Fedoniouk.
http://terrainformatica.com


Original Message from: "Daniel Glazman" 
<daniel.glazman@disruptive-innovations.com>
To: "Orion Adrian" <orion.adrian@gmail.com>
Cc: <www-style@w3.org>
Sent: Tuesday, December 28, 2004 12:48 PM
Subject: Re: The Conflicting Notions of Ease of Use and Need for Authoring 
Tools


|
| Orion Adrian wrote:
|
| > Let us please drop this notion that the authoring tool should be
| > responsible for making CSS an effective language.
|
| Thanks for caring for authoring tools, it's unfortunately quite rare [1].
|
| With my Nvu [2] hat on, and working on both markup and style languages 
since
| 1991, I have to agree with you. Saying complexity in CSS is not a problem
| because Wysiwyg editors should be able to hide that complexity to web 
authors
| is just a false assertion. It's a false assertion because it defers 
complexity
| to UI, instead of solving it from the very beginning, and UI's acceptable
| complexity is relatively far lower than a CSS-alike language's acceptable
| complexity.
| Coders facing a complex language read a how-to or a spec; normal users 
facing
| a tool with a complex UI just change the tool. If _you_ don't change the 
tool,
| then you're a coder, you're able to read the spec anyway, right ?
|
| I can easily prove the above : the biggest problem in Nvu - or in any 
wysiwyg
| editor that would like to implement CSS-generated styles - right now is
| certainly the way the Object Model gives access to the styles. From a 
given
| real style "this element's font weight is bold", it's just impossible to
| retrieve the rule that caused that style. So it's impossible to really 
*MODIFY*
| the styles of an arbitrary document, it's only possible to *OVERRIDE* them
| using style attributes, !important, or artifically specificity-increased 
[2]
| rules. As a side-effect, the current CSS Object Model and the 
impossibility
| to reverse the cascade is one of the main reasons why we need the style
| attribute, despite of what all the XML-everywhere fanatics keep saying.
|
| That's very nice from a browser's point of view because it simplifies the
| implementation, but that's a nightmare from an editor's one, trust me on 
that
| please.
|
| [1] http://glazman.org/weblog/dotclear/index.php?2004/12/03/725-ah-finally
| [2] http://www.nvu.com
| [3] use a few negated ID selectors with IDs you're sure to never have in
|     your document instance...
|
| </Daniel>
|

Received on Tuesday, 28 December 2004 21:43:04 UTC