- Dillo-dev - lists.mailman3.com

[bug]: CSS sets insanely huge vertical extent

by onepoint＠starurchin.org

On Fri, Oct 15, 2010 at 11:41:18AM +0200, Johannes Hofmann wrote: > I just pushed a fix for the use of uninitialized values issue. Great! I just confirmed that it fixes the test case, and it also fixes the page where I first saw the problem (which is a relief - Hijinks Ensue is one of my favourite webcomics and it would have been upsetting if it had been unreadable in Dillo). > That fixes your testcase, but the modified one below is still > broken. By "broken" you mean that it should respect the "line-height: 10em;" style? Regards, Jeremy Henty PS: I now regret using "insanely" in the subject line - it was over the top and might even be considered derogatory. I apologise to anyone who felt it was inappropriate.

Oct. 15, 2010

Polygon::isPointWithin()

by corvid＠lavabit.com

Why isn't this working? It seems like a perfectly ordinary shape... <html> <body> <img src="doesnt_matter.gif" width="250" height="700" usemap="#themap"> <map name="themap"> <area shape="poly" coords="1,250, 245,270, 223,513" href="http://www.dillo.org"> </map> </body> </html> Dillo doesn't realize it when the cursor is inside the left part of the polygon. I was hoping that this vector product stuff was Johannes code, but I see it goes back to the initial revision of the dw2 tree, so who knows where Sebastian might have gotten the algorithm from...

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

On Fri, Oct 15, 2010 at 10:30:01AM +0200, Johannes Hofmann wrote: > Hi Jeremy, > > On Thu, Oct 14, 2010 at 07:16:15PM +0100, Jeremy Henty wrote: > > > > This small bit of HTML (attached) renders with an enormous vertical > > extent in Dillo - I have to hold down the mouse in the lower half of > > the scrollbar for several seconds before the slider moves even one > > pixel! Strangely, if you take out the "<span>"s then the vertical > > extent is *much* smaller, although still far too large. What's going > > on? > > Thanks for the nice test case. valgrind shows, that an > uninitialized value is used somewhere. > The problem seems quite tricky: > A value of 'auto' is not allowed for line-height ('normal' would be > correct), but dillo does not ignore the declaration as it should. > Attached is a slightly modified test case, that shows the issue. > There are two competing declarations for line-height and normally > the last should win, but if it is illegal, the first should be used. > firefox does that correctly and shows the illegal declaration in the > error console. > I will try to fix it. I just pushed a fix for the use of uninitialized values issue. That fixes your testcase, but the modified one below is still broken. Cheers, Johannes > > Cheers, > Johannes > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > <html> > <head> > <title></title> > <style type="text/css" > > li {line-height: 10em;} > li {line-height: auto;} > </style> > </head> > <body> > Begin > <ul> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > </ul> > End > </body> > </html>

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Thu, Oct 14, 2010 at 07:16:15PM +0100, Jeremy Henty wrote: > > This small bit of HTML (attached) renders with an enormous vertical > extent in Dillo - I have to hold down the mouse in the lower half of > the scrollbar for several seconds before the slider moves even one > pixel! Strangely, if you take out the "<span>"s then the vertical > extent is *much* smaller, although still far too large. What's going > on? Thanks for the nice test case. valgrind shows, that an uninitialized value is used somewhere. The problem seems quite tricky: A value of 'auto' is not allowed for line-height ('normal' would be correct), but dillo does not ignore the declaration as it should. Attached is a slightly modified test case, that shows the issue. There are two competing declarations for line-height and normally the last should win, but if it is illegal, the first should be used. firefox does that correctly and shows the illegal declaration in the error console. I will try to fix it. Cheers, Johannes

Oct. 15, 2010

Pending tasks

by jcid＠dillo.org

