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

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

H1's inside A's

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

April 29, 2014