Daniel Glazman wrote:
>...
> [1] http://www.mozilla.org/editor/adding-css-to-editor.html
>...
|...
| This document contains a proposal for the addition of CSS 1 support to
| the Editor. It describes the extensions the editor needs to become an
| HTML+CSS wysiwyg editor useable by document providers writing HTML
| documents without breaking the behavior expected by mail/news client
| users (text or text+pure HTML messages, no CSS for the moment).
I think this is the first mistake. The most important thing is to split
the editor UI into two: one UI dedicated to composing mail, and one
dedicated to editing Web pages. Firstly, as discussed several times in
this group, the two tasks have different expectations -- composing mail
is much more about applying basic visual formatting to text, whereas
editing Web pages is much more about applying style to structured
content. And secondly, many of those mail clients which support HTML (to
some extent) will, in all likelihood, never support CSS. HTML 3.2 will
be the lingua franca.
|...
| [STEP 1] preserve all embedded and external styles between load and
| save operations,
| [STEP 2] allow assignment of CSS 1 styles to the user's selection, the
| selection being elements, pure textual content, or an aggregate of
| elements and text,
It is perhaps more important to establish a box model of editing HTML
before allowing CSS to be applied to that HTML. (This is partly why the
mail composition and Web page editing UIs need to diverge.) Currently,
where I have
|
| <p>I <em>really don't</em> think this is a good idea.</p>
|,
I can select `don't think' and apply some formatting to it. In a
CSS-savvy editor, I should be able to specify an id attribute for the
selected content so it can be styled and manipulated -- without a box
model, this would result in
|
| <p>I <em>really <span id="worple">don't</em> think</span> this is a
| good idea.</p>
|,
which is invalid. It would be practically impossible to explain in the
UI why the user couldn't do that, unless you used a box model where
Shift+arrowing or dragging over an element boundary selected the whole
of that element.
|
| <p>I <span id="worple"><em>really don't</em> think</span> this is a
| good idea.</p>
|...
| No element carrying an ID or a CLASS attribute should be removed from
| the document tree or turned into a DIV or SPAN plus CSS styles, unless
| the user intentionally does such a removal.
Ideally, you should be able to do the following:
* load an HTML file in Composer
* insert an `x' character somewhere in the file, then delete it
* save the file under a new name
* run `diff' of the new file against the old file, and see no changes
at all.
|...
| Preferences
|
| There will be added options in the editor's preferences :
| Styles :
| use CSS (Cascading Style Sheets) styles
| use HTML styles
This sooooo does not belong in the preferences. It is a per-document
issue, not a per-user issue.
|...
| There will be an additional, but optional toolbar in the "normal" view
| of the editor showing the ancestors of the current selection. For
| instance, if the insertion point is within the strong element in the
| following markup
|...
| The new toolbar (or sidebar panel) will display : html > body > div >
| p > span > strong
For a more detailed description of how such a toolbar would work, see
<http://geocrawler.com/mail/msg.php3?msg_id=3950344&list=140>.
|...
| A way to disable/enable the User StyleSheet is needed. Without such a
| mechanism, a document provider would be unable to visualize the
| rendering of his document without application of his/her user
| stylesheet. It recommended that a specific menu item or sub-item for
| that purpose.
Like I said before, the default view for Composer should have two panes:
a large pane at the top showing how the document looks in Seamonkey, and
a small pane at the bottom showing how the document looks with no custom
colors, fonts, layout, or images -- pretty similar to how it would have
looked in the last version of Mozilla which didn't support tables (1.0?
0.9?) with images turned off. That would give as good an indication of
the spectrum of presentation possibilities as you could get without (a)
relying on a speech interface or (b) annoying the user immensely.
|...
| It is recommended that the current iconic representation on the
| toolbar be replaced by a tri-color button. For example :
|
|
FYI: You posted that you had fixed this image link, but it's still broken.
|...
| A mechanism will be added for the user to specify and/or remove
| external (LINK ed) stylesheets. It should be a preference option in
| the 'Advanced' tab that can be set to specify the external stylesheet
Oh dear. This strengthens the reputation of the `Advanced' branch of
preferences as the pit of `things we couldn't be bothered finding a
proper place for'. The branch actually shouldn't exist at all.
And as with HTML-formatting-vs.-CSS-formatting, author style sheets are
not a per-user issue; they are a per-document issue.
|...
| Important : It is not suggested to provide the user with a way to
| modify the contents of external stylesheets.
|
| Embedded rules
|
| U sers will also be allowed to specify, modify, enable/disable and
| remove new CSS embedded (in STYLE elements) rules.
|...
Am I reading this right -- is this actively *discouraging* people from
producing lean documents with reusable styles, in favor of bloated
documents containing in-line styles? Surely not ...
--
Matthew `mpt' Thomas, Mozilla user interface QA
Mozilla UI decisions made within 48 hours, or the next one is free
