Stuart Ballard wrote:
> 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.
"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.
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]
