[Seaside] [Q] table elements in loops?

[Julian Fitzell]

Brian Brown wrote:
>> I bet this is related to the other message you posted about image tags 
>> in anchors.
>>
>> The problem seems to be that #tag:do: calls "self close" which closes 
>> the top tag on the stack, no matter what it is.  We used to have a 
>> #close: method that closed everything up to the first tag with the 
>> given name.  Perhaps we need to add that back in?
>>
>> Avi, can you fix this?  I'm not sure whether we're supposed to be 
>> exclusively committing to the MC version now or if you're keeping them 
>> in synch or what - and I haven't built an MC image yet.
>>
> 
> I think it is related as well; I sent Avi a DVS package that 

Ok, I'm sure he'll get to it soon then.  We were both away over the 
weekend and he had meetings all day today...

> demonstrates the issue.. and also, does the HTML spec allow an </img> 

I believe it does not.  When I wrote the template parser for Seaside1 it 
was aware of these rules but I'm not totally sure if the new Seaside2 
parse tree accounts for that... ah... looks like

WAHtmlElement>>shouldPrintCloseTag needs to be changed to include 'img'. 
  Another fix that I'll leave Avi to actually make for the moment :)

Also, related to the addition of #closeTag: again, I see that we still 
have some senders in
WAWikiRenderer>>swikifyPiece:

> tag? I haven't really seen that used before, so I thought it was related 
> to that, but the problem only rears it's ugly head when you are greater 
> that 2 levels deep in rendering components using the 
> WAHtmlRenderer>>imageWithForm:

Yeah, pretty sure the two problems are unrelated.  I'm not actually sure 
  what browsers do if they find a </img> tag but I think they'd just 
ignore it.  The problem is that the "self close" tag is closing the 
image tag instead of the td tag and then you end up out of synch always 
closing the wrong tag each time.

Ooh... I should finally be able to add an option to generate XHTML 
output now that we have a parse tree.  Excellent... gotta add a note to 
do that.

> 
>> Also, Brian, on a side note, you may not be aware, but you should 
>> avoid starting new threads by replying to old ones.  This causes your 
>> mail client to include a References: header and people who use 
>> threaded mail clients see your new message as a reply several levels 
>> deep in the middle of another conversation :)
>>
> 
> No, I wasn't aware of that... I'm using Mac OS X Mail, Kmail, and the 
> Horde/IMP web based mail client... sometimes all three in a day :-) I'll 
> be more careful now though! (btw,  Kmail wins.)

Heh... I've settle on Mozilla Mail because it's the best threading 
client I can find and it has the benefit of running on Windows, Mac, and 
Linux which makes me very happy since I use all 3 fairly regularly :)

Julian


-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)