- Dillo-dev - lists.mailman3.com

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > > but I can reproduce it with a simple test page (attached), so this > > > should not take long, hopefully. > > > > Fixed. > > Good. > > Now, this one [1] hogs the CPU between two alternate layouts... > (it also happens without the patch, but in a slighty different way). > > > [1] http://www.bolsadesantiago.com/index.aspx Works now, too; a problem with the "clear" attribute. (Actually rather similar to the previous problem.) Sebastian

May 1, 2014

More problem pages

by onepoint＠starurchin.org

I updated and rebuilt a few minutes ago and though thecode is shaking out nicely there are still some problems. Layout thrashes: http://www.nature.com/nature/journal/v508/n7496_supp/full/508S66a.html CPU thrashes for a long time but eventually calms down: http://www.sciencebasedmedicine.org/microwaves-and-nutrition/ Regards, Jeremy Henty

April 30, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Tue, Apr 29, 2014, Sebastian Geerken wrote: > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > Most seems fixed, at least the CPU hogging. Still much space above, > but I can reproduce it with a simple test page (attached), so this > should not take long, hopefully. Fixed. Sebastian

April 30, 2014

Gamma error in picture scaling

by jcid＠dillo.org

On Wed, Apr 30, 2014 at 10:09:54AM +0200, Sebastian Geerken wrote: > Hi all! > > Visit <http://www.4p8.com/eric.brasseur/gamma.html> (you remember?) > and search for "dillo". Thanks for sharing the link. It produces some good feelings here. Congrats to all the team. :-) PS: FWIW, it made me remember a long long time ago, when Keith Packard let me knew dillo helped them to show in practice that the xserver was not the bottleneck in rendering speed. -- Cheers Jorge.-

April 30, 2014

Gamma error in picture scaling

by sgeerken＠dillo.org

Hi all! Visit <http://www.4p8.com/eric.brasseur/gamma.html> (you remember?) and search for "dillo". Sebastian

April 30, 2014

H1's inside A's

by tautolog＠gmail.com

I see the anchor as an inline element and the header as a block element, and spanning inlines across blocks makes me cringe. However, an anchor has a very important meaning because of its function. Its loss is different than the loss of an em tag, for example. I am in the strict camp, but would overlook breaking a spec in this case. Ben > On Apr 29, 2014, at 4:03 PM, Dennis New <dennisn at dennisn.linuxd.org> wrote: > > From: Dennis New <dennisn at dennisn.linuxd.org> > Newsgroups: gmane.comp.web.dillo.devel > Subject: Re: H1's inside A's > Date: Tue, 29 Apr 2014 19:01:33 -0400 > X-Newsreader: Sylpheed 3.2.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) > >> On 30 Apr 2014 00:34:58 +0200, Sebastian Geerken wrote: >>> On Di, Apr 29, 2014, Johannes Hofmann wrote: >>>> On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: >>>> I know technically the H1 heading tags aren't allowed between >>>> A../A, and Dillo rightfully complains about this: >>>> >>>> "a" is not allowed to contain "h1". -- closing "a" >>>> >>>> But it seems like an innocent tiny mistake. Can't dillo linkify >>>> anyways, in addition to throwing this error? Currently the >>>> link-information is lost and only accessibly if I manually view >>>> the source and copy-paste it. Other browsers (i.e. webkitgtk >>>> based ones) do this, which is quite useful. >>> >>> I agree, that it would be nice to have those links working - while >>> still reporting it as an error. >>> I didn't check yet how complicated it would be to get things working >>> that way. >> >> Would this not collide with rules to implicitely close <a> in HTML >> (not XHTML!)? >> >> Anyway: The attached page behaves the same way in dillo as in Firefox. > > My webkitgtk browser behaves differently -- it doesn't automatically > close the first "nowhere" link, until the next one starts. The DOM tree > looks like: > > http://imgur.com/4OHrNHN > > By the way, I came across this case on a website that wanted to have > the titles to stories as links, and bigger text size, something like: > > <a href="story1"><h1>Story One Title</h1></a> > > And in such cases, dillo won't render the link. The html rule banning > such constructs doesn't seem obvious to me, so I imagine there are many > such cases floating around. H1 kinda is just a <font size="+1"> with a > <br> at the end :P. > > >> OTOH, w3m closes the first, but not the second <a> implicitely. Do >> you have other test cases? >> >> (I haven't looked in detail at the specs, and it may be different in >> HTML 5.) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

April 29, 2014

H1's inside A's

by dennisn＠dennisn.linuxd.org

From: Dennis New <dennisn at dennisn.linuxd.org> Newsgroups: gmane.comp.web.dillo.devel Subject: Re: H1's inside A's Date: Tue, 29 Apr 2014 19:01:33 -0400 X-Newsreader: Sylpheed 3.2.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) On 30 Apr 2014 00:34:58 +0200, Sebastian Geerken wrote: > On Di, Apr 29, 2014, Johannes Hofmann wrote: > > On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: > > > I know technically the H1 heading tags aren't allowed between > > > A../A, and Dillo rightfully complains about this: > > > > > > "a" is not allowed to contain "h1". -- closing "a" > > > > > > But it seems like an innocent tiny mistake. Can't dillo linkify > > > anyways, in addition to throwing this error? Currently the > > > link-information is lost and only accessibly if I manually view > > > the source and copy-paste it. Other browsers (i.e. webkitgtk > > > based ones) do this, which is quite useful. > > > > I agree, that it would be nice to have those links working - while > > still reporting it as an error. > > I didn't check yet how complicated it would be to get things working > > that way. > > Would this not collide with rules to implicitely close <a> in HTML > (not XHTML!)? > > Anyway: The attached page behaves the same way in dillo as in Firefox. My webkitgtk browser behaves differently -- it doesn't automatically close the first "nowhere" link, until the next one starts. The DOM tree looks like: http://imgur.com/4OHrNHN By the way, I came across this case on a website that wanted to have the titles to stories as links, and bigger text size, something like: <a href="story1"><h1>Story One Title</h1></a> And in such cases, dillo won't render the link. The html rule banning such constructs doesn't seem obvious to me, so I imagine there are many such cases floating around. H1 kinda is just a <font size="+1"> with a <br> at the end :P. > OTOH, w3m closes the first, but not the second <a> implicitely. Do > you have other test cases? > > (I haven't looked in detail at the specs, and it may be different in > HTML 5.)

April 29, 2014

H1's inside A's

by sgeerken＠dillo.org

On Di, Apr 29, 2014, Johannes Hofmann wrote: > On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: > > I know technically the H1 heading tags aren't allowed between A../A, > > and Dillo rightfully complains about this: > > > > "a" is not allowed to contain "h1". -- closing "a" > > > > But it seems like an innocent tiny mistake. Can't dillo linkify anyways, > > in addition to throwing this error? Currently the link-information is > > lost and only accessibly if I manually view the source and copy-paste > > it. Other browsers (i.e. webkitgtk based ones) do this, which is quite > > useful. > > I agree, that it would be nice to have those links working - while > still reporting it as an error. > I didn't check yet how complicated it would be to get things working > that way. Would this not collide with rules to implicitely close <a> in HTML (not XHTML!)? Anyway: The attached page behaves the same way in dillo as in Firefox. OTOH, w3m closes the first, but not the second <a> implicitely. Do you have other test cases? (I haven't looked in detail at the specs, and it may be different in HTML 5.) Sebastian

April 29, 2014