Cascading styles

Cascading styles

[Lars Magne Ingebrigtsen]

We should probably implement (at least) text-decoration, text-transform
and font-style, and do the cascading thing.  But a thing just occurred
to me.

<p style="color: black;"><p style="color: white;">Foo</p></p>

will first make Foo white, and then black.  So, er, either the overlays
should be applied in reverse-stack-order, or `shr-insert-*-overlay'
should avoid clobbering overlays that are already there, and that use
the same properties (i.e., :foreground, etc).

The latter seems easier.

But what I wanted to talk was the CSS inheritance thing and non-inline
style sheets.

So here's my thought:

shr should parse the style sheet first, and bind the thing at the
top-most level, like:

(defun shr-insert-document (dom)
  (let ((shr-stylesheet (shr-parse-stylesheets dom)))
    ...))

or something.

And then we'd have

(defun shr-descend (dom)
  (let ((shr-stylesheet (append (shr-parse-style (cdr (assq :style (cdr dom))))))) ...
  
So you'd inherit down into the DOM and pop when you exit.  However,
would that be correct?  Er, no, not really.  So you'd basically have the
inline thing, plus the stylesheet, but not endlessly combining inline
things.

And I'm not sure this is worth doing...  I mean, implementing it is
probably easy, but computation-wise for the user...
  
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cascading styles

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Thu, Nov 25 2010, Lars Magne Ingebrigtsen wrote:

> will first make Foo white, and then black.  So, er, either the overlays
> should be applied in reverse-stack-order, or `shr-insert-*-overlay'
> should avoid clobbering overlays that are already there, and that use
> the same properties (i.e., :foreground, etc).

Well I had the same problem with background. I resolved it by inserting
the background overlay with rear-advance.
But actually that's not a good fix since it will never stop advancing…
But I need it to be inserted before so the foregrounds will know what
the background is.

> So you'd inherit down into the DOM and pop when you exit.  However,
> would that be correct?  Er, no, not really.  So you'd basically have the
> inline thing, plus the stylesheet, but not endlessly combining inline
> things.

I am missing the why. :)

> And I'm not sure this is worth doing...  I mean, implementing it is
> probably easy, but computation-wise for the user...

I like it. It would be fun!

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Cascading styles

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Well I had the same problem with background. I resolved it by inserting
> the background overlay with rear-advance.
> But actually that's not a good fix since it will never stop advancing…
> But I need it to be inserted before so the foregrounds will know what
> the background is.

Ah, right.  Hm...  this complicates things somewhat.

Like with

<p style="background: blue; color: red;">foo<p style="color: green;">bar</p></p>

the inner thing doesn't know what the background is...

However, if we did bind `shr-style', then the inner thing could just
look what the current background setting is and do its thing.

>> So you'd inherit down into the DOM and pop when you exit.  However,
>> would that be correct?  Er, no, not really.  So you'd basically have the
>> inline thing, plus the stylesheet, but not endlessly combining inline
>> things.
>
> I am missing the why. :)

Well, in this case, the colour renderer is interested in seeing what
background is, so it's (sort of) inherited downwards, while a border
setting is not.

Perhaps we should just special-case the colour settings.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cascading styles

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Fri, Nov 26 2010, Lars Magne Ingebrigtsen wrote:

>>> So you'd inherit down into the DOM and pop when you exit.  However,
>>> would that be correct?  Er, no, not really.  So you'd basically have the
>>> inline thing, plus the stylesheet, but not endlessly combining inline
>>> things.
>>
>> I am missing the why. :)
>
> Well, in this case, the colour renderer is interested in seeing what
> background is, so it's (sort of) inherited downwards, while a border
> setting is not.
>
> Perhaps we should just special-case the colour settings.

I don't like special-case.

I don't see why inheriting would not work with what you did propose. if
its shr-descend call adds style information to the dynamic variable
shr-stylesheet (and merge them of course), we're just having correct
inheritance.

With:
<p style="background: blue; color: red;">foo<p style="color: green;">bar</p></p>

You start with the first style, render foo with background and
foreground. Then you got for bar via shr-descend, which changes color to
green, but merge with the previous dynamically bound shr-stylesheet, so
it still has background set to 'blue'. You render bar, exit 2
shr-descend calls, and continue to render what else is in the document.

If only I had more time I would try to implement something. :)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Cascading styles

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> I don't see why inheriting would not work with what you did propose. if
> its shr-descend call adds style information to the dynamic variable
> shr-stylesheet (and merge them of course), we're just having correct
> inheritance.

Yes, but that's special-casing the colour things.  :-)  If you have

<p style="border: 3px;">foo<p>bar

then only the top-level p should have a border, and the next one
shouldn't.  But it's kinda moot, since I don't think any of the
properties we're interested in have this kinda of behaviour.

> With:
> <p style="background: blue; color: red;">foo<p style="color: green;">bar</p></p>
>
> You start with the first style, render foo with background and
> foreground. Then you got for bar via shr-descend, which changes color to
> green, but merge with the previous dynamically bound shr-stylesheet, so
> it still has background set to 'blue'. You render bar, exit 2
> shr-descend calls, and continue to render what else is in the document.

Yes...  except that we're setting the colour after rendering all the
children today.  So I think we'll have to have the inheritance as well
as the non-overwriting colour property stuff to get it right.

I'm not sure how selectors like

p.foo > div > p { colour: red; }

selectors fit in here.  I suspect it doesn't.  :-)

I'll take a whack at implementing the inheritance thing, and we'll see
how that goes...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cascading styles

[Lars Magne Ingebrigtsen]

I've now made the color CSS stuff have inheritance and stuff.  There are
probably bugs in the code, but I think the general idea should be
sound.  (Ish.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cascading styles

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Sun, Dec 05 2010, Lars Magne Ingebrigtsen wrote:

> Yes, but that's special-casing the colour things.  :-)  If you have
>
> <p style="border: 3px;">foo<p>bar
>
> then only the top-level p should have a border, and the next one
> shouldn't.  But it's kinda moot, since I don't think any of the
> properties we're interested in have this kinda of behaviour.

Well, rendering foo is calling shr-descend, so you'll only have border
style set on foo. (how to draw the border is another problem. :))

>> With:
>> <p style="background: blue; color: red;">foo<p style="color: green;">bar</p></p>
>>
>> You start with the first style, render foo with background and
>> foreground. Then you got for bar via shr-descend, which changes color to
>> green, but merge with the previous dynamically bound shr-stylesheet, so
>> it still has background set to 'blue'. You render bar, exit 2
>> shr-descend calls, and continue to render what else is in the document.
>
> Yes...  except that we're setting the colour after rendering all the
> children today.

Yes, that's our problem I think. I think it should be done in 2 passes:
first render text (`insert') then render style (`overlay'). That would
probably solves all the problem (and maybe insert new ones :-)).

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Cascading styles

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Yes, that's our problem I think. I think it should be done in 2 passes:
> first render text (`insert') then render style (`overlay'). That would
> probably solves all the problem (and maybe insert new ones :-)).

I just implemented it by not overwriting any colours that were already
present in the buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cascading styles

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote:

>> Yes, that's our problem I think. I think it should be done in 2 passes:
>> first render text (`insert') then render style (`overlay'). That would
>> probably solves all the problem (and maybe insert new ones :-)).
>
> I just implemented it by not overwriting any colours that were already
> present in the buffer.

I've fixed a bunch of stuff so everything is working better. Now we
colorize only in one place, we just enhance the stylesheet with the
information the tag can have, like bgcolor, etc.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]