- Dillo-dev - lists.mailman3.com

patch: text-indent

by Johannes.Hofmann＠gmx.de

On Tue, Nov 09, 2010 at 09:40:19PM +0000, corvid wrote: > Johannes wrote: > > I just noticed one thing that might complicate stuff a bit. Consider > > the following page: > > > > <div style="text-indent: 3em; border: 1px solid"> > > <div style="text-indent: 3em; border: 1px solid"> > > foo > > </div> > > bar > > </div> > > > > It seems that the inner <div> should not be indented, just text. The > > spec says: "More precisely, it specifies the indentation of the > > first box that flows into the block's first line box" > > > > I'd interpet it in dillo terms as to do the indent only if the first > > word is not a textblock widget. > > As in the attached? Yes, but also for Tables. What other widgets do we have? Bullet I guess they are inline Images are inline I think Ruler this is block level, so needs no indent ListItem do we need to check for it or will it show up as Textblock::CLASS_ID? TableCell same as for ListItem We probabely want some isBlockLevelWidget() function... > > > The question is then whether the "bar" should be indented. From the > > spec I would say yes, but firefox does not seem to do it... > > > > What do you think? > > My impression is that the inner div is a block, and the bar goes into > an anonymous block according to the spec, and the anonymous block > inherits text-indent, and would indent it, but the spec is a little > monstrous, so there may be some reason why that's not it. I would think > the intention of text-indent is only to indent the first thing... > Sounds reasonable. Cheers, Johannes

Nov. 10, 2010

News from FLTK

by Johannes.Hofmann＠gmx.de

On Wed, Nov 10, 2010 at 04:24:19PM -0300, Jorge Arellano Cid wrote: > Hi there, > > FYI: > > http://fltk.org/newsgroups.php?s9941+gfltk.development+v9960+T0 Hey cool! Seems we really need to get ready to port dillo to 1.3. Cheers, Johannes

Nov. 10, 2010

News from FLTK

by jcid＠dillo.org

Hi there, FYI: http://fltk.org/newsgroups.php?s9941+gfltk.development+v9960+T0 -- Cheers Jorge.-

Nov. 10, 2010

patch: text-indent

by corvid＠lavabit.com

Johannes wrote: > I just noticed one thing that might complicate stuff a bit. Consider > the following page: > > <div style="text-indent: 3em; border: 1px solid"> > <div style="text-indent: 3em; border: 1px solid"> > foo > </div> > bar > </div> > > It seems that the inner <div> should not be indented, just text. The > spec says: "More precisely, it specifies the indentation of the > first box that flows into the block's first line box" > > I'd interpet it in dillo terms as to do the indent only if the first > word is not a textblock widget. As in the attached? > The question is then whether the "bar" should be indented. From the > spec I would say yes, but firefox does not seem to do it... > > What do you think? My impression is that the inner div is a block, and the bar goes into an anonymous block according to the spec, and the anonymous block inherits text-indent, and would indent it, but the spec is a little monstrous, so there may be some reason why that's not it. I would think the intention of text-indent is only to indent the first thing...

Nov. 9, 2010

patch: text-indent

by Johannes.Hofmann＠gmx.de

On Sun, Nov 07, 2010 at 12:43:42AM +0000, corvid wrote: > Johannes wrote: > > On Sat, Nov 06, 2010 at 03:04:16PM +0000, corvid wrote: > > > "Percentage values: refer to parent element's width" > > > > > > So a Textblock wants to decide how big it is, and it asks its children > > > how big they are, and the child has, say, text-indent: 50%, and so it > > > gets to wordWrap and asks "So, ah...how big are _you_?". And the parent > > > doesn't know yet. > > > > Ah interesting.... > > > > What about using something like availWidth in Textblock::wordWrap() as an > > aproximation of the future width of the Textblock? > > Maybe this would be good enough. > > In which cases would this be way off? > > That's a good idea! > It seems to work pretty well in general... > > (You will note that this ignores negative values (LENGTH_PERCENTAGE) and > allows overflow.) Thanks for committing the patch! I just noticed one thing that might complicate stuff a bit. Consider the following page: <div style="text-indent: 3em; border: 1px solid"> <div style="text-indent: 3em; border: 1px solid"> foo </div> bar </div> It seems that the inner <div> should not be indented, just text. The spec says: "More precisely, it specifies the indentation of the first box that flows into the block's first line box" I'd interpet it in dillo terms as to do the indent only if the first word is not a textblock widget. The question is then whether the "bar" should be indented. From the spec I would say yes, but firefox does not seem to do it... What do you think? Cheers, Johannes

Nov. 9, 2010

patch: text-indent

by Johannes.Hofmann＠gmx.de

On Sun, Nov 07, 2010 at 12:43:42AM +0000, corvid wrote: > Johannes wrote: > > On Sat, Nov 06, 2010 at 03:04:16PM +0000, corvid wrote: > > > "Percentage values: refer to parent element's width" > > > > > > So a Textblock wants to decide how big it is, and it asks its children > > > how big they are, and the child has, say, text-indent: 50%, and so it > > > gets to wordWrap and asks "So, ah...how big are _you_?". And the parent > > > doesn't know yet. > > > > Ah interesting.... > > > > What about using something like availWidth in Textblock::wordWrap() as an > > aproximation of the future width of the Textblock? > > Maybe this would be good enough. > > In which cases would this be way off? > > That's a good idea! > It seems to work pretty well in general... Wow nice! >From looking at the specs I think it should use the whole width of the block including margin and padding, like this: indent = misc::roundInt(this->availWidth * core::style::perLengthVal (getStyle()->textIndent)); As far as I can tell firefox is also doing it that way in: <div style="text-indent: 50%; border: 1px solid; padding: 2cm; margin: 2cm"> foo bar </div> Cheers, Johannes PS: Feel free to commit your patch!

Nov. 7, 2010

patch: text-indent

by corvid＠lavabit.com

