[bug]: ignored CSS attributes on html element
Penny Arcade is illegible in Dillo[1]. The problem is that its CSS sets the text attribute on the html element and Dillo ignores this, so we get black text on blue instead of white text on blue. Here is a demo: <html> <head> <style type="text/css">html{text:#F00;}</style> </head> <body> Blah, blah, blah </body> </html> The text is plain black, but if you change html to body in the CSS then the text is red as it should be. Thoughts on how to fix this? It's not obvious to me whether this is a one-liner patch or something more radical is needed. Regards, Jeremy Henty [1] see http://www.penny-arcade.com/2010/9/10/
Hi, On Sun, Sep 12, 2010 at 10:26:29PM +0100, Jeremy Henty wrote:
Penny Arcade is illegible in Dillo[1]. The problem is that its CSS sets the text attribute on the html element and Dillo ignores this, so we get black text on blue instead of white text on blue.
Here is a demo:
<html> <head> <style type="text/css">html{text:#F00;}</style> </head> <body> Blah, blah, blah </body> </html>
The text is plain black, but if you change html to body in the CSS then the text is red as it should be.
Thoughts on how to fix this? It's not obvious to me whether this is a one-liner patch or something more radical is needed.
Hm, I've never seen the "text" property in CSS, can you point me to the place where it is documented? Also in http://www.penny-arcade.com/2010/9/10/ I can't find the string "text:" neither in the source nor in the stylesheet - am I missing something? Regards, Johannes
On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
Hi, Hm, I've never seen the "text" property in CSS, can you point me to the place where it is documented? Also in http://www.penny-arcade.com/2010/9/10/ I can't find the string "text:" neither in the source nor in the stylesheet - am I missing something?
Regards, Johannes
I'm guessing it's just a typo for "color". ~Benjamin
On Mon, Sep 13, 2010 at 03:54:22PM -0400, Benjamin Johnson wrote:
On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
Hm, I've never seen the "text" property in CSS, can you point me to the place where it is documented? Also in http://www.penny-arcade.com/2010/9/10/ I can't find the string "text:" neither in the source nor in the stylesheet - am I missing something?
I'm guessing it's just a typo for "color".
Yes, you're right. I'm bewildered as to how I could have messed that up. But anyway, dillo ignores the "color" attribute on the html element (as easily seen by changing "text" to "color" in the example I gave and then experimenting with changing between "html" and "body"). So, how to fix this? Regards, Jeremy Henty
On Tue, Sep 14, 2010 at 07:26:53PM +0100, Jeremy Henty wrote:
On Mon, Sep 13, 2010 at 03:54:22PM -0400, Benjamin Johnson wrote:
On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
Hm, I've never seen the "text" property in CSS, can you point me to the place where it is documented? Also in http://www.penny-arcade.com/2010/9/10/ I can't find the string "text:" neither in the source nor in the stylesheet - am I missing something?
I'm guessing it's just a typo for "color".
Yes, you're right. I'm bewildered as to how I could have messed that up. But anyway, dillo ignores the "color" attribute on the html element (as easily seen by changing "text" to "color" in the example I gave and then experimenting with changing between "html" and "body"). So, how to fix this?
It took me a while to find out, but the reason is rather simple: The <html> is opened before the style is loaded (it's in <head> after all). So at the time we call startElement() for <html>, we don't have the style information. I didn't find anything in the CSS reference how to handle this case, but major browsers seem to allow CSS for the html-element. We could somehow delay the startElement() call for <html> until <head> is parsed completely, but I have to look for a way to make this hack not too ugly... Suggestions welcome :-) Cheers, Johannes
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Tue, 14 Sep 2010 14:54:19 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
It took me a while to find out, but the reason is rather simple:
The <html> is opened before the style is loaded (it's in <head> after all). So at the time we call startElement() for <html>, we don't have the style information.
I didn't find anything in the CSS reference how to handle this case, but major browsers seem to allow CSS for the html-element.
We could somehow delay the startElement() call for <html> until <head> is parsed completely, but I have to look for a way to make this hack not too ugly... Suggestions welcome :-)
Cheers, Johannes
Maybe treat it, for CSS purposes, like a second <body> tag? i.e. rather than delay startElement(), map CSS attributes assigned to "html" to some pseudo-element parsed just before <body>. That might be a really stupid idea, but it makes sense to me since that's how <html> usually behaves, CSS-wise. For example, on my own sites I use something like html { background: #202020; color: #202020; } body { background: white; width: 6in; margin: 2em auto 2em auto; padding: 1em 4em 1em 4em; border: 2px solid black; } to display the body as a white box against a black background. ~Benjamin
On Tue, Sep 14, 2010 at 03:27:25PM -0400, Benjamin Johnson wrote:
On Tue, 14 Sep 2010 14:54:19 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
It took me a while to find out, but the reason is rather simple:
The <html> is opened before the style is loaded (it's in <head> after all). So at the time we call startElement() for <html>, we don't have the style information.
I didn't find anything in the CSS reference how to handle this case, but major browsers seem to allow CSS for the html-element.
We could somehow delay the startElement() call for <html> until <head> is parsed completely, but I have to look for a way to make this hack not too ugly... Suggestions welcome :-)
Cheers, Johannes
Maybe treat it, for CSS purposes, like a second <body> tag? i.e. rather than delay startElement(), map CSS attributes assigned to "html" to some pseudo-element parsed just before <body>.
That might be a really stupid idea, but it makes sense to me since that's how <html> usually behaves, CSS-wise. For example, on my own sites I use something like
html { background: #202020; color: #202020; }
body { background: white; width: 6in; margin: 2em auto 2em auto; padding: 1em 4em 1em 4em; border: 2px solid black; }
to display the body as a white box against a black background.
Ok it is defined here: http://www.w3.org/TR/CSS2/colors.html They say "we recommend that authors specify the background for the BODY element rather than the HTML element", but I guess we still have to support it for <html> as well. Johannes
On Tue, Sep 14, 2010 at 07:26:53PM +0100, Jeremy Henty wrote:
On Mon, Sep 13, 2010 at 03:54:22PM -0400, Benjamin Johnson wrote:
On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
Hm, I've never seen the "text" property in CSS, can you point me to the place where it is documented? Also in http://www.penny-arcade.com/2010/9/10/ I can't find the string "text:" neither in the source nor in the stylesheet - am I missing something?
I'm guessing it's just a typo for "color".
Yes, you're right. I'm bewildered as to how I could have messed that up. But anyway, dillo ignores the "color" attribute on the html element (as easily seen by changing "text" to "color" in the example I gave and then experimenting with changing between "html" and "body"). So, how to fix this?
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec. Regards, Johannes
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame. So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions? Cheers, Johannes
Johannes wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Is it incorrect for dillo to have a body textblock smaller than the whole page? (I remember looking into this when we couldn't pop up menus below the bottom of the textblock, and I think it was either not quite trivial, or ugly to deal with, but if we accumulate other ugliness to work around it...)
On Sat, Sep 18, 2010 at 06:54:00PM +0000, corvid wrote:
Johannes wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Is it incorrect for dillo to have a body textblock smaller than the whole page?
If I check <body style="border: 1px solid black"> dillo </body> with dillo and firefox, it seems that both do more or less the same. Cheers, Johannes
On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Can't we set both <html> and <body> ? -- Cheers Jorge.-
On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote:
On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Can't we set both <html> and <body> ?
Unfortunately no. If we do that and the page sets background-color for body, we would have a frame with our background-color and a box (for <body>) with the background-color defined in the page. Also if the page sets a background-color for <html>, we have a frame with the pages background-color and a box with our color. Cheers, Johannes
On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote:
On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Can't we set both <html> and <body> ?
Unfortunately no. If we do that and the page sets background-color for body, we would have a frame with our background-color and a box (for <body>) with the background-color defined in the page. Also if the page sets a background-color for <html>, we have a frame with the pages background-color and a box with our color.
I see... IMHO, having just one place for setting the appearance is an important asset (simplicity/orthogonality). If we can keep this feature without introducing an ugly hack I'd go for it. Now, as you know much better the implementation details, I leave it for you to decide. -- Cheers Jorge.-
On Tue, Sep 21, 2010 at 01:39:47PM -0400, Jorge Arellano Cid wrote:
On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote:
On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote:
Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Can't we set both <html> and <body> ?
Unfortunately no. If we do that and the page sets background-color for body, we would have a frame with our background-color and a box (for <body>) with the background-color defined in the page. Also if the page sets a background-color for <html>, we have a frame with the pages background-color and a box with our color.
I see...
IMHO, having just one place for setting the appearance is an important asset (simplicity/orthogonality).
If we can keep this feature without introducing an ugly hack I'd go for it. Now, as you know much better the implementation details, I leave it for you to decide.
I fully agree, but currently I don't see any way to set the background color from the user-agent-, or user-stylesheet such that it works for pages that set background-color on the <html> element and for pages that set background-color on the <body> element. I will prepare the patch and sleep some nights over it. Then we can decide whether we commit it. Cheers, Johannes
On Tue, Sep 21, 2010 at 10:20:27PM +0200, Johannes Hofmann wrote:
On Tue, Sep 21, 2010 at 01:39:47PM -0400, Jorge Arellano Cid wrote:
On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote:
On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote:
On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote:
Johannes wrote: > Please test attached patch. It is a bit more involved than I had > hoped, but it seems necessary after looking at the spec.
en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.
Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame.
So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions?
Can't we set both <html> and <body> ?
Unfortunately no. If we do that and the page sets background-color for body, we would have a frame with our background-color and a box (for <body>) with the background-color defined in the page. Also if the page sets a background-color for <html>, we have a frame with the pages background-color and a box with our color.
I see...
IMHO, having just one place for setting the appearance is an important asset (simplicity/orthogonality).
If we can keep this feature without introducing an ugly hack I'd go for it. Now, as you know much better the implementation details, I leave it for you to decide.
I fully agree, but currently I don't see any way to set the background color from the user-agent-, or user-stylesheet such that it works for pages that set background-color on the <html> element and for pages that set background-color on the <body> element.
I will prepare the patch and sleep some nights over it. Then we can decide whether we commit it.
Ok here http://flpsed.org/tmp/html_element_style.diff is the updated patch. It brings back the bg_color dillorc option. Please give it a try. Cheers, Johannes
Johannes wrote:
Ok here http://flpsed.org/tmp/html_element_style.diff is the updated patch. It brings back the bg_color dillorc option. Please give it a try.
I'm getting an assertion failure with: <html> <head> <head> </head> <body> </body> </html>
yOn Sun, Sep 26, 2010 at 12:04:06AM +0000, corvid wrote:
Johannes wrote:
Ok here http://flpsed.org/tmp/html_element_style.diff is the updated patch. It brings back the bg_color dillorc option. Please give it a try.
I'm getting an assertion failure with:
<html> <head> <head> </head> <body> </body> </html>
Oh, good point. This needs some thought...
participants (5)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
obeythepenguin＠gmail.com -
onepoint＠starurchin.org