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

Re: Broken CSS in Hacker News

by Rodrigo Arias

FYI ----- Forwarded message from Hacker News <hn(a)ycombinator.com> ----- Date: Sat, 4 May 2024 13:58:22 -0700 From: Hacker News <hn(a)ycombinator.com> To: Rodrigo Arias <rodarima(a)gmail.com> Subject: Re: Broken CSS in Hacker News Should be fixed now. Thanks! dang On Sat, May 4, 2024 at 4:36 AM Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > I'm adding Hacker News in CC. > > On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex(a)dismail.de wrote: > >Hi Rodrigo, > > > >> >>Sometimes the page text is not entirely wrapped to the browser > >> >>window, resulting in lines extending off screen, which is a pain. > >> > >> What do you mean by "resulting in lines extending off screen"? If you > >> mean the Dillo viewport, that is probably caused by some missing CSS > >> feature, which we should fix too, but shouldn't happen with CSS > >> disabled. > > > >Here is an example: > >https://news.ycombinator.com/item?id=40250573 > > > >Viewing the page in Dillo with CSS turned off, some of the text > >runs off the window and I have to scroll right to see it. With CSS > >turned on, the text is very small and impossible to read on my monitor > >(but now the offending lines fit on the window). > >In Firefox, the text appears correctly and is always wrapped to the > >window regardless of zoom level. > > I see what is going on. > > By default, Dillo doesn't wrap the content of <pre> elements. But, the > following rule in HN CSS should cause it to wrap the text at spaces and > newlines: > > > pre { overflow: auto; padding: 2px; white-space: pre-wrap; > > overflow-wrap:anywhere; } > > But Dillo fails to process the CSS document because it doesn't > understand a previous rule: > > > input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; } > > The 'input[type=\"submit\"]' selector is causing the CSS parser to > ignore the rest of the CSS style sheet. > > I believe this is a bug in HN CSS, as it should be: > > > input[type="submit"] { font-family:Verdana, Geneva, sans-serif; } > > Which works properly, I attached a reproducer. > > I have to check what is going on in the parser, by I suspect the first > \" causes the parser to enter "string mode", and then the second \" is > parsed as a quote inside the string because it is escaped, not as the > closing quote. So everything else in the CSS file is treated as the > content of the string. This should be fixed on HN side. > > We should make the CSS parser more robust to these problems. > > In the meanwhile, you can add this workaround in ~/.dillo/style.css to > make <pre> wrapped by default in all pages: > > > pre { white-space: pre-wrap; } > > Best, > Rodrigo > ----- End forwarded message -----

May 4, 2024

Dillo 3.1.0 released

by Rodrigo Arias

Hi, I'm happy to announce that version 3.1.0 is finally released! https://dillo-browser.github.io/latest.html Thank you all for the patches and tests! Best, Rodrigo.

May 4, 2024

Re: Broken CSS in Hacker News

by a1ex＠dismail.de

> We should make the CSS parser more robust to these problems. > > In the meanwhile, you can add this workaround in ~/.dillo/style.css to > make <pre> wrapped by default in all pages: > > > pre { white-space: pre-wrap; } That does the trick, thanks very much! This has been a frustration for quite a while, and I'm pretty sure I have run into other sites in the past with similar issues. Hopefully never again :) Thanks again, Alex

May 4, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, I reply to this in another thread to keep the topic about the zoom feature. On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex(a)dismail.de wrote: >I have tested your patch and it works pretty well, minus the image >scaling issue you mentioned. Thanks for testing! >One thing I will note however, on a TKL (ten key less) keyboard, there >is no dedicated '+' key, so zooming in doesn't work. On a US layout >for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have >the expected result. I changed the mapping in keys.cc to Ctrl-= and it >works for me, but would vary for other localizations. I choose the Ctrl + / Ctrl - as it is the default in other browsers, but I mostly use Ctrl and the mouse wheel. I haven't been able to figure it out how to make it work yet on Dillo, but maybe that would help you too. In any case, you can adjust the ~/.dillo/keysrc file to you needs[1], no need to change the source code. [1]: https://dillo-browser.github.io/user_help.html#keysrc Best, Rodrigo.

May 4, 2024

Broken CSS in Hacker News

by Rodrigo Arias

Hi, I'm adding Hacker News in CC. On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >> >>Sometimes the page text is not entirely wrapped to the browser >> >>window, resulting in lines extending off screen, which is a pain. >> >> What do you mean by "resulting in lines extending off screen"? If you >> mean the Dillo viewport, that is probably caused by some missing CSS >> feature, which we should fix too, but shouldn't happen with CSS >> disabled. > >Here is an example: >https://news.ycombinator.com/item?id=40250573 > >Viewing the page in Dillo with CSS turned off, some of the text >runs off the window and I have to scroll right to see it. With CSS >turned on, the text is very small and impossible to read on my monitor >(but now the offending lines fit on the window). >In Firefox, the text appears correctly and is always wrapped to the >window regardless of zoom level. I see what is going on. By default, Dillo doesn't wrap the content of <pre> elements. But, the following rule in HN CSS should cause it to wrap the text at spaces and newlines: > pre { overflow: auto; padding: 2px; white-space: pre-wrap; > overflow-wrap:anywhere; } But Dillo fails to process the CSS document because it doesn't understand a previous rule: > input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; } The 'input[type=\"submit\"]' selector is causing the CSS parser to ignore the rest of the CSS style sheet. I believe this is a bug in HN CSS, as it should be: > input[type="submit"] { font-family:Verdana, Geneva, sans-serif; } Which works properly, I attached a reproducer. I have to check what is going on in the parser, by I suspect the first \" causes the parser to enter "string mode", and then the second \" is parsed as a quote inside the string because it is escaped, not as the closing quote. So everything else in the CSS file is treated as the content of the string. This should be fixed on HN side. We should make the CSS parser more robust to these problems. In the meanwhile, you can add this workaround in ~/.dillo/style.css to make <pre> wrapped by default in all pages: > pre { white-space: pre-wrap; } Best, Rodrigo

