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 1 of 2  [1] 2  Next page →

#35538 — Finding a real background color of an element

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.

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

[toc] | [next] | [standalone]

#35539

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.

You can try this: 

<https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas>

And then sample a representative pixel of your subsequent image

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

#35540

On Tue, 21 Aug 2018 19:40:59 +0200, 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.

You'll have to check the specified element first, then check its parent
element, and repeat that until you have a non transparent background color.
Exclude the HTML element, because styles do not apply to that element. Once
you have a non transparent background color, return that color. e.g.

  function getBackgroundColor(ele) {
    var color = "transparent";
    while (ele !== document.documentElement) {
      color = getComputedStyle(ele).backgroundColor;
      ele = ele.parentNode;
    }
    return color;
  }

Keep in mind, that a document may have transparent background color. In this
case, the web browser's default background color is used. Or if the document
is served in an IFRAME element, then the IFRAME element's background color
is used. While in some conditions, the IFRAME element's background color can
be retrieved, it's not possible to retrieve the web browser's default color
- since it's not exposed to document scripts.

The method which takes screenshot with canvas, also has this limitation. For
example, using html2canvas <https://github.com/niklasvh/html2canvas> to
render that H1 element on JSBin. The result will also have transparent
background in its image data. And there's no way to retrieve the IFRAME's
background color because the IFRAME is served on a document which is in a
different domain.

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

#35541

On 22/08/2018 09:32, JJ wrote:
> On Tue, 21 Aug 2018 19:40:59 +0200, 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.
> 
> You'll have to check the specified element first, then check its parent
> element, and repeat that until you have a non transparent background color.
> Exclude the HTML element, because styles do not apply to that element. Once
> you have a non transparent background color, return that color. e.g.
> 
>    function getBackgroundColor(ele) {
>      var color = "transparent";
>      while (ele !== document.documentElement) {
>        color = getComputedStyle(ele).backgroundColor;
>        ele = ele.parentNode;
>      }
>      return color;
>    }
> 
> Keep in mind, that a document may have transparent background color. In this
> case, the web browser's default background color is used. Or if the document
> is served in an IFRAME element, then the IFRAME element's background color
> is used. While in some conditions, the IFRAME element's background color can
> be retrieved, it's not possible to retrieve the web browser's default color
> - since it's not exposed to document scripts.

That's exactly what I've done - process parent's until "body" and until 
the background color is founded. However, yes - the transparent and not 
being able to get default background color is the issue I am facing now.

> The method which takes screenshot with canvas, also has this limitation. For
> example, using html2canvas <https://github.com/niklasvh/html2canvas> to
> render that H1 element on JSBin. The result will also have transparent
> background in its image data. And there's no way to retrieve the IFRAME's
> background color because the IFRAME is served on a document which is in a
> different domain.

That means to me that there is no reliable way to get a real background 
color of the HTML element. :/

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

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

#35542

On Wednesday, 22 August 2018 19:01:56 UTC+2, Cezary Tomczyk  wrote:

> That means to me that there is no reliable way to get a real background 
> color of the HTML element. :/

Well, if you have control over it, do set a color and background color on
the body, that's required for accessibility anyway.  When there is no such
information and one needs it, rather review your approach and expectations.
What is it that you are trying to build?  Theming?  A self-styling widget?
Otherwise what?  There are solutions to every well-posed problem, as well as
there are ill-posed problems or solutions for no problem at all...

Julio

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

#35543

On 22/08/2018 20:37, Julio Di Egidio wrote:
> On Wednesday, 22 August 2018 19:01:56 UTC+2, Cezary Tomczyk  wrote:
> 
>> That means to me that there is no reliable way to get a real background
>> color of the HTML element. :/
> 
> Well, if you have control over it, do set a color and background color on
> the body, that's required for accessibility anyway.  When there is no such
> information and one needs it, rather review your approach and expectations.

The background and foreground color should be defined for the body, but 
mostly is not defined. In reality, I mean.

> What is it that you are trying to build?  Theming?  A self-styling widget?
> Otherwise what?  There are solutions to every well-posed problem, as well as
> there are ill-posed problems or solutions for no problem at all...

I do calculate a contrast ratio and for that purpose I need background 
and foreground color. Currently, if I can't determine a background color 
for a particular element then I do skip contrast ratio calculation.

I am working on https://www.aslint.org/. The code is not public yet, but 
I have a plan to publish it.


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

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

#35544

On Thursday, 23 August 2018 07:52:23 UTC+2, Cezary Tomczyk  wrote:
> On 22/08/2018 20:37, Julio Di Egidio wrote:
> > On Wednesday, 22 August 2018 19:01:56 UTC+2, Cezary Tomczyk  wrote:
> > 
> >> That means to me that there is no reliable way to get a real background
> >> color of the HTML element. :/
> > 
> > Well, if you have control over it, do set a color and background color on
> > the body, that's required for accessibility anyway.  When there is no such
> > information and one needs it, rather review your approach and expectations.
> 
> The background and foreground color should be defined for the body, but 
> mostly is not defined. In reality, I mean.

