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

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

Element visible

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

Contents

  Element visible Andrew Poulos <ap_prog@hotmail.com> - 2014-07-09 10:09 +1000
    Re: Element visible Andrew Poulos <ap_prog@hotmail.com> - 2014-07-09 13:32 +1000
      Re: Element visible "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-07-09 09:54 +0200
      Re: Element visible Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-09 11:18 +0200
        Re: Element visible Andrew Poulos <ap_prog@hotmail.com> - 2014-07-09 23:17 +1000
          Re: Element visible John Harris <niam@jghnorth.org.uk.invalid> - 2014-07-09 16:08 +0100
        Re: Element visible Andrew Poulos <ap_prog@hotmail.com> - 2014-07-10 10:07 +1000
          Re: Element visible "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-07-10 09:15 +0200
            Re: Element visible "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2014-07-10 10:45 +0300
              Re: Element visible Andrew Poulos <ap_prog@hotmail.com> - 2014-07-10 22:13 +1000
                Re: Element visible "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-07-10 14:31 +0200
                  Re: Element visible Scott Sauyet <scott.sauyet@gmail.com> - 2014-07-10 13:35 -0700
                    Re: Element visible "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-07-11 00:23 +0200
                      Re: Element visible Scott Sauyet <scott.sauyet@gmail.com> - 2014-07-12 20:09 -0700
                        Re: Element visible "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-07-13 09:07 +0200
            Re: Element visible John Harris <niam@jghnorth.org.uk.invalid> - 2014-07-10 10:46 +0100
          Re: Element visible Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-10 12:10 +0200
            Re: Element visible Andrew Poulos <ap_prog@hotmail.com> - 2014-07-14 13:00 +1000
            Re: Element visible Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-15 15:08 +0200

#25263 — Element visible

Is the only way to know if an element could (ignoring if its been 
scrolled off screen or under another element) be visible is to test that 
its display is not 'none', its opacity is greater than 0, its visibility 
is 'visible', and that its width and height are greater than zero?

Andrew Poulos

[toc] | [next] | [standalone]

#25265

On 9/07/2014 12:18 PM, Stefan Ram wrote:
> Andrew Poulos <ap_prog@hotmail.com> writes:
>> Is the only way to know if an element could (ignoring if its been
>> scrolled off screen or under another element) be visible is to test that
>> its display is not 'none', its opacity is greater than 0, its visibility
>> is 'visible', and that its width and height are greater than zero?
>
> cssexample { position: absolute; width: 14em; left: -999em; }

And also ignoring other instances where its positioned off screen.

Andrew Poulos

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

#25266

Andrew Poulos <ap_prog@hotmail.com> wrote on 09 jul 2014 in 
comp.lang.javascript:

> On 9/07/2014 12:18 PM, Stefan Ram wrote:
>> Andrew Poulos <ap_prog@hotmail.com> writes:
>>> Is the only way to know if an element could (ignoring if its been
>>> scrolled off screen or under another element) be visible is to test that
>>> its display is not 'none', its opacity is greater than 0, its visibility
>>> is 'visible', and that its width and height are greater than zero?
>>
>> cssexample { position: absolute; width: 14em; left: -999em; }
> 
> And also ignoring other instances where its positioned off screen.

The content is empty, and no inner background.
The content is empty, 
  and the inner background is the same as the background.
The img is the same as te background.
The img is transparent.
The monitor is switched off.
The window is not visible on screen.

But all of these are OFF topic, wrong NG, mate.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#25267

Andrew Poulos wrote:

> On 9/07/2014 12:18 PM, Stefan Ram wrote:
>> Andrew Poulos <ap_prog@hotmail.com> writes:
>>> Is the only way to know if an element could (ignoring if its been
>>> scrolled off screen or under another element) be visible is to test that
>>> its display is not 'none', its opacity is greater than 0, its visibility
>>> is 'visible', and that its width and height are greater than zero?
>>
>> cssexample { position: absolute; width: 14em; left: -999em; }
> 
> And also ignoring other instances where its positioned off screen.

Wrong newsgroup, stupid/no question → stupid/no answer.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25268

