- Dillo-dev - lists.mailman3.com

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Thu, Feb 19, 2009 at 03:32:54PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > > > Johannes wrote: > > > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > > > I tried > > > > > font-size: .6in > > > > > (we still love archaic measurements here) > > > > > and it didn't work. > > > > > > > > > > The grammar says > > > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > > > float... > > > > > > Attached. > > > Looks good to me so far. The only thing I'm wooried about is the > > hack where Css_parse_simple_selector() checks for CSS_TK_FLOAT and > > interprets them as class selectors. > > After looking at the CSS syntax I think this is not necessary, as > > class names must not start with numbers. > > Can you please have look at the spec too, to confirm this? > > In that case we could just remove the hack in > > Css_parse_simple_selector(). > > I did happen to see: > In CSS1, a class name could start with a digit (".55ft"), unless > it was a dimension (".55in"). In CSS2, such classes are parsed as > unknown dimensions (to allow for future additions of new units). > To make ".55ft" a valid class, CSS2 requires the first digit to be > escaped (".\35 5ft") Ah ok. That explains the current implementation. For CSS 2.1 must not support class selectors like '.1'. http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/by-section.htm has some nice test cases on this subject. I also noticed, that we need to discard the whole ruleset in case of an invalid selector. Cheers, Johannes PS: I haven't looked at escaped chars at all yet. There seems to be some code for it in cssparser.cc.

Feb. 19, 2009

Re: css parsing numbers

by corvid＠lavabit.com

Johannes wrote: > On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > > Johannes wrote: > > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > > I tried > > > > font-size: .6in > > > > (we still love archaic measurements here) > > > > and it didn't work. > > > > > > > > The grammar says > > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > > float... > > > > Attached. > Looks good to me so far. The only thing I'm wooried about is the > hack where Css_parse_simple_selector() checks for CSS_TK_FLOAT and > interprets them as class selectors. > After looking at the CSS syntax I think this is not necessary, as > class names must not start with numbers. > Can you please have look at the spec too, to confirm this? > In that case we could just remove the hack in > Css_parse_simple_selector(). I did happen to see: In CSS1, a class name could start with a digit (".55ft"), unless it was a dimension (".55in"). In CSS2, such classes are parsed as unknown dimensions (to allow for future additions of new units). To make ".55ft" a valid class, CSS2 requires the first digit to be escaped (".\35 5ft")

Feb. 19, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > I tried > > > font-size: .6in > > > (we still love archaic measurements here) > > > and it didn't work. > > > > > > The grammar says > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > float... > > Attached. > > I'm too much of a css newbie to promise great testing, but I did cobble together > the following and the right things seemed to happen: > > <html> > <head> > <style type="text/css"> > hr.aaaaa {width: 1.5in} > bbbbb {width: 2 in} > </style> > </head> > <body> > <hr style="width: 0.3in"> > <hr style="width: .6in"> > <hr style="width: 1 in"> > <hr class="aaaaa"> > <hr class="bbbbb"> > </body > </html> Looks good to me so far. The only thing I'm wooried about is the hack where Css_parse_simple_selector() checks for CSS_TK_FLOAT and interprets them as class selectors. After looking at the CSS syntax I think this is not necessary, as class names must not start with numbers. Can you please have look at the spec too, to confirm this? In that case we could just remove the hack in Css_parse_simple_selector(). Cheers, Johannes

Feb. 19, 2009

Re: css parsing numbers

by corvid＠lavabit.com

Johannes wrote: > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > I tried > > font-size: .6in > > (we still love archaic measurements here) > > and it didn't work. > > > > The grammar says > > num [0-9]+|[0-9]*"."[0-9]+ > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > float... Attached. I'm too much of a css newbie to promise great testing, but I did cobble together the following and the right things seemed to happen: <html> <head> <style type="text/css"> hr.aaaaa {width: 1.5in} bbbbb {width: 2 in} </style> </head> <body> <hr style="width: 0.3in"> <hr style="width: .6in"> <hr style="width: 1 in"> <hr class="aaaaa"> <hr class="bbbbb"> </body </html>

Feb. 19, 2009

Leaking image structures

