Matthew Thomas wrote:
> | 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.
I *strongly* disagree with this last assertion but it is my personal
opinion
only. If you look at the MUAs market, most of them rely or will rely on
browsers that are already CSS-aware (meaning "that understand at least a
good
part of css1").
> | [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
A box model ? What do you mean ?
> 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>
Definitely not. It would result in <p>I <em>really
<span id="worple">don't</span></em><span id="worple">think</span> this
is
a good idea</p>.
And that's how it works _now_ in the editor.
> | 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.
I tend to agree with that, but what is exactly your point ?
> | 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.
I strongly disagree with that. Average users with no knowledge of HTML
or CSS don't want to see a technical menu item they don't understand !
> | 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.
Why not three panes with the source view ?-) Seriously, you really think
that people want to see both views at the same time ?
> | 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.
www.mozilla.org took some time to update from cvs.
> | 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.
Not in Advanced Preferences !!! In Advanced Dialog...
> | 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 ...
How do you want to offer people that have
no ability to store an external stylesheet on a web page a way to modify
or specify external stylesheets ? How are you going to send external
stylesheets by email ? Why the hell are inline styles "bloated" ??? How
can you copy/paste a fragment with its styles from a document to another
one if you don't have inline styles ?
Just fyi : this doc is the result of a long work and a lot of
discussions with a lot of people. Your msg sounds really like a strong
flame.
</Daniel>