On 9/07/2014 7:18 PM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 9/07/2014 12:18 PM, Stefan Ram wrote:
>>> Andrew Poulos <ap_prog@hotmail.com> writes:
>>>> Is the only way to know if an element could (ignoring if its been
>>>> scrolled off screen or under another element) be visible is to test that
>>>> its display is not 'none', its opacity is greater than 0, its visibility
>>>> is 'visible', and that its width and height are greater than zero?
>>>
>>> cssexample { position: absolute; width: 14em; left: -999em; }
>>
>> And also ignoring other instances where its positioned off screen.
>
> Wrong newsgroup, stupid/no question → stupid/no answer.

You're wrong three times in one reply.

Andrew Poulos

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

#25269

On Wed, 09 Jul 2014 23:17:00 +1000, Andrew Poulos
<ap_prog@hotmail.com> wrote:

>On 9/07/2014 7:18 PM, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>
>>> On 9/07/2014 12:18 PM, Stefan Ram wrote:
>>>> Andrew Poulos <ap_prog@hotmail.com> writes:
>>>>> Is the only way to know if an element could (ignoring if its been
>>>>> scrolled off screen or under another element) be visible is to test that
>>>>> its display is not 'none', its opacity is greater than 0, its visibility
>>>>> is 'visible', and that its width and height are greater than zero?
>>>>
>>>> cssexample { position: absolute; width: 14em; left: -999em; }
>>>
>>> And also ignoring other instances where its positioned off screen.
>>
>> Wrong newsgroup, stupid/no question ? stupid/no answer.
>
>You're wrong three times in one reply.

I was going to say that :-)

Alternatively, people should read the question before condemning the
author.

  John

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

#25270

On 9/07/2014 7:18 PM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 9/07/2014 12:18 PM, Stefan Ram wrote:
>>> Andrew Poulos <ap_prog@hotmail.com> writes:
>>>> Is the only way to know if an element could (ignoring if its been
>>>> scrolled off screen or under another element) be visible is to test that
>>>> its display is not 'none', its opacity is greater than 0, its visibility
>>>> is 'visible', and that its width and height are greater than zero?
>>>
>>> cssexample { position: absolute; width: 14em; left: -999em; }
>>
>> And also ignoring other instances where its positioned off screen.
>
> Wrong newsgroup, stupid/no question → stupid/no answer.

Media queries can turn things on or off. User actions can turn things on 
or off. A user turns a thing on and subsequently a media query turns it 
off. If I'm tracking the user interaction the thing is on when in fact 
its not. So then to know if the thing is on or off I need to either 
track media queries and user interaction or, perhaps, I can just ask it, 
but what would I test for?

Andrew Poulos

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

#25272

Andrew Poulos <ap_prog@hotmail.com> wrote on 10 jul 2014 in 
comp.lang.javascript:

> On 9/07/2014 7:18 PM, Thomas 'PointedEars' Lahn wrote:
>> Wrong newsgroup, stupid/no question ā' stupid/no answer.
> 
> Media queries can turn things on or off. User actions can turn things on 
> or off. A user turns a thing on and subsequently a media query turns it 
> off. If I'm tracking the user interaction the thing is on when in fact 
> its not. So then to know if the thing is on or off I need to either 
> track media queries and user interaction or, perhaps, I can just ask it, 
> but what would I test for?

Do you have a javascript related Q?

If so, please elaborate on "things".

But if this is a about CSS, go to a dedicated NG.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#25273

2014-07-10 10:15, Evertjan. wrote:

> Do you have a javascript related Q?

I have not had difficulties with understanding the question or with 
seeing it as being on-topic. The question was about ways to know if an 
element could be visible, and it seems obvious, in the context of this 
group, that it meant to ask how to test such a thing in JavaScript. 
Basically, how could you write a JavaScript function that takes an 
element node as argument and returns true or false depending on whether 
the element is visible or not.

The main problem with the question is that it is too vague. What is 
“visible” in this context. You already made some good points about this. 
Apparently some of the conditions for being visible, in some sense, are 
things you cannot test in JavaScript, like the user being blind. But 
many things, like the position of the element, its dimensions, and CSS 
styles and HTML attributes that apply to it, can be tested, to some 
extent at least.

