Daniel Glazman wrote:
>
> Matthew Thomas wrote:
>
> > 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.
>
> I'd be surprised if they don't include it.
Ok, so I actually looked it up. I can't see any mention on the Web of
CSS support in Pegasus Mail; but Eudora has an .ini option to let you
specify a user style sheet, which would suggest that it does support
arbitrary CSS now (presumably through embedding the Internet Explorer
HTML control). Mea culpa.
However, I would think that old e-mail programs will remain in use a lot
more than old browsers do. The e-mail-related RFCs change a lot less
often than the HTML/CSS specifications do, so there is less incentive to
upgrade; and processing e-mail is considerably more complex than
processing Web pages, so there is incentive *not* to upgrade once you
have learnt the UI of a particular mailer.
> > See <http://mathtype.com/features/basic.stm>, and imagine that
> > applied to HTML (or arbitrary XML) elements rather than math.
>
> ok, so you really meant a box model like the one we have in CSS.
Ummmmmm ... Not a box model as in `float' and `position', but a box
model as in elements within elements within elements, like Chinese
nested dolls.
In Internet Explorer (and Microsoft Office apps by default), if you
select across a word boundary, you automatically select the entire word.
And in MathType, if you select across an element boundary, you
automatically select the entire element. Composer should work like that,
for HTML elements rather than words or bits of math. As soon as you
select outside the boundary of an element, you select the entire element.
> > 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>.
>
> Sorry, copy/paste error. I meant to turn into classes or style attr.
Well, ok, if you do *that* the bugs will be just as bad. Scripts which
look for the element with id="worple" will not be able to find it. And
if you had other elements with class="worple" already, styles for that
class will be applied to your new elements even though you didn't want
them to.
> > 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.
>
> Definitely false if the author only cares about the rendering and not
> about the structure/markup.
Yes, but people who only care about the rendering and not about the
structure won't be using Mozilla Composer.
They'll be using the Microsoft Word instead, which has a more familiar
interface than Composer does, and which goes to great<span style=
"mso-spacerun: yes"> </span>lengths in order to let the author care
about the rendering rather than about the structure.
Or they'll use the `Save as Web Page' feature in Microsoft Publisher,
which emits prodigious amounts of pixel-specific TABLE elements (and
plenty of COLSPAN and ROWSPAN attributes) in order to let the user care
about the rendering rather than the structure.
Or, if they're on Unix, they'll use latex > dvips > ps2pdf, which gives
a much nicer rendering than any HTML rendering engine is ever likely to
produce in the near future
<http://bugzilla.mozilla.org/show_bug.cgi?id=67715>.
For Navigator to try so hard to encourage well-written Web pages, and
for Composer to try so hard to discourage them, would be a rather
amusing conflict between the two Mozilla apps.
I wouldn't be surprised if Netscape's apparent desire to make Composer
Just Another WYSIWYG-Attempting Editor, rather than a solid structural
editor, is a major factor behind the dearth of contributions to that
part of the Mozilla project from those outside Netscape.
> > 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.
>
> I still disagree.
Feel free to give reasons.
> > 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?
>
> Well, HTML documents are not only for Web pages ! I see people doing
> slides in HTML, sending HTML documents instead of DOC. 99% of my
> personal documents are in HTML and never went on a httpd.
That doesn't preclude the style sheets themselves from being on a Web
server. Netscape Communication Corporation's house style could be a
style sheet stored somewhere on home.netscape.com. If Netscape decided
that they wanted to switch their corporate font from Antique Olive
Condensed to Optima, all they would need to do would be to change a few
rules in that style sheet. All your slides, white papers, memos, etc --
not just your Web pages -- would automatically inherit the new appearance.
>...
> > 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).
>
> Attaching them is not enough. What if the external stylesheet imports
> another one ? What if it contains image URLs ? Are you going to remap
> them ? Using MIME content-ids ? If yes, how are going to save them on
> recipient's side ? Rewriting them again ?
In a word, yes. Unless the URLs are on a publicly-accessible Web server
(e.g. the author is using one of the W3C Core Styles), in which case
none of that is necessary.
>...
> And that's why at the time people started inventing style sheets, they
> *ALL* added processing instructions to the markup in order to store
> inline styles. Inline styles are (a) natural (b) absolutely necessary.
> IMHO, the XML people who want to get rid of the STYLE attribute are
> totally wrong.
Nice straw man you've got there! I never said that in-line styles
weren't natural or necessary -- and as for these `XML people' you speak
of, I've never heard of them.
But allowing users to specify an external style sheet for their
documents should be the *first* step in providing CSS styling in
Composer, not the last. And the coding involved in allowing
specification of one or more external style sheets for a document would
be *much* easier than that involved in allowing users to specify
intra-document CSS properties from within the editor.
> > > 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?
>
> Again, think of a Wysiwyg environment.
I'm sorry, I thought we were discussing an HTML editor.
> If you *SEE* something, copy
> and paste it somewhere else, you should *SEE* the same thing.
>...
<div id="sidebar" style="width: 25%; float: right; background: black;
color: white;">
<p>
Ok, here's a simple example.
</p>
<p>
Let's say I have an article, with a colored sidebar offering a
summary of the article. The article has a white background with
black text; the sidebar has a black background with white text.
</p>
<p>
Then I decide that one sentence from the sidebar would be better as
part of the main article.
</p>
</div>
<div id="article" style="background: white; color: black;">
<h1>The odyssey of King Fred</h1>
<p>
So I copy the sentence from the sidebar, and paste it into the main
article. Which do you think would be the most preferable behavior?
</p>
<ol>
<li>
<p>
Those in-line styles which were affecting the copied text, and
which do not (currently) affect the text at the position where
the text was inserted, are duplicated around the pasted text.
<span style="width: 25%; float: right; background: black; color:
white;">This results in an irregular black block with white
text in the midst of the article, where the whole of the rest of
the article is using black text on a white background.</span>
</p>
</li>
<li>
<p>
The sentence is copied without extra styling information, and
when pasted it inherits the style of the text around it.
</p>
</li>
</ol>
<p>
I know which I'd prefer.
</p>
</div>
--
Matthew `mpt' Thomas, Mozilla user interface QA
Mozilla UI decisions made within 48 hours, or the next one is free
