- Dillo-dev - lists.mailman3.com

patch: vertical-align

by corvid＠lavabit.com

http://www.dillo.org/test/vertical-align.patch - this won't do anything for table cells - it sometimes won't do the right thing because it doesn't know what is yet to come later in the line - it calculates Y offsets for words when drawing them. It may be better to add a field to Word

Dec. 21, 2009

[oph-villedieu@orange.fr: dillo_2.1.1]

by corvid＠lavabit.com

Johannes wrote: > On Sun, Dec 20, 2009 at 11:28:15AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > I just received this email. The attached example shows the bug. > > Does anybody remember what we did with valign? ;) > > > > > > I'm afraid I found a bug in this release (?) : > > > it does not understand the html tag <td valign="bottom"> > > > it reads instead <td valign="top"> > I think we never supported valign=top | middle | bottom > in dillo-fltk. > We probabely need to implement it in Textblock::sizeAllocateImpl(). The vertical-align code I have around doesn't do anything for table cells. I guess I have increased incentive to clean up what I already have, at least.

Dec. 20, 2009

[oph-villedieu@orange.fr: dillo_2.1.1]

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Dec 20, 2009 at 11:28:15AM -0300, Jorge Arellano Cid wrote: > Hi, > > I just received this email. The attached example shows the bug. > Does anybody remember what we did with valign? ;) > > > > I'm afraid I found a bug in this release (?) : > > it does not understand the html tag <td valign="bottom"> > > it reads instead <td valign="top"> > > #:-(( > > hoping it helps, > > best whishes for Christmas and New year, > > > > Edouard BENOIS (France) > > > > http://pagesperso-orange.fr/edouard.benois/photos.htm > > Ouch, that doesn't look good :-) > > > > > <html> > <body> > <table border='1'> > <tr> > <td>1<br>2<br>3 > <td valign=top>* > <td valign=middle>* > <td valign=bottom>* > </table> > </body> > </html> I think we never supported valign=top | middle | bottom in dillo-fltk. We probabely need to implement it in Textblock::sizeAllocateImpl(). Cheers, Johannes

Dec. 20, 2009

[oph-villedieu@orange.fr: dillo_2.1.1]

by jcid＠dillo.org

Hi, I just received this email. The attached example shows the bug. Does anybody remember what we did with valign? ;) -- Cheers Jorge.-

Dec. 20, 2009

new fltk snapshot

by corvid＠lavabit.com

There's a new fltk2 snapshot with a change to the key handling code. I don't know whether it could make any difference for people who have had modifier problems, but it would probably be good to give it a try. http://fltk.org/articles.php?L958

Dec. 18, 2009

dillo2.x on Fedora 12

by newman.x＠gmail.com

On Fri, Dec 18, 2009 at 4:47 AM, Globe Trotter <itsme_410(a)yahoo.com> wrote: > Hi, > > Any likelihood of getting some Fedora 12 dillo2 RPMS? > You may try http://mnowak.fedorapeople.org/dillo2/ should be the last release. There are static RPMs for F-11 and SRPM, which you can rebuild yourself for F-12, when you have installed static FLTK2 http://mnowak.fedorapeople.org/fltk2/static/ Though, unlikely to have Dillo 2 in Fedora as a supported package due to FLTK2, which is used in Dillo 2, is unreleased version, we don't wanna in Fedora. (Anyway FLTK2 seemed to me dead, last time I've looked, anyway.) Unless Dillo 2 is based on some released and supported toolkit, Dillo 2 won't be Fedora-supported. > Thanks for the great work!! > > Best, > T Michal

Dec. 18, 2009

dillo2.x on Fedora 12

by itsme_410＠yahoo.com

Hi, Any likelihood of getting some Fedora 12 dillo2 RPMS? Thanks for the great work!! Best, T

Dec. 18, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Thu, Dec 17, 2009 at 12:37:36AM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > > > > Any opinions? Does this solve the problem? > > > > > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > > > > > Looks good to me. Is this ok for all? > > > > > If there are no complaints I would commit a slightly modified version (attached). > > > > > > > > I think I like having Location lose focus after I press enter. > > > > > > but the patch I had proposed originally doesn't seem to fix all of > > > furaisanjin's issues. E.g. when starting dillo with an URL on > > > the commandline, the location bar will have the focus. > > > > > > Are there cases where my furaisanjin's patch causes unexpected > > > switches of focus, i.e. not triggered directly by a user action? > > > > I've completely lost track of what various versions do; > > I'm just saying that typing in an address, pressing enter, and > > having focus switch from Location to Main is nice. > > Ah ok. I just committed furaisanjin's patch with a minor change. I > there should be unexpected focus switches please report them, so we > can look it this again. Oh, I see the confusion now. I must have misapplied that last version somehow, because it wasn't changing focus for me, but now using that same patch from tip seems to be working fine. Sorry about that.