Johannes wrote: > On Sat, Nov 06, 2010 at 03:04:16PM +0000, corvid wrote: > > "Percentage values: refer to parent element's width" > > > > So a Textblock wants to decide how big it is, and it asks its children > > how big they are, and the child has, say, text-indent: 50%, and so it > > gets to wordWrap and asks "So, ah...how big are _you_?". And the parent > > doesn't know yet. > > Ah interesting.... > > What about using something like availWidth in Textblock::wordWrap() as an > aproximation of the future width of the Textblock? > Maybe this would be good enough. > In which cases would this be way off? That's a good idea! It seems to work pretty well in general... (You will note that this ignores negative values (LENGTH_PERCENTAGE) and allows overflow.)

Nov. 7, 2010

vertical gaps

by jcid＠dillo.org

On Tue, Nov 02, 2010 at 08:59:05PM +0100, Johannes Hofmann wrote: > On Tue, Nov 02, 2010 at 11:02:55AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > Just noticed large vertical rendering gaps with: > > > > http://www.monotone.ca/ > > > > I'd guess it's: > > padding-bottom: 300em; > margin-bottom: -300em; > > in .box-small style. > I'm not sure what it's supposed to do, but negative margins > currently don't work. Oh, I thought it could be related with the uninitialized values Jeremy reported. > > Note1: dillo-2.1.1 doesn't have the problem > > Probabely because CSS didn't work with multiple classes > (class="box box-small" in this case) back then. Thanks for the explanation. -- Cheers Jorge.-

Nov. 3, 2010

vertical gaps

by Johannes.Hofmann＠gmx.de

On Tue, Nov 02, 2010 at 11:02:55AM -0300, Jorge Arellano Cid wrote: > Hi, > > Just noticed large vertical rendering gaps with: > > http://www.monotone.ca/ > I'd guess it's: padding-bottom: 300em; margin-bottom: -300em; in .box-small style. I'm not sure what it's supposed to do, but negative margins currently don't work. > Note1: dillo-2.1.1 doesn't have the problem Probabely because CSS didn't work with multiple classes (class="box box-small" in this case) back then. Cheers, Johannes

Nov. 2, 2010

vertical gaps

by jcid＠dillo.org

Hi, Just noticed large vertical rendering gaps with: http://www.monotone.ca/ Note1: dillo-2.1.1 doesn't have the problem Note2: I haven't investigated the problem -- Cheers Jorge.-

Nov. 2, 2010

Dillo confused by embedded NULL characters

by corvid＠lavabit.com

Jeremy wrote: > On Sat, Oct 23, 2010 at 09:19:45PM +0000, corvid wrote: > > Jeremy wrote: > > > On Sat, Oct 23, 2010 at 08:02:04PM +0000, corvid wrote: > > > > Jeremy wrote: > > > > > http://makespace.org/ has some NULL characters in its header, > > > > > which causes it to disappear in Dillo. Firefox and links have > > > > > no problems. What's the fix? > > > > > > > > It seems to be showing up fine for me. > > > > > > So it is! It's my local patches that are trying to parse quoted > > > attributes like Firefox that are doing it. > > I have yet to look at it in detail, but I think the problem is that > strcspn() assumes that there are no NULLs in its argument apart from > the terminating NULL so it may give the wrong result when there are > embedded NULLs. The current logic assumes that the return value will > be the index of one of the terminating characters or the index of the > terminating NULL. But here it might be the index of an embedded NULL > which is a case that the current code does not handle. I *suspect* > that Dillo does the right thing more by accident than design. > > > I think the SGML declaration in section 20.1 of the 4.01 spec means > > that NULLs are not legal. > > So we have a choice: do we treat embedded NULLs as undefined > behaviour? If we decide "No, Dillo must handle embedded NULLs in the > 'right' way" then we have to rewrite Html_write_raw() (and possibly > a_Html_parse_entities() and Html_get_javascript_link() too) to not use > strcspn(). Ouch! This seems to be a pretty rare case so maybe it is > not worth the effort? I personally lean toward not handling it if it's illegal in particular because it's so rarely encountered that I imagine we'll forget about it at some point and accidentally make it stop working. PS Speaking of embedded NULLs, we still need to make HTTPS queries with embedded NULLs work properly at some point. (Submit a form with a file input.) a_Dpip_build_cmd() is not built to handle that case.

Oct. 26, 2010

Https remote certificate cannot be verified

by corvid＠lavabit.com

Dennis wrote: > The "The remote certificate cannot be verified (code 20)" dialog popup > window, that presumably pops up when accessing an unverifiable https > site, often pops up many times while loading a page -- probably a > separate instance for each image? Can it not pop up only once? (per > unverifiable https domain?) I think everyone wants that, and we just need someone to put in the work. > (And perhaps the current window title "Choice5" could be a bit more > informative? And maybe there should be an option to save such > certificates to avoid future warnings?) IIRC, adding an option to save certificates would be easy. I was sort of thinking about it once, but my concern was that not too many users would quite understand that they were now trusting something in perpetuity that they shouldn't necessarily. (Maybe making sure that the warning is alarming enough would suffice, though.)

Oct. 26, 2010

Dillo confused by embedded NULL characters

by onepoint＠starurchin.org

On Sat, Oct 23, 2010 at 09:19:45PM +0000, corvid wrote: > Jeremy wrote: > > On Sat, Oct 23, 2010 at 08:02:04PM +0000, corvid wrote: > > > Jeremy wrote: > > > > http://makespace.org/ has some NULL characters in its header, > > > > which causes it to disappear in Dillo. Firefox and links have > > > > no problems. What's the fix? > > > > > > It seems to be showing up fine for me. > > > > So it is! It's my local patches that are trying to parse quoted > > attributes like Firefox that are doing it. I have yet to look at it in detail, but I think the problem is that strcspn() assumes that there are no NULLs in its argument apart from the terminating NULL so it may give the wrong result when there are embedded NULLs. The current logic assumes that the return value will be the index of one of the terminating characters or the index of the terminating NULL. But here it might be the index of an embedded NULL which is a case that the current code does not handle. I *suspect* that Dillo does the right thing more by accident than design. > I think the SGML declaration in section 20.1 of the 4.01 spec means > that NULLs are not legal. So we have a choice: do we treat embedded NULLs as undefined behaviour? If we decide "No, Dillo must handle embedded NULLs in the 'right' way" then we have to rewrite Html_write_raw() (and possibly a_Html_parse_entities() and Html_get_javascript_link() too) to not use strcspn(). Ouch! This seems to be a pretty rare case so maybe it is not worth the effort? Regards, Jeremy Henty

Oct. 26, 2010

Https remote certificate cannot be verified

by dennisn＠dennisn.dyndns.org

The "The remote certificate cannot be verified (code 20)" dialog popup window, that presumably pops up when accessing an unverifiable https site, often pops up many times while loading a page -- probably a separate instance for each image? Can it not pop up only once? (per unverifiable https domain?) (And perhaps the current window title "Choice5" could be a bit more informative? And maybe there should be an option to save such certificates to avoid future warnings?)

Oct. 24, 2010

Dillo confused by embedded NULL characters

by corvid＠lavabit.com

Jeremy wrote: > On Sat, Oct 23, 2010 at 08:02:04PM +0000, corvid wrote: > > Jeremy wrote: > > > http://makespace.org/ has some NULL characters in its header, which > > > causes it to disappear in Dillo. Firefox and links have no problems. > > > What's the fix? > > > > It seems to be showing up fine for me. > > So it is! It's my local patches that are trying to parse quoted > attributes like Firefox that are doing it. Very strange! However, if > you go to http://makespace.org/ and then view the page source, the > result is truncated, even in vanilla Dillo. I think the SGML declaration in section 20.1 of the 4.01 spec means that NULLs are not legal.

Oct. 23, 2010

Dillo confused by embedded NULL characters

by onepoint＠starurchin.org

On Sat, Oct 23, 2010 at 08:02:04PM +0000, corvid wrote: > Jeremy wrote: > > http://makespace.org/ has some NULL characters in its header, which > > causes it to disappear in Dillo. Firefox and links have no problems. > > What's the fix? > > It seems to be showing up fine for me. So it is! It's my local patches that are trying to parse quoted attributes like Firefox that are doing it. Very strange! However, if you go to http://makespace.org/ and then view the page source, the result is truncated, even in vanilla Dillo. Regards, Jeremy Henty

Oct. 23, 2010

Dillo confused by embedded NULL characters

by corvid＠lavabit.com

Jeremy wrote: > http://makespace.org/ has some NULL characters in its header, which > causes it to disappear in Dillo. Firefox and links have no problems. > What's the fix? It seems to be showing up fine for me.

Oct. 23, 2010

Dillo confused by embedded NULL characters

by onepoint＠starurchin.org

http://makespace.org/ has some NULL characters in its header, which causes it to disappear in Dillo. Firefox and links have no problems. What's the fix? Regards, Jeremy Henty

Oct. 23, 2010

major commit upcoming

by jcid＠dillo.org

On Thu, Oct 21, 2010 at 09:47:46PM +0200, Johannes Hofmann wrote: > On Thu, Oct 21, 2010 at 08:48:19AM -0300, Jorge Arellano Cid wrote: > > On Wed, Oct 20, 2010 at 10:05:28PM +0200, Johannes Hofmann wrote: > > > On Wed, Oct 20, 2010 at 12:39:37PM -0300, Jorge Arellano Cid wrote: > > > > On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > just a headsup, that I plan to commit some changes for the CSS on > > > > > <HTML> element issue that involve quite a few files. > > > > > Basically it is a minor API change for StyleEngine, but as > > > > > StyleEngine is called from quite a few places, the patch is rather > > > > > big. > > > > > Please let me know in case this is inconvenient atm. > > > > > > > > On my part, go ahead. > > > > I'm still working on the collapsing border code. > > > > > > Ok then - here you go.... > > > > > > Basically the changes are to fix the problem that CSS for the <HTML> > > > element was not evaluated (reported by Jeremy). > > > But the changes in StyleEngine will also help to implement dynamic > > > style changes in the future (as needed for :visited :hover :focus > > > etc). > > > > > > As always please report any regressions... > > > > It looks like it will help me! (inherit nonCSS stuff) > > > > --- > > > > BTW, I had a hard time with border collapsing, because after > > adapting dillo to render my test cases as Firefox, other tests > > showed big differences. It was after digging into cell_props, > > resetValues, {pre, post}processAttrs, parser, etc... that I found > > the problem: dillo is not discarding CSS with syntax errors: > > > > http://www.dillo.org/test/discard-syntax-errors.html > > > > Note1: I tried pushing to hg css_compat, but it didn't work. My > > local repo behaved as the push was successful but no changes were > > made in the remote one (setting hofmann as trusted in my local > > hgrc didn't help either). > > > > Note2: index.html has 644 permissions > > Can you please retry - I hope it's fixed now. I can pull and push to the hg repo, but the web page is not updated. There's still this message: <cite> remote: Not trusting file /sfhome/groups/dillo/htdocs/css_compat/.hg/hgrc from untrusted user hofmann, group dillo remote: Not trusting file /auriga/sfhome/groups/dillo/htdocs/css_compat/.hg/hgrc from untrusted user hofmann, group dillo </cite> I have: [paths] default = ssh://dillo.org//sfhome/groups/dillo/htdocs/css_compat [trusted] users = hofmann as local .hg/hgrc -- Cheers Jorge.-

Oct. 22, 2010

major commit upcoming

by Johannes.Hofmann＠gmx.de

On Thu, Oct 21, 2010 at 02:49:00PM +0200, Johannes Hofmann wrote: > -----Urspr?ngliche Nachricht----- > Von: Jorge Arellano Cid <jcid(a)dillo.org> > Gesendet: Do 21.10.2010 13:49 > An: dillo-dev(a)dillo.org; > Betreff: Re: [Dillo-dev] major commit upcoming > > > On Wed, Oct 20, 2010 at 10:05:28PM +0200, Johannes Hofmann wrote: > > > On Wed, Oct 20, 2010 at 12:39:37PM -0300, Jorge Arellano Cid wrote: > > > > On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > just a headsup, that I plan to commit some changes for the CSS on > > > > > <HTML> element issue that involve quite a few files. > > > > > Basically it is a minor API change for StyleEngine, but as > > > > > StyleEngine is called from quite a few places, the patch is rather > > > > > big. > > > > > Please let me know in case this is inconvenient atm. > > > > > > > > On my part, go ahead. > > > > I'm still working on the collapsing border code. > > > > > > Ok then - here you go.... > > > > > > Basically the changes are to fix the problem that CSS for the <HTML> > > > element was not evaluated (reported by Jeremy). > > > But the changes in StyleEngine will also help to implement dynamic > > > style changes in the future (as needed for :visited :hover :focus > > > etc). > > > > > > As always please report any regressions... > > > > It looks like it will help me! (inherit nonCSS stuff) > > Right, I moved this functionality from html.cc / table.cc into styleengine.cc. > > > > > --- > > > > BTW, I had a hard time with border collapsing, because after > > adapting dillo to render my test cases as Firefox, other tests > > showed big differences. It was after digging into cell_props, > > resetValues, {pre, post}processAttrs, parser, etc... that I found > > the problem: dillo is not discarding CSS with syntax errors: > > > > http://www.dillo.org/test/discard-syntax-errors.html > > > > Generally dillo should discard CSS with errors, but there are some cases > where it doesn't. I will look at your test case when I'm at home. Ah now I see what you mean... Declaration dropping does not work with shortcuts like margin:, border: and so on. It should work for single properties like border-bottom-style: and so on. I will look into it. Cheers, Johannes

Oct. 21, 2010

major commit upcoming

by Johannes.Hofmann＠gmx.de

On Thu, Oct 21, 2010 at 08:48:19AM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 20, 2010 at 10:05:28PM +0200, Johannes Hofmann wrote: > > On Wed, Oct 20, 2010 at 12:39:37PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > just a headsup, that I plan to commit some changes for the CSS on > > > > <HTML> element issue that involve quite a few files. > > > > Basically it is a minor API change for StyleEngine, but as > > > > StyleEngine is called from quite a few places, the patch is rather > > > > big. > > > > Please let me know in case this is inconvenient atm. > > > > > > On my part, go ahead. > > > I'm still working on the collapsing border code. > > > > Ok then - here you go.... > > > > Basically the changes are to fix the problem that CSS for the <HTML> > > element was not evaluated (reported by Jeremy). > > But the changes in StyleEngine will also help to implement dynamic > > style changes in the future (as needed for :visited :hover :focus > > etc). > > > > As always please report any regressions... > > It looks like it will help me! (inherit nonCSS stuff) > > --- > > BTW, I had a hard time with border collapsing, because after > adapting dillo to render my test cases as Firefox, other tests > showed big differences. It was after digging into cell_props, > resetValues, {pre, post}processAttrs, parser, etc... that I found > the problem: dillo is not discarding CSS with syntax errors: > > http://www.dillo.org/test/discard-syntax-errors.html > > Note1: I tried pushing to hg css_compat, but it didn't work. My > local repo behaved as the push was successful but no changes were > made in the remote one (setting hofmann as trusted in my local > hgrc didn't help either). > > Note2: index.html has 644 permissions Can you please retry - I hope it's fixed now. Cheers, Johannes

Oct. 21, 2010

major commit upcoming

by Johannes.Hofmann＠gmx.de

On Thu, Oct 21, 2010 at 11:01:42AM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 21, 2010 at 02:49:00PM +0200, Johannes Hofmann wrote: > > > > [...] > > > > > > Note4: Considering the extensive use of "html->styleEngine", > > > I'd use something similar to HT2TB, S_TOP macros. This is: > > > SE(html) <=> html->styleEngine > > > SE(html)->setNonCssHint <=> html->styleEngine->setNonCssHint > > > I can quickly make a patch if you agree. > > > > > > > Yes, sure. Maybe an inlined method in DilloHtml like > > > > DilloHtml::setNonCssHint(...) { > > styleEngine->setNonCssHint(...); > > } > > > > would result in even shorter lines: > > > > html->setNonCssHint(...) > > DISCLAIMER: I'm by no mean a C++ guru! > > gcc says: > > html_common.hh:213: error: invalid use of incomplete type 'struct > StyleEngine' Bleh, that's what you get if you play tricks and make circular depending includes (as I did with styleengine.hh). > > AFAIU, the original setNonCssHint is also inlined, and it uses > the private "struct Node", which upon expansion is not defined. That shouldn't be a problem, inlining is not done by the preprocessor. > > I'd go with "SE(html)" ;-) Let me first try whether I can disentangle the includes. If that doesn't work we can use the macro. Cheers, Johannes

Oct. 21, 2010

major commit upcoming

by jcid＠dillo.org

On Thu, Oct 21, 2010 at 02:49:00PM +0200, Johannes Hofmann wrote: > > [...] > > > > Note4: Considering the extensive use of "html->styleEngine", > > I'd use something similar to HT2TB, S_TOP macros. This is: > > SE(html) <=> html->styleEngine > > SE(html)->setNonCssHint <=> html->styleEngine->setNonCssHint > > I can quickly make a patch if you agree. > > > > Yes, sure. Maybe an inlined method in DilloHtml like > > DilloHtml::setNonCssHint(...) { > styleEngine->setNonCssHint(...); > } > > would result in even shorter lines: > > html->setNonCssHint(...) DISCLAIMER: I'm by no mean a C++ guru! gcc says: html_common.hh:213: error: invalid use of incomplete type 'struct StyleEngine' AFAIU, the original setNonCssHint is also inlined, and it uses the private "struct Node", which upon expansion is not defined. I'd go with "SE(html)" ;-) -- Cheers Jorge.-

Oct. 21, 2010

AW: [Dillo-dev] major commit upcoming

by johannes.hofmann＠gmx.de

-----Urspr?ngliche Nachricht----- Von: Jorge Arellano Cid <jcid(a)dillo.org> Gesendet: Do 21.10.2010 13:49 An: dillo-dev(a)dillo.org; Betreff: Re: [Dillo-dev] major commit upcoming > On Wed, Oct 20, 2010 at 10:05:28PM +0200, Johannes Hofmann wrote: > > On Wed, Oct 20, 2010 at 12:39:37PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > just a headsup, that I plan to commit some changes for the CSS on > > > > <HTML> element issue that involve quite a few files. > > > > Basically it is a minor API change for StyleEngine, but as > > > > StyleEngine is called from quite a few places, the patch is rather > > > > big. > > > > Please let me know in case this is inconvenient atm. > > > > > > On my part, go ahead. > > > I'm still working on the collapsing border code. > > > > Ok then - here you go.... > > > > Basically the changes are to fix the problem that CSS for the <HTML> > > element was not evaluated (reported by Jeremy). > > But the changes in StyleEngine will also help to implement dynamic > > style changes in the future (as needed for :visited :hover :focus > > etc). > > > > As always please report any regressions... > > It looks like it will help me! (inherit nonCSS stuff) Right, I moved this functionality from html.cc / table.cc into styleengine.cc. > > --- > > BTW, I had a hard time with border collapsing, because after > adapting dillo to render my test cases as Firefox, other tests > showed big differences. It was after digging into cell_props, > resetValues, {pre, post}processAttrs, parser, etc... that I found > the problem: dillo is not discarding CSS with syntax errors: > > http://www.dillo.org/test/discard-syntax-errors.html > Generally dillo should discard CSS with errors, but there are some cases where it doesn't. I will look at your test case when I'm at home. > Note1: I tried pushing to hg css_compat, but it didn't work. My > local repo behaved as the push was successful but no changes were > made in the remote one (setting hofmann as trusted in my local > hgrc didn't help either). > > Note2: index.html has 644 permissions Ok, I will check that. > > Note3: I'll work a bit more on the collapse patches and get > back to you before committing. > > Note4: Considering the extensive use of "html->styleEngine", > I'd use something similar to HT2TB, S_TOP macros. This is: > SE(html) <=> html->styleEngine > SE(html)->setNonCssHint <=> html->styleEngine->setNonCssHint > I can quickly make a patch if you agree. > Yes, sure. Maybe an inlined method in DilloHtml like DilloHtml::setNonCssHint(...) { styleEngine->setNonCssHint(...); } would result in even shorter lines: html->setNonCssHint(...) Cheers, Johannes

Oct. 21, 2010

major commit upcoming

by jcid＠dillo.org

On Wed, Oct 20, 2010 at 10:05:28PM +0200, Johannes Hofmann wrote: > On Wed, Oct 20, 2010 at 12:39:37PM -0300, Jorge Arellano Cid wrote: > > On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > just a headsup, that I plan to commit some changes for the CSS on > > > <HTML> element issue that involve quite a few files. > > > Basically it is a minor API change for StyleEngine, but as > > > StyleEngine is called from quite a few places, the patch is rather > > > big. > > > Please let me know in case this is inconvenient atm. > > > > On my part, go ahead. > > I'm still working on the collapsing border code. > > Ok then - here you go.... > > Basically the changes are to fix the problem that CSS for the <HTML> > element was not evaluated (reported by Jeremy). > But the changes in StyleEngine will also help to implement dynamic > style changes in the future (as needed for :visited :hover :focus > etc). > > As always please report any regressions... It looks like it will help me! (inherit nonCSS stuff) --- BTW, I had a hard time with border collapsing, because after adapting dillo to render my test cases as Firefox, other tests showed big differences. It was after digging into cell_props, resetValues, {pre, post}processAttrs, parser, etc... that I found the problem: dillo is not discarding CSS with syntax errors: http://www.dillo.org/test/discard-syntax-errors.html Note1: I tried pushing to hg css_compat, but it didn't work. My local repo behaved as the push was successful but no changes were made in the remote one (setting hofmann as trusted in my local hgrc didn't help either). Note2: index.html has 644 permissions Note3: I'll work a bit more on the collapse patches and get back to you before committing. Note4: Considering the extensive use of "html->styleEngine", I'd use something similar to HT2TB, S_TOP macros. This is: SE(html) <=> html->styleEngine SE(html)->setNonCssHint <=> html->styleEngine->setNonCssHint I can quickly make a patch if you agree. -- Cheers Jorge.-

Oct. 21, 2010

major commit upcoming

by Johannes.Hofmann＠gmx.de

On Wed, Oct 20, 2010 at 12:39:37PM -0300, Jorge Arellano Cid wrote: > On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > > Hi, > > > > just a headsup, that I plan to commit some changes for the CSS on > > <HTML> element issue that involve quite a few files. > > Basically it is a minor API change for StyleEngine, but as > > StyleEngine is called from quite a few places, the patch is rather > > big. > > Please let me know in case this is inconvenient atm. > > On my part, go ahead. > I'm still working on the collapsing border code. Ok then - here you go.... Basically the changes are to fix the problem that CSS for the <HTML> element was not evaluated (reported by Jeremy). But the changes in StyleEngine will also help to implement dynamic style changes in the future (as needed for :visited :hover :focus etc). As always please report any regressions... Cheers, Johannes

Oct. 20, 2010

major commit upcoming

by jcid＠dillo.org

On Tue, Oct 19, 2010 at 09:11:41PM +0200, Johannes Hofmann wrote: > Hi, > > just a headsup, that I plan to commit some changes for the CSS on > <HTML> element issue that involve quite a few files. > Basically it is a minor API change for StyleEngine, but as > StyleEngine is called from quite a few places, the patch is rather > big. > Please let me know in case this is inconvenient atm. On my part, go ahead. I'm still working on the collapsing border code. -- Cheers Jorge.-

Oct. 20, 2010

major commit upcoming

by Johannes.Hofmann＠gmx.de

Hi, just a headsup, that I plan to commit some changes for the CSS on <HTML> element issue that involve quite a few files. Basically it is a minor API change for StyleEngine, but as StyleEngine is called from quite a few places, the patch is rather big. Please let me know in case this is inconvenient atm. Cheers, Johannes

Oct. 19, 2010

Offtopic: big miners rescue

by vic＠smartqsys.com

Indeed! Hi there, A few days have passed since the big miners rescue finished as a complete success. Locally, we chileans, followed the events since the beginning, and specially moved since a small paper note emerged to earth level saying they were all alive. These days I've realized the press coverage was humongous. It's said that a thousand million saw a part of the rescue around the world. It's one of those few moments a lifetime gifts our souls with, where events, so powerful an real as these, make us look inwards and see the real value of things, instead of the things we usually entertain ourselves in. -- Cheers Jorge.- ------------------------------ _______________________________________________ Dillo-dev mailing list Dillo-dev(a)dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev End of Dillo-dev Digest, Vol 62, Issue 14 *****************************************

Oct. 19, 2010

Offtopic: big miners rescue

by jcid＠dillo.org

Hi there, A few days have passed since the big miners rescue finished as a complete success. Locally, we chileans, followed the events since the beginning, and specially moved since a small paper note emerged to earth level saying they were all alive. These days I've realized the press coverage was humongous. It's said that a thousand million saw a part of the rescue around the world. It's one of those few moments a lifetime gifts our souls with, where events, so powerful an real as these, make us look inwards and see the real value of things, instead of the things we usually entertain ourselves in. -- Cheers Jorge.-

Oct. 17, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

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? Ha! The (incorrect) use of line-height:auto seems to be more common than I thought. Just found it again on dev.mysql.com... Cheers, Johannes

Oct. 17, 2010

Dillo config in LTIB

by vic＠smartqsys.com

Hi, For now I can live without WLAN access. Now that I have Dillo up, I click on a button on a page and have this form handler issue. Is this a configuration issue or a feature not supported by Dillo? Thanks, Vic [root@nxp /]# Nav_open_url: new url='http://192.168.1.5:88/LoginForm?Ctr_No=1' Dns_server [0]: 192.168.1.5 is 192.168.1.5 Connecting to 192.168.1.5 Unable to convert from character encoding: 'ISO-8859-1' >>> a_Nav_repush <<<< Nav_open_url: new url='http://192.168.1.5:88/LoginForm?Ctr_No=1' a_Nav_expect_done: repush! Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/all.css Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/Accounts.Css NumPendingStyleSheets=1 NumPendingStyleSheets=2 HTTP warning: unhandled MIME type: "image/png" >>> a_Nav_repush <<<< Nav_open_url: new url='http://192.168.1.5:88/LoginForm?Ctr_No=1' a_Nav_expect_done: repush! Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/all.css Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/Accounts.Css bad font: variable HTTP warning: unhandled MIME type: "image/png" DilloHtmlForm::eventHandler DilloHtmlForm::eventHandler ----- Original Message ----- From: "Vic" <vic(a)smartqsys.com> To: <dillo-dev(a)dillo.org> Sent: Wednesday, October 13, 2010 5:00 PM Subject: Re: [Dillo-dev] Dillo config in LTIB > Hi Jorge, > > The EA lpc3250 is connected to a gateway router with IP 192.168.1.4. > pinging > local LAN hosts is fine but WLAN host are unreachable. I tried editing > etc/resolv.conf with nameserver 192.168.1.4 , but this time after dillo is > up instead and not before launching dillo. It is able to > resolve but this is what I get... > > [root@nxp /]# ping www.dillo.org -c 4 > PING www.dillo.org (134.102.206.165): 56 data bytes > ping: sendto: Network is unreachable > [root@nxp /]# > > Nav_open_url: new url='http://www.dillo.org' > Dns_server [0]: www.dillo.org is 134.102.206.165 > Connecting to 134.102.206.165 > Http_connect_socket ERROR: Network is unreachable > > Thanks, > Vic > > >> >> Message: 1 >> Date: Tue, 12 Oct 2010 09:20:50 -0300 >> From: Jorge Arellano Cid <jcid(a)dillo.org> >> Subject: Re: [Dillo-dev] Dillo config in LTIB >> To: dillo-dev(a)dillo.org >> Message-ID: <20101012122050.GB2862(a)dillo.org> >> Content-Type: text/plain; charset=us-ascii >> >> Hi, >> >> On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: >>> Hi, >>> >>> I installed Dillo in LTIB and while the splash page went up, >>> clicking links reported a dns error. I checked out dillorc and >>> saw no setting related to dns. >> >> Dillo uses getaddrinfo(). It depends on the OS. >> >>> Trying a link to localhost also >>> gave I/O errors. >> >> This is strange... >> >>> My trace as follows: >>> >>> Nav_open_url: new url='http://www.dillo.org/' >>> DNS error: TRY_AGAIN >>> Dns_server [0]: www.dillo.org is (nil) >> >> Does "ping www.dillo.org" resolve? >> >> >>> Using localhost: >>> >>> Nav_open_url: new url='http://localhost:88' >>> Dns_server [0]: localhost is 127.0.0.1 >>> Connecting to 127.0.0.1 >>> ** WARNING **: IO_write, closing with pending data not sent >>> ** WARNING **: "GET / HTTP/1.1\x0D >>> Connection: close\x0D >>> Accept-Charset: utf-8,*;q=0.8\x0D >>> Accept-Encoding: gzip\x0D >>> Host: localhost:88\x0D >>> Referer: http://localhost:88/\x0D >>> User-Agent: Dillo/2.1\x0D >>> \x0D >>> " >>> >>> Thanks for any help. >> >> It looks like something external closed the connection. >> Firewall? >> >> -- >> Cheers >> Jorge.- >> >> >> >

Oct. 16, 2010

Polygon::isPointWithin()

by corvid＠lavabit.com

Johannes wrote: > I have commited a fix - please test. Thanks! > PS: To me it seems that the explicit closing of polygon paths in > html.cc:2348 is unnecessary and complicating things. > Can we remove it? Removed.

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

On Fri, Oct 15, 2010 at 07:31:13PM +0100, Jeremy Henty wrote: > 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). Good! > > > 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? Yes. I don't think it is very critical, but it should be fixed at some point. Cheers, Johannes

Oct. 15, 2010

Polygon::isPointWithin()

by Johannes.Hofmann＠gmx.de

On Fri, Oct 15, 2010 at 05:23:13PM +0000, corvid wrote: > 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... That code is pretty cool - I would be proud of it if had written it ;-) The issue was just a that a product could overflow a 32bit integer. I have commited a fix - please test. Cheers, Johannes PS: To me it seems that the explicit closing of polygon paths in html.cc:2348 is unnecessary and complicating things. Can we remove it?

Oct. 15, 2010

[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

Dillo config in LTIB

by vic＠smartqsys.com

Hi Jorge, The EA lpc3250 is connected to a gateway router with IP 192.168.1.4. pinging local LAN hosts is fine but WLAN host are unreachable. I tried editing etc/resolv.conf with nameserver 192.168.1.4 , but this time after dillo is up instead and not before launching dillo. It is able to resolve but this is what I get... [root@nxp /]# ping www.dillo.org -c 4 PING www.dillo.org (134.102.206.165): 56 data bytes ping: sendto: Network is unreachable [root@nxp /]# Nav_open_url: new url='http://www.dillo.org' Dns_server [0]: www.dillo.org is 134.102.206.165 Connecting to 134.102.206.165 Http_connect_socket ERROR: Network is unreachable Thanks, Vic > > Message: 1 > Date: Tue, 12 Oct 2010 09:20:50 -0300 > From: Jorge Arellano Cid <jcid(a)dillo.org> > Subject: Re: [Dillo-dev] Dillo config in LTIB > To: dillo-dev(a)dillo.org > Message-ID: <20101012122050.GB2862(a)dillo.org> > Content-Type: text/plain; charset=us-ascii > > Hi, > > On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: >> Hi, >> >> I installed Dillo in LTIB and while the splash page went up, >> clicking links reported a dns error. I checked out dillorc and >> saw no setting related to dns. > > Dillo uses getaddrinfo(). It depends on the OS. > >> Trying a link to localhost also >> gave I/O errors. > > This is strange... > >> My trace as follows: >> >> Nav_open_url: new url='http://www.dillo.org/' >> DNS error: TRY_AGAIN >> Dns_server [0]: www.dillo.org is (nil) > > Does "ping www.dillo.org" resolve? > > >> Using localhost: >> >> Nav_open_url: new url='http://localhost:88' >> Dns_server [0]: localhost is 127.0.0.1 >> Connecting to 127.0.0.1 >> ** WARNING **: IO_write, closing with pending data not sent >> ** WARNING **: "GET / HTTP/1.1\x0D >> Connection: close\x0D >> Accept-Charset: utf-8,*;q=0.8\x0D >> Accept-Encoding: gzip\x0D >> Host: localhost:88\x0D >> Referer: http://localhost:88/\x0D >> User-Agent: Dillo/2.1\x0D >> \x0D >> " >> >> Thanks for any help. > > It looks like something external closed the connection. > Firewall? > > -- > Cheers > Jorge.- > > >

Oct. 14, 2010

Pending tasks

by jcid＠dillo.org

On Tue, Oct 12, 2010 at 09:54:13PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Tue, Oct 12, 2010 at 02:59:24PM -0300, Jorge Arellano Cid wrote: > > On Mon, Oct 11, 2010 at 11:08:11PM +0200, Johannes Hofmann wrote: > > > On Mon, Oct 11, 2010 at 01:33:17PM -0300, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > With regard to: > > > > > > > > > 1 provide a dillo css compatibility table (and keep it up to date) > > > > > 2 optimizing line-breaks - i.e. break at '-' but don't > > > > > break e.g. <b>D</b>illo (after the 'D'). > > > > > 3 support for  > > > > > 4 support for text-indent > > > > > 5 support font-variant > > > > > 6 support more vertical-align options > > > > > 7 make thickness of lines for underline and line-through > > > > > depending on the font size and weight > > > > > 8 support more border-style options (dotted, dashed ...) > > > > > 9 support border-collapse (table related) > > > > > > > > 5 and 7 are in testing phase (in the repo). > > > > AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by > > > > corvid. > > > > > > > > After the big table rendering work long ago, I'm studying the > > > > tables code again. > > > > > > > > Please notice that the doxygen dw documentation on table > > > > algorithms (the math formulas part) is not up-to-date. It's done > > > > in a different way since the big patch. > > > > > > > > My idea is to refresh my memory on this part of the code, and > > > > then to try to devise a way to implement 8 and 9. At the same > > > > time, working on this part will help for 6. > > > > > > > > Most probably we'll have to try to tackle these complex > > > > problems coordinating our effort/knowledge. I'll be in better > > > > shape to help with this after working for a while on tables. > > > > > > > > @Johannes, @corvid, please state what are your plans for work > > > > on these remaining parts (if there's one already). > > > > > > I'm still working on CSS for the <html>-element (the issue reported > > > by Jeremy). > > > As my original patch had issues with pages that have multiple <head> > > > elements, I decided to make some major changes to the > > > StyleEngine-API. > > > It looks ok now, but I need to do some more tests. > > > > I'm working on 9, and so far haven't found a convenient way to > > tweak CSS atributes for a certain element (most probably my > > fault). For instance, margin and padding are not meant as usual > > for tables (CSS2 SPEC), see the difference between FF and dillo > > here: > > > > http://www.dillo.org/test/bc1.html > > 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. 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!). 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. > - 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. -- Cheers Jorge.-

Oct. 13, 2010

Re: Dillo config in LTIB

by vic＠smartqsys.com

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. Thanks, Vic Message: 1 Date: Tue, 12 Oct 2010 09:20:50 -0300 From: Jorge Arellano Cid Subject: Re: [Dillo-dev] Dillo config in LTIB To: dillo-dev(a)dillo.org Message-ID: <20101012122050.GB2862(a)dillo.org> Content-Type: text/plain; charset=us-ascii Hi, On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: > Hi, > > I installed Dillo in LTIB and while the splash page went up, > clicking links reported a dns error. I checked out dillorc and > saw no setting related to dns. Dillo uses getaddrinfo(). It depends on the OS. > Trying a link to localhost also > gave I/O errors. This is strange... > My trace as follows: > > Nav_open_url: new url='http://www.dillo.org/' > DNS error: TRY_AGAIN > Dns_server [0]: www.dillo.org is (nil) Does "ping www.dillo.org" resolve? > Using localhost: > > Nav_open_url: new url='http://localhost:88' > Dns_server [0]: localhost is 127.0.0.1 > Connecting to 127.0.0.1 > ** WARNING **: IO_write, closing with pending data not sent > ** WARNING **: "GET / HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: localhost:88\x0D > Referer: http://localhost:88/\x0D > User-Agent: Dillo/2.1\x0D > \x0D > " > > Thanks for any help. It looks like something external closed the connection. Firewall? -- Cheers Jorge.-

Oct. 13, 2010

Pending tasks

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Tue, Oct 12, 2010 at 02:59:24PM -0300, Jorge Arellano Cid wrote: > On Mon, Oct 11, 2010 at 11:08:11PM +0200, Johannes Hofmann wrote: > > On Mon, Oct 11, 2010 at 01:33:17PM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > With regard to: > > > > > > > 1 provide a dillo css compatibility table (and keep it up to date) > > > > 2 optimizing line-breaks - i.e. break at '-' but don't > > > > break e.g. <b>D</b>illo (after the 'D'). > > > > 3 support for  > > > > 4 support for text-indent > > > > 5 support font-variant > > > > 6 support more vertical-align options > > > > 7 make thickness of lines for underline and line-through > > > > depending on the font size and weight > > > > 8 support more border-style options (dotted, dashed ...) > > > > 9 support border-collapse (table related) > > > > > > 5 and 7 are in testing phase (in the repo). > > > AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by > > > corvid. > > > > > > After the big table rendering work long ago, I'm studying the > > > tables code again. > > > > > > Please notice that the doxygen dw documentation on table > > > algorithms (the math formulas part) is not up-to-date. It's done > > > in a different way since the big patch. > > > > > > My idea is to refresh my memory on this part of the code, and > > > then to try to devise a way to implement 8 and 9. At the same > > > time, working on this part will help for 6. > > > > > > Most probably we'll have to try to tackle these complex > > > problems coordinating our effort/knowledge. I'll be in better > > > shape to help with this after working for a while on tables. > > > > > > @Johannes, @corvid, please state what are your plans for work > > > on these remaining parts (if there's one already). > > > > I'm still working on CSS for the <html>-element (the issue reported > > by Jeremy). > > As my original patch had issues with pages that have multiple <head> > > elements, I decided to make some major changes to the > > StyleEngine-API. > > It looks ok now, but I need to do some more tests. > > I'm working on 9, and so far haven't found a convenient way to > tweak CSS atributes for a certain element (most probably my > fault). For instance, margin and padding are not meant as usual > for tables (CSS2 SPEC), see the difference between FF and dillo > here: > > http://www.dillo.org/test/bc1.html Oh, "The collapsing border model" in the spec looks tricky :-) > > 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). > > 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. 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. 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. > > 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... - but of course I don't want to discourage you :-) Cheers, Johannes

Oct. 12, 2010

Pending tasks

by jcid＠dillo.org

On Mon, Oct 11, 2010 at 11:08:11PM +0200, Johannes Hofmann wrote: > On Mon, Oct 11, 2010 at 01:33:17PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > With regard to: > > > > > 1 provide a dillo css compatibility table (and keep it up to date) > > > 2 optimizing line-breaks - i.e. break at '-' but don't > > > break e.g. <b>D</b>illo (after the 'D'). > > > 3 support for  > > > 4 support for text-indent > > > 5 support font-variant > > > 6 support more vertical-align options > > > 7 make thickness of lines for underline and line-through > > > depending on the font size and weight > > > 8 support more border-style options (dotted, dashed ...) > > > 9 support border-collapse (table related) > > > > 5 and 7 are in testing phase (in the repo). > > AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by > > corvid. > > > > After the big table rendering work long ago, I'm studying the > > tables code again. > > > > Please notice that the doxygen dw documentation on table > > algorithms (the math formulas part) is not up-to-date. It's done > > in a different way since the big patch. > > > > My idea is to refresh my memory on this part of the code, and > > then to try to devise a way to implement 8 and 9. At the same > > time, working on this part will help for 6. > > > > Most probably we'll have to try to tackle these complex > > problems coordinating our effort/knowledge. I'll be in better > > shape to help with this after working for a while on tables. > > > > @Johannes, @corvid, please state what are your plans for work > > on these remaining parts (if there's one already). > > I'm still working on CSS for the <html>-element (the issue reported > by Jeremy). > As my original patch had issues with pages that have multiple <head> > elements, I decided to make some major changes to the > StyleEngine-API. > It looks ok now, but I need to do some more tests. I'm working on 9, and so far haven't found a convenient way to tweak CSS atributes for a certain element (most probably my fault). For instance, margin and padding are not meant as usual for tables (CSS2 SPEC), see the difference between FF and dillo here: http://www.dillo.org/test/bc1.html 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. 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. Another approach is to make dw::table render its borders and margin, and only leave padding to the cell widget. -- Cheers Jorge.-

Oct. 12, 2010