Instead of theoretical discussions about such aspects and detailed 
treatment of how some specific things affecting visibility might be 
tested, maybe the OP should clarify what he is trying to accomplish. 
Some sample code, preferably with a link to an online demo, would 
greatly help in understanding what the practical problem is.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

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

#25285

On 10/07/2014 5:45 PM, Jukka K. Korpela wrote:
> 2014-07-10 10:15, Evertjan. wrote:
>
>> Do you have a javascript related Q?
>
> I have not had difficulties with understanding the question or with
> seeing it as being on-topic. The question was about ways to know if an
> element could be visible, and it seems obvious, in the context of this
> group, that it meant to ask how to test such a thing in JavaScript.
> Basically, how could you write a JavaScript function that takes an
> element node as argument and returns true or false depending on whether
> the element is visible or not.
>
> The main problem with the question is that it is too vague. What is
> “visible” in this context. You already made some good points about this.
> Apparently some of the conditions for being visible, in some sense, are
> things you cannot test in JavaScript, like the user being blind. But
> many things, like the position of the element, its dimensions, and CSS
> styles and HTML attributes that apply to it, can be tested, to some
> extent at least.
>
> Instead of theoretical discussions about such aspects and detailed
> treatment of how some specific things affecting visibility might be
> tested, maybe the OP should clarify what he is trying to accomplish.
> Some sample code, preferably with a link to an online demo, would
> greatly help in understanding what the practical problem is.

I've found window.matchMedia and together with addListener (given I'll 
need to work around the lack of support for it in IE 9) I should be able 
to track the "visibility" of the things that need tracking.

Andrew Poulos

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

#25287

Andrew Poulos <ap_prog@hotmail.com> wrote on 10 jul 2014 in 
comp.lang.javascript:

> I've found window.matchMedia and together with addListener (given I'll 
> need to work around the lack of support for it in IE 9) I should be able 
> to track the "visibility" of the things that need tracking.

The visibility does not mean you can see the element.

You will first have to define visibility as something else,
perhaps having the CSS style visibility as not hidden,
and the css style display as not none,
and z-index not making the element below an other one,
and ... ad libitum.

All this is not javascript related.

However if you programme consistent html cum css, 
you will know if an element is visible,
there is no need to "track".

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#25289

Evertjan. wrote:
> Andrew Poulos wrote
> 
>> I've found window.matchMedia and together with addListener (given I'll 
>> need to work around the lack of support for it in IE 9) I should be able 
>> to track the "visibility" of the things that need tracking.
> 
> The visibility does not mean you can see the element.
> You will first have to define visibility as something else,
> perhaps having the CSS style visibility as not hidden,
> and the css style display as not none,
> and z-index not making the element below an other one,
> and ... ad libitum.
> 
> All this is not javascript related.

With the OP's discussion of "tracking" the visibility, presumably
the values of some of these properties can change dynamically.  If
that's the case, then I think this is very much the domain of client-
side Javascript.  


> However if you programme consistent html cum css, 
> you will know if an element is visible,
> there is no need to "track".

Only if those properties remain static.

  -- Scott

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

#25290

Scott Sauyet <scott.sauyet@gmail.com> wrote on 10 jul 2014 in 
comp.lang.javascript:

> Evertjan. wrote:
>> Andrew Poulos wrote
>> 
>>> I've found window.matchMedia and together with addListener (given I'll 
>>> need to work around the lack of support for it in IE 9) I should be able 
>>> to track the "visibility" of the things that need tracking.
>> 
>> The visibility does not mean you can see the element.
>> You will first have to define visibility as something else,
>> perhaps having the CSS style visibility as not hidden,
>> and the css style display as not none,
>> and z-index not making the element below an other one,
>> and ... ad libitum.
>> 
>> All this is not javascript related.
> 
> With the OP's discussion of "tracking" the visibility, presumably
> the values of some of these properties can change dynamically.  If
> that's the case, then I think this is very much the domain of client-
> side Javascript.  

As I say below, the dynamics of the page could be done by javascript,
or by pure css, or by manually changing the window size,
but should be fully designed by the code and the specs of the browser.
 
>> However if you programme consistent html cum css, 
>> you will know if an element is visible,
>> there is no need to "track".
> 
> Only if those properties remain static.