On Thu, Oct 14, 2010 at 09:49:37AM +0200, Johannes Hofmann wrote: > On Wed, Oct 13, 2010 at 03:13:16PM -0300, Jorge Arellano Cid wrote: > > On Tue, Oct 12, 2010 at 09:54:13PM +0200, Johannes Hofmann wrote: > > *snip* > > > > > > > > > As currently the cell border, padding and margin are drawn by > > > > the cell widget (textblock) inside a table, the general idea is > > > > to make textblock consider "collapse" mode when inside a table. > > > > > > postprocessAttrs() does not take into account in which > > > element we currently are (e.g. <table>, <td>, ...) > > > You could check whether you currently are in a certain element by > > > looking at doctree->top ()->element and do special things for > > > certain elements. > > > However looking at "The collapsing border model" I'm not sure > > > whether you can get away with leaving the dw/* code as it is and > > > just fiddling with the Style objects. > > > For example if you have > > > > > > <td>1</td><td>2</td> > > > > > > There currently is no way to get the style of the first <td> when > > > creating the style of the second <td> in StyleEngine - which you > > > would need to compute the thickness of the border between the two. > > > > Fully agreed. > > > > > Actually we can't play with the values of the Style object in > > > postprocessAttrs() as we like. > > > They must contain what the spec mentions as "computed > > > value". And as I read the spec, the computed value of e.g. > > > border-width does not depend on the value of border-collapse. > > > > I didn't know this ("computed value" requirement). Well, it > > defines better what's to be done if ever. > > > > > > > What *might* work is to take the Style object that StyleEngine gives > > > you and modify it in in case that border-collapse is set before passing > > > it to the table cell in src/table.cc:293. > > > > Do you mean as if it was a nonCssHint? > > I was afraid CSS would take precedence (i.e. if nonCssHint says > > margin is 0 and CSS says it's 20, I'd bet on the second one!). > > No, not via nonCssHints. I meant to directly modify the style before > giving it to the Textblock. Attached is a small patch to demonstrate > what I mean. > With some more work I think we could make it cover the most common > cases of the collapsing border model. > > > > > At this point, if we can set margin to zero for the "separate" > > model, and half the value for "collapsing" it would be quite an > > advance (in rendering). OTOH, it must be commented as a > > workaround because it's not the correct way to implement it. An > > implementation would need major surgery. > > > > > > > > Another approach is to make dw::table render its borders and > > > > margin, and only leave padding to the cell widget. > > > > > > Yes, that's the other way to do it. You could still reuse the border > > > drawing helper routines from style.cc. > > > Nevertheless it might be pretty complex. Not sure if it is really > > > worth it... > > > > Fully agreed. > > > > Most probably a full implementation is not worth ATM, given the > > small use cases out there. A partial workaround may help though. > > Yes, I think it would be reasonable to just cover the common cases > e.g a table with a 1px grid with a single color and style. After some more testing, and some tricks, it looks like common cases could get away with a good workaround. I'll keep working on it. -- Cheers Jorge.-

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by onepoint＠starurchin.org

This small bit of HTML (attached) renders with an enormous vertical extent in Dillo - I have to hold down the mouse in the lower half of the scrollbar for several seconds before the slider moves even one pixel! Strangely, if you take out the "<span>"s then the vertical extent is *much* smaller, although still far too large. What's going on? Regards, Jeremy Henty

Oct. 14, 2010

Re: Dillo config in LTIB

by vic＠smartqsys.com

Hi Johannes, Right, after editing etc/resolv.conf and setting nameserver ip after dillo is launched, it can now resolve WLAN addresses but still remains unreachable. However, local LAN published web pages can now display. So I'm sure wget will work within LAN but not WLAN. It looks like a gateway ip/ routing issue at this point. Is there a gateway ip related variable much like what nameserver is for the dns ip? Btw, does dillo support printing initiated via the web page's html script? Thanks so much, Vic Message: 4 Date: Thu, 14 Oct 2010 09:13:40 +0200 From: Johannes Hofmann Subject: Re: [Dillo-dev] Re: Dillo config in LTIB To: dillo-dev(a)dillo.org Message-ID: <20101014071340.GB934(a)blob.baaderstrasse.com> Content-Type: text/plain; charset=us-ascii On Thu, Oct 14, 2010 at 12:00:47AM +0800, vic wrote: > Hi Jorge, > > Thanks for the prompt reply. I'm using ltib Linux kernel 2.6.34 on an Embedded Artists LPC3250 development board, no firewall. The board is connected to a gateway router. > > Does "ping www.dillo.org" resolve? > It does not, it responds with "unreachable destination". However, a ping to a host in the local LAN is fine and a link to a host in the local LAN has this response... > > > Nav_open_url: new url='http://192.168.1.6:88' > > Dns_server [0]: 192.168.1.6 is 192.168.1.6 > > Connecting to 192.168.1.6 > > ** WARNING **: IO_write, closing with pending data not sent > > ** WARNING **: "GET / HTTP/1.1\x0D > > I read from a thread to place "nameserver=dns ip" in /etc/resolv.conf but nothing changed. I took a look at dns.c but I can't figure out where it's getting the value of "nameserver" from or whether it's really using that module. I think it's resolving fine, so it's probabely not a DNS issue. Can you install e.g. wget and try wget http://192.168.1.6:88 Cheers, Johannes