Sometimes accessibility really doesn't matter (but then one would not lint for
accessibility anyway).  In all other cases, I'd say no competent web programmer
can make that mistake: in our toolbox there is a minimal style just as there is
a minimal html...

> > What is it that you are trying to build?  Theming?  A self-styling widget?
> > Otherwise what?  There are solutions to every well-posed problem, as well as
> > there are ill-posed problems or solutions for no problem at all...
> 
> I do calculate a contrast ratio and for that purpose I need background 
> and foreground color. Currently, if I can't determine a background color 
> for a particular element then I do skip contrast ratio calculation.

I'd expect an accessibility linter to rather report it as a most basic and
most serious violation.

> I am working on https://www.aslint.org/. The code is not public yet, but 
> I have a plan to publish it.

Not an easy one: accessibility requirements for a significant part rely on
subjective evaluation.  So, it will be interesting to see what you come up
with...  :)

Julio

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

#35545

On 23/08/2018 13:54, Julio Di Egidio wrote:
> On Thursday, 23 August 2018 07:52:23 UTC+2, Cezary Tomczyk  wrote:
>> On 22/08/2018 20:37, Julio Di Egidio wrote:
>>> On Wednesday, 22 August 2018 19:01:56 UTC+2, Cezary Tomczyk  wrote:
>>>
>>>> That means to me that there is no reliable way to get a real background
>>>> color of the HTML element. :/
>>>
>>> Well, if you have control over it, do set a color and background color on
>>> the body, that's required for accessibility anyway.  When there is no such
>>> information and one needs it, rather review your approach and expectations.
>>
>> The background and foreground color should be defined for the body, but
>> mostly is not defined. In reality, I mean.
> 
> Sometimes accessibility really doesn't matter (but then one would not lint for
> accessibility anyway).  In all other cases, I'd say no competent web programmer
> can make that mistake: in our toolbox there is a minimal style just as there is
> a minimal html...

Yes, I share these thoughts "minimal style just as there is a minimal 
html...".

>>> What is it that you are trying to build?  Theming?  A self-styling widget?
>>> Otherwise what?  There are solutions to every well-posed problem, as well as
>>> there are ill-posed problems or solutions for no problem at all...
>>
>> I do calculate a contrast ratio and for that purpose I need background
>> and foreground color. Currently, if I can't determine a background color
>> for a particular element then I do skip contrast ratio calculation.
> 
> I'd expect an accessibility linter to rather report it as a most basic and
> most serious violation.

Unfortunately none of known to me are reporting it.

>> I am working on https://www.aslint.org/. The code is not public yet, but
>> I have a plan to publish it.
> 
> Not an easy one: accessibility requirements for a significant part rely on
> subjective evaluation.  So, it will be interesting to see what you come up
> with...  :)

I think I'll include that case in the report to draw the attention. I 
think developers should be aware that if background can not be 
explicitly determined then they should fix it. :-)

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

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

#35553

On Friday, 24 August 2018 19:09:48 UTC+2, Cezary Tomczyk  wrote:
> On 23/08/2018 13:54, Julio Di Egidio wrote:
<snip>
> > I'd expect an accessibility linter to rather report it as a most basic and
> > most serious violation.
> 
> Unfortunately none of known to me are reporting it.

Well, no surprise there: let's see if you can do any better than the usual
disasters and frauds, that would be a surprise.

> I think I'll include that case in the report to draw the attention. I 
> think developers should be aware that if background can not be 
> explicitly determined then they should fix it. :-)

Default colors may vary across browsers and user settings, and determining them
"at runtime" is NOT any accessibility verification: the *code* must be verified!
(Do you need me to quote from the standard?)

Julio

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

#35555

On Monday, 3 September 2018 12:55:13 UTC+2, Julio Di Egidio  wrote:
> On Friday, 24 August 2018 19:09:48 UTC+2, Cezary Tomczyk  wrote:
> > On 23/08/2018 13:54, Julio Di Egidio wrote:
> <snip>
> > > I'd expect an accessibility linter to rather report it as a most basic and
> > > most serious violation.
> > 
> > Unfortunately none of known to me are reporting it.
> 
> Well, no surprise there: let's see if you can do any better than the usual
> disasters and frauds, that would be a surprise.

Sorry, for that case the guidelines indeed say the opposite:

"The author specifies neither text color nor background, and does not use CSS. As a result the user can set his browser defaults to provide the colors and contrasts that work well for them."

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

