February 2009 - Dillo-dev - lists.mailman3.com

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Jorge wrote: > Now, if we're to put them in CSS, we must provide > well-commented sample stylesheets, and also give some directions > in the FAQ. It should be simple for the user to know how to set > his own stylesheet options without previous CSS knowledge, and > also how to disable the remote CSS when a page doesn't look good. > > It'd be great to specify, for instance, a "reading" stylesheet > (for low contrast and highcontrast) from our website and to let > the user tweak it. Then when he gets to a long page that he wants > to read (not just skim), he could disable remote CSS and use the > one he prefers. Some days ago, I started trying to put together a sample style sheet (attached). I got as far as putting in the things that I would find valuable to know, but I _have_ been exposed to CSS a bit in recent months, so it was hard to see how much would have to be spelled out to an intelligent layman and how much would be obvious from context and insulting to spell out. So I...I got stuck. (Strays from topic a bit: The world is filled with things aimed toward experts and filled with things aimed toward ignorant people who can be kept ignorant and separated from their money, but the intelligent layman does not have his needs met.)

Feb. 16, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > On Sun, Feb 15, 2009 at 11:11:59PM +0000, corvid wrote: > > Jorge wrote: > > > summary: Fixed handling of META's content-type with no MIME type > > > (e.g. only charset). > > > > Is that legal? It doesn't sound legal. > > Verbatim from HTML-4.01 SPEC: > > META: > [...] > content = cdata [CS] > > This attribute specifies a property's value. This specification > does not list legal values for this attribute. Right, MIME types are specified elsewhere and not here in the HTML spec. I imagine this has to do with furaisanjin's "'", and a quick look into the spec suggests that should be getting turned into a "'" if it's an attr. I'll see if I can find what's going on there. PS I was just recently trying to figure out exactly whether quoted attributes can contain '<' or '>', and it's amazing how hard it can be to get a straight answer from the spec sometimes. (I think quite possibly so, but they started talking about CDATA for the content of script and style tags in a way that made the whole thing sort of unclear to me.)

Feb. 16, 2009

ChangeLog link

by jcid＠dillo.org

Hi, Does anybody know how to ask hgweb for the "tip" ChangeLog file? (The current link is set to a specific version). -- Cheers Jorge.-

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Mon, Feb 16, 2009 at 09:48:23AM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 15, 2009 at 07:54:15PM +0100, Hofmann Johannes wrote: > > On Sun, Feb 15, 2009 at 03:57:46PM -0300, Jorge Arellano Cid wrote: > > > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > > > I was just looking at some of the prefs that I > > > > > > > > don't think are doing anything right now, e.g., > > > > > > > > link_color, force_my_colors... > > > > > > > > I could stuff them into buildUserStyle(), but > > > > > > > > I don't know which should prevail in case of > > > > > > > > conflicts. > > > > > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > > > I've been wondering whether it might be reasonable to > > > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > > > a dillo user to be able to deal with a well-commented > > > > > > > > sample style.css instead. > > > > > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > > > just adds confusion. We need to document this properly as you > > > > > > > said. > > > > > > > > > > > > If I have a style.css containing: > > > > > > > > > > > > * {font-size: 30px} > > > > > > > > > > > > and a page containing: > > > > > > > > > > > > regular regular large > > > > > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > > > > > Sorry, I think I don't fully understand the question. > > > > > > > > > > * {font-size: 30px !important} > > > > > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > > > it. What am I missing? > > > > > > > > If I do this, it doesn't use 30px until the first tag it sees. > > > > > > BTW, there's BUG#892 (prefs' bg_color is not working). > > > > Jorge, what do you think about this? Can we go the style.css > > way and remove all dillorc options for stuff that can also be done > > with style.css? > > I'm very happy with the latest patches on font size, it's very > important: > > http://www.useit.com/alertbox/designmistakes.html > > Reading that page is assuring. We're providing the necessary > controls for people expressing their need for them! > > WRT your question, yes, it'd be good to go the CSS way, but > also to keep it simple for a non-CSS-savvy user to set. This is, > maybe font_{min_size, max_size, factor} are well placed in > dillorc. For text background and color, linkcolor, visited > linkcolor they seem to belong in CSS. Exactly. font_{min_size, max_size, factor} can't be expressed in CSS, so they must stay in dillorc. Whatever can be expressed in CSS should be done in style.css. > > Now, if we're to put them in CSS, we must provide > well-commented sample stylesheets, and also give some directions > in the FAQ. It should be simple for the user to know how to set > his own stylesheet options without previous CSS knowledge, and > also how to disable the remote CSS when a page doesn't look good. > > It'd be great to specify, for instance, a "reading" stylesheet > (for low contrast and highcontrast) from our website and to let > the user tweak it. Then when he gets to a long page that he wants > to read (not just skim), he could disable remote CSS and use the > one he prefers. As you say, it's mostly a question of documentation. Cheers, Johannes > > A few days ago I got to read the above link and relized the > actual relevance of this issue. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 16, 2009

