Re: RCC and z-index a Dialog solution?

Hi-

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-
-Doug

Jim Ley wrote:
>
> Hi,
>
> If we use RCC, we almost completely lose the ability to have any control
of
> 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
place
> "dialog boxes" and similar above the other content, for example an html
form
> 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
to
> 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
tree
> 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
will
> hopefully be an alternative method to providing the same functionality.
>

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