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

Re: Links closed empty due to <a> containing <div>

by Kevin Koster

On Sat, 20 Apr 2024 13:43:12 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Thank you for testing 3.1.0-rc1 and reporting the problems. I will > try to address them in the following days. Thank you for the quick and informative responses. Great to see someone so active with Dillo development again. > If we allow broken pages to be displayed properly, there is no > incentive for them to be fixed. My recommendation is that you contact > the website so they fix it (along with the 92 errors reported by the > HTML validator)[3]. > > [3]:https://validator.w3.org/check?uri=http%3A%2F%2Fmy-addr.com%2F That's a reasonable approach, and I've done that. I'm sure it's hard enough trying to support modern web standards without attempting to support websites that break them as well. I also notice that Dillo 0.8.5 actually has the same objections to those <div> tags as 3.1.0-rc1, so its tollerance for such things has varied over the years.

April 21, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, On Sat, Apr 20, 2024 at 02:00:05PM +1000, Kevin Koster wrote: >This problem was present in 3.0.5 as well as in 3.1.0-rc1. > >URL: http://www.lemis.com/ >CSS: enabled or disabled >Summary: Won't render HTML with comments before <!DOCTYPE>. >Pages on this website aren't rendered, just displayed as source code. >Although they are XHTML, this doesn't appear to be due to this bug: >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036382 >If I save the file as lemis.xhtml and remove the two comment lines >before the <!DOCTYPE> declaration, then it renders when I load it with >file:// or http://, otherwise it doesn't. > >My reading is that comments there are valid for HTML 4 (which is >declared in the page's <!DOCTYPE>) since the standard says: > White space (spaces, newlines, tabs, and comments) may appear before or > after each section. >https://www.w3.org/TR/html401/struct/global.html#h-7.1 Yeah, the current detection mechanism in Dillo for content types is not very good. It searches for the doctype line at the beginning of the document[1] but it doesn't handle comments. [1]:https://github.com/dillo-browser/dillo/blob/v3.1.0-rc1/src/misc.c#L148 We should rely on the Content-Type provided by the server, or at least improve the detection. Best, Rodrigo.

April 20, 2024

Re: scroll_step description

by Rodrigo Arias

Hi, On Sat, Apr 20, 2024 at 01:54:26PM +1000, Kevin Koster wrote: >There's a new "scroll_step" option in the example configuration file for >3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that >this only affects the mouse wheel, but it also changes the distance the >page moves when the arrow keys are pressed and the overlap of >previous page content that's left when you press Page Up/Down. I think >that's a little confusing, especially as the value has changed since >the default behaviour in 3.0.5 (the old value seems to have been about >25). Thanks, I agree. Could you provide a patch? Please consider reviewing the manual on that topic[1], in case some parts need to be clarified too. [1]:https://dillo-browser.github.io/user_help.html#scrolling Best, Rodrigo.

April 20, 2024

Re: <td> width attributes ignored

by Rodrigo Arias

Hi, On Sat, Apr 20, 2024 at 01:49:13PM +1000, Kevin Koster wrote: >Another page rendering issue that's introduced after the 3.0.5 release, >this time affecting my own website. > >URL: http://www.ombertech.com/ >CSS: enabled or disabled >Summary: <td> width attributes ignored. >3.0.5: >Heading table at the top of the page displays correctly scaled with >links in the middle formatted in a horizontal row if they all fit in >1/3rd of the browser window's width. >3.1.0-rc1: >The "width" attributes of the <td> elements are ignored and the links in >the middle are thereby squashed into a vertical row. Further testing >with modified versions of the page shows that this table cell width >problem is only present if the width attribute in the <td> elements is a >percentage and the <table> element also has a width attribute set as a >percentage, then the <td> width attributes get ignored. If either (or >both) table or td width is in pixels, the problem isn't present, only >when table and td width are both specified as percentages. > >So far as I can tell setting width in <table> and <td> elements as a >percentage is valid for HTML 4.01 Transitional, and other browsers >(Links, Firefox) render the table correctly. Thanks. This is caused by commit f5a0b6[1], which should be already solved[2]. Reverting it fixes this specific problem, I'll add some regression tests and see if it doesn't break anything else. [1]:https://github.com/dillo-browser/dillo/commit/f5a0b6030c2001e5a0fcacf813… [2]:https://github.com/dillo-browser/dillo/commit/b0f6a3f055039c5c9c3ab65102… Best, Rodrigo.

April 20, 2024

Re: Links closed empty due to <a> containing <div>

by Rodrigo Arias

