- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 20 Sep 2011 20:15:58 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps@w3.org
On Tue, Sep 20, 2011 at 7:47 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > A comment on use cases that was brought up over here. > > There's a use case that is not addressed by XBL1 and impossible to quite > address in a JS library that goes as follows. Say you have some data in a > <table>. Semantically it's a data table. But you may want to present it as > a graphic (SVG or canvas). > > XBL1 will let you construct a block or inline box for the <table> and then > stick a shadow tree containing just an <svg> or <canvas> inside. But it > would be nicer if that wrapper block/inline box were not there and if the > box that were created were just the <svg> or <canvas> box... So > effectively, treating the element the component is attached to as a > <content> element in terms of box tree construction. > > Is this a use case we want to address? I think this is properly a CSS issue. You want an element to not exist in the box tree, but to still have its children in the tree, which should be controllable with a display value, perhaps called 'transparent'. It's a more complex version of display:none. This sort of functionality would be useful outside of this specific use-case as well. For example, it seems that the most natural and easy way to handle the <details> element is to produce a shadow wrapper around its non-<summary> contents. That way, one can do a simple "details:not(:open) > magic-wrapper { display: none; }". But you don't want this wrapper to show up and interfere with styling when the <details> is open. display:transparent would help here. ~TJ
Received on Wednesday, 21 September 2011 03:16:46 UTC