The default bug view has changed. See this FAQ.

the Text Field Highlight color is not skinnable

NEW
Assigned to

Status

()

Core
Editor
P4
normal
16 years ago
10 months ago

People

(Reporter: marlon bishop, Assigned: glazou)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
mozilla1.0.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Theme development would benefit tremendously by having ability to access this 
color in theme CSS

Comment 1

16 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 2

16 years ago
css -- handing over to marc
Assignee: beppe → attinasi

Comment 3

16 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

16 years ago
Status: NEW → ASSIGNED

Comment 4

16 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

16 years ago
Depends on: 65133
(Reporter)

Comment 5

16 years ago
yes it comes from the OS

Comment 6

16 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

16 years ago
If :selection is too complex to implement for moz0.9, we can add a new property 
-moz-selectionColor

Comment 8

16 years ago
setting to moz1.0
Priority: -- → P4
Target Milestone: --- → mozilla1.0

Comment 9

16 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

16 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.

Updated

16 years ago
Blocks: 24413

Comment 11

16 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
Depends on: 183646
No longer depends on: 65133

Updated

13 years ago
Depends on: 176170
No longer depends on: 183646
QA Contact: sujay → editor
Blocks: 357052
You need to log in before you can comment on or make changes to this bug.