Robert O'Callahan wrote:
>
> Stuart Ballard wrote:
> > 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.
>
> That rule would be REALLY hard to implement.
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.
> > 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! :)
>
> 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.
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 :)
Stuart.
