@accesskey appended after label cannot be hidden with CSS

RESOLVED FIXED

Status

--
minor
RESOLVED FIXED
13 years ago
3 years ago

People

(Reporter: victor.engmark, Assigned: allan)

Tracking

({fixed1.8.0.5, fixed1.8.1})

Trunk
fixed1.8.0.5, fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Using the following XForms, "(1)" is appended after the label.

<xf:trigger accesskey="1" id="show-slotid-form-trigger">
  <xf:label>Slot by ID</xf:label>
  <xf:action ev:event="DOMActivate">
    <xf:toggle case="show-slotid-form"/>
  </xf:action>
</xf:trigger>

I've tried hiding it with the following CSS rules, without success:
trigger:after {content: ""; display: none;}
label:after {content: ""; display: none;}

Using !important with the rules doesn't work either.

Reproducible: Always

Steps to Reproduce:
1. Add an @accesskey to an XForms control which does not match any letters in the label
2. Add CSS to hide the automatically generated :after contents
3. Load XForms in Firefox with the XForms 0.4 extension installed

Actual Results:  
The @accesskey contents is appended in parentheses after the label.

Expected Results:  
The @accesskey contents should be hidden.

AFAIK, the following is the correct minimal CSS to do this:
label:after {display: none;}
We create a html:u for the accesskey, so :

xforms|label html|u {
  display: none;
}

probably will work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1)
> We create a html:u for the accesskey, so :
> 
> xforms|label html|u {
>   display: none;
> }
> 
> probably will work.
> 

Not always. Parenthesis will be threre :)

There are two issues. The first we should provide a ability to hide additional accesskey label. Though I can't see a usecase when it's needed. The second issue is related with generated text of css. Should the example work at all? Btw how is generated text supporting realized?
We could remove the () stuff if the accesskey isn't found in the value.  Mozilla UI does the (_accesskey) stuff so I automatically added it.
(Assignee)

Updated

13 years ago
Assignee: aaronr → xforms
(Assignee)

Updated

13 years ago
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
(Assignee)

Comment 4

13 years ago
Created attachment 223694 [details] [diff] [review]
Patch

Another approach on accesskeys. Instead of using a "u" element, I create spans for both the case where the key is found in the label (inline) and where it is appended.

I then set the classes xf-accesskey-inline and xf-accessley-appended. These are are then styled per default (with underline and ()), and it is possible for the form author to style them as she pleases.
Assignee: xforms → allan
Status: NEW → ASSIGNED
Attachment #223694 - Flags: review?(doronr)
(Assignee)

Comment 5

13 years ago
Created attachment 223695 [details] [diff] [review]
Patch w/jst nits fixed
Attachment #223694 - Attachment is obsolete: true
Attachment #223695 - Flags: review?(doronr)
Attachment #223694 - Flags: review?(doronr)
(Assignee)

Comment 6

13 years ago
Created attachment 223696 [details]
Testcase for proposed patch
Attachment #223695 - Flags: review?(doronr) → review+
(Assignee)

Updated

13 years ago
Attachment #223695 - Flags: review?(Olli.Pettay)
Attachment #223695 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 7

13 years ago
Fixed on trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
(Assignee)

Updated

13 years ago
Keywords: fixed1.8.0.5
(Assignee)

Updated

13 years ago
Keywords: fixed1.8.1
(Assignee)

Updated

13 years ago
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.