- Dillo-dev - lists.mailman3.com

Css_next_token() bug

by Johannes.Hofmann＠gmx.de

Hi, can someone (corvid?) please have a look at attached patch that fixes a bug in Css_next_token() (at least I think so). Consider: <div style="font-family: '\''; background-color: red;">foo bar</div> In firefox the background is red, in current dillo not, because the string '\'' is not parsed properly. As I'm still uncertain whether to go the re2c way (there the problem does not exist), I'd like to have this fixed in the standard version. However as the code is pretty subtle it would be nice if someone could have a look. Cheers, Johannes

March 6, 2009

allow_white_bg and contrast_visited_color

by Johannes.Hofmann＠gmx.de

On Thu, Mar 05, 2009 at 10:39:23PM +0000, corvid wrote: Committed. Thanks, Johannes

March 6, 2009

RFC: Dillo presentation

by furaisanjin＠gmail.com

2009/3/6 corvid <corvid(a)lavabit.com>: > furaisanjin wrote: >> 2009/3/5 Jorge Arellano Cid <jcid(a)dillo.org>: >> > ? ?- Low bandwidth requirement (very important in rural areas) >> >> Is there any plan to limit simultaneous HTTP connections? If the page >> contains lots of pictures, dillo generates simultaneous HTTP >> connections to fetch them and those occupy certain amount of >> bandwidth. > > Speaking of which, it would be nice to use Connection: Keep-Alive as > part of this. I agree. Major browsers support this feature. Regards, furaisanjin

March 6, 2009

allow_white_bg and contrast_visited_color

by Johannes.Hofmann＠gmx.de

On Thu, Mar 05, 2009 at 08:24:42PM +0000, corvid wrote: > Johannes wrote: > > standard_widget_colors: > > > > Not sure about this one. On the one hand I think that CSS support > > broke this. > > On the other hand CSS allows the page author to directly set colors > > of form widgets. > > corvid, can you please have a look? > > I see that non-form inputs get a background color if I put > html->styleEngine->inheritBackgroundColor () > in open_body. I thought I didn't need that for elements that > have a widget -- or is it different when the widget already exists? No, I think the problem is that fltk widgets are not transparent. So even if the parent widget has drawn the background properly, it won't shine through the fltk widgets. > > (and presumably I would just have to add another inheritBackgroundColor > in open_form...) I would rather suggest using styleEnginge::backgroundStyle() for non-transparent widgets. I haven't tested it though. To sum it up, inheritBackgroundColor() should be set if an element does not create a widget and therefore does not draw a background (e.g. <span>). backgroundStyle() can be used for widgets that need to have style->backgroundColor set to something non-NULL. Cheers, Johannes

March 5, 2009

allow_white_bg and contrast_visited_color

by corvid＠lavabit.com

Johannes wrote: > standard_widget_colors: > > Not sure about this one. On the one hand I think that CSS support > broke this. > On the other hand CSS allows the page author to directly set colors > of form widgets. > corvid, can you please have a look? I see that non-form inputs get a background color if I put html->styleEngine->inheritBackgroundColor () in open_body. I thought I didn't need that for elements that have a widget -- or is it different when the widget already exists? (and presumably I would just have to add another inheritBackgroundColor in open_form...)

March 5, 2009

clipping image inputs

by corvid＠lavabit.com

Johannes wrote: > On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > > With > > > > <input type="image" name="name1" src="whatever" > > WIDTH="80" HEIGHT="14" > > alt="name1name1name1name1"> > > <input type="image" name="name2" src="whatever" > > width="9" height="14" > > alt="name2name2name2name2"> > > > > the long alt text doesn't clip. > > It looks like the embed knows that it's 80 pixels wide > > (at least the child widget area stuff in Textblock::drawLine > > seemed to have the right idea), > > but the image thinks it's 188 (in my case). > > Can you please test attached patch? Not sure if it covers all > related cases, but for me it fixes the above example. Seems to be working for me, too. Thanks...

