This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The visibility prose around the BODY element in the spec should be changed to explain why it's always considered visible by WebDriver. Also the bullet points needs to be turned into an actual algorithm (covered by bug 26275). Setting background-color or background-image on either the HTML or the first BODY element triggers special casing. If set they get transposed on to the canvas painting area. This means for example that if your BODY element has a background-color set and you resize the viewport, the coloured area will always cover the whole viewport. The only two provisions are: * The element has display: none set * The element has visibility: hidden set If the background-color is undefined in user style the default is "transparent". The CSS spec defines this to be undefined user agent behaviour, but in all desktop and mobile browsers' base.css rules it means "white". However, this isn't true for HTML/CSS used in native OS widgets on such systems as Firefox OS. My suggestion is for WebDriver to only consider visibility within the context of the current top-level browsing context and not window-on-window transparency. What this effectively means for WebDriver is that the canvas is always visible, and because HTML (alternatively the first BODY) element's styling properties are propagated on to it, it is consequently always visible. This applies to both HTML and XHTML documents (even when served as application/xhtml+xml). The relevant CSS spec prose is here: http://dev.w3.org/csswg/css-backgrounds/#special-backgrounds There's a bug in the current draft which has been logged here about display: none and visibility: hidden (not in the spec at the time of writing this): http://lists.w3.org/Archives/Public/www-style/2014Jul/0137.html
https://dvcs.w3.org/hg/webdriver/rev/19e266efb48d
Created attachment 1512 [details] Patch 1/2 Following filing this bug the CSS WG has changed their position on this: http://lists.w3.org/Archives/Public/www-style/2014Jul/0312.html If the element whose background would be used for the background of the canvas (that is the first body element or its ancestor) has display: none the background is no longer undefined UA behaviour, but "transparent". This means the window could technically be see-through. Rethinking what I said earlier, this element is obviously not visible to the human eye. There's also the case of background-position on a background-image which does make it visible. This means we need to take into account the following things: 1. Which element the canvas' background is propagated from. 2. That visibility: hidden on this element is ignored completely, but that display: none isn't. 3. That display: none makes background-color "transparent" which might affect the function for getting the computed CSS value. 4. We also need to consider background-image. 5. There might also be issues with the content CSS property here (needs investigation). r19e266efb48d doesn't really address all of these concerns so I'm reopening this. I'm attaching the first half of a patch which separates the algorithm we need for populating the response from the element visibility algorithm. I'll upload my second patch later.
Created attachment 1517 [details] Revised element visibility proposal Attaching an updated patch including a rewritten element visibility algorithm. It's very inefficient and probably wrong, but I think an improvement over the list of somewhat inaccurate conditions that are in the spec now.
For the most part this looks good. We need to change visibility to displayed in your text. This was agreed by everyone a while ago because the we are trying to see if an element can be visible Can you please update and I will walk through this again