- Dillo-dev - lists.mailman3.com

zero-delay refresh, but no URL

by corvid＠lavabit.com

http://www.algo-prog.info/ocmc/ contains <meta http-equiv="refresh" content="0;web/" /> For refresh, we assume there will be an '=' from "URL=". Since there isn't one, we refresh the same URL over and over and over... We could refuse to follow a zero-delay refresh without a new URL, but I seem to recall back in the never-follow days that sometimes a page _wanted_ to be immediately refreshed once, after which it would provide the contents (I always wondered why). So perhaps the nav redirection stuff should use bw->redirect_level.

April 22, 2010

image background colors

by Johannes.Hofmann＠gmx.de

On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > Is this anywhere near correct? It is definately better than what we have now, but somehow this image background handling is a bit of a hack all together. Basically the Image Widget should get the background color via Widget::getBgColor() at drawing time. That would avoid any special handling in html.cc and would allow to modify the background color by setting a different style. However I can't see any easy way to achive this atm. > > (This at least makes the background colors right for the rounded-corner > images on the top row of links at fltk.org. > Of course it still looks funny because valign top isn't obeyed...) > > diff -r 3e01d83fd6d1 src/html.cc > --- a/src/html.cc Wed Apr 21 03:46:20 2010 +0000 > +++ b/src/html.cc Wed Apr 21 04:52:00 2010 +0000 > @@ -2119,7 +2119,10 @@ > > /* Add a new image widget to this page */ > Image = a_Image_new(alt_ptr, 0); > - if (HT2TB(html)->getBgColor()) > + > + if (html->styleEngine->style()->backgroundColor) > + Image->bg_color =html->styleEngine->style()->backgroundColor->getColor(); > + else if (HT2TB(html)->getBgColor()) > Image->bg_color = HT2TB(html)->getBgColor()->getColor(); > > load_now = prefs.load_images || > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 21, 2010

classes and pseudoclasses

by Johannes.Hofmann＠gmx.de

