W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: Styling of search/find-in-page results

From: Zack Weinberg <zackw@panix.com>
Date: Fri, 4 Apr 2014 10:31:32 -0400
Message-ID: <CAKCAbMgcRCemOE5z-jFQxY_NLt1hctivtg0bZK=irP=AMH=uiw@mail.gmail.com>
To: Mitar <mmitar@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
If the PDF.js team would take the time to write up their use cases in
detail--both what is needed, and how it would most conveniently work--that
would be very helpful to the cause of getting ::selection and friends
specified. Right now we don't have a good sense of how it _should_ work.

On Friday, April 4, 2014, Mitar <mmitar@gmail.com> wrote:

> Hi!
>
> Oh, then this means this is one more argument for the whole family of
> related pseudo elements. :-)
>
>
> Mitar
>
> On Thu, Apr 3, 2014 at 9:19 AM, Tab Atkins Jr. <jackalmage@gmail.com<javascript:;>>
> wrote:
> > On Wed, Apr 2, 2014 at 11:20 PM, Mitar <mmitar@gmail.com <javascript:;>>
> wrote:
> >> Currently it is not really possible to style search/find-in-page
> >> results. Some browsers reuse selection style (Firefox), some browsers
> >> have special style you cannot style with CSS (Chrome). I think a
> >> pseudo-element selector should be provided to change background-color
> >> and color properties.
> >>
> >> Additionally, some browsers support highlighting all search results
> >> (for example, in Chrome, when user selects to "highlight all"
> >> matches). This might be another pseudo element?
> >>
> >> The use case for this is in Mozilla pdf.js HTML5 PDF library and
> >> viewer. It uses HTML5 canvas to render PDF5 content. But for the user
> >> to be able to search and select text content of the PDF, a transparent
> >> text layer is created above. If you search on the page, you get
> >> results, but because text layer is transparent, instead of the result
> >> only an empty colorful box is shown. See here:
> >>
> >> http://mozilla.github.io/pdf.js/web/viewer.html
> >>
> >> (Use browser search and not interface which overrides ctrl-f keyboard
> >> shortcut, this is the topic of another my post to whatwg mailing list:
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-February/042100.html
> )
> >
> > Unfortunately, the definition of such a thing would be essentially
> > identical to ::selection, which we haven't yet actually specified
> > either.  (We tried to in the past, but everyone implemented something
> > observably different, and we haven't taken the time to figure out what
> > the best solution is yet.)
> >
> > I think this use-case is valuable, but we need to do more than just
> > define a variant of ::selection, because ::selection isn't defined
> > yet. :/
> >
> > ~TJ
>
>
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
>
Received on Friday, 4 April 2014 14:31:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC