- From: Erik Arvidsson <arv@chromium.org>
- Date: Tue, 20 Sep 2011 20:10:21 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps@w3.org
On Tue, Sep 20, 2011 at 19:47, 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? This is what we often refer to as the decorator pattern. The decorator pattern in XBL has the problem that it changes the interface of the element at runtime which I think we all agree is bad. However, maybe we can do decoration without the automatic hookup of the constructor? WDYT? -- erik
Received on Wednesday, 21 September 2011 03:11:07 UTC