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! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Hi all. I just tried this and noticed that I wasn't able to change font by dillorc. It seems that all fonts are decided in css.c - buildUserAgentStyle. Regards, furaisanjin
Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine? For example, when style sheet contains body { font-family: MS Gothic, Osaka, monospace; } but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup. Regards, furaisanjin 2009/1/17 corvid <corvid@lavabit.com>:
furaisanjin wrote:
I just tried this and noticed that I wasn't able to change font by dillorc. It seems that all fonts are decided in css.c - buildUserAgentStyle.
For now you could override them in .dillo/style.css
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote:
Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine?
For example, when style sheet contains
body { font-family: MS Gothic, Osaka, monospace; }
In this case dillo should try the three fonts given. At least "monospace" should exist and be mapped to some default monospace font. This part of the font selection is just not implemented yet.
but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup.
It might be possible to map font names at the X11 level, i.e. in .fonts.conf. But I don't know the details. Regards, Johannes
On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote:
On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote:
Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine?
For example, when style sheet contains
body { font-family: MS Gothic, Osaka, monospace; }
In this case dillo should try the three fonts given. At least "monospace" should exist and be mapped to some default monospace font. This part of the font selection is just not implemented yet.
but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup.
It might be possible to map font names at the X11 level, i.e. in .fonts.conf. But I don't know the details.
BTW, is it possible to force a single font in style.css? this is, even when the page specified font exists in the machine. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Jorge wrote:
On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote:
On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote:
Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine?
For example, when style sheet contains
body { font-family: MS Gothic, Osaka, monospace; }
In this case dillo should try the three fonts given. At least "monospace" should exist and be mapped to some default monospace font. This part of the font selection is just not implemented yet.
but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup.
It might be possible to map font names at the X11 level, i.e. in .fonts.conf. But I don't know the details.
BTW, is it possible to force a single font in style.css? this is, even when the page specified font exists in the machine.
I'm not sure whether it's working for the right reason, but I haven't seen any Courier since I put code, tt, pre, samp, kbd {font-family: mono !important} in mine. BTW, are bold and italic supposed to work?
On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote:
Jorge wrote:
On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote:
On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote:
Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine?
For example, when style sheet contains
body { font-family: MS Gothic, Osaka, monospace; }
In this case dillo should try the three fonts given. At least "monospace" should exist and be mapped to some default monospace font. This part of the font selection is just not implemented yet.
but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup.
It might be possible to map font names at the X11 level, i.e. in .fonts.conf. But I don't know the details.
BTW, is it possible to force a single font in style.css? this is, even when the page specified font exists in the machine.
I'm not sure whether it's working for the right reason, but I haven't seen any Courier since I put code, tt, pre, samp, kbd {font-family: mono !important} in mine.
BTW, are bold and italic supposed to work?
Yes, where are you seeing problems? Cheers, Johannes
On Sat, Jan 17, 2009 at 03:43:30PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote:
BTW, are bold and italic supposed to work?
Yes, where are you seeing problems?
I don't see them at all.
Hm, do you have a user stylesheet set? For me <body> Hello <b>World</b> <i>dillo</i> </body> works ok. Cheers, Johannes
Johannes wrote:
On Sat, Jan 17, 2009 at 03:43:30PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote:
BTW, are bold and italic supposed to work?
Yes, where are you seeing problems?
I don't see them at all.
Hm, do you have a user stylesheet set?
For me
<body> Hello <b>World</b> <i>dillo</i> </body>
works ok.
It was breaking with or without a user stylesheet, but now I have found that adding * {font-family: sans !important} makes them appear properly. My system must not like Helvetica or something... 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.
On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 17, 2009 at 03:43:30PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 17, 2009 at 03:20:45PM +0000, corvid wrote:
BTW, are bold and italic supposed to work?
Yes, where are you seeing problems?
I don't see them at all.
Hm, do you have a user stylesheet set?
For me
<body> Hello <b>World</b> <i>dillo</i> </body>
works ok.
It was breaking with or without a user stylesheet, but now I have found that adding * {font-family: sans !important} makes them appear properly. My system must not like Helvetica or something...
Currently font handling is more or less not existing. Whatever we get from CSS as font-family is passed directly to fltk - even if it is a comma separated list.
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. Cheers, Johannes
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? Also, is <element style="[whatever]"> supposed to work?
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.
Also, is <element style="[whatever]"> supposed to work?
Yes, since today :-)
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...
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. Cheers, Johannes
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.
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
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 :)
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
On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote:
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 :)
Just implemented that. Please test. Cheers, Johannes
On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote:
On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote:
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 :)
Just implemented that. Please test.
I don't know what to test but there're rendering differences with this page: http://www.thefreedictionary.com/unneeded (comparing with 83d840739a0e as tip) HTH. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Sat, Jan 31, 2009 at 06:15:50PM -0300, Jorge Arellano Cid wrote:
On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote:
On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote:
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 :)
Just implemented that. Please test.
I don't know what to test but there're rendering differences with this page:
http://www.thefreedictionary.com/unneeded
(comparing with 83d840739a0e as tip)
HTH.
Well, rendering differences are the point here :) For example on cnn.com you can now read the "Home" white on red background, which was red on red before. Thanks for testing, Johannes
On Sat, Jan 17, 2009 at 09:45:07AM -0300, Jorge Arellano Cid wrote:
On Sat, Jan 17, 2009 at 10:16:31AM +0100, Hofmann Johannes wrote:
On Sat, Jan 17, 2009 at 05:47:19PM +0900, furaisanjin wrote:
Thank you, now I can change my favorite font in much easier way. I have one more question. Is there any way to specify default font if the font specified in style sheet doesn't exist on local machine?
For example, when style sheet contains
body { font-family: MS Gothic, Osaka, monospace; }
In this case dillo should try the three fonts given. At least "monospace" should exist and be mapped to some default monospace font. This part of the font selection is just not implemented yet.
but I don't have none of them but I have VL Gothic. In this case I want to use VL Gothic as backup.
It might be possible to map font names at the X11 level, i.e. in .fonts.conf. But I don't know the details.
BTW, is it possible to force a single font in style.css? this is, even when the page specified font exists in the machine.
* {font-family: helvetica !important} should do that. Cheers, Johannes
Hi, On Fri, 16 Jan 2009 14:50:43 -0300 Jorge Arellano Cid <jcid@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/ (gdb) bt #0 0x080a3a85 in dw::core::Widget::queueResize (this=0x9bc1db0, ref=0, extremesChanged=true) at widget.cc:347 #1 0x080a41c3 in dw::core::Widget::setStyle (this=0x9bc1db0, style=0x9bc26f0) at widget.cc:520 #2 0x08072646 in Html_tag_open_input (html=0x9b45020, tag=0x9b90149 "<INPUT type=\"image\" src=\"/startseite/grafiken/go.gif\" wid th=\"22\" height=\"18\" alt=\"Los gehts\" style=\"font-size: 9pt; face: Arial,He lvetica\" border=\"0\"></td>\n", ' ' <repeats 19 times>, "</tr>\n", ' ' <repeats 19 times>..., tagsize=150) at form.cc:1954 #3 0x0806c403 in Html_write_raw (html=0x9b45020, buf=0x9b8e4c1 "\n<!--\nfunction GrafikPopUp(Grafik)\n{\n bild = new Image( );\n bild.src = Grafik;\n groesse(Grafik);\n}\n\nfunction groesse(Grafik)\n{ \n if ((bild.width != 0) && (bild.height != 0))\n {\n Ausgleich"..., bufsize=21961, Eof=0) at html.cc:3389 #4 0x0806cb4b in DilloHtml::write (this=0x9b45020, Buf=0x9b8dc18 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//E N\">\n<html>\n<head>\n <meta http-equiv=\"content-type\" CONTENT=\"text/html; c harset=iso-8859-1\">\n <meta http-equiv=\"language\" content=\"de\">\n <"..., BufSize=162377984, Eof=0) at html.cc:578 #5 0x0806cbce in Html_callback (Op=0, Client=0x9b449c0) at html.cc:3569 #6 0x0805ce1a in Cache_process_queue (entry=0x9b448e0) at cache.c:1134 #7 0x0805a4dd in a_Chain_fcb (Op=162377984, Info=0x810e648, Data1=0x9b62f00, Data2=0x8106388) at chain.c:112 ---Type <return> to continue, or q <return> to quit--- #8 0x0807d82c in a_Dpi_ccc (Op=2, Branch=2, Dir=<value optimized out>, Info=0x9b4e530, Data1=0x9b63608, Data2=0x0) at dpi.c:219 #9 0x0805a4dd in a_Chain_fcb (Op=162377984, Info=0x810e648, Data1=0x9b63608, Data2=0x0) at chain.c:112 #10 0x0807dfd9 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x9b526b8, Data1=0x9b63a00, Data2=0x0) at IO.c:414 #11 0x0807e1f4 in IO_callback (io=0x9b63a00) at IO.c:201 #12 0x0807e2eb in IO_fd_read_cb (fd=6, data=0x2) at IO.c:287 #13 0x080d585c in fltk::wait () #14 0x080d5a34 in fltk::run () #15 0x0804fa02 in main (argc=2, argv=0xbfbbd40 widget2 seems to be invalid... Greetings Andreas Kemnade
Andreas Kemnade (2009-01-17 20:52):
Hi,
On Fri, 16 Jan 2009 14:50:43 -0300 Jorge Arellano Cid <jcid@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/
CSS support is really nice and it doesn't crash on www.wetteronline.de here. Neither with fltk2 r6403, nor with r6525, nor with default dillorc, nor with mine. I haven't got custom stylesheets... Don't know why it crashes for you, though. -- -- Rogut?s Sparnuotos
On Sat, Jan 17, 2009 at 11:31:32PM +0200, Rogut?s wrote:
Andreas Kemnade (2009-01-17 20:52):
Hi,
On Fri, 16 Jan 2009 14:50:43 -0300 Jorge Arellano Cid <jcid@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/
CSS support is really nice and it doesn't crash on www.wetteronline.de here. Neither with fltk2 r6403, nor with r6525, nor with default dillorc, nor with mine. I haven't got custom stylesheets...
Don't know why it crashes for you, though.
I can reproduce a crash on http://www.wetteronline.de/ when I set special malloc debugging options. It's funny because I check http://www.wetteronline.de/ quite often, but I never saw that crash until now... Cheers, Johannes
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@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
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.
Hi, On Sun, 18 Jan 2009 17:10:54 +0100 Hofmann Johannes <Johannes.Hofmann@gmx.de> wrote:
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@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?
Yes, it works now. Before that fix, starting dillo with valgrind "solved" the problem and shows some invalid reads and writes. Now these invalid reads and writes are gone. Greetings Andreas Kemnade
participants (6)
-
akemnade＠tzi.de -
corvid＠lavabit.com -
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
rogutes＠googlemail.com