Closed Bug 68206 Opened 24 years ago Closed 2 years ago

the Text Field Highlight color is not skinnable

Categories

(Core :: Layout: Text and Fonts, defect, P4)

defect

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
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
css -- handing over to marc
Assignee: beppe → attinasi
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
Status: NEW → ASSIGNED
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?
Depends on: selectors3
yes it comes from the OS
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
If :selection is too complex to implement for moz0.9, we can add a new property 
-moz-selectionColor
setting to moz1.0
Priority: -- → P4
Target Milestone: --- → mozilla1.0
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.
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.
Blocks: uaag
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
Depends on: 176170
No longer depends on: 183646
QA Contact: sujay → editor
Status: NEW → RESOLVED
Closed: 2 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.