May 4, 2024

Re: Feature idea: zoom buttons

by a1ex＠dismail.de

Hi Rodrigo, > >>Sometimes the page text is not entirely wrapped to the browser > >>window, resulting in lines extending off screen, which is a pain. > > What do you mean by "resulting in lines extending off screen"? If you > mean the Dillo viewport, that is probably caused by some missing CSS > feature, which we should fix too, but shouldn't happen with CSS > disabled. Here is an example: https://news.ycombinator.com/item?id=40250573 Viewing the page in Dillo with CSS turned off, some of the text runs off the window and I have to scroll right to see it. With CSS turned on, the text is very small and impossible to read on my monitor (but now the offending lines fit on the window). In Firefox, the text appears correctly and is always wrapped to the window regardless of zoom level. > > I think we should implement a zoom control, like on other browsers > with Control + / Control -. Here is an issue on this topic: > > https://github.com/dillo-browser/dillo/issues/21 > > I have a patch that implements it by adding a zoom factor that > changes with Ctrl + and Ctrl -, but it doesn't work well in some > cases. Notice that the font_factor is not the same as "zooming" all > elements. I have tested your patch and it works pretty well, minus the image scaling issue you mentioned. One thing I will note however, on a TKL (ten key less) keyboard, there is no dedicated '+' key, so zooming in doesn't work. On a US layout for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have the expected result. I changed the mapping in keys.cc to Ctrl-= and it works for me, but would vary for other localizations. Regards, Alex

May 4, 2024

Re: "Layout::resizeIdle calls" messages ignore show_msg=NO

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Fri, May 03, 2024 at 12:48:54PM +1000, Kevin Koster wrote: >>Layout::resizeIdle calls = 582 >>Layout::resizeIdle calls = 583 >>... >> >>I see that they come from a printf call in dw/layout.cc, line 876. >> >>Dillo 3.0.5 doesn't output such messages, and they are a minor >>inconvenience when starting dillo from a terminal window, so it would >>be nice if they obeyed the show_msg setting in dillorc when Dillo 3.1.0 >>is released. > > Yeah, there is no way to properly output messages from the dw module > (the layout renderer), as it doesn't link with the code that parses the > preferences, so it cannot access the "prefs.show_msg" variable to find > out if it should output messages or not. > > I will disable it for now by using _MSG() instead, and we can think of > something more elaborate later. Sounds good. The messages look like they'd mainly be useful to someone looking to to tweak the code and rebuild anyway.

May 4, 2024

Re: "Layout::resizeIdle calls" messages ignore show_msg=NO

by Rodrigo Arias

Hi, On Fri, May 03, 2024 at 12:48:54PM +1000, Kevin Koster wrote: >With Dillo 3.1.0-rc1 (and the current Git repo master branch), these >messages are printed to stdout when pages load even with show_msg=NO in >dillorc: >... >Layout::resizeIdle calls = 578 >Layout::resizeIdle calls = 579 >Layout::resizeIdle calls = 580 >Layout::resizeIdle calls = 581 >Layout::resizeIdle calls = 582 >Layout::resizeIdle calls = 583 >... > >I see that they come from a printf call in dw/layout.cc, line 876. > >Dillo 3.0.5 doesn't output such messages, and they are a minor >inconvenience when starting dillo from a terminal window, so it would >be nice if they obeyed the show_msg setting in dillorc when Dillo 3.1.0 >is released. Yeah, there is no way to properly output messages from the dw module (the layout renderer), as it doesn't link with the code that parses the preferences, so it cannot access the "prefs.show_msg" variable to find out if it should output messages or not. I will disable it for now by using _MSG() instead, and we can think of something more elaborate later. Thanks, Rodrigo.

May 3, 2024

"Layout::resizeIdle calls" messages ignore show_msg=NO

by Kevin Koster

With Dillo 3.1.0-rc1 (and the current Git repo master branch), these messages are printed to stdout when pages load even with show_msg=NO in dillorc: ... Layout::resizeIdle calls = 578 Layout::resizeIdle calls = 579 Layout::resizeIdle calls = 580 Layout::resizeIdle calls = 581 Layout::resizeIdle calls = 582 Layout::resizeIdle calls = 583 ... I see that they come from a printf call in dw/layout.cc, line 876. Dillo 3.0.5 doesn't output such messages, and they are a minor inconvenience when starting dillo from a terminal window, so it would be nice if they obeyed the show_msg setting in dillorc when Dillo 3.1.0 is released.

May 3, 2024

Re: [PATCH] User defined new tab page

by Rodrigo Arias

On Thu, Apr 11, 2024 at 05:36:07PM +0200, a1ex(a)dismail.de wrote: > >> We may leave the value "about:blank" by default (and forbid ""), but >> then, when opening a new tab, if the new_tab_url matches >> "about:blank", we set it to NULL to leave the location empty, which >> follows the current behavior. Maybe, something like this? >> >> + if (!url && strcmp(URL_STR(prefs.new_tab_page), "about:blank") != >> 0) >> + url = prefs.new_tab_page; > >That does seem like the most elegant solution for now. Thanks! Related PR: https://github.com/dillo-browser/dillo/pull/147 Rodrigo.

May 2, 2024