Hi Kevin, On Sat, Apr 20, 2024 at 01:45:24PM +1000, Kevin Koster wrote: >I use Dillo 3.0.5 (with SNI support added to the HTTPS plug-in) for the >majority of my web browsing, so it's great to see some movement towards >the next version. Testing 3.1.0-rc1 I still notice some HTML rendering >regressions and other bugs which I'll report in this and the following >emails. Thank you for testing 3.1.0-rc1 and reporting the problems. I will try to address them in the following days. >I don't see any of these the GitHub Issues section, but I won't post >them there because I hate the GitHub website - it doesn't work in my >favourite web browser for one thing! Other people are welcome to, though >I'll only participate in discussion here. It is fine. I also don't like the GitHub website and I'm looking to switch to something more convenient with multi-platform CI. >URL: http://my-addr.com/ >CSS: enabled or disabled >Summary: Links closed empty due to <a> containing <div>. >3.0.5: >All links on page are usable and <a> elements don't have errors listed >in the bug window. >3.1.0-rc1: >Links below the horizontal heading bar at the top of the page aren't >usable, they're just shown as plain text. The Bug window shows all of >these <a> elements are closed when a <div> element is found inside them, >leaving no text present inside the link. I see that <div> isn't allowed >inside <a> according to the standard, but other browsers (Links and >Firefox) still render this website's links in a functional way and it's >a pretty inconvenient breakage. That page declares compliance with HTML 4.01 Transitional but then proceeds to not follow it. In HTML 4.01, anchors cannot contain div elements[1] so Dillo closes the anchor[2]. In HTML 5 they are allowed, so those anchors would work properly. [1]:https://www.w3.org/TR/REC-html40/sgml/loosedtd.html#inline [2]:https://github.com/dillo-browser/dillo/blob/v3.1.0-rc1/src/html.cc#L3742 We try to stick to the standards rather than implementing a quirks mode like Firefox. If we allow broken pages to be displayed properly, there is no incentive for them to be fixed. My recommendation is that you contact the website so they fix it (along with the 92 errors reported by the HTML validator)[3]. [3]:https://validator.w3.org/check?uri=http%3A%2F%2Fmy-addr.com%2F Best, Rodrigo.

April 20, 2024

Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

This problem was present in 3.0.5 as well as in 3.1.0-rc1. URL: http://www.lemis.com/ CSS: enabled or disabled Summary: Won't render HTML with comments before <!DOCTYPE>. Pages on this website aren't rendered, just displayed as source code. Although they are XHTML, this doesn't appear to be due to this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036382 If I save the file as lemis.xhtml and remove the two comment lines before the <!DOCTYPE> declaration, then it renders when I load it with file:// or http://, otherwise it doesn't. My reading is that comments there are valid for HTML 4 (which is declared in the page's <!DOCTYPE>) since the standard says: White space (spaces, newlines, tabs, and comments) may appear before or after each section. https://www.w3.org/TR/html401/struct/global.html#h-7.1

April 20, 2024

scroll_step description

by Kevin Koster

There's a new "scroll_step" option in the example configuration file for 3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that this only affects the mouse wheel, but it also changes the distance the page moves when the arrow keys are pressed and the overlap of previous page content that's left when you press Page Up/Down. I think that's a little confusing, especially as the value has changed since the default behaviour in 3.0.5 (the old value seems to have been about 25).

April 20, 2024

<td> width attributes ignored

by Kevin Koster

Another page rendering issue that's introduced after the 3.0.5 release, this time affecting my own website. URL: http://www.ombertech.com/ CSS: enabled or disabled Summary: <td> width attributes ignored. 3.0.5: Heading table at the top of the page displays correctly scaled with links in the middle formatted in a horizontal row if they all fit in 1/3rd of the browser window's width. 3.1.0-rc1: The "width" attributes of the <td> elements are ignored and the links in the middle are thereby squashed into a vertical row. Further testing with modified versions of the page shows that this table cell width problem is only present if the width attribute in the <td> elements is a percentage and the <table> element also has a width attribute set as a percentage, then the <td> width attributes get ignored. If either (or both) table or td width is in pixels, the problem isn't present, only when table and td width are both specified as percentages. So far as I can tell setting width in <table> and <td> elements as a percentage is valid for HTML 4.01 Transitional, and other browsers (Links, Firefox) render the table correctly.

April 20, 2024

Links closed empty due to <a> containing <div>

by Kevin Koster

I use Dillo 3.0.5 (with SNI support added to the HTTPS plug-in) for the majority of my web browsing, so it's great to see some movement towards the next version. Testing 3.1.0-rc1 I still notice some HTML rendering regressions and other bugs which I'll report in this and the following emails. I don't see any of these the GitHub Issues section, but I won't post them there because I hate the GitHub website - it doesn't work in my favourite web browser for one thing! Other people are welcome to, though I'll only participate in discussion here. URL: http://my-addr.com/ CSS: enabled or disabled Summary: Links closed empty due to <a> containing <div>. 3.0.5: All links on page are usable and <a> elements don't have errors listed in the bug window. 3.1.0-rc1: Links below the horizontal heading bar at the top of the page aren't usable, they're just shown as plain text. The Bug window shows all of these <a> elements are closed when a <div> element is found inside them, leaving no text present inside the link. I see that <div> isn't allowed inside <a> according to the standard, but other browsers (Links and Firefox) still render this website's links in a functional way and it's a pretty inconvenient breakage.

April 20, 2024

DFKOO Order Purchase

by Brumaco Brasil Ltda

April 16, 2024