<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>Re: [Seaside] Seaside sessions and ajax</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Semantically sound html = easier styling and better accessibility. For instance screen readers place emphasis on h1 and h2 whereas they mostly ignore text styling.<BR>
<BR>
Cheers!<BR>
<BR>
-Boris<BR>
(Sent from a BlackBerry)<BR>
<BR>
----- Original Message -----<BR>
From: seaside-bounces@lists.squeakfoundation.org <seaside-bounces@lists.squeakfoundation.org><BR>
To: 'Seaside - general discussion' <seaside@lists.squeakfoundation.org><BR>
Sent: Thu Dec 06 07:38:13 2007<BR>
Subject: RE: [Seaside] Seaside sessions and ajax<BR>
<BR>
> I don't want a DIV around all my components.<BR>
><BR>
<BR>
Thanks for the reading Lukas. I make some commments on each.<BR>
<BR>
> <A HREF="http://www.whatstyle.net/articles/22/less_div_more_html">http://www.whatstyle.net/articles/22/less_div_more_html</A><BR>
<BR>
Quoting it's stronger argument:<BR>
"It's cleaner, it has less code, and therefore; less clutter and lower<BR>
maintenance."<BR>
<BR>
OK, I say: that is important if you deal with that code as a direct author.<BR>
Seasiders are not direct authors of their html. Scriptaculousiders also<BR>
aren't direct authors of most javascritp they use. Seaside spits all<BR>
serialized for you so you don't have to worry about it. That fact makes that<BR>
argument extreamely weak at least for the most heavy part: lower<BR>
maintenance.<BR>
Just to illustrate: all my wrapper divs are in 1 method of this seaside<BR>
compoents family that has 16 short lines (of those, 1 is the selector of the<BR>
method, 2 are comments and 3 are separations).<BR>
<BR>
> <A HREF="http://www.motive.co.nz/glossary/div.php">http://www.motive.co.nz/glossary/div.php</A><BR>
><BR>
This author state he's counter divitis arguments in 3 parts:<BR>
1. complex code<BR>
I already deactivated this.<BR>
<BR>
2. Quoting: "A web designer might add additional <div>s that are redundant<BR>
(in terms of the final design), but that allow for future revision to the<BR>
design. In some cases, redundant <div>s are required to account for<BR>
variations in that way that different web browsers interpret the CSS<BR>
language."<BR>
<BR>
Here is being contradictive with himself by justifying why he do not make<BR>
allways what he promotes, so nothing to say.<BR>
<BR>
3. Quoting: "Less-experienced webpage authors will often use a <div> in<BR>
place of a more semantically-appropriate HTML element. For example, they<BR>
might use a <div> and CSS to style text to look like a heading, rather than<BR>
using an HTML heading element (<h1>, <h2>,<h3>, etc.)."<BR>
<BR>
I agree and should add that is *only* valued by webdesigners elite (which I<BR>
don't give a dime for). Not one single user will value more a heading that<BR>
looks like a header because it *is* a <h1> instead of a syled <div> nor that<BR>
will make you gain more money, so... as I stated, I don't give a dime to<BR>
HTML and or CSS beauty code. Html is conceptually poor and is doing what it<BR>
can to evolve so why I should be a devote admirer of a languange designed<BR>
bad from start? I'll, by no mean, be of the "beauty html" religion. It's not<BR>
a language for persons nor for machines. Let user agents to deal with it.<BR>
<BR>
End users don't want to look your html, they should not and they ever will.<BR>
So if costs are the problem I say that technologies that spit html for you<BR>
will make that argument insignificant.<BR>
<BR>
Besides they are talking mostly for pages that have extreamely simple<BR>
layouts: 1 (one) container (probably body)with 3 or 4 colums with a liquid<BR>
center. I want/need and talking about here, of having the chance of<BR>
composing ANY seaside component (of this family) trivially in an arbitrary<BR>
order of magnitude with border layout (see example:<BR>
<A HREF="http://extjs.com/deploy/dev/examples/layout/complex.html">http://extjs.com/deploy/dev/examples/layout/complex.html</A>). I gave a quick<BR>
look in the app I'm working on and counted 9 levels deep of border layout to<BR>
reach the div that wraps a button in a medium-simple form. When I can I'll<BR>
show you some so you can firebug that insane html (firebug thank you for<BR>
exist).<BR>
<BR>
> > The fact is that didn't stop me yet of doing anything. Besides<BR>
> > behavior, if you're valuing the elegance of the html I would agree.<BR>
> > The html would seem heavy but todays it can travel deflated<BR>
> by apache.<BR>
> > Besides The structure of what I have rendered on the user agent is<BR>
> > kind of homogeneus in nature even in a high degree of<BR>
> composition. I<BR>
> > know that it should be the designer's problem but I think I've also<BR>
> > have solved a priori most of the positioning problems with this. By<BR>
> > having a little painful experience on layouting things in<BR>
> html you may know how valuable this could be.<BR>
><BR>
> I don't see how these DIVs could be valuable for a designer,<BR>
> as they are probably auto generated. What worried me<BR>
> initially was that I had the impression that you wanted to<BR>
> put a DIV around every component.<BR>
><BR>
I may not let that clear enough. I don't want to force anything in Seaside<BR>
normal components hierarchy. Just a family of components that work like<BR>
this. Designers 99.9% probably get scared when see that html because they<BR>
are so used to manage html manually or semi-manually. But they should not.<BR>
This industrial way of using divs is meant to provide power. Power when you<BR>
use them with an associated CSS class (that by the way I also generate<BR>
automatically). The worst for webdesigners is the part they'll see<BR>
compromised CSS cascading capabilities. Several properties are repeated in<BR>
the CSS but is not that bad as it sounds. OK, my CSS is 14KB and it is<BR>
promising keep growing firmly but it goes deflated and ends cached anyway.<BR>
<BR>
> > So I say we can scale<BR>
> > that to make a family of components that are also AJAXianly<BR>
> backtrackeable.<BR>
> > Those components have the trade off of having to be identifiable in<BR>
> > the DOM and capable of setting it's innerHTML (that's why<BR>
> I've choosed<BR>
> > to wrapp with div containers).<BR>
><BR>
> That makes sense.<BR>
><BR>
> > If those components have to exists in a different hierarchy<BR>
> other than<BR>
> > WAComponent let's be it.<BR>
><BR>
> Sure that's a detail. I don't see any problems in starting<BR>
> with a subclass of WAComonent, I just feel that maybe later<BR>
> on you might want to choose a different superclass.<BR>
> WAComponent provides a lot of functionality that might not be<BR>
> too useful in your context.<BR>
><BR>
OK, later we can review that in the name of refactoring and clean Smalltalk<BR>
code :)<BR>
<BR>
> > I thought in continuations because how Seaside works. Suposing AJAX<BR>
> > did not exists, Seaside maps one unique url per<BR>
> reandereable action.<BR>
> > What I was thinking is that we can map those rendereable<BR>
> actions also<BR>
> > to AJAX style of render elements: updaters. If the problem<BR>
> to solve is<BR>
> > backtrack rendereable actions, no matter if they are full<BR>
> or partial,<BR>
> > I think Seaside is the winner because of continuations (I say this<BR>
> > because one can go back and forward in different "branches"<BR>
> of actions<BR>
> > and as far as I know only continuations handle that).<BR>
><BR>
> So far, I don't see any use of continuations. Seaside only<BR>
> uses continuations to wait in the middle of a method for the<BR>
> next request, e.g. with #call: and #answer:. The state<BR>
> backtracking has nothing to do with continuations (with the<BR>
> exception of the method-temps that are part of a suspended method).<BR>
><BR>
Now you let me thinking!.. I didn't realize that. I should take a reading on<BR>
how those methods work. Oh, I get it with the updaters we are not<BR>
interrupting any method execution in the middle right? Sure man, that is<BR>
only a need if we want to make a kind of #call: to works with AJAX. Ok, this<BR>
is the "one problem at the time baby" hour so we let that for a second<BR>
stage, I bet is solvable.<BR>
<BR>
So I need to understand better how Seaside maintain things backtrakable.<BR>
What do you suggest me to read?<BR>
<BR>
Cheers,<BR>
<BR>
Sebastian<BR>
<BR>
> > I'm still thinking loud here so please feel free to feedback,<BR>
><BR>
> Interesting discussion.<BR>
><BR>
> Cheers,<BR>
> Lukas<BR>
><BR>
> --<BR>
> Lukas Renggli<BR>
> <A HREF="http://www.lukas-renggli.ch">http://www.lukas-renggli.ch</A><BR>
> _______________________________________________<BR>
> seaside mailing list<BR>
> seaside@lists.squeakfoundation.org<BR>
> <A HREF="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR>
<BR>
_______________________________________________<BR>
seaside mailing list<BR>
seaside@lists.squeakfoundation.org<BR>
<A HREF="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR>
</FONT>
</P>
</BODY>
</HTML>