Closed
Bug 68206
Opened 24 years ago
Closed 3 years ago
the Text Field Highlight color is not skinnable
Categories
(Core :: Layout: Text and Fonts, defect, P4)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
DUPLICATE
of bug 509958
mozilla1.0.1
People
(Reporter: marlon.bishop, Assigned: glazou)
References
(Depends on 1 open bug)
Details
Theme development would benefit tremendously by having ability to access this color in theme CSS
Comment 1•24 years ago
|
||
sounds like more of an editor issue, reassigning.
Assignee: trudelle → beppe
Component: XP Toolkit/Widgets → Editor
QA Contact: jrgm → sujay
Summary: the Text Field Highlight color is not skinnable → the Text Field Highlight color is not skinnable
Comment 3•24 years ago
|
||
Looks like there's a proposed pseudoelement in the latest CSS3 spec with just this purpose in mind. See: http://www.w3.org/TR/2000/WD-css3-selectors-20001005/#UIfragments
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 4•24 years ago
|
||
Well, we could go ahead and implement the ::selection pseudo-element as a proprietary extension until the CSS3 Selector module is ratified. '::-moz-selection' would do the trick. Please see bug 62843 an bug 65133. Bug 65133 is a tracking bug for CSS3 selectors, so I am linking this bug to that one for now. Also, CC'ing glazman since he is the CSS3 selector draft editor and the most likely candidate to implement this (wink-wink, nudge-nudge) ;) ps. I'm curious, where is the current selection color coming from, the OS?
Updated•24 years ago
|
Depends on: selectors3
Reporter | ||
Comment 5•24 years ago
|
||
yes it comes from the OS
Comment 6•24 years ago
|
||
Pusing to Daniel as I try to shed non-critical CSS bugs... This is another CSS3 selector kind of issue. (Daniel, if you object to the reassignment, please let me know)
Assignee: attinasi → glazman
Status: ASSIGNED → NEW
Comment 7•24 years ago
|
||
If :selection is too complex to implement for moz0.9, we can add a new property -moz-selectionColor
Comment 9•24 years ago
|
||
The W3C accessibility guidelines ask that selection be configurable to be shown by something other than color. Wouldn't that be a nightmare for us if the height and width of the selected text changed because of the style rule? What kind of performance hit would we take as the user quickly resized the selection? I can't think of any software where the selected text is a different size than if it was unselected. Even if you could, wouldn't it be confusing as your whole page layout changed? What is really needed, I think, is to be able to draw boxes around the selection, or underline it, without the page layout being affected.
Assignee | ||
Comment 10•24 years ago
|
||
Certainly !!! Imagine that you assign 'font-size : 150%' to the selection. You have "hello world" on your screen and you select "hello" ; the world automagically doubles its size but you did not change the pointer's position. So you end up with "hell" selected. This is the reason why the only applicable property to the new css 3 ::selection pseudo are color, background and decoration properties, ie properties implying a repaint but not a reflow.
Comment 11•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•21 years ago
|
Updated•18 years ago
|
QA Contact: sujay → editor
Status: NEW → RESOLVED
Closed: 3 years ago
Component: DOM: Editor → Layout: Text and Fonts
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•