Dec. 17, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Thu, Dec 17, 2009 at 12:37:36AM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > > > Any opinions? Does this solve the problem? > > > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > > > Looks good to me. Is this ok for all? > > > > If there are no complaints I would commit a slightly modified version (attached). > > > > > > I think I like having Location lose focus after I press enter. > > > > but the patch I had proposed originally doesn't seem to fix all of > > furaisanjin's issues. E.g. when starting dillo with an URL on > > the commandline, the location bar will have the focus. > > > > Are there cases where my furaisanjin's patch causes unexpected > > switches of focus, i.e. not triggered directly by a user action? > > I've completely lost track of what various versions do; > I'm just saying that typing in an address, pressing enter, and > having focus switch from Location to Main is nice. Ah ok. I just committed furaisanjin's patch with a minor change. I there should be unexpected focus switches please report them, so we can look it this again. Cheers, Johannes

Dec. 17, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > > Any opinions? Does this solve the problem? > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > Looks good to me. Is this ok for all? > > > If there are no complaints I would commit a slightly modified version (attached). > > > > I think I like having Location lose focus after I press enter. > > but the patch I had proposed originally doesn't seem to fix all of > furaisanjin's issues. E.g. when starting dillo with an URL on > the commandline, the location bar will have the focus. > > Are there cases where my furaisanjin's patch causes unexpected > switches of focus, i.e. not triggered directly by a user action? I've completely lost track of what various versions do; I'm just saying that typing in an address, pressing enter, and having focus switch from Location to Main is nice.

Dec. 17, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > Any opinions? Does this solve the problem? > > > > > > Could you consider this patch? This solves both problems I reported. > > > > Looks good to me. Is this ok for all? > > If there are no complaints I would commit a slightly modified version (attached). > > I think I like having Location lose focus after I press enter. but the patch I had proposed originally doesn't seem to fix all of furaisanjin's issues. E.g. when starting dillo with an URL on the commandline, the location bar will have the focus. Are there cases where my furaisanjin's patch causes unexpected switches of focus, i.e. not triggered directly by a user action? Cheers, Johannes

Dec. 16, 2009

take_focus on a new tab

by tim.nieradzik＠gmx.de

> I think I like having Location lose focus after I press enter. I agree. This would be nice. --Tim

Dec. 15, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > Any opinions? Does this solve the problem? > > > > Could you consider this patch? This solves both problems I reported. > > Looks good to me. Is this ok for all? > If there are no complaints I would commit a slightly modified version (attached). I think I like having Location lose focus after I press enter.

Dec. 15, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > Any opinions? Does this solve the problem? > > Could you consider this patch? This solves both problems I reported. Looks good to me. Is this ok for all? If there are no complaints I would commit a slightly modified version (attached). Cheers, Johannes

Dec. 15, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Any opinions? Does this solve the problem? Could you consider this patch? This solves both problems I reported. diff -r c38e7c577023 src/uicmd.cc --- a/src/uicmd.cc Thu Dec 10 21:50:17 2009 +0000 +++ b/src/uicmd.cc Tue Dec 15 21:17:49 2009 +0900 @@ -604,6 +604,7 @@ if (url) { a_Nav_push(bw, url); a_Url_free(url); + a_UIcmd_focus_main_area(bw); } } @@ -617,6 +618,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUrl *url) { a_Nav_push(bw, url); + a_UIcmd_focus_main_area(bw); } static void UIcmd_open_url_nbw(BrowserWindow *new_bw, const DilloUrl *url) Regards, furaisanjin

Dec. 15, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Wed, Dec 02, 2009 at 06:42:27PM +0100, Johannes Hofmann wrote: > > On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > > > furaisanjin wrote: > > > > 2. When URL is given on address bar, cursor stays on address bar after > > > > the page rendering finishes. This isn't side effect. This may be > > > > matter of taste but I don't like this behavior. > > > > > > We'll need to be careful if changing focus in this case, since > > > the user may be in the middle of typing something somewhere. > > > > > > (My local public library's site, if used in firefox, likes to reset > > > form fields with javascript when a page finishes loading, and it's > > > irritating.) > > > > What do all think about attached patch. It switches the focus when > > the user hits return. > > So the focus switch does not happen at some random time when the > > page has loaded which might be irritating. > > Any opinions? Does this solve the problem? I like it.

Dec. 15, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Wed, Dec 02, 2009 at 06:42:27PM +0100, Johannes Hofmann wrote: > On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > > furaisanjin wrote: > > > 2. When URL is given on address bar, cursor stays on address bar after > > > the page rendering finishes. This isn't side effect. This may be > > > matter of taste but I don't like this behavior. > > > > We'll need to be careful if changing focus in this case, since > > the user may be in the middle of typing something somewhere. > > > > (My local public library's site, if used in firefox, likes to reset > > form fields with javascript when a page finishes loading, and it's > > irritating.) > > What do all think about attached patch. It switches the focus when > the user hits return. > So the focus switch does not happen at some random time when the > page has loaded which might be irritating. Any opinions? Does this solve the problem? Cheers, Johannes > > Cheers, > Johannes > diff -r a41372a38f02 src/ui.cc > --- a/src/ui.cc Wed Dec 02 17:40:33 2009 +0100 > +++ b/src/ui.cc Wed Dec 02 18:42:15 2009 +0100 > @@ -267,6 +267,7 @@ > * page. BUG: this must be investigated and reported to FLTK2 team */ > if (event_key() == ReturnKey) { > a_UIcmd_open_urlstr(a_UIcmd_get_bw_by_widget(i), i->value()); > + ui->focus_main(); > } > if (ui->get_panelmode() == UI_TEMPORARILY_SHOW_PANELS) { > ui->set_panelmode(UI_HIDDEN);

