Return-Path: Delivered-To: apmail-click-dev-archive@www.apache.org Received: (qmail 83431 invoked from network); 24 May 2010 09:42:49 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 May 2010 09:42:49 -0000 Received: (qmail 21963 invoked by uid 500); 24 May 2010 09:42:49 -0000 Delivered-To: apmail-click-dev-archive@click.apache.org Received: (qmail 21907 invoked by uid 500); 24 May 2010 09:42:49 -0000 Mailing-List: contact dev-help@click.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@click.apache.org Delivered-To: mailing list dev@click.apache.org Received: (qmail 21900 invoked by uid 99); 24 May 2010 09:42:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 May 2010 09:42:48 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 May 2010 09:42:45 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o4O9gOG1005957 for ; Mon, 24 May 2010 09:42:24 GMT Message-ID: <17170622.6261274694144258.JavaMail.jira@thor> Date: Mon, 24 May 2010 05:42:24 -0400 (EDT) From: "Bob Schellink (JIRA)" To: dev@click.apache.org Subject: [jira] Commented: (CLK-545) Better rendering of disabled link controls MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CLK-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870540#action_12870540 ] Bob Schellink commented on CLK-545: ----------------------------------- >This is the standard way of doing "disabling" of controls if I recall well. What standard is that and what UI guidelines are we talking about here? The only standards I'm aware of is HTML4 and CSS2.1. > IMHO it's the duty of the business logic or security filter to not allow the execution of that link if the user doesn't have the credentials. Just like that? So existing users who thought the link was obscured now has to implement new logic? This sounds alot like self interest and not taking the greater Click community into consideration. > Well, we do the exact opposite :). We are letting the user to see what he would get if he would have the credentials :) Well maybe your users are interested in viewing links in the status bar but I'm fairly certain the majority of users are not. To be honest I can't see this issue making it into Click core. This is such a core change that affects every link rendered by Click and there are many conflicting points of interest here. Security being a major one. > Better rendering of disabled link controls > ------------------------------------------ > > Key: CLK-545 > URL: https://issues.apache.org/jira/browse/CLK-545 > Project: Click > Issue Type: New Feature > Components: core > Reporter: Adrian A. > Assignee: Adrian A. > Fix For: 2.3.0 > > > Add better rendering of disabled link controls. Right now is a simple span text and there's no visual hint that this might be a disabled Link (except for that ActionButton). > Possible improvements: > - 50% opacity for images/icons > - title on mouse over > - href browser status bar hint on mouse over (but no click possible - since the link is disabled) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.