April 2010 - Dillo-dev - lists.mailman3.com

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

Re: make instant meta-refresh optional?

by dillo-dev＠toykeeper.net

* Dennis Nezic <dennisn(a)dennisn.dyndns.org> wrote: > On Wed, 14 Apr 2010 19:19:42 -0600, Scott Scriven wrote: > > - 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) > I was just about to post about the second point :P. Fixing the first > still wouldn't make the second work? If I disable meta refresh, I can still use the maps site to a limited extent. Or, if I change the user-agent to Mozilla, I can use the HTML version of the mobile interface. Unfortunately, changing the user-agent breaks images.google, because it sends fancy AJAX stuff with no static fallback. And I kinda like to keep Dillo in my user-agent as a way to advertise. > (Why can't dillo read WML?) ... because Dillo is a HTML browser? WML is a totally different language. -- Scott

April 15, 2010

Re: make instant meta-refresh optional?

by dennisn＠dennisn.dyndns.org

On Wed, 14 Apr 2010 19:19:42 -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) I was just about to post about the second point :P. Fixing the first still wouldn't make the second work? (Why can't dillo read WML?)

April 15, 2010