[Seaside] RE: cssClass and cssID (was testing framework)

[Brian Brown]

On Fri, 2004-07-23 at 13:45, Avi Bryant wrote:
> On Jul 23, 2004, at 8:52 AM, Brian Brown wrote:
> 
> > I think the second way introduces an unnecessary layer of abstraction 
> > - yes, each individual method is cleaner to read the CSS info, but 
> > overall it would be much more difficult building that component; I 
> > like the conciseness of the first one.
> 
> Probably true.
> 
> > What about the idea of assigning each component a default css name 
> > based on the name of the component. All elements rendered in that 
> > component would be in a namespace (from a CSS perspective) like:
> >
> > MyComponent.table
> > MyComponent.h3
> >
> > etc. This would follow the standard CSS inheritance, giving very fine 
> > grained control to each component only if desired.
> 
> Yes, this makes good sense.  The question is, I guess, where you hang 
> that class.  Do you wrap every component in a div automatically?  But 
> some components should be in spans instead, and some probably shouldn't 
> be in either.  So are there methods #wantsDiv, #wantsSpan that can be 
> overridden?  Or maybe there are #divClass and #spanClass methods, and 
> if either is overridden to return something non-nil, then the 
> appropriate tag is used (and you could have, by default,
> 
> divClass
> 	^ self class name
> 

Yes, I was initially thinking you would wrap every component
automatically, but having the #divClass and #spanClass would work well,
and give a lot of control for components. We would only have to resort
to the current way of doing things in limited cases.

> There's no need for #spanText: - this will already work:
> 
> 	html span: 'Some words'.
> 
> Methods like #span: aren't actually expecting a block specifically 
> (though a block is the most common thing to give them), they're 
> expecting anything that implements #renderOn:.  It's just that:
> 
> BlockContext>>renderOn: aRenderer
> 	self value
> 
I probably should have tried it that way ;)

Brian