- Dillo-dev - lists.mailman3.com

Server-side CSS detection?

by rn214＠cam.ac.uk

Dear All, I've just joined this list, so I hope I'm posting this in the right place. I'm a webmaster, and I want to make sure that my site works properly in all browsers including dillo. However, some of the new code (*) in my site relies on CSS properties such as display:none and does not gracefully degrade. If a browser has no CSS support, the newest stuff breaks in a very ugly manner, whereas most of the CSS I've written to date fails gracefully (we don't really care if some text-colour is wrong). So my question is, how can I detect CSS support server-side? I don't need to know precise details of the CSS-support; I just want a simple yes/no. So Netscape 4.6 would be "yes", whereas Dillo 0.8, and links/lynx/w3m/googlebot would be "no". I don't want to do it by user-agent sniffing, and, if at all possible, I don't want to rely on javascript (there are plenty of people who have CSS-capable browsers with JS turned off). I've had no luck from google, so I thought I'd ask here, as you'll know the best way to do this. Thank you for your help, Regards, Richard (*) for example, I display HTML tooltips like this: span.tool { position: relative; cursor: help; } span.tool span.tip { display: none;} span.tool:hover span.tip { display: block; z-index: 100; position: absolute; top: 1.6em; left: 0; width: auto; padding: 6px; border: #F00;} <span class='tool'>this is the link <span class='tip'>Here is some <b>html</b> for the tooltip </span> </span> i.e. the tool.tip is normally hidden by display:none, but is displayed as result of the hover action. If a browser doesn't support the CSS display:none property, that will render in a very ugly way, with the tooltip contents displayed inline. So I want to have a way to fall-back (server-side) to: <span title='this is the tooltip, without html'>this is the link </span> My intention is to do this server-side, using a session-variable after testing whether the client supports CSS. But how?

March 7, 2009

[patch]: typo fix

by Johannes.Hofmann＠gmx.de

On Fri, Mar 06, 2009 at 06:55:16PM +0000, Jeremy Henty wrote: > > Nothing else to say, really. Attached. Committed.

March 6, 2009

Css_next_token() bug

by Johannes.Hofmann＠gmx.de

On Fri, Mar 06, 2009 at 05:57:09PM +0000, corvid wrote: > Johannes wrote: > > 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. > > It seems right to me. Thanks! Committed.

March 6, 2009

[patch]: typo fix

by onepoint＠starurchin.org

Nothing else to say, really. Attached. Regards, Jeremy Henty

March 6, 2009

Css_next_token() bug

by corvid＠lavabit.com

Johannes wrote: > 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. It seems right to me.

March 6, 2009

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