click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <a.adrian.t...@gmail.com>
Subject Re: Click Release Strategy
Date Thu, 21 May 2009 19:31:18 GMT
>> It does not depend on JavaScript code. If the onClick event has 
>> "return false" 
> 
> 
> 'return false' is JS. Without it the link becomes clickable. 
If javascript is not available, the validations don't work either, as 
well as other click features. IMHO for those cases, there should
be another type of handling from Click's side.

> I don't 
> really see the advantage from rendering a span vs rendering a link with 
> JS in it? 
I suppose than that you haven't tried the example :).
A link feels like a link - title, browser status bar change, hover 
effects, etc.

> Right now you can apply the CSS from this issue to your site 
> stylesheet and disabled links will look the way you want it to.
Or I can hack Abstract link to do it (the way many use Click, and
why most users build it from the source).
This is however not the point, but good defaults are (and the 80/20 rule).

>> Also it would not be "another" CSS but the official Click one - and 
>> that's really included in every click based application.
> 
> 
> control.css is only included by Form. If you don't include a Form in 
> your page the link won't be rendered as disabled unless we add 
> control.css as a resource for AbstractLink.
Form and the rest of the fields - so almost all the time :).
Also something like css reset(e.g. from YUI) or some way to make click 
default rendering more uniform across all browsers would be a big 
advantage for Click (as these compatibility glitches waste allot of 
development effort).


Mime
View raw message