- vsource request crashes when dpid isn't working. - source is slow to render, seemingly something to do with large tables. - on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider. - on some sites, the ending words of a line are missing. - img alt text not constrained by width/height. - --local : reload turns off URL_SpamSafe, but there it is again upon repush. - "shift+arrows in the url bar is doing nothing instead of selecting the text".
On Wed, Dec 24, 2014 at 09:07:08PM +0000, eocene wrote:
- vsource request crashes when dpid isn't working. - source is slow to render, seemingly something to do with large tables. - on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider. - on some sites, the ending words of a line are missing. - img alt text not constrained by width/height. - --local : reload turns off URL_SpamSafe, but there it is again upon repush. - "shift+arrows in the url bar is doing nothing instead of selecting the text".
Thanks for the bump. I'll pick some of these items to work on and send them to Johannes. BTW, I also have others in mind. @eocene: now that 3.0.4.1 is out, can you merge the branch? -- Cheers Jorge.-
On Wed, 24 Dec 2014 21:07:08 +0000, eocene <eocene at gmx.com> wrote:
- vsource request crashes when dpid isn't working. - source is slow to render, seemingly something to do with large tables. - on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider. - on some sites, the ending words of a line are missing. - img alt text not constrained by width/height. - --local : reload turns off URL_SpamSafe, but there it is again upon repush. - "shift+arrows in the url bar is doing nothing instead of selecting the text".
add the problem of rendering of both the <noscript> and <script> content when both exits. It probably should prefer the <noscript> or leave the prefered mode for a option in the preferences menu higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
On Thu, 25 Dec 2014 17:37:58 +0000, eocene <eocene at gmx.com> wrote:
higuita wrote:
add the problem of rendering of both the <noscript> and <script> content when both exits. It probably should prefer the <noscript> or leave the prefered mode for a option in the preferences menu
Can you give an example of it rendering both?
Look at the food icons in the table: http://dont-starve-game.wikia.com/wiki/Crock_Pot but i was looking a wrong example, i don't see the <script> here, just the <noscript>, making this harder to fix <td> <a href="/wiki/Spicy_Chili" class="image image-thumbnail link-internal" title="Spicy Chili" > <img src="data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw%3D%3D" alt="Spicy Chili" class="lzy lzyPlcHld " style="vertical-align: text-bottom" data-image-key="Spicy_Chili.png" data-image-name="Spicy Chili.png" data-src="http://vignette4.wikia.nocookie.net/dont-starve-game/images/7/76/Spicy_Chili..." width="48" height="48" onload="if(typeof ImgLzy==='object'){ImgLzy.load(this)}" > <noscript> <img src="http://vignette4.wikia.nocookie.net/dont-starve-game/images/7/76/Spicy_Chili..." alt="Spicy Chili" class="" style="vertical-align: text-bottom" data-image-key="Spicy_Chili.png" data-image-name="Spicy Chili.png" width="48" height="48" > </noscript> </a> </td> higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
higuita wrote:
Look at the food icons in the table:
http://dont-starve-game.wikia.com/wiki/Crock_Pot
but i was looking a wrong example, i don't see the <script> here, just the <noscript>, making this harder to fix
<td> <a href="/wiki/Spicy_Chili" class="image image-thumbnail link-internal" title="Spicy Chili" > <img src="data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw%3D%3D" alt="Spicy Chili" class="lzy lzyPlcHld " style="vertical-align: text-bottom" data-image-key="Spicy_Chili.png" data-image-name="Spicy Chili.png" data-src="http://vignette4.wikia.nocookie.net/dont-starve-game/images/7/76/Spicy_Chili..." width="48" height="48" onload="if(typeof ImgLzy==='object'){ImgLzy.load(this)}" > <noscript> <img src="http://vignette4.wikia.nocookie.net/dont-starve-game/images/7/76/Spicy_Chili..." alt="Spicy Chili" class="" style="vertical-align: text-bottom" data-image-key="Spicy_Chili.png" data-image-name="Spicy Chili.png" width="48" height="48" > </noscript> </a> </td>
Yes, it's not clear to me that dillo's doing anything incorrect in that example.
Hi!
Look at the food icons in the table: http://dont-starve-game.wikia.com/wiki/Crock_Pot but i was looking a wrong example, i don't see the <script> here, just the <noscript>, making this harder to fix Yes, it's not clear to me that dillo's doing anything incorrect in that example.
I contacted wikia and they replied with this: Rappy, Dec 27 07:32 AM Hello, Thanks for contacting Wikia. It seems that your browser is also stripping the CSS that should be supplied when JavaScript doesn't load. This CSS file ( http://slot1.images.wikia.nocookie.net/__cb1419252955/common/extensions/wiki... ) should hide the double image issue you are seeing. I will be filing a ticket, based on this, with our engineers to see if enclosing the first image in a <script> tag for these types of browsers is an option. Thanks for bringing this to our attention. Timothy Collins Community Technical Support So should dillo follow this css and we have a bug or is not supported yet? Thanks in advance higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
Hi, On Sat, Dec 27, 2014 at 08:27:41PM +0000, higuita wrote:
Hi!
Look at the food icons in the table: http://dont-starve-game.wikia.com/wiki/Crock_Pot but i was looking a wrong example, i don't see the <script> here, just the <noscript>, making this harder to fix Yes, it's not clear to me that dillo's doing anything incorrect in that example.
I contacted wikia and they replied with this:
Rappy, Dec 27 07:32 AM
Hello,
Thanks for contacting Wikia. It seems that your browser is also stripping the CSS that should be supplied when JavaScript doesn't load. This CSS file ( http://slot1.images.wikia.nocookie.net/__cb1419252955/common/extensions/wiki... ) should hide the double image issue you are seeing.
I will be filing a ticket, based on this, with our engineers to see if enclosing the first image in a <script> tag for these types of browsers is an option. Thanks for bringing this to our attention.
Timothy Collins Community Technical Support
So should dillo follow this css and we have a bug or is not supported yet?
The mentioned stylesheet isn't loaded, as it is referenced from the body, not from the head section which is not allowed. See e.g. http://www.w3schools.com/tags/tag_link.asp Cheers, Johannes
On Sat, Dec 27, 2014 at 09:51:21PM +0100, Johannes Hofmann wrote:
Hi,
On Sat, Dec 27, 2014 at 08:27:41PM +0000, higuita wrote:
Hi!
Look at the food icons in the table: http://dont-starve-game.wikia.com/wiki/Crock_Pot but i was looking a wrong example, i don't see the <script> here, just the <noscript>, making this harder to fix Yes, it's not clear to me that dillo's doing anything incorrect in that example.
I contacted wikia and they replied with this:
Rappy, Dec 27 07:32 AM
Hello,
Thanks for contacting Wikia. It seems that your browser is also stripping the CSS that should be supplied when JavaScript doesn't load. This CSS file ( http://slot1.images.wikia.nocookie.net/__cb1419252955/common/extensions/wiki... ) should hide the double image issue you are seeing.
I will be filing a ticket, based on this, with our engineers to see if enclosing the first image in a <script> tag for these types of browsers is an option. Thanks for bringing this to our attention.
Timothy Collins Community Technical Support
So should dillo follow this css and we have a bug or is not supported yet?
The mentioned stylesheet isn't loaded, as it is referenced from the body, not from the head section which is not allowed. See e.g. http://www.w3schools.com/tags/tag_link.asp
Hm, for some reason firefox with Javascript disabled seems to disagree with me. I'll check how firefox loads ImageLazyLoadNoScript.css. Cheers, Johannes
On Sun, Dec 28, 2014 at 10:22:49AM +0100, Johannes Hofmann wrote:
On Sat, Dec 27, 2014 at 09:51:21PM +0100, Johannes Hofmann wrote:
Hi,
On Sat, Dec 27, 2014 at 08:27:41PM +0000, higuita wrote:
Hi!
Look at the food icons in the table: http://dont-starve-game.wikia.com/wiki/Crock_Pot but i was looking a wrong example, i don't see the <script> here, just the <noscript>, making this harder to fix Yes, it's not clear to me that dillo's doing anything incorrect in that example.
I contacted wikia and they replied with this:
Rappy, Dec 27 07:32 AM
Hello,
Thanks for contacting Wikia. It seems that your browser is also stripping the CSS that should be supplied when JavaScript doesn't load. This CSS file ( http://slot1.images.wikia.nocookie.net/__cb1419252955/common/extensions/wiki... ) should hide the double image issue you are seeing.
I will be filing a ticket, based on this, with our engineers to see if enclosing the first image in a <script> tag for these types of browsers is an option. Thanks for bringing this to our attention.
Timothy Collins Community Technical Support
So should dillo follow this css and we have a bug or is not supported yet?
The mentioned stylesheet isn't loaded, as it is referenced from the body, not from the head section which is not allowed. See e.g. http://www.w3schools.com/tags/tag_link.asp
Hm, for some reason firefox with Javascript disabled seems to disagree with me. I'll check how firefox loads ImageLazyLoadNoScript.css.
Ok, firefox seems to load stylesheets from the body section. See [1] for a discussion whether this is allowed. Attached is a small test case that illustrates how dillo and firefox handle this case differently. Cheers, Johannes [1] http://stackoverflow.com/questions/4957446/load-external-css-file-in-body-ta...
I have missing words on the right, on the attached, which are exercisable only: - with the CSS - with at least one graphic correctly linked I didn't finish walking down a small test-case, because the other thing intervened. Regards, James.
On Mon, Dec 29, 2014, James C. wrote:
I have missing words on the right, on the attached, which are exercisable only: - with the CSS - with at least one graphic correctly linked
I didn't finish walking down a small test-case, because the other thing intervened.
This works now, too. BTW, there were a couple of bugs occurring here. Sebastian
On Sun, Dec 28, 2014 at 02:44:55PM +0100, Sebastian Geerken wrote:
On Wed, Dec 24, 2014, eocene wrote:
- source is slow to render, seemingly something to do with large tables.
Yes, I'm noticing that rendering large tables is much slower than in 3.0.4. I'll work on this. (Probably a side-effect of GROWS.)
There're sites where "too many redraws" penalize rendering speed. See for instance [1] by going back and forward into it from the splash page. Most probably it's not related to large tables, but something lurks in there. [1] http://www.ethericwarriors.com/forum -- Cheers Jorge.-
On Sun, Dec 28, 2014, Sebastian Geerken wrote:
On Wed, Dec 24, 2014, eocene wrote:
- source is slow to render, seemingly something to do with large tables.
Yes, I'm noticing that rendering large tables is much slower than in 3.0.4. I'll work on this. (Probably a side-effect of GROWS.)
It has become much better, although still slower than 3.0.4. Sebastian
On Tue, Jan 06, 2015, Sebastian Geerken wrote:
On Sun, Dec 28, 2014, Sebastian Geerken wrote:
On Wed, Dec 24, 2014, eocene wrote:
- source is slow to render, seemingly something to do with large tables.
Yes, I'm noticing that rendering large tables is much slower than in 3.0.4. I'll work on this. (Probably a side-effect of GROWS.)
It has become much better, although still slower than 3.0.4.
A simple gprof run showed another opportunity for optimization. There should now be no performance problems anymore with tables. Sebastian
On Mi, Dez 24, 2014, eocene wrote:
- on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider. - on some sites, the ending words of a line are missing.
Before digging through the archive: are there examples for both? Sebastian
Sebastian wrote:
On Mi, Dez 24, 2014, eocene wrote:
- on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider.
arstechnica.com does this like 95% of the time (I think deterministically -- like you can catch them at a time when their html is such that it doesn't show the problem, but it normally does.)
- 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
Before digging through the archive: are there examples for both?
On Sun, Dec 28, 2014, eocene wrote:
Sebastian wrote:
On Mi, Dez 24, 2014, eocene wrote:
- on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider.
arstechnica.com does this like 95% of the time (I think deterministically -- like you can catch them at a time when their html is such that it doesn't show the problem, but it normally does.)
This seems fixed now. Sebastian
Sebastian wrote:
On Sun, Dec 28, 2014, eocene wrote:
Sebastian wrote:
On Mi, Dez 24, 2014, eocene wrote:
- on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider.
arstechnica.com does this like 95% of the time (I think deterministically -- like you can catch them at a time when their html is such that it doesn't show the problem, but it normally does.)
This seems fixed now.
Great :)
- 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? Sebastian
On Fri, Jan 02, 2015 at 06:13:38PM +0100, Sebastian Geerken 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?
Speaking from experience gained from having to handle HTML parsing errors, and table apportioning algorithms, with all the contradicting directives, overrides, etc. In the long run, having dillo decide the final values by adding a cleanup stage at some points, has emerged as the choice with better rendering. (e.g. w3c_plus_heuristics=YES, cleanup_at_{open, close}(), contrast_visited_color=YES, ... ;) -- Cheers Jorge.-
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.
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
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...
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.-
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
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
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.-
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
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.
Hi Sebastian, On Sun, Jan 04, 2015 at 02:00:52PM +0100, Sebastian Geerken wrote:
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).
Yes, sure. Now, with some sites it's not clear whether something is a bug, bad HTML, contradicting directives, etc. IMHO, just there, having an easy (i.e. user ready, click-click) way to customize can help a lot. e.g.[1] Here, I don't know what's wrong, but reading the text in those colors clearly hurts. Avoiding embedded CSS "solves" the problem with one click (from a user perspective). I may try coding it a bit and check how it feels. [1] http://www.veteranstoday.com/2015/01/05/hate-conspiracies/
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.
Yes, but this solution requires good knowledge on CSS and HTML and some digging time (as in the example above where we don't know the problem in advance). OTOH, clicking a pair of checkboxes and see whether that helps is much easier. It's a user-level "solution".
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.
It's very good you discovered this point!
From my understanding,
(i) this is incorrect HTML, but
Yes.
(ii) since "div" is not allowed within "em", this could be easily detected, to mimic Firefox behaviour.
Yes.
This page is a simplified version of a real-word page, and in some cases, the implications for the rendering are quite extreme.
Yes. IMO this is a good place to nail some "rendering bugs" (by reacting as FF to bad HTML). AFAIR, the HTML cleanup heuristics were tuned before DIV was supported! I'll work on this now. Please let me know of any other tags you've found in real pages that mess with DIV in this sense while I work on it (for instance EM is in the phrase set which should be treated similarly). It may end helping rendering of a lot of sites or just a few, who knows, but's definitely worth the try. See attached toy-patch for the test case. -- Cheers Jorge.-
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])
[1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes
It is getting better (fixing "plain" bugs). While examining why the images are not shown, I noticed that some element is set at height 0. Test the attached page in dillo and Firefox and notice the difference: Firefox shows the first line, although it has height 0, but draws the second line at the same position as the first, the latter shining through. It is somewhat difficult to imitate this behavour [1]; but two solutions are feasable: (i) ignore height (perhaps via user style sheet); (ii) use 'height' only to make elements larger (somewhat similar to 'adjust_min_width'). In both cases, the two lines would be put on top of each other. Sebastian [1] Complicated cases of overlapping elements are handled in the "dillo_grows" repository, at <http://flpsed.org/hgweb/dillo_grows>.
On Mon, Jan 05, 2015 at 03:59:15PM +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])
[1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes
It is getting better (fixing "plain" bugs). While examining why the images are not shown, I noticed that some element is set at height 0. Test the attached page in dillo and Firefox and notice the difference: Firefox shows the first line, although it has height 0, but draws the second line at the same position as the first, the latter shining through.
It is somewhat difficult to imitate this behavour [1]; but two solutions are feasable: (i) ignore height (perhaps via user style sheet); (ii) use 'height' only to make elements larger (somewhat similar to 'adjust_min_width'). In both cases, the two lines would be put on top of each other.
I like (ii). It falls in the "make dillo decide when directives make no sense" philosophy I'm advocating for.. -- Cheers Jorge.-
On Fri, Jan 02, 2015, 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...
Finally works, although the floats ("Tonight", "Monday" ...) look a bit different from Firefox. Sebastian
Sebastian wrote:
On Fri, Jan 02, 2015, 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...
Finally works, although the floats ("Tonight", "Monday" ...) look a bit different from Firefox.
Thanks :)
participants (6)
-
eocene＠gmx.com -
higuita7＠yahoo.co.uk -
james.from.wellington＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
sgeerken＠dillo.org