Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #35538 > unrolled thread

Finding a real background color of an element

Back to article view | Back to comp.lang.javascript

Contents

  Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-08-21 19:40 +0200
    Re: Finding a real background color of an element "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-08-21 21:14 -0700
    Re: Finding a real background color of an element JJ <jj4public@vfemail.net> - 2018-08-22 14:32 +0700
      Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-08-22 19:01 +0200
        Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-08-22 11:37 -0700
          Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-08-23 07:52 +0200
            Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-08-23 04:54 -0700
              Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-08-24 19:09 +0200
                Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-03 03:55 -0700
                  Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-03 04:28 -0700
                    Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-03 05:09 -0700
            Re: Finding a real background color of an element "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-09-02 12:40 -0700
              Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-03 03:51 -0700
                Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-03 03:55 -0700
              Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-09-04 18:52 +0200
    Re: Finding a real background color of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-08-29 22:12 +0200
      Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-08-31 22:30 +0200
        Re: Finding a real background color of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-02 05:09 +0200
          Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-09-02 19:57 +0200
            Re: Finding a real background color of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-03 15:09 +0200
              Re: Finding a real background color of an element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-09-04 19:02 +0200
                Re: Finding a real background color of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-04 22:15 +0200
                  Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-04 22:48 -0700
                    Re: Finding a real background color of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-08 15:39 +0200
                      Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-08 06:57 -0700
                    Re: Finding a real background color of an element Richard Damon <Richard@Damon-Family.org> - 2018-09-08 13:32 -0400
                      Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-08 10:43 -0700
                        Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-08 10:44 -0700
                          Re: Finding a real background color of an element Richard Damon <Richard@Damon-Family.org> - 2018-09-08 14:23 -0400
                            Re: Finding a real background color of an element Julio Di Egidio <julio@diegidio.name> - 2018-09-08 11:31 -0700
                              Re: Finding a real background color of an element Richard Damon <Richard@Damon-Family.org> - 2018-09-08 17:59 -0400
    Re: Finding a real background color of an element Silvio <silvio@internet.com> - 2018-09-04 22:05 +0200

Page 2 of 2 — ← Prev page 1 [2]

#35559

On 03/09/2018 15:09, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 02/09/2018 05:09, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> On 29/08/2018 22:12, Thomas 'PointedEars' Lahn wrote:
>>>>> Cezary Tomczyk wrote:
>>>>>> I am trying to figure it out how to determine a real background color
>>>>>> of an element that is visible on the screen.
>>>>> Why?
>>>> To calculate high contrast ratio.
>>> Why?
>>
>> Because I am working on https://www.aslint.org/ and implementing
>> https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
> 
> Very good.  Then I suggest, too, that you traverse the document tree upwards
> from the target element node:
> 
>    let node = targetElement;
>    do
>    {
>      … document.defaultView.getComputedStyle(node)
>          .getPropertyValue("background-color") …
>    }
>    while ((node = node.parentNode));
> 
> Note that this should return an RGB*A* value *string* for each element in
> the traversal, so in order to obtain the *visible* color, some calculation
> and therefore knowledge of color theory, is required.  For example, you have
> to be able to answer the question “What color, in the RGBA color space, is
> the combination of 50 % skyblue ("rgba(135, 206, 235, 0.5)") on white
> ("rgba(255, 255, 255, 1)") in the subtractive color model?”.

I do traverse up to the body HTML element, but when the body itself 
contains rgba(0, 0, 0, 0) then I can't use it.

> You could use my JSX:dom/css/color.js:jsx.dom.css.Color type to parse that
> string into an object whose numeric properties you can use for the
> calculation.  (The type itself does not provide the required calculation
> methods yet, but it does provide methods for conversion to and from HSL and
> HSV, which should be helpful.  Pull Requests are welcome.)

I do calculations correctly, but the only trouble is to get what's 
really rendered. So, instead rgba(0, 0, 0, 0) in reality I see white 
background.

I think Julio's right by saying that not defined explicitly background 
for body is an issue and that is something I will raise in the ASLint.

Also https://www.w3.org/TR/WCAG20-TECHS/F24.html

> Note also that this approach does not handle background images, and requires
> additional work for non-rectangular shapes (e.g. round borders).

If background-image is defined then calculating contrast ratio is 
impossible.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#35561

Cezary Tomczyk wrote:
> I do traverse up to the body HTML element, but when the body itself 
> contains rgba(0, 0, 0, 0) then I can't use it.

You can if you consider the alpha value, but you do not need to consider
alpha == 0 as it does not change the result.

I am working on adding the “over” operation to my color library although it
is likely that someone else has already done it.

