- Dillo-dev - lists.mailman3.com

CSS branch merged!

by corvid＠lavabit.com

Johannes wrote: > turned out that at least the crash I could reproduce on > http://www.wetteronline.de/ was due to the fact that form.cc was not > yet converted to the new style handling. > Can you please retry with current tip? > > @all: please check whether forms look different now. There may > still be things to be added to the user-agent style. <button>s give me ** WARNING **: No background color found! now.

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

Hi Andreas, On Sat, Jan 17, 2009 at 08:52:00PM +0100, Andreas Kemnade wrote: > Hi, > > On Fri, 16 Jan 2009 14:50:43 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > Hi there, > > > > The CSS branch was merged back into main! > > > > It has been stabilized and we can continue working from this > > basis towards our next release. I want to thank all of you > > involved in helping this happen. Having basic CSS support merged > > in, is quite an achievement! > > > nice. But.. > the second page I opened causes dillo to crash. > That was http://www.wetteronline.de/ turned out that at least the crash I could reproduce on http://www.wetteronline.de/ was due to the fact that form.cc was not yet converted to the new style handling. Can you please retry with current tip? @all: please check whether forms look different now. There may still be things to be added to the user-agent style. Cheers, Johannes

Jan. 18, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

Hi all. I created new subject thread since the original one becomes quite long and. I found one difference between dillo-2.0 and dillo-css. there was a_Decode_charset_init calling at Cache_parse_header in cache.c when HTTP server Content-Type was detected but there isn't this in dillo-css. Because if HTTP server Content-Type is same as META content-type, there isn't any chance to call a_Decode_charset_init. This is one reason why the page is drawn properly. I still don't figure out another timing issue yet. Regards, furaisanjin

Jan. 18, 2009

[bug]: hang in Css_parse_declaration()

by onepoint＠starurchin.org

The following HTML makes dillo hang and burn 100% CPU. <html> <body> <span style="{}">a</span> </body> </html> The bug does not appear if the span contains no text, or only whitespace. The stack trace always ends inside Css_parse_declaration(). The line number varies, but seems to be always one of 809, 823 or 963. You can see the same bug online at http://www.nation.co.ke/News/-/1056/515354/-/u1acuw/-/index.html Regards, Jeremy Henty

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > I wonder whether there's a way to specify something like > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > * {font-family: sans !important} > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > the first rule should overrule the second one if it matches. > > > > > > So this should work. > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > it should be sufficient for the example above. > > > > > > > > > > Does it work for you? > > > > > > > > Yes, I tried: > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > * {color: red !important} > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > All red for me. > > > > > > I tried reverting to the official tip, even I don't have anything > > > much except forms code in my tree right now. > > > Still all red. > > > > > > How strange that we would see different behaviour here... > > > I guess I'll have to dive into the code myself... > > > > Please check again with attached patch. > > It's working! > Thanks! Excellent customer service :) It's not the proper solution though. Here's the plan to apply rules according to http://www.w3.org/TR/CSS21/cascade.html#specificity: * For each CssRule compute the specificity according to http://www.w3.org/TR/CSS21/cascade.html#specificity * Store the rules in RuleList sorted by this specificity. * In CssStyleSheet::apply() merge-sort the 4 ruleLists with potentially matching rules and apply them in the order given by their specificity. If anyone feels like implementing it - go ahead :) Cheers, Johannes

Jan. 18, 2009

CSS branch merged!

by furaisanjin＠gmail.com