March 5, 2009

allow_white_bg and contrast_visited_color

by Johannes.Hofmann＠gmx.de

Hi, as we seem to have agreed on using CSS for style customization intead of dillorc settings, I'm trying to get rid of these: link_color: visited_color: text_color: bg_color: force_my_colors: The same thing can more or less be expressed with a custom user stylesheet, so I want to remove them. The problem is non-HTML pages (plain). I would propose to simulate <body><pre> in this case and use the corresponding style. allow_white_bg: This can't be expressed with CSS. We could detect a white background in StyleEngine (like we detect font sizes smaller than font_min_size), but what color should we use instead in this case (note that it must be different enough from the text color)? contrast_visited_color: This one is hard. Consider we want to render a visited link. >From StyleEngine we get a background and a text color, but we don't know what the text color would have been if the link would not be visited. So we can't enforce a color that is different from that. Generally (and even more with CSS), background- and text-colors can change arbitrarily within a page. So there is not a background and a text color per page. standard_widget_colors: Not sure about this one. On the one hand I think that CSS support broke this. On the other hand CSS allows the page author to directly set colors of form widgets. corvid, can you please have a look? Cheers, Johannes

March 5, 2009

clipping image inputs

by Johannes.Hofmann＠gmx.de

On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > With > > <input type="image" name="name1" src="whatever" > WIDTH="80" HEIGHT="14" > alt="name1name1name1name1"> > <input type="image" name="name2" src="whatever" > width="9" height="14" > alt="name2name2name2name2"> > > the long alt text doesn't clip. > It looks like the embed knows that it's 80 pixels wide > (at least the child widget area stuff in Textblock::drawLine > seemed to have the right idea), > but the image thinks it's 188 (in my case). Can you please test attached patch? Not sure if it covers all related cases, but for me it fixes the above example. Cheers, Johannes

March 5, 2009

RFC: Dillo presentation

by corvid＠lavabit.com

furaisanjin wrote: > 2009/3/5 Jorge Arellano Cid <jcid(a)dillo.org>: > > ? ?- Low bandwidth requirement (very important in rural areas) > > Is there any plan to limit simultaneous HTTP connections? If the page > contains lots of pictures, dillo generates simultaneous HTTP > connections to fetch them and those occupy certain amount of > bandwidth. Speaking of which, it would be nice to use Connection: Keep-Alive as part of this.

March 5, 2009

clipping image inputs

by Johannes.Hofmann＠gmx.de

On Thu, Mar 05, 2009 at 12:03:48AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > > > With > > > > > > <input type="image" name="name1" src="whatever" > > > WIDTH="80" HEIGHT="14" > > > alt="name1name1name1name1"> > > > <input type="image" name="name2" src="whatever" > > > width="9" height="14" > > > alt="name2name2name2name2"> > > > > > > the long alt text doesn't clip. > > > It looks like the embed knows that it's 80 pixels wide > > > (at least the child widget area stuff in Textblock::drawLine > > > seemed to have the right idea), > > > but the image thinks it's 188 (in my case). > > > > > > > > > PS I have "white-space: nowrap" pretty much working, > > > but I don't know what I'm doing in Textblock very well, > > > so it's definitely not going into this release. > > > > Can you explain the issue your are working on? At least > > > > <div style="white-space: nowrap">foo bar foo bar foo bar</div> > > > > seems to work already (the line is not wrapped). > > First I noticed that the boxes at the bottoms of the pages about > web browser stuff in en.wikipedia weren't wrapping (including > Dillo's page) because they go <..nowrap>...</span> <span..nowrap>...</span> > and it wasn't taking spaceStyle->whiteSpace into account. > Not handling its own wikipedia page well is sort of unfortunate. > > and then I found that if you have a line that goes: > some normal text <span ...nowrap>really really long stretch of nowrap</span>, > it wouldn't break before the span. I see.

March 5, 2009