>> You could use my JSX:dom/css/color.js:jsx.dom.css.Color type to parse that
>> string into an object whose numeric properties you can use for the
>> calculation.  (The type itself does not provide the required calculation
>> methods yet, but it does provide methods for conversion to and from HSL and
>> HSV, which should be helpful.  Pull Requests are welcome.)
> 
> I do calculations correctly, but the only trouble is to get what's 
> really rendered. So, instead rgba(0, 0, 0, 0) in reality I see white 
> background.

If you have a document where there is no background-color defined at all,
then you can consider it garbage regarding accessibility in the first place.

> I think Julio's right by saying that not defined explicitly background 
> for body is an issue and that is something I will raise in the ASLint.

Yes.

Another issue are user and dynamically inserted stylesheets which can
produce both false negatives and false positives.  You would have to make
sure that a computed style is not produced by such a stylesheet.

> Also https://www.w3.org/TR/WCAG20-TECHS/F24.html

Exactly.

>> Note also that this approach does not handle background images, and requires
>> additional work for non-rectangular shapes (e.g. round borders).
> 
> If background-image is defined then calculating contrast ratio is 
> impossible.

No, but it is more difficult and less compatible.

Coincidentally, I am working on a WCAG 2.0 AA task for the Swiss
Confederation, and I am looking forward to use your tool to double-check
my work :)


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#35562

On Tuesday, 4 September 2018 22:15:54 UTC+2, Thomas 'PointedEars' Lahn  wrote:
> Cezary Tomczyk wrote:
<snip>
> > I think Julio's right by saying that not defined explicitly background 
> > for body is an issue and that is something I will raise in the ASLint.
> 
> Yes.

Thanks guys, I am touched...  :)

But, seriously, I'd take some caution with that: not per chance it was born as
a *guideline*, plus I have warned that it's *not technically tractable*, not
only because it's subjective in inception, but also because pages are not in
fact static.  OTOH, that's the reference and that's what any linter should
take into account...

E.g. consider again (*) which says *it's fine if both are not defined*: if
there is an issue there, it's with the standard, not with the linters.  Then
consider also that the issue (if any) is with the very approach that is taken
in that standard, the underlying philosophy so to speak, not just with one or
two specific choices.