Sorry, I didn't sent e-mail to mailing list. 2009/1/18 furaisanjin <furaisanjin(a)gmail.com>: > Hi all. > > 2009/1/18 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: >> On Sat, Jan 17, 2009 at 11:51:37PM +0900, furaisanjin wrote: >>> Sorry, I mixed up 2 things. I guess default font is something I >>> specified in ~/.dillo/style.css if dillo can't find any fonts >>> specified in style. It seems that there is some timing issue when the >>> page is loaded. The first time somehow the page is unreadable but if I >>> goto to bookmark page and come back to the page, the page is readable. >> >> Argh, timing issues are bad. Can you please point me to a page where >> this happens? > > It seems that there are lots. I notice that Html_tag_open_meta doesn't > repush when charset is detected anymore. So I modified codes like > this. > > /* Cannot ask cache whether the content type was changed, as > * this code in another bw might have already changed it for us. > */ > if (a_Misc_content_type_cmp(html->content_type, new_content)) { > + a_Nav_repush(html->bw); > + html->stop_parser = true; > html->repush_after_head = true; > } > > This helps. I may not need to keep html->repush_after_head = true but > I'm not sure. I was wrong. This doesn't help all cases. The problem seems that when the page is repushed, somehow decoder_charset isn't called so that charset conversion doesn't happens. >>> Another issue is that if style sheet specified none Japanese font and >>> the font exists on my machine, then of course the page isn't readable >>> at all. This isn't dillo problem but style sheet problem. >> >> Do you have an example? How does firefox handle these pages? > > This (http://furaisanjin.blog.so-net.ne.jp) is one example. Firefox > shows something like this > (http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/firefox.…) > and this is readable. However dillo shows something like this > (http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/dillo.png) > and I can see only dotted squares. > > Style sheet page contains > > #banner h1{ > margin:0; > padding:80px 0 0 14px; > font-size:36px; > font-family: Helvetica; > } > > and Helvetica isn't suitable for Japanese. Regards, furaisanjin

Jan. 18, 2009

Re: A couple of patches

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: > > * snip* > > > > BTW, I have a question. How can a minimal font size be specified? > > Currently I have: > > > > body {font-size: 18px !important} > > > > in style.css, but often pages come with smaller fonts. e.g. > > http://www.linux.org.uk/Portaloo.cs > > > > For me is important because I have a problems reading tiny fonts, > > and my working laptop has a high screen resolution. > > I've just made a change that uses the existing prefs.font_factor > value to scale the base font. If I use 14 instead of 12, it's a lot more readable. (Or is the 12 important for some CSS reason involving picas?)

Jan. 18, 2009

CSS branch merged!

by corvid＠lavabit.com

Johannes wrote: > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > I wonder whether there's a way to specify something like > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > * {font-family: sans !important} > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > the first rule should overrule the second one if it matches. > > > > > So this should work. > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > it should be sufficient for the example above. > > > > > > > > Does it work for you? > > > > > > Yes, I tried: > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > * {color: red !important} > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > All red for me. > > > > I tried reverting to the official tip, even I don't have anything > > much except forms code in my tree right now. > > Still all red. > > > > How strange that we would see different behaviour here... > > I guess I'll have to dive into the code myself... > > Please check again with attached patch. It's working! Thanks! Excellent customer service :)

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > I wonder whether there's a way to specify something like > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > * {font-family: sans !important} > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > the first rule should overrule the second one if it matches. > > > > So this should work. > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > it should be sufficient for the example above. > > > > > > Does it work for you? > > > > Yes, I tried: > > > > code, tt, pre, samp, kbd {color: green !important} > > * {color: red !important} > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > All red for me. > > I tried reverting to the official tip, even I don't have anything > much except forms code in my tree right now. > Still all red. > > How strange that we would see different behaviour here... > I guess I'll have to dive into the code myself... Please check again with attached patch. Cheers, Johannes

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 17, 2009 at 11:54:08PM +0100, Hofmann Johannes wrote: > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > I wonder whether there's a way to specify something like > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > * {font-family: sans !important} > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > the first rule should overrule the second one if it matches. > > > > > So this should work. > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > it should be sufficient for the example above. > > > > > > > > Does it work for you? > > > > > > Yes, I tried: > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > * {color: red !important} > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > All red for me. > > > > I tried reverting to the official tip, even I don't have anything > > much except forms code in my tree right now. > > Still all red. > > > > How strange that we would see different behaviour here... > > Weird... > > > I guess I'll have to dive into the code myself... > > Check CssStyleSheet::apply(). The color:red directive should be in > the anyTable and the color:green thing in > elementTable[docTree->top ()->element], if element is code, tt ... > > Due to the ordering in the inner for-loop, the color:red should be > overridden by color:green for these elements. Wait. Now, that I wrote it, there may be an issue here... Will check that.

Jan. 18, 2009