cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Refactoring woody styling (was Re: Woody Rant)
Date Mon, 24 Nov 2003 20:25:54 GMT
On 22.11.2003 14:40, Sylvain Wallez wrote:

>> It's maybe to late in the night to start a rant, but I will do it.
> Rants are more "ranty" late in the night ;-)
> I hear your concerns an try to turn them into constructive criticism. 

Thanks ...

> See below:
>> The problem I have with Woody at the moment is, that it becomes more 
>> and more a client side styling and JavaScript library while it should 
>> focus on the server side form processing.
>> Especially the JS stuff is ugly and horrible. If I see things like
>> result += 
>> "<HTML><HEAD><TITLE>Calendar</TITLE>"+this.getStyles()+"</HEAD><BODY

>> I wonder why you are doing/choosing/accepting such an approach. How 
>> should this work in future? It might work for many cases at the 
>> moment, but not all browsers are supported, Safari does even crash on 
>> such stuff [1]. You will get more and more bug reports in the future 
>> about any JS not working in a browser or a styling not looking correct 
>> like [2]. Strict HTML 4 has little problems at the moment, XHTML does 
>> not work completely! And I do not wonder about this. Might all be 
>> little fixable bugs, but it's not worth the time IMO.
> The main reason why I chose this is because of the calendar. I spent 
> some time searching for a good calendar, and chose this one for the 
> following reasons (in no particular order):

Yes - and this was absolutely okay.

> - it displays nicely in many browsers (at least those I work with),

Especially in older browsers, but not with XHTML as it is understandable 
because of document.write() usage. It's similar to <xsl:text 
disable-output-escaping="yes">&lt;element/&gt;</xsl:text> in XSLT.

> - it isn't bloated with unnecessary features,
> - its date format is the same as java.text.SimpleDateFormat, which will 
> make it very easy to "propagate" the server-side convertor format on the 
> client-side (still to be done, however),
> - it's licence is compatible with inclusion in Cocoon's CVS
> Now I'm definitely not a cross-browser compatibility expert, and I'm 
> open to any improvement, as long as the above requirements are met.

Of course. The problem I see with the current code:

The calendar is optimized for older browsers (let's say NS 4, IE 4) and 
works in recent browsers because of their backwards compatibility (up to 
HTML 4.0).

The HTML elements like <label> and <fieldset> only work for recent 
browsers (NS 6, IE 4 and above). So we have only a short time where it 
works. Especially where XHTML is on the road our nice samples can not work.

(BTW are cross browser information like
also available in other languages? SelfHTML is really *THE* HTML 
information source for German understanding people.)

>> IMO Woody should re-focus on form processing. Yes, we should provide a 
>> default view, but a simple one. If there must be used any JS as I see 
>> it for the calendar or the help popups then it should definitely be 
>> done the standard way (i.e. W3C DOM) and never using document.write(). 
>> We can show nice gimmicks, but not "everything that's possible".
> I don't agree with you here: you cannot seriously convince people to use 
> Woody if it doesn't provide the minimal "fancy features" that every 
> other form framework provides. You won't convince anybody with flat 
> inputs. We need tooltips, help popups, calendars, etc. But I also think 
> the current field-styling.xsl has reached a size where it must be split 
> into smaller units that everybody can assemble depending on their needs 
> (see below).

I don't want to remove things like calendar or tooltip popups. That's 
really cool stuff. But the implementation is really bad. And I had the 
impression that we are focussing only on extending that JS library while 
"it's not worth the time".

>> Is the calendar styleable to get it in Corporate Identity? In 
>> contradiction to "all browser support" ("works with Netscape 4.x, 6.x, 
>> IE 5.x ...") new stuff like <label/> and <fieldset/> is used, that 
>> only works in recent browsers, while for JS you want to support 
>> NetScape 4.x.
> Yes, the calendar is stylable.

In which way? CSS? CSS and NS 4 is almost a contradiction in itself ;-)

> Following a recent remark of Leszek 
> Gawron (aka "ouzo"), I wanted to remove the calendar stuff that is 
> always produced even if you don't use it.

That would be cool.

>> I also don't like "mattkruse-lib". I thought we have no 
>> code-ownership? Mentioning him like @author is absolutely ok, but not 
>> that conspicuous.
> Well, IMO the notion of "code ownership" as we usually use it here 
> doesn't apply in this case: Matt Kruse is not a Cocoon committer, and 
> his libraries are available at I named the file after the 
> web site name which happends to be also the guy's name. I considered 
> this a giving proper credit to someone not involved in Cocoon, but 
> there's absolutely no problem with renaming the files if you don't think 
> that it's appropriate.

Nobody else gave a comment on this, so it seems not important. I only 
don't like it that prominent.

>> I don't know if I forget any detail I wanted also to point out. Maybe 
>> I can add it in the (hopefully raising) discussion.
> Sure. As a first step, I propose to refactor the current woody styling 
> into smaller units. This will allow us to separate basic styling from 
> advanced styling (something I started to do with page/field styling), 
> and allow people to build their own styling with these more granular 
> blocks.


> However, we cannot totally remove client-side JS, but the minimal 
> requirement is really small.

I don't want to.

> My recent additions led me to identify 3 
> hooks where Woody has some work to do in the lifecycle of a form:
> - at page load time: the <body> tag must call "woody_onload" in its 
> "onload" event.
> - at form submit time: the <form> tag must call "woody_onsubmit" in its 
> "onsubmit" event
> - if some non-input fields submit the form (such as in an "onchange"), 
> they must call "woody_submitForm(element)".
> These 3 hooks should allow to handle all kind of complex JS-driven 
> widgets and styling. The first 2 ones just call event handlers that can 
> be registered at any time using the "woody_onloadHandlers" and 
> "woody_onsubmitHandlers" arrays.

If it's that easy (= a few general hooks, not here JS and there JS) I'm 
absolutely okay with it.

> If we agree on this minimal contract, we can split the styling into 
> independent elements that are assembled through includes/imports by the 
> main stylesheet. This will allow people to choose which of the provided 
> "styling snippets" they want to use, and plug in their own specific 
> stylings.


> But once again, I think Woody must come with some decently featured 
> styling out of the box, and we must work together to have a robust 
> cross-browser solution.

Of course. But as I pointed out the current solution is not really 
cross-browser, but only works for many browsers at the moment because 
they are backwards compatible. I don't know if you heard of it, but at 
the time Apple chose Konqueror as the base of Safari they said it was 
because of the FAT gecko engine. And why is it fat? Because they added 
backward compatibility here and there. But otherwise gecko browsers as 
Mozilla were not accepted. But we with our new Cocoon forms framework 
should not rely on browser backward compatibility, but exhaust their new 
features as far as possible and appropriate.

> What do you think?

Agreement in general :-)


View raw message