Closed
Bug 331346
Opened 18 years ago
Closed 18 years ago
@accesskey appended after label cannot be hidden with CSS
Categories
(Core Graveyard :: XForms, defect)
Core Graveyard
XForms
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;}
Comment 1•18 years ago
|
||
We create a html:u for the accesskey, so : xforms|label html|u { display: none; } probably will work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•18 years ago
|
||
(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?
Comment 3•18 years ago
|
||
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•18 years ago
|
Assignee: aaronr → xforms
Assignee | ||
Updated•18 years ago
|
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 4•18 years ago
|
||
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 | ||
Comment 5•18 years ago
|
||
Attachment #223694 -
Attachment is obsolete: true
Attachment #223695 -
Flags: review?(doronr)
Attachment #223694 -
Flags: review?(doronr)
Assignee | ||
Comment 6•18 years ago
|
||
Updated•18 years ago
|
Attachment #223695 -
Flags: review?(doronr) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #223695 -
Flags: review?(Olli.Pettay)
Updated•18 years ago
|
Attachment #223695 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 7•18 years ago
|
||
Fixed on trunk
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.0.5
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.1
Assignee | ||
Updated•18 years ago
|
Whiteboard: xf-to-branch
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•