Oct. 14, 2010

Pending tasks

by jcid＠dillo.org

On Thu, Oct 14, 2010 at 09:49:37AM +0200, Johannes Hofmann wrote: > On Wed, Oct 13, 2010 at 03:13:16PM -0300, Jorge Arellano Cid wrote: > > On Tue, Oct 12, 2010 at 09:54:13PM +0200, Johannes Hofmann wrote: > > *snip* > > > > > > > Oh, "The collapsing border model" in the spec looks tricky :-) > > > > Given the too many overlapping directives in the model, it was > > destined to be complex. > > > > Personally I believe the collapsing model and its baroque > > combinations are seldom used in the Web. Most sites are > > structured around floating DIVs these days, and even the last > > SPEC more or less recognizes the problem: > > > > <cite> > > Automatic table layout algorithm > > > > The input to the suggested (non-normative) automatic layout > > algorithm for tables is restricted to (1) the containing block > > width and (2) the content and properties of the table and its > > children. This restriction may be lifted. > > </cite> > > > > Nevertheless, digging into the SPEC makes clear that if the > > collapsing border model is to be partly implemented (the simple > > cases at least), there's a need to move rendering from the cell > > widget into the table in Dw. > > > > > > > > The only way I've found is to set a hard value in postprocessAttrs(), > > > > but not yet a way to do it from Html_tag_open_table(). > > > > > > > > As you're working on the API, please give me some hints on how > > > > it works. > > > > > > The basic idea is that the stuff in css.cc is doing pure CSS > > > and does not care about the actual implementation or rendering in > > > dw/*. StyleEngine then translates this to dw::core::style::Style > > > objects (which also were designed with CSS in mind). > > > > Yes, that's the basis. > > The engine also takes care of inheritance, rules, nonCSS hints > > (i.e. old HTML visual directives) and their precedence. > > > > One specific question is where's the correct point to take into > > account that cell margin should be ignored in table cells. > > > > One way is to tweak the value (set it to 0), but then the > > "computed" value is not honoured as you point out. > > If the spec would say, that the computed value is set to 0 if > border-collapse is 'collapse' (which it doesn't say as far as I can > see), the correct place would be in postprocessAttrs(). > E.g. in http://www.w3.org/TR/CSS2/box.html#propdef-border-top-width > it is stated that > "Computed?value:??absolute length; '0' if the border style is > 'none' or 'hidden'" > That's why borderWidth is set to 0 in postprocessAttrs() if > borderStyle is 'none'. > ... and now I see, that the same thing for 'hidden' is missing. > Boh, I always thought that the difference between 'none' and > 'hidden' was exactly that 'hidden' does not affect the computed > value of border-width - seems that I was wrong. > > If the computed value should not be changed, we need to tweak the > style somewhere else where it does not interfere with inheritance > (see below). Thanks for the detailed explanation. My concern here is not to introduce cascading errors. > > > > Another is to ignore it in the draw method, but then draw() > > must know what element it is drawing, and for "collapsing" > > there's a need to know much more context. > > > > I quite agree with your view of the subject matter. > > > > > > > > > > As currently the cell border, padding and margin are drawn by > > > > the cell widget (textblock) inside a table, the general idea is > > > > to make textblock consider "collapse" mode when inside a table. > > > > > > postprocessAttrs() does not take into account in which > > > element we currently are (e.g. <table>, <td>, ...) > > > You could check whether you currently are in a certain element by > > > looking at doctree->top ()->element and do special things for > > > certain elements. > > > However looking at "The collapsing border model" I'm not sure > > > whether you can get away with leaving the dw/* code as it is and > > > just fiddling with the Style objects. > > > For example if you have > > > > > > <td>1</td><td>2</td> > > > > > > There currently is no way to get the style of the first <td> when > > > creating the style of the second <td> in StyleEngine - which you > > > would need to compute the thickness of the border between the two. > > > > Fully agreed. > > > > > Actually we can't play with the values of the Style object in > > > postprocessAttrs() as we like. > > > They must contain what the spec mentions as "computed > > > value". And as I read the spec, the computed value of e.g. > > > border-width does not depend on the value of border-collapse. > > > > I didn't know this ("computed value" requirement). Well, it > > defines better what's to be done if ever. > > > > > > > What *might* work is to take the Style object that StyleEngine gives > > > you and modify it in in case that border-collapse is set before passing > > > it to the table cell in src/table.cc:293. > > > > Do you mean as if it was a nonCssHint? > > I was afraid CSS would take precedence (i.e. if nonCssHint says > > margin is 0 and CSS says it's 20, I'd bet on the second one!). > > No, not via nonCssHints. I meant to directly modify the style before > giving it to the Textblock. Attached is a small patch to demonstrate > what I mean. > With some more work I think we could make it cover the most common > cases of the collapsing border model. I tried four or five fragile methods that didn't work, postprocessAttrs() showed something but clearly wasn't the place to change. Agreed. With the gained knowledge, and the example patch, I can work further on a workaround that works using the current in-cell rendering. > > > > At this point, if we can set margin to zero for the "separate" > > model, and half the value for "collapsing" it would be quite an > > advance (in rendering). OTOH, it must be commented as a > > workaround because it's not the correct way to implement it. An > > implementation would need major surgery. > > > > > > > > Another approach is to make dw::table render its borders and > > > > margin, and only leave padding to the cell widget. > > > > > > Yes, that's the other way to do it. You could still reuse the border > > > drawing helper routines from style.cc. > > > Nevertheless it might be pretty complex. Not sure if it is really > > > worth it... > > > > Fully agreed. > > > > Most probably a full implementation is not worth ATM, given the > > small use cases out there. A partial workaround may help though. > > Yes, I think it would be reasonable to just cover the common cases > e.g a table with a 1px grid with a single color and style. ACK. > > > - but of course I don't want to discourage you :-) > > > > you did! :-) > > > > Seriously, so far we have a better effort estimation on it, and > > we know how not to try to implement it, and what a correct > > implementation would need. > > > > Given the high cost/benefit, besides a workaround, i'd move to > > investigate 8 and 6: *postponed* -- Cheers Jorge.-