META charset without MIME type

by jcid＠dillo.org

On Sun, Feb 15, 2009 at 11:11:59PM +0000, corvid wrote: > Jorge wrote: > > summary: Fixed handling of META's content-type with no MIME type > > (e.g. only charset). > > Is that legal? It doesn't sound legal. Verbatim from HTML-4.01 SPEC: META: [...] content = cdata [CS] This attribute specifies a property's value. This specification does not list legal values for this attribute. -- Cheers Jorge.-

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by jcid＠dillo.org

On Sun, Feb 15, 2009 at 07:54:15PM +0100, Hofmann Johannes wrote: > On Sun, Feb 15, 2009 at 03:57:46PM -0300, Jorge Arellano Cid wrote: > > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > > I was just looking at some of the prefs that I > > > > > > > don't think are doing anything right now, e.g., > > > > > > > link_color, force_my_colors... > > > > > > > I could stuff them into buildUserStyle(), but > > > > > > > I don't know which should prevail in case of > > > > > > > conflicts. > > > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > > I've been wondering whether it might be reasonable to > > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > > a dillo user to be able to deal with a well-commented > > > > > > > sample style.css instead. > > > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > > just adds confusion. We need to document this properly as you > > > > > > said. > > > > > > > > > > If I have a style.css containing: > > > > > > > > > > * {font-size: 30px} > > > > > > > > > > and a page containing: > > > > > > > > > > regular regular large > > > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > > > Sorry, I think I don't fully understand the question. > > > > > > > > * {font-size: 30px !important} > > > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > > it. What am I missing? > > > > > > If I do this, it doesn't use 30px until the first tag it sees. > > > > BTW, there's BUG#892 (prefs' bg_color is not working). > > Jorge, what do you think about this? Can we go the style.css > way and remove all dillorc options for stuff that can also be done > with style.css? I'm very happy with the latest patches on font size, it's very important: http://www.useit.com/alertbox/designmistakes.html Reading that page is assuring. We're providing the necessary controls for people expressing their need for them! WRT your question, yes, it'd be good to go the CSS way, but also to keep it simple for a non-CSS-savvy user to set. This is, maybe font_{min_size, max_size, factor} are well placed in dillorc. For text background and color, linkcolor, visited linkcolor they seem to belong in CSS. Now, if we're to put them in CSS, we must provide well-commented sample stylesheets, and also give some directions in the FAQ. It should be simple for the user to know how to set his own stylesheet options without previous CSS knowledge, and also how to disable the remote CSS when a page doesn't look good. It'd be great to specify, for instance, a "reading" stylesheet (for low contrast and highcontrast) from our website and to let the user tweak it. Then when he gets to a long page that he wants to read (not just skim), he could disable remote CSS and use the one he prefers. A few days ago I got to read the above link and relized the actual relevance of this issue. -- Cheers Jorge.-

Feb. 16, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sun, Feb 15, 2009 at 06:13:27PM +0100, Hofmann Johannes wrote: > Do the dates on the page mean that the CSS related leaks mostly > started with dillo sources from after 2009-02-12? No. I show each error once at the most recent time that it appeared in any log. There is no indication of how long the error has been appearing (although I could add it if it would be useful). All you can infer is that each error was unfixed on the day it was logged (at least in my repository, which I try to keep up to date). Also, statistically, errors near the top of the page are probably fairly commonm, and those near the bottom are probably either fixed or rare. Regards, Jeremy Henty