(*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>

Julio

[toc] | [prev] | [next] | [standalone]

#35565

</killfile>

Julio Di Egidio wrote:
> E.g. consider again (*) which says *it's fine if both are not defined*: 

That is a gross misrepresentation of what is cited.

Without a background color and foreground color defined there is no way to
establish proper color contrast between elements to allow them to be easily
distinguished.  But that is a requirement of WCAG 2.0 Level A already.

> if there is an issue there, it's with the standard, not with the linters.>
> Then consider also that the issue (if any) is with the very approach that is taken
> in that standard, the underlying philosophy so to speak, not just with one or
> two specific choices.

Nonsense.

> (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>

| Important Information about Techniques
|
| See <Understanding Techniques for WCAG Success Criteria> for important
| information about the usage of these informative techniques and how they
                                       ^^^^^^^^^^^
| relate to the normative WCAG 2.0 success criteria. The Applicability
| section explains the scope of the technique, and the presence of
                                                   ^^^^^^^^^^^^^^^
| techniques for a specific technology does not imply that the technology
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| can be used in all situations to create content that meets WCAG 2.0.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

<killfile>


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#35566

On Saturday, 8 September 2018 15:39:57 UTC+2, Thomas 'PointedEars' Lahn  wrote:
> </killfile>
> 
> Julio Di Egidio wrote:
> > E.g. consider again (*) which says *it's fine if both are not defined*: 
> > (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html> 
> 
> That is a gross misrepresentation of what is cited.

Is it??  Have you even bothered to read the Description section?

> Without a background color and foreground color defined there is no way to
> establish proper color contrast between elements to allow them to be easily
> distinguished.  But that is a requirement of WCAG 2.0 Level A already.

And again, if that is so (I couldn't care less to double-check in detail), you
have found an inconsistency *in the standard*...

> > if there is an issue there, it's with the standard, not with the linters.>
> > Then consider also that the issue (if any) is with the very approach that is taken
> > in that standard, the underlying philosophy so to speak, not just with one or
> > two specific choices.
> 
> Nonsense.

Which part of the water is wet you do not understand?  Idiot...

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#35567

On 9/5/18 1:48 AM, Julio Di Egidio wrote:
> On Tuesday, 4 September 2018 22:15:54 UTC+2, Thomas 'PointedEars' Lahn  wrote:
>> Cezary Tomczyk wrote:
> <snip>
>>> I think Julio's right by saying that not defined explicitly background 
>>> for body is an issue and that is something I will raise in the ASLint.
>>
>> Yes.
> 
> Thanks guys, I am touched...  :)
> 
> But, seriously, I'd take some caution with that: not per chance it was born as
> a *guideline*, plus I have warned that it's *not technically tractable*, not
> only because it's subjective in inception, but also because pages are not in
> fact static.  OTOH, that's the reference and that's what any linter should
> take into account...
> 
> E.g. consider again (*) which says *it's fine if both are not defined*: if
> there is an issue there, it's with the standard, not with the linters.  Then
> consider also that the issue (if any) is with the very approach that is taken
> in that standard, the underlying philosophy so to speak, not just with one or
> two specific choices.
> 
> (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
> 
> Julio
> 

My reading of that page is that it is ok to specify NEITHER of the
foreground and background, and thus let the user set them to something
suitable for them, or you need to specify BOTH, so that you can make
sure that you set them to something with sufficient visibility.

Setting just one of the colors says that you can not be sure you have
sufficient contrast, and that condition would be good to detect and warn
about.

[toc] | [prev] | [next] | [standalone]

#35568

On Saturday, 8 September 2018 19:33:01 UTC+2, Richard Damon  wrote:
> On 9/5/18 1:48 AM, Julio Di Egidio wrote:
<snip>
> > E.g. consider again (*) which says *it's fine if both are not defined*: if
> > there is an issue there, it's with the standard, not with the linters.  Then
> > consider also that the issue (if any) is with the very approach that is taken
> > in that standard, the underlying philosophy so to speak, not just with one or
> > two specific choices.
> > 
> > (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
> 
> My reading of that page is that it is ok to specify NEITHER of the
> foreground and background, and thus let the user set them to something
> suitable for them, or you need to specify BOTH, so that you can make
> sure that you set them to something with sufficient visibility.
> 
> Setting just one of the colors says that you can not be sure you have
> sufficient contrast, and that condition would be good to detect and warn
> about.

And I of course agree with your reading...

Julio

[toc] | [prev] | [next] | [standalone]

#35569

On Saturday, 8 September 2018 19:43:15 UTC+2, Julio Di Egidio  wrote:
> On Saturday, 8 September 2018 19:33:01 UTC+2, Richard Damon  wrote:
> > On 9/5/18 1:48 AM, Julio Di Egidio wrote:
> <snip>
> > > E.g. consider again (*) which says *it's fine if both are not defined*: if
> > > there is an issue there, it's with the standard, not with the linters.  Then
> > > consider also that the issue (if any) is with the very approach that is taken
> > > in that standard, the underlying philosophy so to speak, not just with one or
> > > two specific choices.
> > > 
> > > (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
> > 
> > My reading of that page is that it is ok to specify NEITHER of the
> > foreground and background, and thus let the user set them to something
> > suitable for them, or you need to specify BOTH, so that you can make
> > sure that you set them to something with sufficient visibility.
> > 
> > Setting just one of the colors says that you can not be sure you have
> > sufficient contrast, and that condition would be good to detect and warn
> > about.
> 
> And I of course agree with your reading...

P.S.  "Both are not" <=> "Neither is", in case that was the doubt.

Julio

[toc] | [prev] | [next] | [standalone]

#35570

On 9/8/18 1:44 PM, Julio Di Egidio wrote:
> On Saturday, 8 September 2018 19:43:15 UTC+2, Julio Di Egidio  wrote:
>> On Saturday, 8 September 2018 19:33:01 UTC+2, Richard Damon  wrote:
>>> On 9/5/18 1:48 AM, Julio Di Egidio wrote:
>> <snip>
>>>> E.g. consider again (*) which says *it's fine if both are not defined*: if
>>>> there is an issue there, it's with the standard, not with the linters.  Then
>>>> consider also that the issue (if any) is with the very approach that is taken
>>>> in that standard, the underlying philosophy so to speak, not just with one or
>>>> two specific choices.
>>>>
>>>> (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
>>>
>>> My reading of that page is that it is ok to specify NEITHER of the
>>> foreground and background, and thus let the user set them to something
>>> suitable for them, or you need to specify BOTH, so that you can make
>>> sure that you set them to something with sufficient visibility.
>>>
>>> Setting just one of the colors says that you can not be sure you have
>>> sufficient contrast, and that condition would be good to detect and warn
>>> about.
>>
>> And I of course agree with your reading...
> 
> P.S.  "Both are not" <=> "Neither is", in case that was the doubt.
> 
> Julio
> 

The issue is that some people may try to parse "Both are not defined" as
more like "it is not the case that both are defined" (which means
something very different). (!A) & (!B) vs !(A&B)

[toc] | [prev] | [next] | [standalone]

#35571

On Saturday, 8 September 2018 20:23:45 UTC+2, Richard Damon  wrote:
> On 9/8/18 1:44 PM, Julio Di Egidio wrote:
> > On Saturday, 8 September 2018 19:43:15 UTC+2, Julio Di Egidio  wrote:
> >> On Saturday, 8 September 2018 19:33:01 UTC+2, Richard Damon  wrote:
> >>> On 9/5/18 1:48 AM, Julio Di Egidio wrote:
> >> <snip>
> >>>> E.g. consider again (*) which says *it's fine if both are not defined*: if
> >>>> there is an issue there, it's with the standard, not with the linters.  Then
> >>>> consider also that the issue (if any) is with the very approach that is taken
> >>>> in that standard, the underlying philosophy so to speak, not just with one or
> >>>> two specific choices.
> >>>>
> >>>> (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
> >>>
> >>> My reading of that page is that it is ok to specify NEITHER of the
> >>> foreground and background, and thus let the user set them to something
> >>> suitable for them, or you need to specify BOTH, so that you can make
> >>> sure that you set them to something with sufficient visibility.
> >>>
> >>> Setting just one of the colors says that you can not be sure you have
> >>> sufficient contrast, and that condition would be good to detect and warn
> >>> about.
> >>
> >> And I of course agree with your reading...
> > 
> > P.S.  "Both are not" <=> "Neither is", in case that was the doubt.
> 
> The issue is that some people may try to parse "Both are not defined" as
> more like "it is not the case that both are defined" (which means
> something very different). (!A) & (!B) vs !(A&B)

Are you complaining that my English is worse than I thought?  Yet, you know
that fool-proof is fool in itself, don't you?

Some people should try and get their head out of their ass for a change.

Good evening,

Julio

[toc] | [prev] | [next] | [standalone]

#35572

On 9/8/18 2:31 PM, Julio Di Egidio wrote:
> On Saturday, 8 September 2018 20:23:45 UTC+2, Richard Damon  wrote:
>> On 9/8/18 1:44 PM, Julio Di Egidio wrote:
>>> On Saturday, 8 September 2018 19:43:15 UTC+2, Julio Di Egidio  wrote:
>>>> On Saturday, 8 September 2018 19:33:01 UTC+2, Richard Damon  wrote:
>>>>> On 9/5/18 1:48 AM, Julio Di Egidio wrote:
>>>> <snip>
>>>>>> E.g. consider again (*) which says *it's fine if both are not defined*: if
>>>>>> there is an issue there, it's with the standard, not with the linters.  Then
>>>>>> consider also that the issue (if any) is with the very approach that is taken
>>>>>> in that standard, the underlying philosophy so to speak, not just with one or
>>>>>> two specific choices.
>>>>>>
>>>>>> (*) <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
>>>>>
>>>>> My reading of that page is that it is ok to specify NEITHER of the
>>>>> foreground and background, and thus let the user set them to something
>>>>> suitable for them, or you need to specify BOTH, so that you can make
>>>>> sure that you set them to something with sufficient visibility.
>>>>>
>>>>> Setting just one of the colors says that you can not be sure you have
>>>>> sufficient contrast, and that condition would be good to detect and warn
>>>>> about.
>>>>
>>>> And I of course agree with your reading...
>>>
>>> P.S.  "Both are not" <=> "Neither is", in case that was the doubt.
>>
>> The issue is that some people may try to parse "Both are not defined" as
>> more like "it is not the case that both are defined" (which means
>> something very different). (!A) & (!B) vs !(A&B)
> 
> Are you complaining that my English is worse than I thought?  Yet, you know
> that fool-proof is fool in itself, don't you?
> 
> Some people should try and get their head out of their ass for a change.
> 
> Good evening,
> 
> Julio
> 

No complaints about your English, just pointing out that SOME people may
try to interpret that phrase differently, and that can lead to the sort
of issue that was being talked about. Asking about getting the 'default
background color' is a red flag, as it should never matter. If you are
setting the foreground color, you should have set the background color,
and thus not need to worry about the 'default'

Yes, if you could query this you could perhaps choose to theme your page
based on it, but then that really should be a very top level decision,
and after determining their 'default' you still set it in case you got
something wrong.

[toc] | [prev] | [next] | [standalone]

#35560

On 21-08-18 19:40, Cezary Tomczyk wrote:
> I am trying to figure it out how to determine a real background color of 
> an element that is visible on the screen.
> 
> Here is a code example:
> https://jsbin.com/mahabiyumi/edit?html,js,console,output
> 
> The trouble with determining background color is that it doesn't have to 
> have same value as the user sees on the screen. In above example the 
> element <h1> is visibly on the white background and
> 
> 1) it has defined rgba(0, 0, 0, 0) by default
> 2) all parents are having also defined rgba(0, 0, 0, 0) by default
> 
> but I can clearly see that <h1> is having a white background color.
> 
> Note: I do skip elements that have defined position absolute or fixed.
> 
> Any suggestions are very welcome.
> 

And what is the background color of en element with background: 
linear-gradient(...) then? You are trying to determine something that is 
not (clearly) defined.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web