W3C home > Mailing lists > Public > www-style@w3.org > January 2001

summary of recent mozilla discussion on styling every line

From: Dylan Schiemann <dylans@yahoo.com>
Date: Sun, 21 Jan 2001 18:10:27 -0800 (PST)
Message-ID: <20010122021027.26227.qmail@web124.yahoomail.com>
To: www-style@w3.org
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.

-Dylan Schiemann

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/
Received on Sunday, 21 January 2001 21:10:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:07 GMT