- Dillo-dev - lists.mailman3.com

display: inline

by tim.nieradzik＠gmx.de

Hi Johannes, thank you very much. The patch works great for <li> elements but for each <ul> there is still some unused space. See http://www.heise.de/. I added "display: list-item" to the ul-item in Dillo's stylesheet definition and in Html_tag_open_ul() I am comparing the the display-attribute with the "list-item"-value. Strangely enough it worked! I am still wondering why it does. --Tim

Dec. 6, 2009

display: inline

by Johannes.Hofmann＠gmx.de

Hi Tim, On Sat, Dec 05, 2009 at 09:10:45PM +0100, Tim Nieradzik wrote: > I am currently working on adding CSS support for "display: inline" tags. > They are commonly used for navigation menus. As these menus are nothing > more than simple unordered lists (<ul>), the items are printed one below > the other which wastes lots of space. > > The patch I came up with does only partially implement support for these > tags: The items are correctly displayed within one line but I cannot > figure out why there is so much empty space after each item. > > Perhaps somebody with a better understanding of the dw-code than me > might have a look into the issue. If I am correct, the dw/textblock.cc > is responsible for calculating the widths. Textblock::wordWrap() looks > pretty promising as there is a variable (hasListitemValue) determining > whether it is a list item and calculates values for lastLine->leftOffset > and words->getRef(0)->effSpace depending on this state. I think we need to be a bit more radical. Consider this slightly modified patch (attached). If I read the CSS 2.1 Spec correctly then the idea is that every element can be a list-item if it has display: list-item set. So <li> elements would have to be handled as any other element but get display: list-item from our user-agent style. So for the real implementation we would need to change html.cc in a way that not the current element name, but the value of the display property determines whether to show a list item, or to show nothing at all (display: none) and so on. That said, I think the modified version of your patch is a good start until we fully support the display property, as lists with display: inline seem to be pretty common. So please test this with your favorite web sites. Cheers, Johannes

Dec. 6, 2009

HTML parser bug

by jcid＠dillo.org

On Sat, Dec 05, 2009 at 08:47:56PM +0000, corvid wrote: > Tim wrote: > > There is a bug in the HTML parser: Tags within quotes are interpreted: > > > > <input type="text" name="test" value="<p>asdf</p>" /> > > > > I think it is line 3754f (src/html.cc) which evokes the unwanted > > behaviour. I'd fix this bug by introducing two variables: The first one > > states whether we're currently inside of a quote and the second one > > stores its type (single or double quote). As long as the current > > character does not equal the type, all characters in between the > > starting and ending quote will be ignored. Of course we should be also > > able to deal with escaped quotes allowing constructs similar to the > > following one: > > > > <input type="text" name="test" value="<p>\"asdf\"</p>" /> > > Strictly speaking, for attributes that are CDATA, at least, > my impression is that the element is closed if the parser encounters an > (SGML jargon!) end-tag open (ETAGO, i.e., "</") "delimiter-in-context" > (meaning, I think, that it is followed by certain characters such as > ASCII letters). > > Of course, sgml is a horrible, loony monstrosity, and we don't follow > it to the letter to begin with, so I'm not sure that I'd necessarily be > opposed to making the parser behave as you say. > (Remembers http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-January/003668.html) Good advice! ;) Although a better heuristic is welcomed, it's not easy. Beware of the sleeping dragon. You have to consider (at least): * RFC (HTML, SGML, XML) * What do other browsers do. * Heuristic worst case and average. * Unexpected input (broken HTML or XML, attacks...). * Complexity and overhead (it affects the tokenizer). * Error reporting. The above idea has been tried, but it fails when the attribute lacks its closing quote, sometimes eating lots of content when plain text follows. You can find more details in doc/HtmlParser.txt. I wish we could find a better heuristic. For instance to clean the IFRAME rendering of http://www.linuxfordevices.com/. -- Cheers Jorge.-

Dec. 5, 2009

HTML parser bug

by corvid＠lavabit.com

