- Dillo-dev - lists.mailman3.com

Floating objects

by jcid＠dillo.org

Hi there, Well, time to focus on floating objects (at least for me) @Johannes: what's the status and info we have from Sebastian on his prototype so far? I vaguely remember there were some issues with the design, and on whether to try to implement it inside the textblock or elsewhere. -- Cheers Jorge.-

Sept. 19, 2011

Page layout bug: disappears mysteriously when the source is saved locally.

by jcid＠dillo.org

On Mon, Sep 19, 2011 at 10:18:14AM +0200, Diego . wrote: > I have see a similar problem with a page > (http://www.natami.net/knowledge.php) When load from net latout is > bad, but good from dillo cache. > > Please try to load the page, go to another one (bm: for example) and > go back to original page. > > ?do you see diference? Yes, I can reproduce it. This is an old bug present at least in 3.x and 2.x branches. -- Cheers Jorge.-

Sept. 19, 2011

Page layout bug: disappears mysteriously when the source is saved locally.

by jcid＠dillo.org

On Sun, Sep 18, 2011 at 10:59:55PM +0100, Jeremy Henty wrote: > > This page[1] renders badly in Dillo - the text wraps to a width much > wider than the browser window. But when I save the page locally it > renders fine! How is this possible? The only CSS is a small inline > <style>, which rules out the obvious guess of a style sheet failing to > load. Fixing all the relative URLs to absolute ones has no effect. > > I'm mystified. Any ideas? > > Regards, > > Jeremy Henty > > [1] http://thbecker.net/articles/rvalue_references/section_08.html After trying remote, local, and a slow local stream, it doesn't happen here... BTW, beware there's a TABLE width=680 in the page. Also, there're two image references that will not be found when local, (and the alt text used instead). If you want to chase it, please try to reproduce it locally first, then reduce the testcase and mist may get thiner. HTH. -- Cheers Jorge.-

Sept. 19, 2011

Page layout bug: disappears mysteriously when the source is saved locally.

by darkspirit5000＠gmail.com

I have see a similar problem with a page (http://www.natami.net/knowledge.php) When load from net latout is bad, but good from dillo cache. Please try to load the page, go to another one (bm: for example) and go back to original page. ?do you see diference? Diego. 2011/9/18, Jeremy Henty <onepoint at starurchin.org>: > > This page[1] renders badly in Dillo - the text wraps to a width much > wider than the browser window. But when I save the page locally it > renders fine! How is this possible? The only CSS is a small inline > <style>, which rules out the obvious guess of a style sheet failing to > load. Fixing all the relative URLs to absolute ones has no effect. > > I'm mystified. Any ideas? > > Regards, > > Jeremy Henty > > [1] http://thbecker.net/articles/rvalue_references/section_08.html > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 19, 2011

Line breaking bug.

by johannes.hofmann＠gmx.de

Hi Jeremy, On Mon, Sep 19, 2011 at 12:20:49AM +0100, Jeremy Henty wrote: > > In the attached example the first paragraph is only broken before the > last word. The bug depends on the text containing the <pre> element > and on it being inside a <div> inside a <table>. Real live example: > > http://www.devx.com/cplus/10MinuteSolution/34577/0/page/4 I'm working on this. Should be fixed soon. Cheers, Johannes

Sept. 19, 2011

Line breaking bug.

by onepoint＠starurchin.org

In the attached example the first paragraph is only broken before the last word. The bug depends on the text containing the <pre> element and on it being inside a <div> inside a <table>. Real live example: http://www.devx.com/cplus/10MinuteSolution/34577/0/page/4 Regards, Jeremy Henty

Sept. 18, 2011

Page layout bug: disappears mysteriously when the source is saved locally.

by onepoint＠starurchin.org

This page[1] renders badly in Dillo - the text wraps to a width much wider than the browser window. But when I save the page locally it renders fine! How is this possible? The only CSS is a small inline <style>, which rules out the obvious guess of a style sheet failing to load. Fixing all the relative URLs to absolute ones has no effect. I'm mystified. Any ideas? Regards, Jeremy Henty [1] http://thbecker.net/articles/rvalue_references/section_08.html

Sept. 18, 2011

Close dillo with multiple tabs open

by rogutes＠googlemail.com

Benjamin Johnson (2011-09-18 13:33): <...> > Even if you're just viewing static HTML pages, a browser session is > not *itself* a static thing: it is the unique result of a long chain > of user interactions. If you close a text editor, all you lose is a > single file, which is very easy to re-open. If you close a browser, > you lose not only the open pages, but also their history, and for > dynamic pages, the interactions and form posts that generated them > -- in short, the pages' context. And that's much more difficult to > recover, even in the most sophisticated modern browsers. Add the scrolling position to this list, which applies to both, long text files and long HTML pages :) -- -- Rogut?s Sparnuotos

Sept. 18, 2011

Close dillo with multiple tabs open

by obeythepenguin＠gmail.com

On Sun, 18 Sep 2011 13:05:31 -0400, Roger <rogerx.oss at gmail.com> wrote: > You answered this one yourself. The default option for VIM on quit, is > to only > ask if it should quit when the file in the buffer has been modified. > Other > then this, if the file buffer is unmodified, no prompt before quitting is > issued. > > As such, should a browser do the same; only when forms or HTML > composer/editor > has a current editing session, or associated email composition has been > edited, > should a browser ask when to quit? The only thing likely editable > within Dillo > are bookmarks and some forms. > > When you think about it, all data being viewed within the browser is > static to > it's original location. The only information lost is the original > entered URL, > which usually can be found via Google, hence, no information is at > threat of > being lost. I beg to differ; it's no longer 1994, and a good bit of the web -- in fact, I'd dare say most of it -- is no longer static content. In the absence of anything to indicate otherwise, it's better to assume *all* information displayed in a browser could potentially be lost. A couple weeks ago, one of my professors had to take an online exam for certification. Her printer was out, so she had to send it through the department printer. Long story short, somehow the print job got lost in transmission. She'd already closed the browser, and it didn't save her session, so she had to take the entire 4+ hour exam again. Bear in mind, the page she was trying to print -- and subsequently closed out of -- didn't have any HTML forms. Basically it was just an image and some text to say she had successfully completed the exam. Granted, it was *generated* from form data, but it was not itself a "current editing session". Even if you're just viewing static HTML pages, a browser session is not *itself* a static thing: it is the unique result of a long chain of user interactions. If you close a text editor, all you lose is a single file, which is very easy to re-open. If you close a browser, you lose not only the open pages, but also their history, and for dynamic pages, the interactions and form posts that generated them -- in short, the pages' context. And that's much more difficult to recover, even in the most sophisticated modern browsers. In short, the *data* may be static, but the larger browser session is not. Don't confuse the two. ~Benjamin

Sept. 18, 2011

Close dillo with multiple tabs open

by rogerx.oss＠gmail.com

> On Sat, Sep 17, 2011 at 06:00:35PM -0400, Benjamin Johnson wrote: >On Sat, 17 Sep 2011 17:08:52 -0400, Roger <rogerx.oss at gmail.com> wrote: > >> However, how would you like a prompt on your vehicle every time you >> pressed the >> brakes? Do you really want to stop? Or, how about every time you start >> your >> vehicle and you're within an emergency situation and get, "Do you really >> want >> to start your car?" With real world applications, security of preventing >> accidental quitting is application response to users intentions. > >I don't know much about cars, but I do know it's pretty hard to >accidentally start one. And computers are, in terms of physical >interactions, much more difficult to use than most real-world objects (and >less predictable, as well). That's why usability is so tricky to get >right, and why most programs' interfaces tend to follow established >standards and conventions. > >By the way, it's worth noting that vim prompts you to prevent accidental >quitting, BSD vi prompts you to prevent accidental quitting, even freaking >*ed* prompts you to prevent accidental quitting. I find it pretty >annoying sometimes, too, but there have been many times when that prompt >has saved me from far greater frustration. You answered this one yourself. The default option for VIM on quit, is to only ask if it should quit when the file in the buffer has been modified. Other then this, if the file buffer is unmodified, no prompt before quitting is issued. As such, should a browser do the same; only when forms or HTML composer/editor has a current editing session, or associated email composition has been edited, should a browser ask when to quit? The only thing likely editable within Dillo are bookmarks and some forms. When you think about it, all data being viewed within the browser is static to it's original location. The only information lost is the original entered URL, which usually can be found via Google, hence, no information is at threat of being lost. -- Roger http://rogerx.freeshell.org/

Sept. 18, 2011