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 16:26:43 GMT
>> #6 - https://issues.apache.org/jira/browse/CLK-545
>>   "Better rendering of disabled link controls"
>>   No patch, but the required changes are described in the issue comment.
>>   It works on the browsers Click usually supports (see the above
>>   LinkDemo example too)
> 
> 
> I have a problem with controls which depend on JavaScript because 
> sometimes (by law) you have to deal with the fact that JavaScript cannot 
> be used or at least degrade gracefully.
It does not depend on JavaScript code. If the onClick event has "return 
false" than the browser won't follow that link. It's just an extra to 
still give the feel (not just the look) of a disabled link.
The actual solution is primitive and looks unprofessional too - no user 
I asked was able to guess that "that simple text" would a "disabled link".
If you apply the patch example from #5 with this issue, you will see 
what a huge difference that small improvement makes in LinksDemo.

> Also the issue suggests to use 
> an external CSS file for links? So if I want to render a link with Click 
> it will load an external stylesheet? Thats quite heavy for something as 
> simple as a link.
We are talking about browser based applications, right?
The browser's default CSS already does a nice look for e.g. a Button 
when "disabled" but not for Links.
Many use links even that "look" like buttons. However with the above 
trick, Click would keep the style of the link, and add the look&feel of 
a disabled element(so if it's red, it will be a "disabled red": that's 
user and developer friendly.
Also it would not be "another" CSS but the official Click one - and 
that's really included in every click based application.

> I've noticed quite a number of JIRA's related to adding styles to 
> control which I really hope we stay away from.
> 
> A more practical approach is to create site wide themes but to me this 
> is outside Click's scope. See JQuery theme roller for an example: 
> http://jqueryui.com/themeroller/.
This is not about themes, but about good default behavior and look.
Because the browser defaults are not ideal in many cases (or are not 
compatible from browsers to browser), developers have a hard work making 
it look right. Good default look and behavior saves allot of work (e.g. 
just like Click already does with automapping or autobinidng or with the 
nice "toString()" trick to have templates with just a $form or $table).

Theming is another issue, that might be addressed later.
BTW, jQuery themeroller produces a very heavy theming, and hard to apply 
to other
elements than the standard components (the forums are full of such 
problems). At first sight it's cool, but on the long run it creates more 
problems than it solves :(.


>> #10 https://issues.apache.org/jira/browse/CLK-543
>>   "SimpleLink control" (or improvement to ExternalLink - although
>>                         "SimpleLink" would be a better name.)
> 
> 
> We already have too many link and button controls, I'd rather we 
> consolidate/remove some of them instead of adding more.
Agree (maybe because AbstractLinks shoudn't be just a "Link" - so 
non-abstract and with the functionality of a "SimpleLink"?), but:
The naming is "ExternalLink" is too specific.
Important is that small functionality, independent of how we name it 
(but a good name would not be bad).

Thank you,
Adrian.


Mime
View raw message