September 2010 - Dillo-dev - lists.mailman3.com

[bug]: ignored CSS attributes on html element

by corvid＠lavabit.com

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

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

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

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by onepoint＠starurchin.org

On Fri, Sep 17, 2010 at 11:20:02PM +0200, Johannes Hofmann wrote: > Please test attached patch. It is a bit more involved than I had > hoped, but it seems necessary after looking at the spec. It works! Regards, Jeremy Henty

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by corvid＠lavabit.com

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.

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

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(a)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

Sept. 17, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

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(a)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

Sept. 17, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by Johannes.Hofmann＠gmx.de

On Wed, Sep 15, 2010 at 09:24:58PM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > I don't have a solution yet, but I envision something, where e.g. > > Html_write_raw() or DilloHtml::write() works with a const buf and > > buflen (no null-termination required), but non-terminated buffers > > don't leak into lower-layer functions (like Html_process_space(), or > > Html_process_word()). > > In that case, whenever a "high-layer" function like Html_write_raw() > calls a lower-layer function it will have to either poke in a null > byte (as Html_write_raw() does now) or copy a segment of its buffer > into a new null-terminated buffer. If you want the original buffer to > be const then it can't poke in a null, so it will have to copy. > Unless there's a third way, but I can't see one. As I said, I don't have any good idea either. So maybe what we currently have is a good compromise - I don't know. Also I won't invest much time as there are is no real need to change things. > > Would you consider all the Html_tag_open_*() functions to be > lower-layer too? If so then it would be natural (as I understand your > suggestion) for them to lose their length arguments. Is that right? > And presumably Html_get_{attr,attr2}() also? The more I think about > this the more functions in html.cc I think it might affect. Maybe we > could clone a new repository to experiment with? I would leave them as they are but feel free to experiment. Having a cloned repo for experimenting is always a good idea. I have a clone for every non-trivial thing I do. Regards, Johannes

Sept. 17, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by onepoint＠starurchin.org

Johannes Hofmann wrote: > I don't have a solution yet, but I envision something, where e.g. > Html_write_raw() or DilloHtml::write() works with a const buf and > buflen (no null-termination required), but non-terminated buffers > don't leak into lower-layer functions (like Html_process_space(), or > Html_process_word()). In that case, whenever a "high-layer" function like Html_write_raw() calls a lower-layer function it will have to either poke in a null byte (as Html_write_raw() does now) or copy a segment of its buffer into a new null-terminated buffer. If you want the original buffer to be const then it can't poke in a null, so it will have to copy. Unless there's a third way, but I can't see one. Would you consider all the Html_tag_open_*() functions to be lower-layer too? If so then it would be natural (as I understand your suggestion) for them to lose their length arguments. Is that right? And presumably Html_get_{attr,attr2}() also? The more I think about this the more functions in html.cc I think it might affect. Maybe we could clone a new repository to experiment with? Regards, Jeremy Henty

Sept. 15, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by Johannes.Hofmann＠gmx.de

On Wed, Sep 15, 2010 at 07:45:06AM +0100, Jeremy Henty wrote: > > Just to clarify, I wasn't expecting any speed-up from this, it was > just a cleanup patch. I accept the point about the dangers of fragile > APIs in general, but I don't find it very compelling in this > particular case. Html_process_word() is called from only one place, > and it's caller has to hack its around the entirely unnecessary > requirement that the argument be null-terminated. I don't see that > any API is damaged just by cleaning up this particular function call. First I have to say that I agree with Jorge. Working with non NULL-terminated buffers is extremly ugly and error prone. The reason is that when using length based variants of the standard string routines (e.g. strncmp() ...) you always have to recompute the length relative to your current position in the buffer. With null-terminated strings no matter where you are in the string it will still be properly terminated. On the other hand I'd also like to see Html_write_raw() to work on a const-buffer and even drop the requirement that it's buf parameter needs to be null-terminated (which is not addressed in your patch atm). The reason is that currently we pass a buflen and _also_ require buf to be null-terminated. That's rather confusing. I don't have a solution yet, but I envision something, where e.g. Html_write_raw() or DilloHtml::write() works with a const buf and buflen (no null-termination required), but non-terminated buffers don't leak into lower-layer functions (like Html_process_space(), or Html_process_word()). Also, as there is no pressing need we should be extremely careful and think twice before changing things. Regards, Johannes

Sept. 15, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by onepoint＠starurchin.org

Just to clarify, I wasn't expecting any speed-up from this, it was just a cleanup patch. I accept the point about the dangers of fragile APIs in general, but I don't find it very compelling in this particular case. Html_process_word() is called from only one place, and it's caller has to hack its around the entirely unnecessary requirement that the argument be null-terminated. I don't see that any API is damaged just by cleaning up this particular function call. Regards, Jeremy Henty

Sept. 15, 2010