> > I think I'll include that case in the report to draw the attention. I 
> > think developers should be aware that if background can not be 
> > explicitly determined then they should fix it. :-)
> 
> Default colors may vary across browsers and user settings, and determining them
> "at runtime" is NOT any accessibility verification: the *code* must be verified!
> (Do you need me to quote from the standard?)

I think that's still correct, that one has to verify the DOM/CSS, not the
rendering...

Julio

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

#35556

On Monday, 3 September 2018 13:28:34 UTC+2, Julio Di Egidio  wrote:
> On Monday, 3 September 2018 12:55:13 UTC+2, Julio Di Egidio  wrote:
> > On Friday, 24 August 2018 19:09:48 UTC+2, Cezary Tomczyk  wrote:
> > > On 23/08/2018 13:54, Julio Di Egidio wrote:
> > <snip>
> > > > I'd expect an accessibility linter to rather report it as a most basic and
> > > > most serious violation.
> > > 
> > > Unfortunately none of known to me are reporting it.
> > 
> > Well, no surprise there: let's see if you can do any better than the usual
> > disasters and frauds, that would be a surprise.
> 
> Sorry, for that case the guidelines indeed say the opposite:
> 
> "The author specifies neither text color nor background, and does not use CSS. As a result the user can set his browser defaults to provide the colors and contrasts that work well for them."
> 
> <https://www.w3.org/TR/WCAG20-TECHS/G148.html>
> 
> > > I think I'll include that case in the report to draw the attention. I 
> > > think developers should be aware that if background can not be 
> > > explicitly determined then they should fix it. :-)
> > 
> > Default colors may vary across browsers and user settings, and determining them
> > "at runtime" is NOT any accessibility verification: the *code* must be verified!
> > (Do you need me to quote from the standard?)
> 
> I think that's still correct, that one has to verify the DOM/CSS, not the
> rendering...

No, after all not even that is correct: it's really a tricky standard, surely
sensible in its intent, I guess just not prescriptive enough, so technically
not verifiable, not strictly and not fully.

Anyway my 2c: I am no accessibility expert, nor this is an accessibility group,
nor I should write messages when I am in a hurry...

Julio

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

#35551

Cezary Tomczyk wrote:
> I do calculate a contrast ratio and for that purpose I need background 
> and foreground color. Currently, if I can't determine a background color 
> for a particular element then I do skip contrast ratio calculation.
> 
> I am working on https://www.aslint.org/. The code is not public yet, but 
> I have a plan to publish it.

Did you attempt any of the canvas + SVG based solutions yet? The method I mentioned in my last post has been implemented as a library:

<http://cburgmer.github.io/rasterizeHTML.js/>

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

#35552

On Sunday, 2 September 2018 21:40:42 UTC+2, Michael Haufe (TNO)  wrote:
> Cezary Tomczyk wrote:
> > I do calculate a contrast ratio and for that purpose I need background 
> > and foreground color. Currently, if I can't determine a background color 
> > for a particular element then I do skip contrast ratio calculation.
> > 
> > I am working on https://www.aslint.org/. The code is not public yet, but 
> > I have a plan to publish it.
> 
> Did you attempt any of the canvas + SVG based solutions yet?

Solution for what?  If the colors are not *defined*, that is WACG violation
regardless...

Julio

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

#35554

On Monday, 3 September 2018 12:51:15 UTC+2, Julio Di Egidio  wrote:
> On Sunday, 2 September 2018 21:40:42 UTC+2, Michael Haufe (TNO)  wrote:
> > Cezary Tomczyk wrote:
> > > I do calculate a contrast ratio and for that purpose I need background 
> > > and foreground color. Currently, if I can't determine a background color 
> > > for a particular element then I do skip contrast ratio calculation.
> > > 
> > > I am working on https://www.aslint.org/. The code is not public yet, but 
> > > I have a plan to publish it.
> > 
> > Did you attempt any of the canvas + SVG based solutions yet?
> 
> Solution for what?  If the colors are not *defined*, that is WACG violation
> regardless...

WCAG...

Julio

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

#35558

On 02/09/2018 21:40, Michael Haufe (TNO) wrote:
> Cezary Tomczyk wrote:
>> I do calculate a contrast ratio and for that purpose I need background
>> and foreground color. Currently, if I can't determine a background color
>> for a particular element then I do skip contrast ratio calculation.
>>
>> I am working on https://www.aslint.org/. The code is not public yet, but
>> I have a plan to publish it.
> 
> Did you attempt any of the canvas + SVG based solutions yet? The method I mentioned in my last post has been implemented as a library:
> 
> <http://cburgmer.github.io/rasterizeHTML.js/>

I haven't got a chance to check it, but Julio's right - missing defined 
background color is an issue anyway that should be raised.

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

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

#35546

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?

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#35548

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.

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

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

#35549

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?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#35550

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

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

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

#35557

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?”.

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

Note also that this approach does not handle background images, and requires 
additional work for non-rectangular shapes (e.g. round borders).
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web