CSS needs a :every-line property similar to :first-line

Then we can do

p.quote:every-line:before { content: '> ' }

Adding n.p.m.layout and n.p.m.style - anyone here know how hard it would
be to implement such a property (or whether there is anything like it
planned in CSS3)?

Stuart.

FYI: You are completely right. This is exactly what I would have done,
if I had the option. That's why I said "can't do that".

In article <3A355A58.6010...@bucksch.org>,
   Ben Bucksch <mozilla.n...@bucksch.org> wrote:

I think his real point is that he wants to bring this to the attention
of whoever COULD add such an option to CSS or otherwise implement such
a feature.

I would like to second his plea.

--
J.B. Moreno

I know :).

Add mine :).

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.

</Daniel>

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

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! :)

Stuart.

Hi all,

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.

-Dylan Schiemann
http://www.dylanschiemann.com/

In article <3A35F735.5050...@netscape.com>,
   Daniel Glazman <glaz...@netscape.com> wrote:

-snip inserting something on every line-

I realize it isn't totally trivial -- but it is perhaps the #1
request/complaint about format=flowed that I've seen.  People love the
idea, but not everyone likes the bars.

And it'd have uses outside of quoting.

--
J.B. Moreno

That rule would be REALLY hard to implement.

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.

Rob
--
[Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student
"Now when Joshua was near Jericho, he looked up and saw a man standing in
front of him with a drawn sword in his hand. Joshua went up to him and
asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but
as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

You mean, it should be possible to limit the width of the paragraph? You
can do that today already.

So, if you don't like that format=flowed wraps only at he windows width,
because your window is too wide to allow a comfortable reading, you can
do some CSS to achiove what you want. Should work with current builds.

I was thinking it would be *easier* to implement, because it would make
the width of the generated content constant. If you don't assume that,
you have to determine the style of the generated content based on any
*inline* elements that happen to be active that the relevant point in
the block-level element. Which means that, for example, the word
wrapping on line 1 could change the width of the generated content on
line 2, which could change the word-wrapping of line 2. So it makes your
loop much more complex, and it means you aren't word-wrapping to a fixed
width.

See below for a full specification of behavior, which explains exactly
why I think my rule would be easier to implement.

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...

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 :)

Stuart.

Ooops! Attached the wrong zip file. Here is the right one. To use it
unzip it into your Users50/username/blahblahblah/chrome directory. Add a
@import url(quoteHack.css); to the top of your userContent.css file in
the same directory. If you don't have a userContent.css create one.

Basic LW

quoteHack.zip < 1K Download

In article <3A37D07E.60...@yahoo.com>,
   "Basic (LW)" <_ba...@yahoo.com> wrote:

Ben, any comments upon this?  Do you think it's feasible to use as the
default, or as a standard pref at least?

From looking at the screen shot it looks fine, but a single screen shot
doesn't say a lot in this instance.

--
J.B Moreno

[uses background image]

Yes, well done, especially considering my outdated docs :-/.

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 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.

No. I believe that in general, vertical bars are better than ">"s,
especially if you know for sure that it is a quote.

Why a pref, if you can do it with a few CSS lines in your user stylesheet?

"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.

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.

Rob
--
[Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student
"Now when Joshua was near Jericho, he looked up and saw a man standing in
front of him with a drawn sword in his hand. Joshua went up to him and
asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but
as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

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.

It would be nice to have copy/paste retain css information in mozilla... some
sort of "Paste Special".

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.

-Dylan Schiemann
http://www.dylanschiemann.com/

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; }

Good point.

/ Jonas Sicking

In article <3A37FD12.9080...@bucksch.org>,
   Ben Bucksch <mozilla.n...@bucksch.org> wrote:

I don't think that's as important as the display being "correct".

-snip-

We'll just have to disagree on this -- I think that for this release
it'd be better to show ">" by default and have the option of showing
bars, bars could be the default in the next version (or since my wishes
aren't being taken as commands from on high, maybe not).

Because I haven't a clue as to how or where to edit the user stylesheet
and I probably never will, and I don't think I am that unusual in this
respect.

It's cool that stuff like this is possible with CSS, it's not cool to
require that the user do it for everything (in particular, this is
probably going to be a popular choice, even with the problems with
copying, and should be a pref).

--
J.B. Moreno

IC. But I guess, content(">") would work.

I just remember: The information of being a quote *is* there: The quotes
are all in a <blockquote type=cite>. Its default style is just
overridden based on the prefs. During copy, the style is not copied,
i.e. we get the raw <blockquote type=cite again>.

That's how it is. Just that we don't use MailML, but HTML.

We don't use HTML either if we have |type="cite"|...

--
Ian Hickson                                     )\     _. - ._.)       fL
Netscape, Standards Compliance QA              /. `- '  (  `--'
+1 650 937 6593                                `- , ) -  > ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________

huh? The display is correct. (We are talking about format=flowed.) Using
">"s would only *add* ambiguity. (That doesn't mean, we shouldn't offer
the option, since some users seems to want it.)

I don't think, there will ever be pref UI for it, unless we couple it
with disabling the bars for normal plaintext.
If there is no UI, editing prefs.js or userContent.css is not very
different.

Setting Followup-To .mail-news

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.

Real-world uses?  Oops, must be in the wrong newsgroup.

Al.

Just my .02$ about this discussion : it is about an enhancement of
the css themselves, not mozilla's, and the css&fp working group would
be happy to read it in www-st...@w3.org... It is a good way to
push something to the group efficiently.

</Daniel>, member of the css&fp wg...

Daniel,

I agree.  I was waiting for the idea to mature a little bit, but it is
probably ready for discussion with the working group.  Is anyone
interested in summarizing the desired feature and proposed ideas so far?
If not, I'll volunteer to do so sometime this weekend.

-Dylan Schiemann
http://www.dylanschiemann.com/

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 www-st...@w3.org.
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

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

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:

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.

It would be nice to have copy/paste retain css information in mozilla...
some
sort of "Paste Special".

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.

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...

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.

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
...

read more »