Dec. 14, 2009

display: inline

by Johannes.Hofmann＠gmx.de

Hi Tim, On Sun, Dec 13, 2009 at 03:21:23AM +0100, Tim Nieradzik wrote: > I am still uncertain whether doing the display:none handling in > src/Html.cc is really superior. What I liked about corvid's approach is > the simplicity of the changes. It did not really involve any fundamental > changes. I'm not 100% sure yet either. > > Furthermore, I think handling of hidden elements is generally better > suited in dw/ because it's design-related. It would make the whole > separation useless, if we mixed parsing code with complex > evaluation-logic. Moreover, it should be possible to use the dw-stack > completely independent from Dillo's parsing code. Otherwise, this isn't > necessarily the case as the developer needs to implement hiding > manually. Well, I'm not sure if a independent widget library absolutely needs hiding / unhiding to be useful. > > We could also apply display:none to hidden form elements (what I've > tried in my patch). This is an advantage because dw's focus is not only > HTML and CSS. It should be usable for any other markup as well. > Therefore, I'd propose to introduce a general 'hidden' attribute > applicable to any element. In the parsing code, hidden HTML form fields > are simply converted and internally represented by an ordinary text > field which, however, is not displayed. I would agree if we would just have display:none and display:true or so. But to implement e.g. display:block, we need to add a new textblock or for tables we have to add a table widget. And this has to be done in html.cc as the complete structure of the widget tree is affected. But if we handle all values of display: other than "none" in html.cc, then why not handle "none" there as well? Also using display:none to hide form elements is a bit problematic, because then we loose the original value of display. When the user clicks "show hiddens", should we switch to display:block, or display:inline? > > I haven't done any benchmarks but I guess this approach is more > efficient in terms of memory usage and rendering speed. It doesn't > require to render the whole page repeatedly from scratch when hidden > elements are made visible as only a flag needs to be set. It's not > required to add new widgets to the dw-layout as with the other approach. > As for big pages (HTML manuals with 2-5 MiB), otherwise it would imply > that the entire dw-tree in memory is freed and then reallocated > afterwards - just because one was made visible! For now we might simply not imlement a show display:none option. And for form elements we have it in place already. If we would implement changing the value of display: in place, then we would also have to support a change from e.g. inline to block. Additionally, I don't see a reason why we would have to through away the entire dw-tree in that case. We could just modify it in place and request a redraw. > > Would the code be really shorter if done in src/Html.cc? I doubt that as > we'd still need to check for the "display" value. Actually the patch > doesn't do any more than that. So the benefits wouldn't be that > striking. > > While I really like the idea of a DOM, I am somewhat concerned about the > performance. A DOM is great when it comes to manipulating the design at > runtime. It can be also useful for debugging purposes. However, as Dillo > does not aim to support JavaScript there is virtually no need for a DOM. > dw seems pretty flexible already and I guess it wouldn't be very > difficult to do minor contents manipulation stuff. We already have a DOM tree - though a degenerated one. It is needed for CSS (see styleengine.cc and doctree.hh). It would be pretty simple to expand it to a real tree (it's a stack atm). As you said, this would be needed for manipulating the layout at runtime (e.g. for :hover), for CSS adjacent sibling matching, and for JavaScript. > > If understood your DocTree concept correctly, we won't end up with > duplication as the DocTree represents both the contents and the style > whereas dw only takes care about rendering, right? This sounds > interesting but wouldn't it also mean that partial changes to the layout > (or contents) would result in re-rendering the whole page? > > Therefore, I'd endorse the DocTree concept if there were some kind of > 'change stack'. Changes can be 'reverted' and 'committed'. A commit then > leads to only render the changes. (This idea might also come in handy > with slow connections because we can make the 'commit'-rate dependent on > the transfer speed. Thus, a 500 KiB website with 1 MiB/s will require > only one 'commit' whereas with slower connections there might be more. > How is this currently realized in Dillo, by the way?) You can already modify the widget tree and only the modified stuff will be redrawn. It's implemented in dw/*. Cheers, Johannes

Dec. 13, 2009

display: inline

by tim.nieradzik＠gmx.de

I am still uncertain whether doing the display:none handling in src/Html.cc is really superior. What I liked about corvid's approach is the simplicity of the changes. It did not really involve any fundamental changes. Furthermore, I think handling of hidden elements is generally better suited in dw/ because it's design-related. It would make the whole separation useless, if we mixed parsing code with complex evaluation-logic. Moreover, it should be possible to use the dw-stack completely independent from Dillo's parsing code. Otherwise, this isn't necessarily the case as the developer needs to implement hiding manually. We could also apply display:none to hidden form elements (what I've tried in my patch). This is an advantage because dw's focus is not only HTML and CSS. It should be usable for any other markup as well. Therefore, I'd propose to introduce a general 'hidden' attribute applicable to any element. In the parsing code, hidden HTML form fields are simply converted and internally represented by an ordinary text field which, however, is not displayed. I haven't done any benchmarks but I guess this approach is more efficient in terms of memory usage and rendering speed. It doesn't require to render the whole page repeatedly from scratch when hidden elements are made visible as only a flag needs to be set. It's not required to add new widgets to the dw-layout as with the other approach. As for big pages (HTML manuals with 2-5 MiB), otherwise it would imply that the entire dw-tree in memory is freed and then reallocated afterwards - just because one was made visible! Would the code be really shorter if done in src/Html.cc? I doubt that as we'd still need to check for the "display" value. Actually the patch doesn't do any more than that. So the benefits wouldn't be that striking. While I really like the idea of a DOM, I am somewhat concerned about the performance. A DOM is great when it comes to manipulating the design at runtime. It can be also useful for debugging purposes. However, as Dillo does not aim to support JavaScript there is virtually no need for a DOM. dw seems pretty flexible already and I guess it wouldn't be very difficult to do minor contents manipulation stuff. If understood your DocTree concept correctly, we won't end up with duplication as the DocTree represents both the contents and the style whereas dw only takes care about rendering, right? This sounds interesting but wouldn't it also mean that partial changes to the layout (or contents) would result in re-rendering the whole page? Therefore, I'd endorse the DocTree concept if there were some kind of 'change stack'. Changes can be 'reverted' and 'committed'. A commit then leads to only render the changes. (This idea might also come in handy with slow connections because we can make the 'commit'-rate dependent on the transfer speed. Thus, a 500 KiB website with 1 MiB/s will require only one 'commit' whereas with slower connections there might be more. How is this currently realized in Dillo, by the way?) --Tim

Dec. 13, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Sat, Dec 12, 2009 at 09:38:20PM +0000, corvid wrote: > Johannes wrote: > > 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. > > Your suggestion seems quite sensible to me now :) Let's see :) > > > 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. > > Would dw/ understand the contents of DocTreeNodes? Sorry, what I said was misleading. dw/ would not include doctree.hh. However we could have one style object per DocTreeNode and then all objects in the widget tree (widgets or struct Words) that correspond to that DocTreeNode could point to that single style object - which we could then modify in place. The main link between DocTree and widget tree would be the other way round. Each DocTreeNode would have a pointer to the widget that is responsible for displaying it - we might need further information like the word indices if a single widget displays multiple DocTreeNodes.

Dec. 12, 2009

display: inline

by corvid＠lavabit.com

Johannes wrote: > 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. Your suggestion seems quite sensible to me now :) > 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. Would dw/ understand the contents of DocTreeNodes?

Dec. 12, 2009

display: inline

by Johannes.Hofmann＠gmx.de

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

Dec. 12, 2009

Adding CSS properties and values

by Johannes.Hofmann＠gmx.de

Hi Tim, On Fri, Dec 11, 2009 at 10:53:17PM +0100, Tim Nieradzik wrote: > 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? The problem is that you added more CSS_PROPERTY_* values. The CSS_PROPERTY_* values need to correspond with the CssPropertyInfo in cssparser.cc. By inserting CSS_PROPERTY_* values all properties after CSS_PROPERTY_FLOAT_LEFT will no longer match. But you don't need to add CSS_PROPERTY_* values anyway. There is one CSS_PROPERTY_* value for each CSS property (http://www.w3.org/TR/CSS2/) For floats there is only one property "float" for which there is already CSS_PROPERTY_FLOAT in css.hh. It can have the values you correctly defined in Css_float_enum_vals. So your patch looks good, just leave out the change in css.hh. But that was the easy part... The real problem is what to do with those values. We need a way to render floating elements in dw/* Johannes > > --Tim > diff --git a/src/css.hh b/src/css.hh > index 79ba302..815c14a 100644 > --- a/src/css.hh > +++ b/src/css.hh > @@ -166,7 +166,9 @@ typedef enum { > CSS_PROPERTY_DIRECTION, > CSS_PROPERTY_DISPLAY, > CSS_PROPERTY_EMPTY_CELLS, > - CSS_PROPERTY_FLOAT, > + CSS_PROPERTY_FLOAT_LEFT, > + CSS_PROPERTY_FLOAT_RIGHT, > + CSS_PROPERTY_FLOAT_NONE, > CSS_PROPERTY_FONT_FAMILY, > CSS_PROPERTY_FONT_SIZE, > CSS_PROPERTY_FONT_SIZE_ADJUST, > diff --git a/src/cssparser.cc b/src/cssparser.cc > index 5f5bde0..4b6c2ad 100644 > --- a/src/cssparser.cc > +++ b/src/cssparser.cc > @@ -101,6 +101,10 @@ static const char *const Css_text_decoration_enum_vals[] = { > "underline", "overline", "line-through", "blink", NULL > }; > > +static const char *const Css_float_enum_vals[] = { > + "left", "right", "none", NULL > +}; > + > static const char *const Css_vertical_align_vals[] = { > "top", "bottom", "middle", "baseline", "sub", "super", NULL > }; > @@ -145,7 +149,7 @@ const CssPropertyInfo Css_property_info[CSS_PROPERTY_LAST] = { > {"direction", {CSS_TYPE_UNUSED}, NULL}, > {"display", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_display_enum_vals}, > {"empty-cells", {CSS_TYPE_UNUSED}, NULL}, > - {"float", {CSS_TYPE_UNUSED}, NULL}, > + {"float", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_float_enum_vals}, > {"font-family", {CSS_TYPE_SYMBOL, CSS_TYPE_UNUSED}, NULL}, > {"font-size", {CSS_TYPE_ENUM, CSS_TYPE_LENGTH_PERCENTAGE, CSS_TYPE_UNUSED}, > Css_font_size_enum_vals}, > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 11, 2009

Adding CSS properties and values

by tim.nieradzik＠gmx.de

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

Dec. 11, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Wed, Dec 09, 2009 at 09:07:53PM +0100, Tim Nieradzik wrote: > > Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as > > you did here :-) > > Oh, I just had a look at your private repository and noticed that it > wasn't yet implemented. :) > > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > As you noticed it's not enough to not call the tag open functions, > > as text will still be added. > > I'd suggest to add the elements to the dw representation regardless of > their "display" value. But we should introduce a 'flag' that disables > drawing of elements with "display: none". > > > Also I don't know, whether e.g. inputs in forms which have > > DISPLAY_NONE, should send their contents to the server in case of > > submit, or should they be just non-existent? > > Since CSS only "describes the presentation semantics" (Wikipedia), the > form elements are still available but 'hidden'. In Gecko, the DOM > contains hidden elements as well. "display: none" is commonly used for > menus: With the help of JavaScript, you could fiddle inside the DOM and > toggle "display"-value to make the submenu visible. Yes, that's a problem. We definately need a way to toggle the hidden state. Otherwise pages get less accessible as we don't support JavaScript. > > > Regarding tagIsDisplayEnabled, I don't quite follow what you > > intended? I had added this flag to gradually transform the > > Html_tag_open_*() functions to the new display handling. It > > can only be removed once all these functions have been converted. > > I thought the only sense in implementing tagIsDisplayEnabled was to > prevent Dillo to crash? While playing around with DISPLAY_NONE > detection, the "stack->getRef (stack->size () - 1)->style == NULL" > assert failed for Html_tag_open_body(). Checking > html->styleEngine->style ()->display for DISPLAY_NONE resulted in > initializing the style engine too early. > > > Hm, maybe you are right and as long as the corresponding tags are > > set to DISPLAY_INLINE, which is the default, it would work even > > without the tagIsDisplayEnabled flag. Anyway, I think it's still a > > good marker to see which functions have been converted. > > To what extent would they need to be converted? Why do we care at all if > a tag supports the "display" attribute? Currently the Html_tag_open_*() functions add textblocks, or parbreaks as it fits. The idea is to convert them so that they only do HTML specific attribute parsing, setNonCssHints()-handling, and HTML error reporting. Building the dw widget tree would be solely determined by the current style (mainly the display part). I want to make this transition gradually, leaving e.g. forms and tables as they are atm. Cheers, Johannes

Dec. 9, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Wed, Dec 09, 2009 at 08:47:46PM +0000, corvid wrote: > Tim wrote: > > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > > As you noticed it's not enough to not call the tag open functions, > > > as text will still be added. > > > > I'd suggest to add the elements to the dw representation regardless of > > their "display" value. > > This sounds right to me, too. I'll take a look at preventing them from > being drawn and taking up space. Great, it showing and hiding of hidden form entries works nicely already. > > Also, iterators would have to ignore undisplayed words for copying text. > Is there any case where iterators would need to be able to notice them? No, I don't thinks so. For searching and text selection it should not be needed.

Dec. 9, 2009

display: inline

by tim.nieradzik＠gmx.de

> Is there any case where iterators would need to be able to notice them? No, I don't think so. As for form submitting (src/form.cc) the EmbedIterator is not used at all. The input fields refer directly to the matching embed object (see Html_add_input()). --Tim

Dec. 9, 2009

display: inline

by corvid＠lavabit.com

Tim wrote: > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > As you noticed it's not enough to not call the tag open functions, > > as text will still be added. > > I'd suggest to add the elements to the dw representation regardless of > their "display" value. This sounds right to me, too. I'll take a look at preventing them from being drawn and taking up space. Also, iterators would have to ignore undisplayed words for copying text. Is there any case where iterators would need to be able to notice them?

Dec. 9, 2009

display: inline

by corvid＠lavabit.com

Johannes wrote: > Also I don't know, whether e.g. inputs in forms which have > DISPLAY_NONE, should send their contents to the server in case of > submit, or should they be just non-existent? I'm not aware of anything in html4 about that case. I think css2 says somewhere that it doesn't specify what to do with forms.

Dec. 9, 2009

display: inline

by tim.nieradzik＠gmx.de

> Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as > you did here :-) Oh, I just had a look at your private repository and noticed that it wasn't yet implemented. :) > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > As you noticed it's not enough to not call the tag open functions, > as text will still be added. I'd suggest to add the elements to the dw representation regardless of their "display" value. But we should introduce a 'flag' that disables drawing of elements with "display: none". > Also I don't know, whether e.g. inputs in forms which have > DISPLAY_NONE, should send their contents to the server in case of > submit, or should they be just non-existent? Since CSS only "describes the presentation semantics" (Wikipedia), the form elements are still available but 'hidden'. In Gecko, the DOM contains hidden elements as well. "display: none" is commonly used for menus: With the help of JavaScript, you could fiddle inside the DOM and toggle "display"-value to make the submenu visible. > Regarding tagIsDisplayEnabled, I don't quite follow what you > intended? I had added this flag to gradually transform the > Html_tag_open_*() functions to the new display handling. It > can only be removed once all these functions have been converted. I thought the only sense in implementing tagIsDisplayEnabled was to prevent Dillo to crash? While playing around with DISPLAY_NONE detection, the "stack->getRef (stack->size () - 1)->style == NULL" assert failed for Html_tag_open_body(). Checking html->styleEngine->style ()->display for DISPLAY_NONE resulted in initializing the style engine too early. > Hm, maybe you are right and as long as the corresponding tags are > set to DISPLAY_INLINE, which is the default, it would work even > without the tagIsDisplayEnabled flag. Anyway, I think it's still a > good marker to see which functions have been converted. To what extent would they need to be converted? Why do we care at all if a tag supports the "display" attribute? --Tim

Dec. 9, 2009

display: inline

by Johannes.Hofmann＠gmx.de

Hi Tim, On Wed, Dec 09, 2009 at 12:54:54AM +0100, Tim Nieradzik wrote: > In my opinion, these changes make sense indeed as they provide a more > generic interface. > > Looking at quirkmode's "display: list-item"-demo, listStylePosition > seems to have a wrong value. The bullets are supposed to be drawn > outside the box but they appear inside. Did I understand your changes > correctly that listStylePosition is either 0 ("outside") or 1 ("inside") > because of that enum? > > See http://www.quirksmode.org/css/display.html I guess you're right, that the bullets should be outside the box, but due to the current implementation of ListItem it's inside even if listStylePosition is outside. However as long as you don't look at the border of the box, the behaviour is correct now, see e.g. http://de.selfhtml.org/css/eigenschaften/anzeige/list_style_position.htm > > I tried to implement "display: none" but the contents are still visible. > I also worked on getting rid of tagIsDisplayEnabled but I am yet > uncertain whether it is safe how approached it. Any comments? Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as you did here :-) I'm still uncertain on what to do in case that DISPLAY_NONE is set. As you noticed it's not enough to not call the tag open functions, as text will still be added. Also I don't know, whether e.g. inputs in forms which have DISPLAY_NONE, should send their contents to the server in case of submit, or should they be just non-existent? Regarding tagIsDisplayEnabled, I don't quite follow what you intended? I had added this flag to gradually transform the Html_tag_open_*() functions to the new display handling. It can only be removed once all these functions have been converted. Hm, maybe you are right and as long as the corresponding tags are set to DISPLAY_INLINE, which is the default, it would work even without the tagIsDisplayEnabled flag. Anyway, I think it's still a good marker to see which functions have been converted. Regards, Johannes > > --Tim > diff -r 440fa7e952bd dw/style.hh > --- a/dw/style.hh Tue Dec 08 18:46:31 2009 +0100 > +++ b/dw/style.hh Wed Dec 09 00:48:03 2009 +0100 > @@ -253,7 +253,8 @@ > DISPLAY_TABLE_FOOTER_GROUP, > DISPLAY_TABLE_ROW, > DISPLAY_TABLE_CELL, > - DISPLAY_LAST > + DISPLAY_LAST, > + DISPLAY_NONE > }; > > enum ListStylePosition { > diff -r 440fa7e952bd src/cssparser.cc > --- a/src/cssparser.cc Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/cssparser.cc Wed Dec 09 00:48:03 2009 +0100 > @@ -58,10 +58,10 @@ > "w-resize", "text", "wait", "help", NULL > }; > > -static const char *const Css_display_enum_vals[DISPLAY_LAST + 1] = { > +static const char *const Css_display_enum_vals[] = { > "block", "inline", "list-item", "table", "table-row-group", > "table-header-group", "table-footer-group", "table-row", > - "table-cell", NULL > + "table-cell", "last", "none", NULL > }; > > static const char *const Css_font_size_enum_vals[] = { > diff -r 440fa7e952bd src/html.cc > --- a/src/html.cc Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/html.cc Wed Dec 09 00:48:03 2009 +0100 > @@ -1282,7 +1282,7 @@ > TagInfo toptag = Tags[toptag_idx]; > if (s_sz > idx + 1 && toptag.EndTag != 'O') > BUG_MSG(" - forcing close of open tag: <%s>\n", toptag.name); > - _MSG("Close: %*s%s\n", size," ", toptag.name); > + _MSG("Close: %*s%s\n", s_sz, " ", toptag.name); > toptag.close(html, toptag_idx); > Html_real_pop_tag(html); > } > @@ -1528,13 +1528,6 @@ > } > > /* > - * By setting this to true, a Html_tag_open* function indicates that > - * the common display handling code should be used. > - * TODO: convert all Html_tag_open* functions and remove this variable. > - */ > -static bool tagIsDisplayEnabled; > - > -/* > * Handle open HTML element > */ > static void Html_tag_open_html(DilloHtml *html, const char *tag, int tagsize) > @@ -1876,8 +1869,6 @@ > a_Html_stash_init(html); > S_TOP(html)->parse_mode = > DILLO_HTML_PARSE_MODE_STASH_AND_BODY; > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -1916,8 +1907,6 @@ > > html->styleEngine->setNonCssHints (&props); > dFree(fontFamily); > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -1926,7 +1915,7 @@ > static void Html_tag_open_abbr(DilloHtml *html, const char *tag, int tagsize) > { > const char *attrbuf; > - > + > if (prefs.show_tooltip && > (attrbuf = a_Html_get_attr(html, tag, tagsize, "title"))) { > CssPropertyList props; > @@ -1936,8 +1925,6 @@ > html->styleEngine->setNonCssHints (&props); > dFree(tooltip_str); > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2183,8 +2170,6 @@ > BUG_MSG("name attribute is required for <map>\n"); > } > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2453,8 +2438,6 @@ > dFree(nameVal); > } > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2528,8 +2511,6 @@ > S_TOP(html)->list_type = HTML_LIST_UNORDERED; > S_TOP(html)->list_number = 0; > S_TOP(html)->ref_list_item = NULL; > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2590,10 +2571,9 @@ > BUG_MSG( "illegal '-' character in START attribute; Starting from 0\n"); > n = 0; > } > + > S_TOP(html)->list_number = n; > S_TOP(html)->ref_list_item = NULL; > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2621,8 +2601,6 @@ > *list_number = 0; > } > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -3011,7 +2989,6 @@ > static void Html_tag_open_default(DilloHtml *html,const char *tag,int tagsize) > { > html->styleEngine->inheritBackgroundColor(); > - tagIsDisplayEnabled = true; > } > > /* > @@ -3023,7 +3000,6 @@ > > a_Html_tag_set_align_attr (html, &props, tag, tagsize); > html->styleEngine->setNonCssHints (&props); > - tagIsDisplayEnabled = true; > } > > /* > @@ -3418,11 +3394,11 @@ > ListItem *list_item; > int *list_number; > char buf[16]; > - > + > /* Get our parent tag's variables (used as state storage) */ > list_number = &html->stack->getRef(html->stack->size()-2)->list_number; > ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; > - > + > HT2TB(html)->addParbreak (0, wordStyle); > > list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); > @@ -3430,7 +3406,7 @@ > HT2TB(html)->addParbreak (0, wordStyle); > *ref_list_item = list_item; > S_TOP(html)->textblock = html->dw = list_item; > - > + > if (style->listStyleType == LIST_STYLE_TYPE_NONE) { > // none > } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { > @@ -3496,15 +3472,11 @@ > /* Parse attributes that can appear on any tag */ > Html_parse_common_attrs(html, tag, tagsize); > > - /* Html_tag_open* function can set this to true to enable > - * generic CSS display handling. > - */ > - tagIsDisplayEnabled = false; > - /* Call the open function for this tag */ > - _MSG("Open : %s\n", Tags[ni].name); > - Tags[ni].open (html, tag, tagsize); > - > - if (tagIsDisplayEnabled) { > + if (! html->styleEngine->initialized () > + || html->styleEngine->style ()->display == DISPLAY_NONE) { > + /* Call the open function for this tag */ > + Tags[ni].open (html, tag, tagsize); > + > switch (html->styleEngine->style ()->display) { > case DISPLAY_BLOCK: > Html_display_block(html); > @@ -3549,7 +3521,6 @@ > (strchr(" \"'", tag[tagsize-3]) || /* [ "']/> */ > (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* <x/> */ > > - _MSG("Close: %s\n", Tags[ni].name); > Html_tag_cleanup_at_close(html, ni); > /* This was a close tag */ > html->ReqTagClose = false; > diff -r 440fa7e952bd src/styleengine.cc > --- a/src/styleengine.cc Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/styleengine.cc Wed Dec 09 00:48:03 2009 +0100 > @@ -567,6 +567,10 @@ > return Style::create (layout, &attrs); > } > > +bool StyleEngine::initialized () { > + return stack->getRef (stack->size () - 1)->style != NULL; > +} > + > /** > * \brief Create a new style object based on the previously opened / closed > * HTML elements and the nonCssProperties that have been set. > @@ -585,7 +589,7 @@ > // If this assertion is hit, you need to rearrange the code that is > // doing styleEngine calls to call setNonCssHints() before calling > // style() or wordStyle() for each new element. > - assert (stack->getRef (stack->size () - 1)->style == NULL); > + assert (! StyleEngine::initialized()); > > // reset values that are not inherited according to CSS > attrs.resetValues (); > diff -r 440fa7e952bd src/styleengine.hh > --- a/src/styleengine.hh Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/styleengine.hh Wed Dec 09 00:48:03 2009 +0100 > @@ -59,6 +59,7 @@ > return NULL; > }; > > + bool initialized (); > void parse (DilloHtml *html, DilloUrl *url, const char *buf, int buflen, > CssOrigin origin); > void startElement (int tag);

Dec. 9, 2009

display: inline

by tim.nieradzik＠gmx.de

In my opinion, these changes make sense indeed as they provide a more generic interface. Looking at quirkmode's "display: list-item"-demo, listStylePosition seems to have a wrong value. The bullets are supposed to be drawn outside the box but they appear inside. Did I understand your changes correctly that listStylePosition is either 0 ("outside") or 1 ("inside") because of that enum? See http://www.quirksmode.org/css/display.html I tried to implement "display: none" but the contents are still visible. I also worked on getting rid of tagIsDisplayEnabled but I am yet uncertain whether it is safe how approached it. Any comments? --Tim

Dec. 9, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Tue, Dec 08, 2009 at 08:36:35PM +0000, corvid wrote: > Johannes wrote: > > Please let me know what you think, and I would especially like to > > get opinions on how to implement the various display types: > > > > inline | block | list-item | run-in | inline-block | none > > I don't know about details, but I suspect the logic will all > end up in dw. I thought that the display handling would be done in html.cc - by choosing the proper dw widget structure. I think this is what Sebastian calls "complex properties" in http://www.dillo.org/CSS.html > > And that we will end up having to make a lot of boxes eventually. Yes definately. Currently we sometimes just add a parbreak, where we would need a new box. That's also the reason for the inheritBackgroundColor hack. On the other hand more Textblock widgets consume more memory on large pages. > In bug 929, someone wants to know why padding-left doesn't work > for P elements, for instance. This might be what Sebastian meant in > the top of textblock.hh about collapsing spaces being unnecessary > in a CSS-ized dillo. I don't know enough about this space collapsing...

Dec. 8, 2009

display: inline

by corvid＠lavabit.com

Johannes wrote: > Please let me know what you think, and I would especially like to > get opinions on how to implement the various display types: > > inline | block | list-item | run-in | inline-block | none I don't know about details, but I suspect the logic will all end up in dw. And that we will end up having to make a lot of boxes eventually. In bug 929, someone wants to know why padding-left doesn't work for P elements, for instance. This might be what Sebastian meant in the top of textblock.hh about collapsing spaces being unnecessary in a CSS-ized dillo.

Dec. 8, 2009

display: inline

by Johannes.Hofmann＠gmx.de

Hi, I started to experiment with the real solution, which means that the display member of Style determines whether a (Text)block is created or a ListItem, or whether just normal text is added. The patch is still small, but as the change is pretty fundamental, so I decided to put it in a separate repo for now. You can find it at: http://www.flpsed.org/hgweb/dillo_display/ Please let me know what you think, and I would especially like to get opinions on how to implement the various display types: inline | block | list-item | run-in | inline-block | none I've intentionally left out the table stuff for now ... Cheers, Johannes

Dec. 8, 2009

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

Misbehaving dw-demos

by tim.nieradzik＠gmx.de

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

Dec. 5, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > furaisanjin wrote: > > 2. When URL is given on address bar, cursor stays on address bar after > > the page rendering finishes. This isn't side effect. This may be > > matter of taste but I don't like this behavior. > > We'll need to be careful if changing focus in this case, since > the user may be in the middle of typing something somewhere. > > (My local public library's site, if used in firefox, likes to reset > form fields with javascript when a page finishes loading, and it's > irritating.) What do all think about attached patch. It switches the focus when the user hits return. So the focus switch does not happen at some random time when the page has loaded which might be irritating. Cheers, Johannes

Dec. 2, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Wed, Dec 02, 2009 at 09:33:45PM +0900, furaisanjin wrote: > 2009/12/2 corvid <corvid(a)lavabit.com>: > > furaisanjin wrote: > >> 2. When URL is given on address bar, cursor stays on address bar after > >> the page rendering finishes. This isn't side effect. This may be > >> matter of taste but I don't like this behavior. > > > > We'll need to be careful if changing focus in this case, since > > the user may be in the middle of typing something somewhere. > > I agree but current dillo behavior isn't good either. If I type > something on address bar before a page rendering finishes, typed > characters are appended after URL when URL is pushed on address bar. I > think only typed characters should remain there when the page > rendering finishes. Yes, that's annoying, but I think it's a separate issue. Regards, Johannes

Dec. 2, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/12/2 corvid <corvid(a)lavabit.com>: > furaisanjin wrote: >> 2. When URL is given on address bar, cursor stays on address bar after >> the page rendering finishes. This isn't side effect. This may be >> matter of taste but I don't like this behavior. > > We'll need to be careful if changing focus in this case, since > the user may be in the middle of typing something somewhere. I agree but current dillo behavior isn't good either. If I type something on address bar before a page rendering finishes, typed characters are appended after URL when URL is pushed on address bar. I think only typed characters should remain there when the page rendering finishes. Regards, furaisanjin

Dec. 2, 2009

take_focus on a new tab

by corvid＠lavabit.com

furaisanjin wrote: > 2. When URL is given on address bar, cursor stays on address bar after > the page rendering finishes. This isn't side effect. This may be > matter of taste but I don't like this behavior. We'll need to be careful if changing focus in this case, since the user may be in the middle of typing something somewhere. (My local public library's site, if used in firefox, likes to reset form fields with javascript when a page finishes loading, and it's irritating.)

Dec. 2, 2009