On Wed, Apr 21, 2010 at 02:45:10AM +0000, corvid wrote: > I was looking at how the fltk site appears, and noticed that > dillo and firefox have different ideas of what to do for: > > <html><head><style> > A:link {color: #ff0000} > A.unsel {color: #000000; background-color: #00ff00} > </style></head><body> > <a class=unsel href=http://www.dillo.org>a link</a> > </body></html> Both selectors have the same specificity and therefore the ordering is relevant - the later one should beat the first one (http://www.w3.org/TR/CSS2/cascade.html#cascading-order) dillo stores the selectors in several hash maps and lists for fast access and unfortunately in this case the two selectors end up in separate lists and so the ordering information is lost. The same thing can happen if an element has more than one class: <html><head><style> A.foo {color: #ff0000} A.bar {color: #000000; background-color: #00ff00} </style></head><body> <a class="foo bar" href=http://www.dillo.org>a link</a> </body></html> The obvious fix is to store order information in the selectors and sort them before applying. The question is how to do that efficient (memory and CPU-wise).

April 21, 2010

image background colors

by corvid＠lavabit.com

Is this anywhere near correct? (This at least makes the background colors right for the rounded-corner images on the top row of links at fltk.org. Of course it still looks funny because valign top isn't obeyed...)

April 21, 2010

classes and pseudoclasses

by corvid＠lavabit.com

I was looking at how the fltk site appears, and noticed that dillo and firefox have different ideas of what to do for: <html><head><style> A:link {color: #ff0000} A.unsel {color: #000000; background-color: #00ff00} </style></head><body> <a class=unsel href=http://www.dillo.org>a link</a> </body></html>

April 21, 2010

Dillo: being removed from Debian

by jcid＠dillo.org

FYI, corvid wrote: > Johannes wrote: > > On Tue, Apr 20, 2010 at 10:14:56AM -0400, Jorge Arellano Cid wrote: > > > On Tue, Apr 20, 2010 at 03:31:47PM +0300, Jari Aalto wrote: > > > > > > > > Dillow in in danger being removed from debian > > > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575240 > > > > > > > > This is mostly due to RC bugs (grace, serious, important) listed in: > > > > > > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dillo;dist=unstabl > > > > > > > > The current Debian maintainer does not seem to repond any longer, so I > > > > could offer my help to keep the package in Debian: > > > > > > > > Would you take a look at the Debian bug listing and see their > > > > Could be solved or if they already are in latest version? > > > > > > > > Thanks for any help, > > > > Jari > > > > > > I'd be happy if dillo1 is removed from Debian: > > > > > > > > > * It's full of bugs (+ i18n's patch bugs) > > > * Uses GTK1 (this misleads developers, packagers and distros to > > > think that dillo is still a GTK1-based project). > > > * When people hear about dillo, or find our website, they try a simple > > > 'apt-get dillo' and get the wrong picture. Then they find out it > > > haven't had patches in years <-> dead project. Who would like to > > > put his effort into that project? > > > * It states that is not the official dillo and that dillo.org developers > > > should not be bothered with its bugs (my request at the time), but > > > this chains the question: why did the trusty Debian maintainers chose > > > the unnoficial version? There must be problems with the official on > > > * Dillo1 has been unmaintained for years. > > > > > > Then I'd be even happier if we can get dillo/fltk-1.3 into Debian, > > > in the short term. > > > > > > I guess it's easier by first removing dillo1 and then pushing dillo2, > > > but don't know about Debian policies. > > > > > > I'd answer Jari along the above lines, CC'ing dillo-dev. > > > > > > What do you guys think? > > > > I fully agree > > *agrees* -- Cheers Jorge.-

April 20, 2010

make instant meta-refresh optional?

by jcid＠dillo.org

On Fri, Apr 16, 2010 at 12:24:17AM +0000, corvid wrote: > Scott wrote: > > * Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > The problem is that W3C has zero delay redirection as an > > > standard. I think a "follow_zero_redirects" dillorc option is > > > a good solution. > > > > Sounds perfect! > > > > Sorry I didn't include a patch to implement it... I'm not sure > > how the config mechanisms work, and didn't know whether there was > > any chance of getting the change accepted. > > If you take a look at how other prefs are introduced, e.g. > http://hg.dillo.org/dillo/rev/c47ab3201464 > it's not too complicated. > > I would lean toward using a name more like follow_zero_delay_refresh... +1 -- Cheers Jorge.-

April 16, 2010

make instant meta-refresh optional?

by corvid＠lavabit.com

Scott wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > The problem is that W3C has zero delay redirection as an > > standard. I think a "follow_zero_redirects" dillorc option is > > a good solution. > > Sounds perfect! > > Sorry I didn't include a patch to implement it... I'm not sure > how the config mechanisms work, and didn't know whether there was > any chance of getting the change accepted. If you take a look at how other prefs are introduced, e.g. http://hg.dillo.org/dillo/rev/c47ab3201464 it's not too complicated. I would lean toward using a name more like follow_zero_delay_refresh...

April 16, 2010

make instant meta-refresh optional?

by dillo-dev＠toykeeper.net

* Jorge Arellano Cid <jcid(a)dillo.org> wrote: > The problem is that W3C has zero delay redirection as an > standard. I think a "follow_zero_redirects" dillorc option is > a good solution. Sounds perfect! Sorry I didn't include a patch to implement it... I'm not sure how the config mechanisms work, and didn't know whether there was any chance of getting the change accepted. -- Scott

April 16, 2010

make instant meta-refresh optional?

by jcid＠dillo.org

On Wed, Apr 14, 2010 at 07:19:42PM -0600, Scott Scriven wrote: > I was just trying to look up a local place on Google Maps, and > found that the page wouldn't render any more. So I investigated, > and it turns out to be a combination of two problems: > > - Dillo now follows instant meta-refresh commands, instead of > letting the user decide. > > - Google Maps redirects to a 'mobile' version of the site, > which fails to recognize Dillo's user-agent string and > returns WML instead of HTML. (I sent them info about this > bug a few moments ago; hopefully they'll fix it) > > Would it be possible to make that first one optional? Maybe a > config variable or something? I liked the old behavior much > better. The problem is that W3C has zero delay redirection as an standard. I think a "follow_zero_redirects" dillorc option is a good solution. -- Cheers Jorge.-

April 15, 2010