Re: Elements invisible to naked eye. ::visibly-hidden pseudo class?

[Sorry for the delay; our moderation queue was just emptied.]

On Wed, Jul 9, 2014 at 2:06 PM, Cory Mawhorter <cory.mawhorter@gmail.com> wrote:
> Wanted to throw this out there for discussion...
>
> The problem:
>
> An element with a black background sits inside a container element with a
> black background.  The element is invisible to the naked eye, but not
> display:none or visibility:hidden.  You want to adjust the styling of just
> that element, but have no way to do so that will support future style
> changes.  (What if I want to change the container background to white or add
> support for themes.)
>
> I can't think of any solid workarounds.
>
> I explain the problem in more detail here:
> mawhorter.net/post/91279744832/i-want-a-new-pseudo-class-take-a-look-at-the
>
>
> Proposed solution:
>
> A ::visibly-hidden pseudo selector.  You can then modify properties only
> when an element becomes "invisible".  I realize "invisible to the naked eye"
> is subjective and that my visibly hidden doesn't match yours.  But pretty
> good generalizations exist.

I don't think this'll work, unfortunately.

One, as you note, there's no good definition of "invisible to the
naked eye".  We could be strict and require exact color matches
between text and background, or background and backdrop, but that
would miss a ton of cases that are effectively invisible.

Two, I'm not sure how often this'll apply in a useful way.  You imply
that it can match when an element's background is invisible against
its backdrop.  What about the element's content, though?  It's
perfectly reasonable for an element to have the same background as its
parent (or a transparent background), but have different-colored text.
If its text/background distinction you want, we'd want a different
selector with a better name, because you'd solve that kind of problem
very differently.

More importantly, this has circularity problems real bad.  Take this example:

body { background: black; }
body > div { background: black; }
body > div:visibly-hidden { background: white; }

Is its background black or white?  If its white, it's no longer
visibly hidden, so the pseudo-class shouldn't match. But that means
its black, and so hidden, and the pseudo-class *should* match. Etc.

I've got a proposal for how to handle this kind of thing in general
<https://tabatkins.github.io/specs/css-toggle-states/#checked-problems>,
but it can't be applied to this pseudo-class.  You'd have to add
virtually every property in CSS to the list of selector-affecting
properties, which makes the list useless.  Furthermore, the properties
that affect visibility are probably precisely the kinds of things you
*want* to be able to set on such an element, to make it no longer
invisible!

It's possible that this would be useful just in JS, but then it'd be
done through some JS property or function, not a CSS thing directly.
However, that suffers from similar "what do you mean, invisible"
problems.  Also, see below.

> Accessibility:
>
> As a side benefit, I could see this being hugely useful for getting better
> with accessible websites for the visually impaired (color blind).  Some
> setting would need to be added to the browser to make the selector truly
> useful for this.
>
> It just kinda sucks that people with color blindness are stuck with looking
> at crappy designs like this
> http://dev.chromium.org/user-experience/low-vision-support#TOC-High-Contrast-and-Custom-Color-Support
>
> That is faarrrr outside the scope of this list, but I feel not unrelated.

I feel you, as I'm color-blind.  (Luckily, in a way that rarely causes
problems, but every once in a while...)  But while this is similar in
spirit to "effectively invisible", it's actually far past it in terms
of having-an-API.

Given the diversity of things one might be looking for when scanning
for "invisible" or "hard to see" elements, this really just needs to
be an ordinary JS library that caters to whatever use-case one is
dealing with.  There are already services that can scan a page and
look for places that might be too low-contrast, or otherwise violating
basic accessibility guidelines.  I don't think this sort of thing is
appropriate to bake into any of the web languages, given this
diversity.

~TJ

Received on Wednesday, 23 July 2014 17:02:24 UTC