Tim wrote: > There is a bug in the HTML parser: Tags within quotes are interpreted: > > <input type="text" name="test" value="<p>asdf</p>" /> > > I think it is line 3754f (src/html.cc) which evokes the unwanted > behaviour. I'd fix this bug by introducing two variables: The first one > states whether we're currently inside of a quote and the second one > stores its type (single or double quote). As long as the current > character does not equal the type, all characters in between the > starting and ending quote will be ignored. Of course we should be also > able to deal with escaped quotes allowing constructs similar to the > following one: > > <input type="text" name="test" value="<p>\"asdf\"</p>" /> Strictly speaking, for attributes that are CDATA, at least, my impression is that the element is closed if the parser encounters an (SGML jargon!) end-tag open (ETAGO, i.e., "</") "delimiter-in-context" (meaning, I think, that it is followed by certain characters such as ASCII letters). Of course, sgml is a horrible, loony monstrosity, and we don't follow it to the letter to begin with, so I'm not sure that I'd necessarily be opposed to making the parser behave as you say. (Remembers http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-January/003668.html)

Dec. 5, 2009

display: inline

by tim.nieradzik＠gmx.de

Sorry, I forgot to attach the patch. :) --Tim

Dec. 5, 2009

display: inline

by tim.nieradzik＠gmx.de

I am currently working on adding CSS support for "display: inline" tags. They are commonly used for navigation menus. As these menus are nothing more than simple unordered lists (<ul>), the items are printed one below the other which wastes lots of space. The patch I came up with does only partially implement support for these tags: The items are correctly displayed within one line but I cannot figure out why there is so much empty space after each item. Perhaps somebody with a better understanding of the dw-code than me might have a look into the issue. If I am correct, the dw/textblock.cc is responsible for calculating the widths. Textblock::wordWrap() looks pretty promising as there is a variable (hasListitemValue) determining whether it is a list item and calculates values for lastLine->leftOffset and words->getRef(0)->effSpace depending on this state. --Tim

Dec. 5, 2009

dpid not starting automatically

by corvid＠lavabit.com

Tim wrote: > I am starting Dillo right away from the source code. Thus, it is not > installed in any of the directories listed in $PATH. Dillo gives me the > following errors as it does not seem to be able to find the dpid binary: > > Dpi_check_dpid_ids: Connection refused > Dpi_start_dpid (child): No such file or directory > Dpi_start_dpid: can't start dpid > > What do you think of adding some code that tries to execute the local > dpid binary first (dpid/dpid) before looking into the system paths? I would prefer to limit how clever dillo tries to be. I wouldn't want to get mixed up where it happens to run the local one which I didn't install yet. (Actually, in my case, I don't install them, either, and I symlink into the tree.)

Dec. 5, 2009

HTML parser bug

by tim.nieradzik＠gmx.de

There is a bug in the HTML parser: Tags within quotes are interpreted: <input type="text" name="test" value="<p>asdf</p>" /> I think it is line 3754f (src/html.cc) which evokes the unwanted behaviour. I'd fix this bug by introducing two variables: The first one states whether we're currently inside of a quote and the second one stores its type (single or double quote). As long as the current character does not equal the type, all characters in between the starting and ending quote will be ignored. Of course we should be also able to deal with escaped quotes allowing constructs similar to the following one: <input type="text" name="test" value="<p>\"asdf\"</p>" /> --Tim

Dec. 5, 2009

dpid not starting automatically

by tim.nieradzik＠gmx.de

I am starting Dillo right away from the source code. Thus, it is not installed in any of the directories listed in $PATH. Dillo gives me the following errors as it does not seem to be able to find the dpid binary: Dpi_check_dpid_ids: Connection refused Dpi_start_dpid (child): No such file or directory Dpi_start_dpid: can't start dpid What do you think of adding some code that tries to execute the local dpid binary first (dpid/dpid) before looking into the system paths? --Tim

Dec. 5, 2009

Misbehaving dw-demos

by Johannes.Hofmann＠gmx.de

Hi Tim, On Sat, Dec 05, 2009 at 07:51:35PM +0100, Tim Nieradzik wrote: > The dw-demos stopped working for me with revision 2b0ed71ccec6. The > changeset results in only printing the first character of each word > followed by a line break. As discussed off-list already, this happens because the new letter-spacing member of FontAttrs is not initialized properly in the test programs. I will fix that. Normally a constructor exists to avoid exactly this kind of bugs. However we need to be careful to avoid unnecessary initializations when the members get copied over right after initialization - or maybe this wouldn't even matter performance wise... I need to play with this a little. Thanks for the fault report, Johannes

Dec. 5, 2009