- Dillo-dev - lists.mailman3.com

Over run 'submit' button

by nick＠linicks.net

OK, please ignore this - it was my crappy HTML that produced the issue - Dillo was right, of course. Nick On 10/04/16 18:29, Nick Warne wrote: > Can anybody here tell me why Dillo renders the 'Go' button full form > width on my page here: > > https://linicks.net/cdn1/ > > (forget the iFrame and other stuff). > > It renders nice and small in other browsers [ Go ], but no matter what I > try, the 'Go' button runs the full distance: > [Go ]. > > Dillo reports no errors on the source. > > Thanks, > > Nick > -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 11, 2016

Cached pages

by nick＠linicks.net

Hi Jorge, On 11/04/16 16:23, Jorge Arellano Cid wrote: >> Now, if if you use the same words on the index page, dillo doesn't run the >> CGI, but produces the previous cached page - sure, a reload works, but that >> doesn't seem logical. > > Logic depends upon the considered facts. > > >> Firefox doesn't do this, it runs the CGI each time, which is what I would >> expect on something that produces dynamic content. > > Cache policy is not trivial (e.g. check idempotency in HTTP). > > For instance, if you decide to try to reload whenever it may > seem useful, you start having problems when users go offline > (i.e. intermitent internet connections). BTW, that's how we got > "offline mode"; Good&Simple right? Hmmm, no. Unfortunately it was > nearly impossible to teach the proverbial grandma when to go > offline and when online. Power users started to complain they > were not able to go back and forward fast on already visited > pages, and that pages dissappeared. Why, the browser issued a > reload every time, cleaning the cache, and guess what, websites > used the opportunity to refresh advertisement. > > At some point there were cache directives served in HTTP, but > they got abused by advertising again (i.e. always reload means > more money). And some sites decided to serve their pages with > always reload directives, even some decided to issue automatic > reloads after a certain a mount of time (more clicks/visits on > the stats, more money for payed advertisingt, etc...). > > One of the reasons why people love to have many open tabs is > that since the reload mess inception (and some other stuff as > custom navigation), it became hard to tell whether you'll be able > to see the same page again by going back and forward. So tabs are > a solution to the new problem. > > As you may see from this short sample, a cache policy must > consider lots of cases. First, I wasn't complaining, just curious (as 10CC sang, I don't like Dillo, I love it!) - and as I was debuggng a perl script, in normal use this wouldn't be an issue as the same input will always produce the same output, so a cached page is always correct. Many thanks for a very detailed explanation of the way this issue got into a mess - I am sure you are the best person to steer Dillo away from it. Regards, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 11, 2016

Cached pages

by jcid＠dillo.org

On Mon, Apr 04, 2016 at 05:16:54PM +0100, Nick Warne wrote: > Hi Jorge, > > On 04/04/16 13:00, Jorge Arellano Cid wrote: > >>Usually shift+[refresh] drops the cache and gets the new page, but the only > >>way I get get dillo to do this is exit, and restart (no big deal with a 0.02 > >>second start-up time :) ) > >> > >>Ideas? > > > > Strange, I just tested this trivial cgi script and a simple reload > >does the trick (button press or Ctrl-r). Does it work for you? > > OK, basically on the html page with the form you enter some letters/words... > hit submit (or 'process' in my case) and the perl CGI produces the results > and the time taken. > > Now, if if you use the same words on the index page, dillo doesn't run the > CGI, but produces the previous cached page - sure, a reload works, but that > doesn't seem logical. Logic depends upon the considered facts. > Firefox doesn't do this, it runs the CGI each time, which is what I would > expect on something that produces dynamic content. Cache policy is not trivial (e.g. check idempotency in HTTP). For instance, if you decide to try to reload whenever it may seem useful, you start having problems when users go offline (i.e. intermitent internet connections). BTW, that's how we got "offline mode"; Good&Simple right? Hmmm, no. Unfortunately it was nearly impossible to teach the proverbial grandma when to go offline and when online. Power users started to complain they were not able to go back and forward fast on already visited pages, and that pages dissappeared. Why, the browser issued a reload every time, cleaning the cache, and guess what, websites used the opportunity to refresh advertisement. At some point there were cache directives served in HTTP, but they got abused by advertising again (i.e. always reload means more money). And some sites decided to serve their pages with always reload directives, even some decided to issue automatic reloads after a certain a mount of time (more clicks/visits on the stats, more money for payed advertisingt, etc...). One of the reasons why people love to have many open tabs is that since the reload mess inception (and some other stuff as custom navigation), it became hard to tell whether you'll be able to see the same page again by going back and forward. So tabs are a solution to the new problem. As you may see from this short sample, a cache policy must consider lots of cases. -- Cheers Jorge.-

April 11, 2016

Cached pages

by jcid＠dillo.org

On Mon, Apr 04, 2016 at 08:09:22PM +0300, John Found wrote: > I am not sure its the same problem, but I have problems with the CSS files. > When some page loads CSS files and I press "Refresh" (or Ctrl+R), Dillo reloads > only the content, but not the linked CSS files. This way, when I try to design > some page to be compatible with Dillo, I have to restart it on every test. > > Other browsers sometimes have the same problem, but they have a way to refresh > with cache clearing - Ctrl+F5 in Firefox. Dillo seems to not have such mode. Yes dillo does not have such mode yet. It would be useful to have it though. -- Cheers Jorge.-

April 11, 2016

Over run 'submit' button

by nick＠linicks.net

Can anybody here tell me why Dillo renders the 'Go' button full form width on my page here: https://linicks.net/cdn1/ (forget the iFrame and other stuff). It renders nice and small in other browsers [ Go ], but no matter what I try, the 'Go' button runs the full distance: [Go ]. Dillo reports no errors on the source. Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 10, 2016

URL searches in dillorc

by nick＠linicks.net

Google can now be updated to (I expect you all know): search_url="Google (https) https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=%s" And maybe add 'onelook', a search engine of all dictionaries: search_url="ol Onelook dictionaries http://www.onelook.com/?w=%s" Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 10, 2016

px in HTML

by nick＠linicks.net

On 10/04/16 16:21, Sebastian Geerken wrote: > On So, Apr 10, 2016, Nick Warne wrote: >> I have noticed that Dillo doesn't render px properly - this snippet: >> >> <hr width=500px align=left> >> >> just produces: >> >> . >> >> Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? > > The HTML width attribute (which is depricated, btw) does not support > "px", instead, <hr width=500 ...> would be correct. Yes, thanks, I just sussed that out. Dillo is great for debugging HTML, as most browsers somehow parse crappy input into what seems right (but is wrong!). width=475 works great now. Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 10, 2016

px in HTML

by sgeerken＠dillo.org

On So, Apr 10, 2016, Nick Warne wrote: > I have noticed that Dillo doesn't render px properly - this snippet: > > <hr width=500px align=left> > > just produces: > > . > > Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? The HTML width attribute (which is depricated, btw) does not support "px", instead, <hr width=500 ...> would be correct. Sebastian

April 10, 2016

px in HTML

by nick＠linicks.net

I have noticed that Dillo doesn't render px properly - this snippet: <hr width=500px align=left> just produces: . Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? BTW, great bit of kit - so fast... Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

April 10, 2016

abort on read failure

by eocene＠gmx.com

On Sat, Apr 09, 2016 at 10:18:33PM -0300, Jorge Arellano Cid wrote: > Do you mean the problem of "unresponsive links" doesn't happen > anymore on "solid" environments? I don't think it would have any effect on his problem, if I understand it correctly.

April 10, 2016