Closed Bug 331346 Opened 16 years ago Closed 15 years ago

@accesskey appended after label cannot be hidden with CSS

Categories

(Core Graveyard :: XForms, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mozilla.org, Assigned: allan)

Details

(Keywords: fixed1.8.0.5, fixed1.8.1)

Attachments

(2 files, 1 obsolete file)

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: aaronr → xforms
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Attached patch Patch (obsolete) — Splinter Review
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)
Attachment #223694 - Attachment is obsolete: true
Attachment #223695 - Flags: review?(doronr)
Attachment #223694 - Flags: review?(doronr)
Attachment #223695 - Flags: review?(doronr) → review+
Attachment #223695 - Flags: review?(Olli.Pettay)
Attachment #223695 - Flags: review?(Olli.Pettay) → review+
Fixed on trunk
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
Keywords: fixed1.8.0.5
Keywords: fixed1.8.1
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.