Daniel Glazman wrote:
>...
> > 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").
If you regard Netscape and Outlook as `most', then yes. But Pegasus,
Eudora, etc just understand simple things like <font> and <b> -- I would
be extremely surprised if they ever include support for
`text-decoration' or `border' or whatever.
>...
> > 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 ?
I posted several messages about it to n.p.m.editor in the middle of last
year. (Geocrawler's search function is pretty bad, and I can't find
them, unfortunately -- and Google Groups doesn't go back that far at the
moment.) See <http://mathtype.com/features/basic.stm>, and imagine that
applied to HTML (or arbitrary XML) elements rather than math.
> > 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.
If so, that is a bug. You can't have two elements with the same id
<http://www.w3.org/TR/html4/struct/global.html#adef-id>.
That was my point -- it's ok to copy and paste elements across the
boundaries of other elements when doing mail composition (where you're
not concerned with counting CLASSes or specifying IDs), but when editing
Web pages or XML, dissecting elements like that is almost certainly not
what the author intended.
> > | 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 ?
Simple: What you specified about ID and CLASS attributes above would be
nothing more than a specific case of the general
if-it-ain't-broke-don't-touch-it rule. It wouldn't need any special treatment.
> > | 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 !
That doesn't stop it from being a per-document issue, whereas
preferences are for per-user issues. For example, if I choose `CSS
only', the filepicker isn't going to automagically prevent me from
opening any HTML documents which happen to contain HTML formatting. It
only makes sense once a particular document is open.
If you don't want the average user to see it (and I agree with you on
that), then bury it in an `Advanced' dialog somewhere in the formatting
menus for that document. Not in the prefs dialog.
>...
> > 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 ?-)
Because, if Composer is designed properly, authors shouldn't need to
view source code in order to produce accessible and backward- and
forward-compatible markup. (Currently, I don't think that can be said of
any Web page editor.)
> Seriously, you really
> think that people want to see both views at the same time ?
Usually not at the same time. But defaulting to showing them both would
be a friendly wakeup call that the Web isn't a WYSIWYG environment --
that there are many alternative ways of viewing an HTML document.
>...
> www.mozilla.org took some time to update from cvs.
Ah.
> > | 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...
Sorry, I was confused by your referring to it as a `preference'.
>...
> > 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 ?
I don't follow. If people don't have the ability to publish style
sheets, how do they have the ability to publish Web pages at all?
> How are you going to send external stylesheets by email
> ?
When you attach an HTML file in Messenger, it should be smart enough to
detect whether the style sheets are globally accessible, and if not ask
you if you want to attach the associated style sheet as well (and update
the links in the HTML file accordingly).
> Why the hell are inline styles "bloated" ???
Because the same styles are repeated (and diverged, and unmaintainable)
for every single document you write, instead of just existing in a
single file.
This is, to a large extent, why style sheets were developed in the first place.
> How can you copy/paste
> a fragment with its styles from a document to another one if you don't
> have inline styles ?
You don't. If I'm copying some text from the middle of a paragraph in a
document which happens to use Centaur 12pt, and pasting it into a
paragraph in a document which happens to use Helvetica 14pt, do you
really think I want the pasted text to be in Centaur 12pt when the rest
of the document doesn't use that font at all?
> Just fyi : this doc is the result of a long work and a lot of
> discussions with a lot of people.
I've been subscribed to the mozilla-editor mailing list for over a year
now, and never saw such discussions. Maybe my mail server was playing up.
> Your msg sounds really like a strong
> flame.
>...
I don't believe it. I really don't. I was trying *ever* so hard to be
nice. What more do I have to do?
--
Matthew `mpt' Thomas, Mozilla user interface QA
Mozilla UI decisions made within 48 hours, or the next one is free
