January 2015 - Dillo-dev - lists.mailman3.com

what's currently broken in dillo

by sgeerken＠dillo.org

On Sa, Jan 03, 2015, Jorge Arellano Cid wrote: > [...] > One solution I've been thinking about is to customize the > rendering for each user. In general terms, a user goes to a > handful of websites regularly. Those sites are the ones he cares > more about. > > If we for instance remember that for site X, the user prefers > no embedded CSS, that's it. > > This would be stored in a plain text file as a simple line. The > UI interface, under Tools|Customize may offer something like: > > [ ] Remember settings for this page > [ ] Remember settings for this site > > That's it, after a few simple clicks, problem is gone. > > The idea is this to be exceptional, this is, used as an > exception for a few sites as general rendering should solve most > cases. > > FWIW, I'm planning to make a list of these ideas to work on > this year and be of help in this area. First of all, let's see how many problems fall into the "plain bug" category, and so are simple to fix (although it needs work and time). Partly, this kind of customization is already possible by usage of user style sheets; perhaps we could add a (proprietary) extension for selecting specific sites. While we're at this: Attached is a page which renders differently in dillo and Firefox; the latter closes the "em" implicitely, so that the red box is below (not inside) the green one.

Jan. 4, 2015

what's currently broken in dillo

by james.from.wellington＠gmail.com

I'm imagining, but I have no code, writing stream filters to edit websites until I like them. My first proposed victim would be gmail, to make plain html gmail take less vertical real-estate on my width of monitor. This would be fairly un-userproof. On 1/4/15, Jorge Arellano Cid <jcid at dillo.org> wrote: > On Sat, Jan 03, 2015 at 01:13:11AM +0100, Sebastian Geerken wrote: >> On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: >> > It's a bit sad to find time and again that 3.0.4 has better rendering >> > than the new branch. (e.g. [1]) >> >> The new branch is still in development. > > Sure. > > BTW, there're also cases where it renders better than 3.0.4 (e.g. [1]) > > [1] http://www.phoenixcentre.com/bodywork/bodywork3-4chakra.htm > > Personally I'm optimistic, see below. > >> I'm currently working on another page, which shows a similar behaviour >> (table with too wide columns); in my case, the reason is a plain bug >> which will be fixed soon. Hopefully, your case will be similar. >> >> There are some other issues: >> >> 2. What to do with badly designed pages, which are now less readabe >> since dillo supports new CSS attribues? "adjust_min_width" is a >> solution to one of those problems. > > 3.0.4 came to very reasonable rendering by overriding weird directives, > and solving corner cases and contradicting values as Firefox. I'm > proposing to do the same with floats and CSS. > > Somehow even when 3.0.4 decides a layout that's very different from > the originally intended, it is usable (e.g. [1]). Maybe the same > strategy can work here. > > >> 3. It may be that incomplete support (say, floats but no absolute >> positions) may cause some problems. >> >> Anyway, I believe that most reports fall into the first category. > > Yes, incomplete support (an old constant in dillo) has some > problems, but *somehow*, 3.0.4 ended with a rendering logic that > needed no more tweaks or controls. > > Now that we have CSS, floats, and missing absolute positions, > etc. it may become a bit harder. > > One solution I've been thinking about is to customize the > rendering for each user. In general terms, a user goes to a > handful of websites regularly. Those sites are the ones he cares > more about. > > If we for instance remember that for site X, the user prefers > no embedded CSS, that's it. > > This would be stored in a plain text file as a simple line. The > UI interface, under Tools|Customize may offer something like: > > [ ] Remember settings for this page > [ ] Remember settings for this site > > That's it, after a few simple clicks, problem is gone. > > The idea is this to be exceptional, this is, used as an > exception for a few sites as general rendering should solve most > cases. > > FWIW, I'm planning to make a list of these ideas to work on > this year and be of help in this area. > > HTH. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 4, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Sat, Jan 03, 2015 at 01:13:11AM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > The new branch is still in development. Sure. BTW, there're also cases where it renders better than 3.0.4 (e.g. [1]) [1] http://www.phoenixcentre.com/bodywork/bodywork3-4chakra.htm Personally I'm optimistic, see below. > I'm currently working on another page, which shows a similar behaviour > (table with too wide columns); in my case, the reason is a plain bug > which will be fixed soon. Hopefully, your case will be similar. > > There are some other issues: > > 2. What to do with badly designed pages, which are now less readabe > since dillo supports new CSS attribues? "adjust_min_width" is a > solution to one of those problems. 3.0.4 came to very reasonable rendering by overriding weird directives, and solving corner cases and contradicting values as Firefox. I'm proposing to do the same with floats and CSS. Somehow even when 3.0.4 decides a layout that's very different from the originally intended, it is usable (e.g. [1]). Maybe the same strategy can work here. > 3. It may be that incomplete support (say, floats but no absolute > positions) may cause some problems. > > Anyway, I believe that most reports fall into the first category. Yes, incomplete support (an old constant in dillo) has some problems, but *somehow*, 3.0.4 ended with a rendering logic that needed no more tweaks or controls. Now that we have CSS, floats, and missing absolute positions, etc. it may become a bit harder. One solution I've been thinking about is to customize the rendering for each user. In general terms, a user goes to a handful of websites regularly. Those sites are the ones he cares more about. If we for instance remember that for site X, the user prefers no embedded CSS, that's it. This would be stored in a plain text file as a simple line. The UI interface, under Tools|Customize may offer something like: [ ] Remember settings for this page [ ] Remember settings for this site That's it, after a few simple clicks, problem is gone. The idea is this to be exceptional, this is, used as an exception for a few sites as general rendering should solve most cases. FWIW, I'm planning to make a list of these ideas to work on this year and be of help in this area. HTH. -- Cheers Jorge.-

