I was delayed a bit by a hardware failure and the holidays, but I finally
created a summary of this discussion and sent it to [EMAIL PROTECTED]
Here is a repost:
A recent discussion on the n.p.m.style newsgroup addressed the issue of
using css to styles items such as replies to email, where the original
message adds a character such as > or | to each line. A variety of ideas
were suggested, with the discussion details outlined here:
Stuart Ballard suggested an :every-line pseudo-class:
CSS needs a :every-line property similar to :first-line
Then we can do
p.quote:every-line:before { content: '> ' }
Daniel Glazman replied that:
This is not so easy to do, in fact. When you insert generated content
before or after the contents of the element, you only have to recompute
once the block-level box and inlines boxes for the element. Even in case
of reflow due to viewport resizing.
If every line can have generated content, it can be a long
loop because each content generation changes all the inline boxes after
it.
I don't say it is impossible, just not totally trivial.
Stuart Ballard replied:
>From an outsider's perspective, though, it seems like it should at least
be highly optimizable (almost to the point that the entire code would be
a special case) - the width of the generated content would be constant,
so the linewrapping could all just be done at the appropriately reduced
width.
You would have to either assume that the generated content only
inherited the style of the block-level element (so that for example
> some <b>bold
> text</b> here
would not bolden the second ">"), but given that rule, it should be easy
to implement without complexifying the rules too much. The only real
difficulty that I can imagine would be if the combined :before and
:after content were wider than the width of the box - but I'm sure that
Gecko eats special cases like that for breakfast! :)
Dylan Schiemann, then suggested the following:
I was just thinking about Daniel's comments and Stuart's reply, and it
gave me
a few really rough ideas. I could see a possibility of this working by
emulating the behavior for marker elements, with replaced content in
either
the margin or padding. By default, you could have a repeat-x value for
the
marker equal to the line height of the content contained inside.
Another possibility would be to extend background to include text
characters,
which could base their repeat-x value on the line-height of their
container.
So the style for an element would be something like:
p{padding-left:1.5em;background: char(">") repeat-x;}
or, if margins could have their own background, it could be:
p{margin-left: 1.5em char(">") repeat-x;}
While this doesn't explicity "add" the content to the document, it could
give
the desired view.
Basic LW then posted a screenshot of a hack to to this:
I've a CSS hack that does something like what you suggest. Attached is a
screenshot and a zip file containing a css file and a png file. To use
it, I put the files in the zip in the same directory as the
userContent.css and added a @import url(quoteHack.css); to it. I've only
tested this on win32, might not work as well on other systems because of
font differences.
screenshot:
news://secnews.netscape.com/3A37D07E.60501%40yahoo.com?part=1.2
zip file: news://secnews.netscape.com/3A37D07E.60501%40yahoo.com?part=1.3
Ben Bucksch then wrote:
Somebody suggested using char(something) instead of url(animage). Is
that possible?
Observing the font size of the quoted text would be good.
Also, as akk already mentioned, using background shows problems during
copy. In the clipboard, there won't be any indication that the text was
quoted.
I still believe that creating a :line-start pseudo-class or similar in
Gecko would be the best solution, in part because I think, it would be
generally useful, i.e. should be part of CSS3.
Dylan Schiemann then replied:
> Somebody suggested using char(something) instead of url(animage). Is
> that possible?
That somebody was me. I was suggesting it as a proposal, not as
something
that presently exists.... a way that css could be extended in css3 that
was
different than a pseudo-class and maybe more widely appropriate.
> Observing the font size of the quoted text would be good.
>
> Also, as akk already mentioned, using background shows problems during
> copy. In the clipboard, there won't be any indication that the text was
> quoted.
It would be nice to have copy/paste retain css information in mozilla...
some
sort of "Paste Special".
> I istill believe that creating a :line-start pseudo-class or similar in
> Gecko would be the best solution, in part because I think, it would be
> generally useful, i.e. should be part of CSS3.
I really think that generated content is the wrong approach here. The
content, whether is be > or vertical lines, is really only a style to
indicate
that it is someone else's quote. That is why I suggested a style that
behaved
like a background to the margin or padding. By adding content in such a
way
that it would be added to the document, it becomes a more permanent part
of
the content, which seems wrong to me.
Jonas Sicking then wrote:
That is IMO the best way to solve this. And that would require somethat
like
a char(">") for the paste to actually paste ">" characters (unlike having
an
image looking like a >).
However I don't really understand why having ">" to show quotes is that
important to people? I personally love the bars and all the other cool
stuff
that the text->html does. But I still think this is an interesting
discussion.
What I'd ideally see was that there was some kind of "MailML" that when
displayed in MailNews shows bars (or whatever else could be done in css)
for
quotes and when converted to text (to be pasted in some textonly place)
would use ">" to quote.
IMHO the char() thing could still be useful but not very important.
However
I think that there should be some way to define the font used:
body { background: char("My Cool Site", Verdana, Serif); }
or
body { background: char("My Cool Site"); background-font: Verdana, Serif;
}
Stuart Ballard then clarified his ideas:
Okay... but first I'll clarify my specific proposal. I'm only looking
for something that will work in a limited set of cases, provided that
(1) the cases where it will work can be defined in a clear and
reasonable way based on the CSS model, and (2) it will work for
plain-text, format=flowed email. Being able to use it for HTML mail
would be a bonus, but I'm not considering it a requirement.
Thus, I am proposing that :every-line be implemented for block-level,
non-replaced elements only, and should support only the :before and
:after sub-pseudo-elements. The style for :before and :after should be
based on the style for the block-level element that :every-line is
attached to, and ignore styles on inline elements within the block.
The result of putting a :before or :after on an :every-line
pseudo-element would be:
- Calculate the style of the generated content based on regular CSS
rules, treating the :before and :after as hanging directly off the
appropriate block-level element.
- Calculate the width of the :before and :after generated content
rendered in the calculated style
- Increase the effective margins of the block-level element by the
appropriate amounts (remembering that :before is on the right for RTL
text).
- For each line that is rendered within the block-level element, also
render the generated :before and :after content in the (newly expanded)
margin.
So, having made a concrete proposal, let's see how it handles each of
your points...
> You need a more vivid imagination. Think about how this would work with
> floats, tables, :first-letter, :first-line, and RTL text. Then think
about
> how it would work with all these things together :-). Oh, don't forget
> about nested quoting.
floats: Since my proposal modifies the margin, it should work just fine
with floats, right?
tables: Not a block-level non-replaced element; proposal doesn't apply.
Of course you can have block-level elements *inside* a table, in which
case the proposal still works.
:first-letter and :first-line: These would work as they usually do, but
rendering *inside* the newly-shrunk margins. I would suggest that we
shouldn't support styling the first line *of* the generated content, as
it breaks the assumption that the generated content will always be the
same width (That is, p.quote:every-line:before:first-line would be
illegal).
RTL text: nothing special, except that :before is on the right and
:after is on the left. I already mentioned that, though.
Nested quoting: margins nest, don't they? I believe this would just fall
out of the current proposal.
I'm not suggesting that this is easy to implement, but I don't think
that questions along the lines of "how would it work with XXXXX" are
terribly hard to answer :)
Robert O'Callahan then replied:
"Increasing the effective margins of the block element" would require
changes to lots of code and be ugly, since we'd need to track the "real"
margin and "effective" margin separately.
> I'm not suggesting that this is easy to implement, but I don't think
> that questions along the lines of "how would it work with XXXXX" are
> terribly hard to answer :)
Your proposal is good in that respect. I was thinking you wanted the
:before and :after content to be in the normal flow, but you effectively
take it out of the normal flow, which simplifies things considerably.
However, it does have some unfortunate implications. For example, when
you
select the quoted text, the quotes will not be selected. This is quite
contrary to current behavior and user expectations.
I still think that hacking layout with a custom CSS feature of limited
usefulness is not the right approach to this problem. I like Basic LW's
idea a lot more. BTW, his CSS file just contains this:
.moz-text-flowed blockquote {
background: url(quoteHack.png) repeat-y left top !important;
border:none !important;
padding-left : 15px !important;
}
To make it suck less when the text size changes, the background image
could just be a tiled, connected zig-zag line --- suggestive of ">"s, but
different enough that users don't expect it to have the same size as the
block's text.
Alistair Vining then added:
But this spoils one of the more interesting uses, which is to support
the style of French (and early printed) quotation which does something
similar, so that:
If you begin a « quotation which
« spans several lines, then a guillemet
« should be placed at the start of
« lines which follow. » like that.
In early printed books, the quotation marks were sometimes in the
margin. The über-TeX "Omega" project does this with \localleftbox{},
\localrightbox{} commands.
Many of us hope that something will work its way into CSS3 that would
allow a way to implement such a feature.