Not at all.

The dynamics of a page are fully defined by the programming,
and you can "compute" the effect at any moment.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#25315

 Evertjan. wrote:
> Scott Sauyet wrote:
>> Evertjan. wrote:

>>> However if you programme consistent html cum css, 
>>> you will know if an element is visible,
>>> there is no need to "track".
>> 
>> Only if those properties remain static.
> 
> Not at all.
> The dynamics of a page are fully defined by the programming,
> and you can "compute" the effect at any moment.

Obviously we're using "track" differently.  Computing the effect at the
required moment is the essence of tracking to me.  I'm assuming you're
talking about some event-based real-time watcher?  If so, I agree that
such is not necessary.  But it's certainly not the impression I got
regarding the requirements of either the OP or the subsequent discussion.

  -- Scott

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

#25316

Scott Sauyet <scott.sauyet@gmail.com> wrote on 13 jul 2014 in 
comp.lang.javascript:

>  Evertjan. wrote:
>> Scott Sauyet wrote:
>>> Evertjan. wrote:
> 
>>>> However if you programme consistent html cum css, 
>>>> you will know if an element is visible,
>>>> there is no need to "track".
>>> 
>>> Only if those properties remain static.
>> 
>> Not at all.
>> The dynamics of a page are fully defined by the programming,
>> and you can "compute" the effect at any moment.
> 
> Obviously we're using "track" differently.  Computing the effect at the
> required moment is the essence of tracking to me.  I'm assuming you're
> talking about some event-based real-time watcher?  If so, I agree that
> such is not necessary.  But it's certainly not the impression I got
> regarding the requirements of either the OP or the subsequent discussion.

Agree.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#25274

On Thu, 10 Jul 2014 09:15:53 +0200, "Evertjan."
<exxjxw.hannivoort@inter.nl.net> wrote:

>Andrew Poulos <ap_prog@hotmail.com> wrote on 10 jul 2014 in 
>comp.lang.javascript:
>
>> On 9/07/2014 7:18 PM, Thomas 'PointedEars' Lahn wrote:
>>> Wrong newsgroup, stupid/no question ā' stupid/no answer.
>> 
>> Media queries can turn things on or off. User actions can turn things on 
>> or off. A user turns a thing on and subsequently a media query turns it 
>> off. If I'm tracking the user interaction the thing is on when in fact 
>> its not. So then to know if the thing is on or off I need to either 
>> track media queries and user interaction or, perhaps, I can just ask it, 
>> but what would I test for?
>
>Do you have a javascript related Q?
>
>If so, please elaborate on "things".
>
>But if this is a about CSS, go to a dedicated NG.

How on earth would you *test* anything using CSS ?

Always read the question again before posting (and avoid being misled
by Thomas); it saves embarrassment.

  John

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

#25275

Andrew Poulos wrote:

>> Andrew Poulos wrote:
>>> And also ignoring other instances where its positioned off screen.
>
> Media queries can turn things on or off. User actions can turn things on
> or off. A user turns a thing on and subsequently a media query turns it
> off. If I'm tracking the user interaction the thing is on when in fact
> its not. So then to know if the thing is on or off I need to either
> track media queries and user interaction or, perhaps, I can just ask it,
> but what would I test for?

Good question.

I can only see two possibilities, other than those that you have excluded, 
that can cause an element to be not visible:

One, the element may not be part of a real document but exist only as 
element object in memory.  In that case the value of the “parentNode” 
property of that object would be “null” or at least a false-value because it 
has no parent node.

However, it may also be a descendent node of a node that only exists in 
memory.  In that case the former’s “parentNode” property value would not be 
“null”, but following up to the next ancestor until the “parentNode” 
property value of the target node is “null” should be sufficient in most 
cases.

Yet, with this approach there is a potential for false positives because the 
root element node’s “parentNode” property value is always “null” (or a 
false-value).  I have just found out (in Chromium 34) that even the value of 
the “ownerDocument” property of a node object can be not “null” if the 
represented node was previously part of a real (HTML5) document.  So I have 
yet to find a reliable test for this possibility.

