Re: RCC and z-index a Dialog solution?


I've run into the same problem with dialog boxes that Jim mentions, and this
could be a very good solution. The only change this really makes is the
rendering order of one shadowTree, that of the root element.

I dont see the need for the obligatory opaqueness he mentions, since
standard shadowTrees don't have that restiction, but if that make the
rendering so much easier, I wouldn't have a real problem with it.

The lock/release (modal) mechanism could be very useful, as well... not only
for traditional dialogs, but for loading screens, and even debugging info.
It could block events on the main DOM tree, which would still allow the UA
to function normally (for navigating, closing the UA, etc.), so it would
prevent many of the problems associated with modal dialogs.

My 2 cents-

Jim Ley wrote:
> Hi,
> If we use RCC, we almost completely lose the ability to have any control
> the z-index of the SVG in the shadowTree (since moving the source XML
> element will change the XML model destroying the usefulness of seperating
> content/structure)   However RCC dynamic components will often want to
> "dialog boxes" and similar above the other content, for example an html
> validator may want to inform the user that something is invalid. Something
> people generally misuse alert (*) for currently.
> I think we could create dialog boxes from RCC components by providing a
> dialogTree attribute on the root svg element, which would have a
> setDialogTree method (analgous to the setShadowTree) which could be used
> set a dialogFragment into the dialogTree element.  A dialogTree
> documentFragment would always be rendered above of all other content - and
> it could even be required to have an opaque background for simpler
> rendering.
> It may also be useful to provide a mechanism to lock/release the dialog
> to provide some modality - it probably wouldn't need an actual formal
> lock/release method, but simply a flag that users can set to indicate if
> they expect the dialog to be modal, and perhaps an optional property on
> setDialogTree which would fail if it was set.
> Cheers,
> Jim.
> (*) I still have strong objections to alert being in the 1.2 spec, this
> hopefully be an alternative method to providing the same functionality.

Received on Wednesday, 27 August 2003 19:05:15 UTC