by onepoint＠starurchin.org

On Wed, Feb 18, 2009 at 05:06:16PM +0100, Hofmann Johannes wrote: > Yes. Updated patch attached. OK, I'm running with this patch. Since I don't have reproducible test cases I can't say right away whether it works. Keep an eye on my valgrind log page (it updates every night). http://starurchin.org/dillo/valgrind.html BTW, it seems that the CSS leaks stopped about three days ago. Yay! Regards, Jeremy Henty

Feb. 18, 2009

Leaking image structures

by Johannes.Hofmann＠gmx.de

On Wed, Feb 18, 2009 at 09:13:57AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Feb 18, 2009 at 08:26:52AM +0000, corvid wrote: > > > > On Wed, Feb 18, 2009 at 12:40:57AM +0000, corvid wrote: > > > > > > Can you please try attached patch with valgrind and image loading on > > > > > > and off. > > > > > > > > > > Is this a proposed patch for the tree or an experiment in leak-finding? > > > > > > > > For the tree, if it proofs to fix the leaks and doesn't cause > > > > others. > > > > > > If we always add Image, the code that loads images manually will think > > > it hasn't been loaded yet. > > > > > > > Ah ok. I guess I misunderstood Html_add_new_linkimage() completely. > > Please check the updated patch. > > > > Thanks, > > Johannes > > > > PS: The point of the patch is to actually do reference counting: > > Whenever we create a new reference (pointer) to an image, we call > > a_Image_ref(), when such a pointer is deleted we call > > a_Image_unref(). > > If I see it correctly, the permanent pointers to Image > > structures are in html->images and in the DilloWeb structure. > > It's bedtime now, so I haven't looked at this carefully yet, > but you might need an unref in DilloHtml::loadImages() then. Yes. Updated patch attached.

Feb. 18, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Wed, Feb 18, 2009 at 02:44:15PM +0100, Joerg Sonnenberger wrote: > On Wed, Feb 18, 2009 at 10:49:36AM +0000, Jeremy Henty wrote: > > > > BTW: the autoconf documentation frowns on this sort of thing, > > This only applies for checking things in the host filesystem. Yes, I realised after posting that since the code I am adding is intended to reflect the build system, no matter what the host system is, cross-compilation issues just do not arise. > > +#if HG > > + printf("HG current: %s\n", HG_CURRENT); > > + printf("HG qparent: %s\n", HG_QPARENT); > > +#endif > > + > > Any reason why this are two lines? No specific reason, but on general principle I usually write one line per record of information to make it easier to process the results with grep/sed etc. Regards, Jeremy Henty

Feb. 18, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Wed, Feb 18, 2009 at 10:49:36AM +0000, Jeremy Henty wrote: > I'm completely convinced that this really adds any safety, but it's > easy enough to do. Revised patch attached. Looks good. > BTW: the autoconf documentation frowns on this sort of thing, from > (autoconf.info)Limitations of Builtins: > > `test' (files) > To enable `configure' scripts to support cross-compilation, > they shouldn't do anything that tests features of the build > system instead of the host system. This only applies for checking things in the host filesystem. E.g. testing for the existance of /etc/passwd would be bad for cross-compilation. > --- a/src/dillo.cc > +++ b/src/dillo.cc > @@ -211,6 +211,11 @@ > int width = D_GEOMETRY_DEFAULT_WIDTH, height = D_GEOMETRY_DEFAULT_HEIGHT; > char **opt_argv; > > +#if HG > + printf("HG current: %s\n", HG_CURRENT); > + printf("HG qparent: %s\n", HG_QPARENT); > +#endif > + Any reason why this are two lines? Joerg

Feb. 18, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Wed, Feb 18, 2009 at 10:49:36AM +0000, Jeremy Henty wrote: > I'm completely convinced that this really adds any safety, D'oh: I meant to write "I'm *not* completely convinced...". Regards, Jeremy Henty

Feb. 18, 2009

Leaking image structures

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 08:39:04PM +0100, Hofmann Johannes wrote: > I guess there is a leak when image loading is off. Not the leaks in my valgrind logs: I always have image loading on. Regards, Jeremy Henty

Feb. 18, 2009