Feb. 16, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sun, Feb 15, 2009 at 09:17:09AM -0300, Jorge Arellano Cid wrote: > But, I miss the URL to reproduce the BUG. That's what I meant in > the previous email; please excuse me if it wasn't clear. Oh, I see. Unfortunately I don't have that information, the code just parses the output of Valgrind. When an error occurs there is no indication which of the current pages produced it. Worse, valgrind only reports leaks after the program exits. I haven't been able to find a specific example that reproduces any of these problems. I strongly suspect that the errors we are seeing now are non-deterministic and come from race-like conditions between different pages. Every time I run dillo on a single page the valgrind report is clean. Maybe there's some deep valgrind magic that would yield more information, but if so I don't know of it. Any ideas? Regards, Jeremy Henty

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 11:15:34PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote: > > > Johannes wrote: > > > > > > > [paste] > > > > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > > > > > while having set font-size for * in style.css. > > > > > > > > > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > > > > > What is it doing wrong? > > > > > > > > > > > > > > > > I have set these values in dillorc: > > > > > > > > font_min_size=10 > > > > > > > > font_max_size=12 > > > > > > > > > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > > > > > > > > > My style.css looks like this: > > > > > > > > > > > > > > > > * { > > > > > > > > font-family: ProFont !important; > > > > > > > > font-size: 9pt; > > > > > > > > } > > > > > > > > > > > > > > > > body { > > > > > > > > background-color: white !important; > > > > > > > > } > > > > > > > > > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > > > > > selected the specific range in this screenshot: > > > > > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > > > > > > > > > Any ideas on how to fix this? > > > > > > > > > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > > > > > > > > > > > > > That is possible, but setting font_min_size and font_max_size > > > > > > to a higher value (e.g. 50 and 100) does not fix this issue. > > > > > > When having disabled the style.css, the font sizes are the same as > > > > > > before. > > > > > > > > I think this is some sort of weirdness with either ProFont, fltk or > > > > both in combination. > > > > I can't get ProFont working at all. It only shows 1px high lines. > > > > Can you confirm that the font_min_size works properly with > > > > non-bitmap fonts? > > > > Regarding font_max_size I wasn't sure whether we want another option > > > > or should just set a reasonable fixed upper limit. > > > > But now that someone even made a patch for font_max_size it seems a > > > > good idea to have an option... > > > > > > When I quickly tried font_min_size of 30 and > > > nothing about fonts in my style.css, > > > I saw regular-sized fonts as well. > > > (I'd never even heard of ProFont.) > > > > Ah now I see. The check only happened when the font-size was > > _changed_ > > Please try attached patch. > > It appears to work for me. Committed. Thanks, Johannes

Feb. 16, 2009

Repush and scroll position

by Johannes.Hofmann＠gmx.de

On Thu, Feb 12, 2009 at 05:43:08PM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > > position. This is, if you load a page, start scrolling and the > > > > stylesheet arrives after that, it will no longer go back to the > > > > top. > > > > > > > > Please test. > > > > > > Works for me with Slashdot. Very nice! > > > > Yes, works great. > > > > One minor thing, which also happens when going back/forward: > > > > It seems that the page is first drawn with scroll position 0 and then > > immediately scrolled down to the remembered scroll position. > > Any ideas where the first redraw comes from? Maybe we can eliminate > > that? > > I thought that with the implementation of cancelQueueDraw(), > and the respective call from scrollTo() it would work, but I was > wrong. > > The attached patch implements cancelQueueDraw() and adds some > debugging messages that show interesting facts: > > Nav_open_url: new url='dpi:/bm/' > FltkViewBase::cancelQueueDraw() > Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw > FltkViewBase::cancelQueueDraw() > FltkViewBase::cancelQueueDraw() > FltkViewBase::draw > Nav_open_url: new url='http://localhost/htdocs/redraw.html' > FltkViewBase::cancelQueueDraw() > Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw > FltkViewBase::cancelQueueDraw() > FltkViewBase::cancelQueueDraw() > FltkViewBase::draw > FltkViewBase::draw > FltkViewBase::draw > FltkViewBase::draw > > 1.- There's no need for an explicit call to cancelQueueDraw() > from Layout::scrollTo0(). It happens anyway. > 2.- For bookmarks there's just one draw() call. > 3.- For coming back to a scrolled page, there're four calls!!! > 4.- I'm using a test page with no repush(): > > <html><body><img src="image1.png"> > <ul><li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 > <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 > <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 > </ul></body></html> > > This could take some time, so I'm handing it back to you now... It seems that the problem comes from the fact that we scroll to a position that is not valid at the time we do the scrolling (when the page is still empty). In that case Layout::adjustScrollPos() changes the remembered scroll position to 0,0. Only later we scroll to the desired position. This also has to do with how idle functions are handled. Attached patch seems to fix this problem, but I'm not yet proposing it for inclusion, as I don't understand the details. If anyone want's to take a look - please go ahead! Cheers, Johannes

Feb. 16, 2009