Hi,
In our recent attempts to find suitable styling for the new HTML
<details> element, we came across some limitations relating to XBL and
CSS that we would like to find a solution for.
A detailed description of the problems was posted to the WHATWG list
recently [1], but in summary, the problem is that in XBL, when a shadow
element in inserted around some content for the sole purpose of hiding
and showing that content as needed (i.e. Rendering the open and closed
states of the details element), it has the unfortunate side effect of
inserting an additional block box in the layout that can interfere with
other styles in unfortunate ways.
For example, given a details element like this:
<details>
<summary>Summary</summary>
Content
</details>
With bindings, a shadow element would need to be inserted around the
content by the implementation, like this:
<details>
<summary>Summary</summary>
<::shadow-element>
Content
</::shadow-element>
</details>
This allows the 'display' property of the ::shadow-element to be toggled
between 'inline' and 'none', thus hiding and showing the content.
However, a problem occurs when authors have markup like this
<details>
<summary>Summary</summary>
<div>Content</div>
</details>
And then apply styles like this:
details { display: table; }
summary, div { display: table-cell; }
Ordinarily, this would render just fine. The two table-cells would have
a single surrounding table-row box around them inside the details'
element table box.
But with the shadow element in there as an inline element, it interferes
with that.
<details>
<summary>Summary</summary>
<::shadow-element>
<div>Content</div>
</::shadow-element>
</details>
This extra line box interferes with the table layout algorithm, which
makes the second cell end up with its own independent table and
table-row layout boxes around it. This is undesirable.
It seems that with bindings, this is likely to be a common scenario,
where it would be useful to eliminate the effect of unwanted layout
boxes from a binding.
For this, one solution we came up with was a new value for 'display'
that means to not generate a layout box for the element, but to still
render the child content within as if the element itself wasn't there.
display: transparent;
Such a value would mean the shadow element could be toggled between
'none' and 'transparent', and thus not have any unwanted side effects on
the layout.
We haven't yet implemented this. We instead use some internal magic to
work around the limitation. But we would like to discuss the
feasibility of introducing this feature.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-April/031132.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/http://www.opera.com/