November 2009 - Dillo-dev - lists.mailman3.com

[patch]: fix the default <th> style to match <td>

by onepoint＠starurchin.org

I had assumed that the <th> style would be the same as the <td> style but with bold and centering added, so I was surprised to see that it's not. The <td> style has some border styling and padding that the <th> style does not, which seems wrong to me. I'm attaching a patch that brings the <th> style in line with my expectations, plus a test file and before/after screenshots. Please comment! Regards, Jeremy Henty

Nov. 7, 2009

Style sheet question (centering and list-style-type)

by furaisanjin＠gmail.com

2009/11/5 corvid <corvid(a)lavabit.com>: > It should be fixed now. Thank you. Now pages look better. Regards, furaisanjin

Nov. 5, 2009

Style sheet question (centering and list-style-type)

by corvid＠lavabit.com

It should be fixed now.

Nov. 5, 2009

Style sheet question (centering and list-style-type)

by furaisanjin＠gmail.com

Hi all. I'm wondering how this web page will be rendered. <HTML> <HEAD> <style></style> <TITLE>test</TITLE> </HEAD> <BODY> <div id="menu"> <ul> <li><a href="http://xxx.xxx.xxx/1">first second</a> </ul> </div> </BODY> </HTML> Recent dillo splits "first" and "second" words above and the first one is aligned on the left. Regards, furaisanjin

Nov. 4, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/4 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Please try Hg tip and report. OK, now the problem is solved. > ?BTW, are you using some BSD? Yes, I'm using FreeBSD as I reported in compilation problem. Regards, furaisanjin

Nov. 4, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Tue, Nov 03, 2009 at 03:10:31PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > > > Hi. > > > > > > I don't try all pages but at least there are several pages where dillo > > > keeps crashing. One example is > > > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > > > shows something like this. > > > > It doesn't crash here... :P > > > > The were a couple of patches for cleanup_at_close, please > > try from the repository without them (upto 1404:d4a8309dc63c), > > and let us know how it goes. > > I don't see where the tag variable is set to anything at all in tip. > I don't get a crash, but I get gibberish in the page bugs. Right, I made hurried modifications to a good patch and that bug slipped in. -- Cheers Jorge.-

Nov. 4, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Wed, Nov 04, 2009 at 09:04:40PM +0900, furaisanjin wrote: > 2009/11/4 corvid <corvid(a)lavabit.com>: > > I don't see where the tag variable is set to anything at all in tip. > > Agree. > > > I don't get a crash, but I get gibberish in the page bugs. > > That's interesting aspect in Linux, isn't it? How can you access to > memory pointed by none-initialized variable in Linux? Please try Hg tip and report. BTW, are you using some BSD? -- Cheers Jorge.-

Nov. 4, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/4 corvid <corvid(a)lavabit.com>: > I don't see where the tag variable is set to anything at all in tip. Agree. > I don't get a crash, but I get gibberish in the page bugs. That's interesting aspect in Linux, isn't it? How can you access to memory pointed by none-initialized variable in Linux? Regards, furaisanjin

Nov. 4, 2009

PATCH: don't force selection of first element in multi-select input.

by dtikhonov＠yahoo.com

> It looks like that would change the behaviour for size > 1 even if > multiple is not set. I see what you mean, there's a bug in my patch. I did not see that rows == 1 && multi == false in Html_tag_open_select(). I will try to come up with a new one... I need to save the 'multi' somewhere and then be able to check it in Html_tag_close_select(). C++ is not my forte. - Dmitri.

Nov. 4, 2009

PATCH: don't force selection of first element in multi-select input.

by corvid＠lavabit.com

Dmitri wrote: > Hi all, Hi Dmitri > Great job on dillo! :) > Below is a patch that prevents the browser from selecting the first element of a multi-select input. It looks like that would change the behaviour for size > 1 even if multiple is not set. *digs into the spec a little* Technically, section 17.6.1 just says that "If no OPTION element has the selected attribute set, user agent behavior for choosing which option is initially selected is undefined", as opposed to coming out and saying that we don't have to preselect _any_ for the multiple case if we don't want to. Checking good old firefox, let's see... If size is 1 and multiple is not set, one has to be selected in the option menu, of course. If size > 1, it does not force a selection, regardless of whether multiple is set. For some reason, that seems more reasonable to me in the multiple case than in the non-multiple case. But if we want to simply copy firefox here and we know that it doesn't break websites, I'd be all right with that.

Nov. 3, 2009