We could possibly use selection to do the styling like we do with the protocol in the address bar. This depends on the design from bug 959558.

We cannot implement the styling proposed from bug 959558 with a :-moz-selection. :-moz-selection only allows styilng of 'background-color' and 'color' properties. Should bug 959558 be reopened? I don't know how we would fix this bug without using a selection.

OK, I wasn't familiar with limitations when this was filed during the offsite in Paris. I see three options: 1) Change or fork :-moz-selection to allow more properties to work. 2) Switch the URL bar binding to one which inserts DOM node wrappers to do the styling when the focus leaves it. I'm not sure but I think it could turn into a normal text box upon focus? One would have to check with UX. 3) Change the design to fit the limitations of :-moz-selection. What do you think of those options?

I think we'll have to choose between (3) and (2), although (2) seems quite scary as we would have to be careful not to break text-selection and TART performance. I left a comment in bug 959558 to ask how the design could be changed/simplified.

The reason I didn't say (1) is because ::-moz-selection is not in any standard and is not on a path towards standardization. It is not recommended for content and thus I don't think we'll get any buy-in from people working in Core to support more CSS properties for it.

From bug 959558, (In reply to mmaslaney from comment #4) > Jared, that works. > > Anyway this can be done in the future? My goal is to make the callouts look > clickable, and not like highlighted text. (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5) > Yes, see the patches in https://bugzilla.mozilla.org/show_bug.cgi?id=747085 > as a guide.

Can I propose (4) get the coordinates of the selection rect (AIUI that should be possible with current DOM APIs?) and "underlay" that with a simple box with the 'full' styling? Or is there some reason that wouldn't work? I'm also worried that the selection approach might not work because there's already a selection range (namely the domain thing, as MattN noted in comment #0) and so I don't think we can add a separately styled second range.

(In reply to :Gijs Kruitbosch from comment #6) > I'm also worried that the selection approach might not work because there's > already a selection range (namely the domain thing, as MattN noted in > comment #0) and so I don't think we can add a separately styled second range. I added a separately styled second range in my patch for bug 747085.

(In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #6) > I'm also worried that the selection approach might not work because there's > already a selection range (namely the domain thing, as MattN noted in > comment #0) and so I don't think we can add a separately styled second range. Why can't we just define other ranges? selection supports multiple ranges

fwiw, what I meant is that these search terms should be styled plain black, like the domain, so sounds like it should be easier to just extend domain hilighting

See Boriss mock-up https://bug1029848.bugzilla.mozilla.org/attachment.cgi?id=8450207 I don't think we should go further, we didn't make the domain colored of fancy to avoid distracting the user, we should continue on the same road.

Duping this forward as the styling requests have changed and the conversation in this bug can be confusing to follow as the specs have changed.

Oh, I guess that is a tracking bug.

I think we could just resolve this as incomplete since it's based on a different mock up, or fixed if the discussion brings to a meaningful conclusion. The implementation will happen directly in bug 1047469 once the dependencies (one is this one) are resolved.

I'm fine with closing this bug. Too many bugs around talking about the same thing.