Jan. 3, 2015

should we have a dillo-announce list?

by eocene＠gmx.com

Seems like a release announcements list would be valuable...

Jan. 3, 2015

what's currently broken in dillo

by Johannes.Hofmann＠gmx.de

On Sat, Jan 03, 2015 at 01:13:11AM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > The new branch is still in development. > > I'm currently working on another page, which shows a similar behaviour > (table with too wide columns); in my case, the reason is a plain bug > which will be fixed soon. Hopefully, your case will be similar. > > There are some other issues: > > 2. What to do with badly designed pages, which are now less readabe > since dillo supports new CSS attribues? "adjust_min_width" is a > solution to one of those problems. > > 3. It may be that incomplete support (say, floats but no absolute > positions) may cause some problems. > > Anyway, I believe that most reports fall into the first category. We always had these issues since we started with CSS. Sometimes implementing a feature makes rendering worse instead of better on some pages. But Sebastian's most recent commits improved things a lot again. And you can always add "* {float: none !important}" to your ~/.dillo/style.css Cheers, Johannes

Jan. 3, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > It's a bit sad to find time and again that 3.0.4 has better rendering > than the new branch. (e.g. [1]) The new branch is still in development. I'm currently working on another page, which shows a similar behaviour (table with too wide columns); in my case, the reason is a plain bug which will be fixed soon. Hopefully, your case will be similar. There are some other issues: 2. What to do with badly designed pages, which are now less readabe since dillo supports new CSS attribues? "adjust_min_width" is a solution to one of those problems. 3. It may be that incomplete support (say, floats but no absolute positions) may cause some problems. Anyway, I believe that most reports fall into the first category. Sebastian

Jan. 3, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Fri, Jan 02, 2015 at 07:32:52PM +0000, eocene wrote: > Sebastian wrote: > > Yes, I now see; I assume that you mean this: > > > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > > > I'll look at it. > > Yes, that. Thanks... I'm just using the new setting, and *anything* that helps to have better rendering is welcomed. It's a bit sad to find time and again that 3.0.4 has better rendering than the new branch. (e.g. [1]) OTOH, it looks like if dillo is the one to finally decide how to fit the layout and not the plethora of redundant & weird directives, our postmodern HTML pages have, it'll be much better for everybody. I mean, if the given directives pass our weirdness test, follow them, if not, use our criteria. May be adjustable too. e.g. 1: always follow dillo heuristics 2: when in shallow doubt, follow dillo heuristics 3: only if width exceeds viewport, follow dillo heuristics 4: only if the page is too large/weird, follow dillo heuristics. 5: always follow HTML/CSS/* directives. DISCLAIMER HINT: as stated before. In the long term past, similar schemes ended in just a simple "follow dillo's heuristics unless forced not to". [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes -- Cheers Jorge.-

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > Yes, I now see; I assume that you mean this: > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > I'll look at it. Yes, that. Thanks...

Jan. 2, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, eocene wrote: > Sebastian wrote: > > > > > - on some sites, the ending words of a line are missing. > > > > > > The forecasts on the US national weather service page do this for me. > > > See the Detailed Forecast section. > > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > > demonstrated in the attached test page. Element #b is 1000px wide, but > > its parent, #a, is set to 100%, which refers to the viewport width > > (more or less), which may be less than 1000px. Note also #c, which is > > broken at the viewport width. > > > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > > set to 'YES', the width of #a, and so the srollable area, are adjusted > > (but not the width of #c), so that you can scroll to the right to read > > the rest. > > > > Currently, 'adjust_min_width' is not set by default. Probably, it > > should be set, to avoid such cases. What do you think? > > If it keeps text from being clipped, it sounds good. It is now set by default. > The weather page still breaks for me. Had you been able to reproduce the > problem earlier? I just tried moving dillorc and domainrc without any > effect on it. Yes, I now see; I assume that you mean this: http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png I'll look at it. Sebastian

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > > > > - on some sites, the ending words of a line are missing. > > > > The forecasts on the US national weather service page do this for me. > > See the Detailed Forecast section. > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > demonstrated in the attached test page. Element #b is 1000px wide, but > its parent, #a, is set to 100%, which refers to the viewport width > (more or less), which may be less than 1000px. Note also #c, which is > broken at the viewport width. > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > set to 'YES', the width of #a, and so the srollable area, are adjusted > (but not the width of #c), so that you can scroll to the right to read > the rest. > > Currently, 'adjust_min_width' is not set by default. Probably, it > should be set, to avoid such cases. What do you think? If it keeps text from being clipped, it sounds good. The weather page still breaks for me. Had you been able to reproduce the problem earlier? I just tried moving dillorc and domainrc without any effect on it.

Jan. 2, 2015