Closed
Bug 68206
Opened 25 years ago
Closed 4 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•25 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•25 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•25 years ago
|
Status: NEW → ASSIGNED
Comment 4•25 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•25 years ago
|
Depends on: selectors3
| Reporter | ||
Comment 5•25 years ago
|
||
yes it comes from the OS
Comment 6•25 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•25 years ago
|
||
If :selection is too complex to implement for moz0.9, we can add a new property
-moz-selectionColor
Comment 9•25 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•25 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•24 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•22 years ago
|
Updated•19 years ago
|
QA Contact: sujay → editor
Updated•4 years ago
|
Status: NEW → RESOLVED
Closed: 4 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
•