698844 - getComputedStyle on elements not in the DOM always returns "block" or "table" or "none" for the 'display' property

Status: RESOLVED DUPLICATE of bug 1374994

(Core :: CSS Parsing and Computation, defect)

Description

[Andy Earnshaw]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

There are two tests that Gecko is failing with getComputedStyle - 

  1. on a newly created <input> element, and 

      window.getComputedStyle(document.createElement("input")).display
      //-> "block"

  2. on a pre-existing <input> element already in the document

      window.getComputedStyle(document.getElementsByTagName("input")[0]).display
      //-> "inline"


Actual results:

For both tests, Gecko returns conflicting values, both of which are seemingly incorrect.


Expected results:

According to http://www.w3.org/TR/CSS2/sample.html, the Default StyleSheet for HTML 4, <input> elements should be "inline-block".  This makes perfect sense because they honour width and height, whereas "inline" elements do not.

Trident/IE 9 returns "inline-block" for both tests, WebKit/Chrome 15 returns "inline-block" for the second test and an empty string, "", for the first.  I'm unsure as to whether values should be computed for elements that have not yet been added to the document.

I did a little searching and found http://www.iecss.com/whatwg.css, supposedly the default stylesheet for HTML 5 elements.  I'm not sure how official this is, but I believe that it is incorrect in defining all <input> elements other than `type="hidden"` should be "inline".

Comment 1

[Boris Zbarsky [:bzbarsky]]

The default stylesheet involved is not normative, and we do not have such a rule in our UA sheet.  The HTML5 spec's version of this stylesheet also does not have such a rule.  As a note, <input> is a _replaced_ inline element, which do honor width and height properties; see the CSS spec.  So the behavior for the second test is correct in Gecko.  Note that per spec there is no particular requirement for that test; UAs are free to have any rules they want in their UA stylesheet.

You may want to look up the previous bug reports with discussion about this.

> I'm unsure as to whether values should be computed for elements that have not yet been
> added to the document.

Per proposed spec, yes.

The behavior for the out-of-the-DOM input is more interesting.  I bet that happens because we do the "this is a root element" style fixup for it, which forces display to "block".  David, we should probably limit that test to the actual documentElement....

Note that this issue s not specific to <input>; the same thing happens with <span>.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The problem is that the display fixup happens in nsStyleContext::ApplyStyleFixups at which point we know nothing about the _element_ involved, only about the fact that the style context has no parent.

Should we, perhaps, move that particular fixup to the style set, where we do know the element?

Comment 3

[Andy Earnshaw]

I see, yes, you're absolutely right.  I came across the issue when copying *all* styles from an input element to a span - in Chrome/IE the two elements looked the same, but in Gecko the span ignores the copied value for width.  It's an easy fix just to apply display:inline-block after copying all the other styles.

FWIW, Presto's behaviour is identical to WebKit for test 1 (empty string), and identical to Gecko for test 2 ("inline").

Comment 4

[Emilio Cobos Álvarez (:emilio)]

This is fixed by Stylo.