Oct. 14, 2010

Pending tasks

by Johannes.Hofmann＠gmx.de

On Wed, Oct 13, 2010 at 03:13:16PM -0300, Jorge Arellano Cid wrote: > On Tue, Oct 12, 2010 at 09:54:13PM +0200, Johannes Hofmann wrote: *snip* > > > > Oh, "The collapsing border model" in the spec looks tricky :-) > > Given the too many overlapping directives in the model, it was > destined to be complex. > > Personally I believe the collapsing model and its baroque > combinations are seldom used in the Web. Most sites are > structured around floating DIVs these days, and even the last > SPEC more or less recognizes the problem: > > <cite> > Automatic table layout algorithm > > The input to the suggested (non-normative) automatic layout > algorithm for tables is restricted to (1) the containing block > width and (2) the content and properties of the table and its > children. This restriction may be lifted. > </cite> > > Nevertheless, digging into the SPEC makes clear that if the > collapsing border model is to be partly implemented (the simple > cases at least), there's a need to move rendering from the cell > widget into the table in Dw. > > > > > The only way I've found is to set a hard value in postprocessAttrs(), > > > but not yet a way to do it from Html_tag_open_table(). > > > > > > As you're working on the API, please give me some hints on how > > > it works. > > > > The basic idea is that the stuff in css.cc is doing pure CSS > > and does not care about the actual implementation or rendering in > > dw/*. StyleEngine then translates this to dw::core::style::Style > > objects (which also were designed with CSS in mind). > > Yes, that's the basis. > The engine also takes care of inheritance, rules, nonCSS hints > (i.e. old HTML visual directives) and their precedence. > > One specific question is where's the correct point to take into > account that cell margin should be ignored in table cells. > > One way is to tweak the value (set it to 0), but then the > "computed" value is not honoured as you point out. If the spec would say, that the computed value is set to 0 if border-collapse is 'collapse' (which it doesn't say as far as I can see), the correct place would be in postprocessAttrs(). E.g. in http://www.w3.org/TR/CSS2/box.html#propdef-border-top-width it is stated that "Computed?value:??absolute length; '0' if the border style is 'none' or 'hidden'" That's why borderWidth is set to 0 in postprocessAttrs() if borderStyle is 'none'. ... and now I see, that the same thing for 'hidden' is missing. Boh, I always thought that the difference between 'none' and 'hidden' was exactly that 'hidden' does not affect the computed value of border-width - seems that I was wrong. If the computed value should not be changed, we need to tweak the style somewhere else where it does not interfere with inheritance (see below). > > Another is to ignore it in the draw method, but then draw() > must know what element it is drawing, and for "collapsing" > there's a need to know much more context. > > I quite agree with your view of the subject matter. > > > > > > > As currently the cell border, padding and margin are drawn by > > > the cell widget (textblock) inside a table, the general idea is > > > to make textblock consider "collapse" mode when inside a table. > > > > postprocessAttrs() does not take into account in which > > element we currently are (e.g. <table>, <td>, ...) > > You could check whether you currently are in a certain element by > > looking at doctree->top ()->element and do special things for > > certain elements. > > However looking at "The collapsing border model" I'm not sure > > whether you can get away with leaving the dw/* code as it is and > > just fiddling with the Style objects. > > For example if you have > > > > <td>1</td><td>2</td> > > > > There currently is no way to get the style of the first <td> when > > creating the style of the second <td> in StyleEngine - which you > > would need to compute the thickness of the border between the two. > > Fully agreed. > > > Actually we can't play with the values of the Style object in > > postprocessAttrs() as we like. > > They must contain what the spec mentions as "computed > > value". And as I read the spec, the computed value of e.g. > > border-width does not depend on the value of border-collapse. > > I didn't know this ("computed value" requirement). Well, it > defines better what's to be done if ever. > > > > What *might* work is to take the Style object that StyleEngine gives > > you and modify it in in case that border-collapse is set before passing > > it to the table cell in src/table.cc:293. > > Do you mean as if it was a nonCssHint? > I was afraid CSS would take precedence (i.e. if nonCssHint says > margin is 0 and CSS says it's 20, I'd bet on the second one!). No, not via nonCssHints. I meant to directly modify the style before giving it to the Textblock. Attached is a small patch to demonstrate what I mean. With some more work I think we could make it cover the most common cases of the collapsing border model. > > At this point, if we can set margin to zero for the "separate" > model, and half the value for "collapsing" it would be quite an > advance (in rendering). OTOH, it must be commented as a > workaround because it's not the correct way to implement it. An > implementation would need major surgery. > > > > > Another approach is to make dw::table render its borders and > > > margin, and only leave padding to the cell widget. > > > > Yes, that's the other way to do it. You could still reuse the border > > drawing helper routines from style.cc. > > Nevertheless it might be pretty complex. Not sure if it is really > > worth it... > > Fully agreed. > > Most probably a full implementation is not worth ATM, given the > small use cases out there. A partial workaround may help though. Yes, I think it would be reasonable to just cover the common cases e.g a table with a 1px grid with a single color and style. > > > > - but of course I don't want to discourage you :-) > > you did! :-) > > Seriously, so far we have a better effort estimation on it, and > we know how not to try to implement it, and what a correct > implementation would need. > > Given the high cost/benefit, besides a workaround, i'd move to > investigate 8 and 6: > > 8 support more border-style options (dotted, dashed ...) > Once implemented, this code can be reused/moved if > necessary. > > 6 support more vertical-align options > I hope vertical-align in the textblock can help with > vertical align inside the table. If rows need to > coordinate it will be complex. This feature is much more > visible than border-collapse. This needs coordination > among us, and corvid has already advanced working on it. Ok. Cheers, Johannes

Oct. 14, 2010

Re: Dillo config in LTIB

by Johannes.Hofmann＠gmx.de

On Thu, Oct 14, 2010 at 12:00:47AM +0800, vic wrote: > Hi Jorge, > > Thanks for the prompt reply. I'm using ltib Linux kernel 2.6.34 on an Embedded Artists LPC3250 development board, no firewall. The board is connected to a gateway router. > > Does "ping www.dillo.org" resolve? > It does not, it responds with "unreachable destination". However, a ping to a host in the local LAN is fine and a link to a host in the local LAN has this response... > > > Nav_open_url: new url='http://192.168.1.6:88' > > Dns_server [0]: 192.168.1.6 is 192.168.1.6 > > Connecting to 192.168.1.6 > > ** WARNING **: IO_write, closing with pending data not sent > > ** WARNING **: "GET / HTTP/1.1\x0D > > I read from a thread to place "nameserver=dns ip" in /etc/resolv.conf but nothing changed. I took a look at dns.c but I can't figure out where it's getting the value of "nameserver" from or whether it's really using that module. I think it's resolving fine, so it's probabely not a DNS issue. Can you install e.g. wget and try wget http://192.168.1.6:88 Cheers, Johannes

Oct. 14, 2010