- Dillo-dev - lists.mailman3.com

display: inline
by Johannes.Hofmann＠gmx.de Dec. 13, 2009

Dec. 13, 2009

Hi, On Fri, Dec 11, 2009 at 08:53:18PM +0100, Johannes Hofmann wrote: > Hi, > > On Fri, Dec 11, 2009 at 07:46:33AM +0000, corvid wrote: > > Here's the nightmarish hackery that I ended up with > > while getting show/hide to work on display:none. > > There might be issues with the implementation - I need to look at it > in more detail - but the result is pretty amazing! > > Let me check your patch in detail... > > > bleh. > > But I realized it still won't work right for the case like > > <form action=...> > > <input type=text name=... value="something to right-click on"> > > <div style="display:none"> > > <textarea name=...> > > text > > </textarea> > > </div> > > </form> > > because I would have to start digging into display:none Textblocks in > > search of not-display:none form things, but then normally you don't want > > to display not-display:none things inside display:none...so...ummm... > > this is all a demonstration of what not to do. > > As for what _would_ be non-horrible, good question. > > > > I suppose a way just to toggle whether display:none is obeyed at all > > might be nicer for us, albeit not for the user. Ok, I understand your concerns now. It might be better to simply not create dw-widgets in the display:none case. At least we should try that option to see if it's simpler. My reasons are: * we would not pollute dw/* which is complex already. dw/* would not look at style.display at all. * as Tim mentioned, you can always switch off remote CSS to see display:none stuff. * it does not mean that elements with display:none would not be part of the DOM tree, as the DOM tree will be separate from the widget tree. I also understand now your's and Tim's concerns about the style pointer in struct Word. As soon as we start to modify styles in an existing widget tree we will get into trouble with all those pointers as we can't modify style objects in place. So I would propose to do display handling in html.cc. Then we can convert Doctree to a real DOM tree. With that in place we can come back to the style in struct Word issue. We might simply have a pointer to the corresponding DoctreeNode, which could hold the style. We might even drop the style sharing code then - but let's see. Here comes a simple example to demonstrate why I think DOM-tree and widget tree should be separate - and I suppose that this is what Sebastian also had in mind with his CSS plan. This piece of HTML: <html> <body> <ul> <li>foo</li> <li>ba<b>r</b></li> </ul> </body> </html> results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ / \ li li AlignedTextblock AlignedTextblock | b whereas: <html> <body> <ul> <li style="display: inline">foo</li> <li>ba<b>r</b></li> </ul> </body> </html> results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ | li li AlignedTextblock | b Cheers, Johannes

3 4

Adding CSS properties and values
by tim.nieradzik＠gmx.de Dec. 12, 2009

Dec. 12, 2009

I've just started work on support for the "float" property but I'm already running into difficulties when trying to add the detection for its values. Every website gets screwed up after applying my patch. Any ideas? --Tim

2 1

HTML parser bug
by tim.nieradzik＠gmx.de Dec. 6, 2009

Dec. 6, 2009

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

3 2

display: inline
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

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

1 0

dpid not starting automatically
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

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

2 1

Misbehaving dw-demos
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

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

2 1

patch: anchors no longer words
by corvid＠lavabit.com Nov. 30, 2009

Nov. 30, 2009

A few days ago, I tried to make addParbreak() work properly when listitems have anchors in the beginning (that's why they often show breaks before their contents), but it was quite icky -- and required more extensive changes than I expected. So instead, here's what we get if we pull the anchors out of the Word list and store them separately. Less icky.

3 3

[patch]: trim the labels of the stylesheet menu
by onepoint＠starurchin.org Nov. 21, 2009

Nov. 21, 2009

While thinking about stylesheet issues I noticed a UI problem: the stylesheet menu uses URLs as the labels of the menu items. This is unfortunate because some sites have stylesheets with insanely long URLs. (Try Wikipedia if you don't believe me!) So I'm attaching a patch that trims long URLs in the menu. This is just a UI change - no functionality is affected. Here's a demonstration of the patch on the front page of Wikipedia: http://starurchin.org/dillo/stylesheet_menu/ Notes: Since the label is no longer always the same as the label the callback must find the URL elsewhere. We put it in the user_data() of the menu item. We just copy the pointer to the DilloUrl structure, so we are assuming it will never be free()-ed while the menu is up. If I'm wrong about this the patch will need to be revised. We get a nice cleanup for free: we loose the mysterious magic constant 5 in the callback. (Bonus points if you can see what that magic constant is! Double bonus points if you can see why the code still worked when I erroneously left it in!) Please comment, Jeremy Henty

2 3

EAGAIN loop in IO_read
by furaisanjin＠gmail.com Nov. 21, 2009

Nov. 21, 2009

Hi all. This might be FreeBSD specific issue but I have EAGAIN loop in IO_read. I don't know anything yet why this happens but at some point read function keeps returning EAGAIN in IO_read and nothing is read. Do you have any idea how to investigate this further? I think this happens after DPI big change. Regards, furaisanjin

4 26

Q: why do we defer loading linked stylesheets?
by onepoint＠starurchin.org Nov. 20, 2009

Nov. 20, 2009

Why do we defer loading the CSS stylesheets named in <link> elements until the <head> element is closed? In html.cc, Html_tag_close_head() has the comment "charset is already set, load remote stylesheets now", but I don't understand the significance of the charset. I am asking because I'd like to patch Dillo to add @import-ed stylesheets to the browser window popup menu, just as it already does for <link>-ed stylesheets. At the moment this causes all sorts of code branches (is the @import in a <link>-ed file or an embedded <style>, if the latter, is it in the <head> or not). It would be much simpler to just immediately load every style file at the same time as it is added to html->ccsUrls , but that would change the behaviour to load <link>-ed styles immediately instead of at the end of the <head> element. Would that break anything? Regards, Jeremy Henty

3 8