Two, the element may be part of the document but, as you indicated, 
stylesheet declarations prevent it from being visible.  In that case you 
need to retrieve the computed style of the element and check if any of that 
style’s properties that pertain to display, or a combination of them, could 
cause the element to be not visible.  You may also need to consider the 
style of the element’s ancestors, for example in the case of the “display” 
property.

There is a lot of information about this problem on the Web.  Apparently 
none of the existing approaches cover the full range of possibilities.
See the CSS specifications and the pertaining newsgroup for details.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25354

On 10/07/2014 8:10 PM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>>> Andrew Poulos wrote:
>>>> And also ignoring other instances where its positioned off screen.
>>
>> Media queries can turn things on or off. User actions can turn things on
>> or off. A user turns a thing on and subsequently a media query turns it
>> off. If I'm tracking the user interaction the thing is on when in fact
>> its not. So then to know if the thing is on or off I need to either
>> track media queries and user interaction or, perhaps, I can just ask it,
>> but what would I test for?
>
> Good question.
>
> I can only see two possibilities, other than those that you have excluded,
> that can cause an element to be not visible:
>
> One, the element may not be part of a real document but exist only as
> element object in memory.  In that case the value of the “parentNode”
> property of that object would be “null” or at least a false-value because it
> has no parent node.
>
> However, it may also be a descendent node of a node that only exists in
> memory.  In that case the former’s “parentNode” property value would not be
> “null”, but following up to the next ancestor until the “parentNode”
> property value of the target node is “null” should be sufficient in most
> cases.
>
> Yet, with this approach there is a potential for false positives because the
> root element node’s “parentNode” property value is always “null” (or a
> false-value).  I have just found out (in Chromium 34) that even the value of
> the “ownerDocument” property of a node object can be not “null” if the
> represented node was previously part of a real (HTML5) document.  So I have
> yet to find a reliable test for this possibility.
>
> Two, the element may be part of the document but, as you indicated,
> stylesheet declarations prevent it from being visible.  In that case you
> need to retrieve the computed style of the element and check if any of that
> style’s properties that pertain to display, or a combination of them, could
> cause the element to be not visible.  You may also need to consider the
> style of the element’s ancestors, for example in the case of the “display”
> property.
>
> There is a lot of information about this problem on the Web.  Apparently
> none of the existing approaches cover the full range of possibilities.
> See the CSS specifications and the pertaining newsgroup for details.

Something that can be explained easily (is the element 'blah' visible') 
and yet be difficult to code. Now it seems I need to combine what you've 
written with the approach I am working on using window.matchMedia.

Thanks to all for your input.

Andrew Poulos

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

#25374

Thomas 'PointedEars' Lahn wrote:

> I can only see two possibilities, other than those that you have excluded,
> that can cause an element to be not visible:
> 
> One, the element may not be part of a real document but exist only as
> element object in memory.  In that case the value of the “parentNode”
> property of that object would be “null” or at least a false-value because
> it has no parent node.
> 
> However, it may also be a descendent node of a node that only exists in
> memory.  In that case the former’s “parentNode” property value would not
> be “null”, but following up to the next ancestor until the “parentNode”
> property value of the target node is “null” should be sufficient in most
> cases.
> 
> Yet, with this approach there is a potential for false positives because
> the root element node’s “parentNode” property value is always “null” (or a
> false-value).  I have just found out (in Chromium 34) that even the value
> of the “ownerDocument” property of a node object can be not “null” if the
> represented node was previously part of a real (HTML5) document.  So I
> have yet to find a reliable test for this possibility.

Correction: At least the root element node’s “parentNode” property value is 
not “null” (or a false-value) if, and only if, that element is currently 
part of a document.  Hpwever, a document object’s “parentNode” property 
value is always “null” (or a false-value).  This is the reliable test I was 
looking for:

  function inDocument (e, doc)
  {
    /* null or undefined */
    if (doc == null)
    {
      doc = e.ownerDocument;
    }

    while ((e = e.parentNode))
    {
      if (e == doc)
      {
        return true;
      }
    }

    return false;
  }

Note: This method cannot tell whether “doc” is visible.  However, there 
appears to be the “visibilityState” property for that, and it is a W3C 
Recommendation:

<https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

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

csiph-web