RE: Floating Boxes Idea

I think a value of "external-window" for "display" would be better,
especially if someday somebody wanted to make another value
for nested windows.

I think XLink in XML is supposed to cover this, however. Of course,
as with anything in XLink, it doesn't make a whole lot of sense.

As for the whole z-index thing...do you REALLY want that? I mean,
sure, it could be useful for little toolbars and such, but can you
imagine what advertisers would do with it? Yuck! Pop-up ads are
bad enough, without being unable to cover them up! The mind
boggles.

> -----Original Message-----
> From:	www-style-request@w3.org [SMTP:www-style-request@w3.org]
> Sent:	Thursday, July 29, 1999 10:52 AM
> To:	www-style@w3.org
> Subject:	Floating Boxes Idea
> 
> Firstly, I apologise if this has been discussed before, but I didn't
> notice and I have enjoyed thinking it up for myself :-)...
> 
> For better readability, I have put this suggestion in HTML format at
> <URL: http://www.lundboox.demon.co.uk/george/floating.html > That copy
> has a few modifications and corrections too. The example page doesn't
> work in IE because IE doesn't understand HTTP properly.
> 
> 
> ------------------------------------------------------------------------
> 
> Here are some thoughts on how, for interactive media, a new browser
> window might be created. With HTML 4, the target attribute is deprecated
> [1], effectively precluding authors from creating new windows without
> scripting. Such windows could be a useful way of providing navigation
> for a site, particularly if they could be made to float on top. As the
> navigation aid will not be stored as a separate document (except if
> specifically the CSS were to be applied to an <OBJECT> element), a
> method for keeping the aid on the screen persistently is also required.
> 
> Property: > display < (or should that be > position < ?)
>    An additional value of > floating < is proposed (another name might
> be better to avoid confusion with the float property). Elements with
> display: floating are removed from the flow and placed in a separate
> window. Resizability of the window depends upon the value of the
> > resizer < property. Details of toolbars, menus etc. are up to the UA
> although on a typical system none would be required. The window must be
> able to be moved around. UAs choosing not to implement this value for
> > display < should replace > floating < with > block < . The default
> size of the window depends on the content and the UA (width and height
> properties still apply). Positioning with > left < and > top <
> properties is relative to the window from which the navigation aid
> originated, but regardless UAs must not position it beyond the visible
> area of the screen.
>    If a floating window box (hmm, that phrase conjures up strange
> images!) contains no content, no new window must be created.
> 
> Property: > z-index <
>    This property has the effect that might be expected, i.e. a value
> other than auto specifies that the new window will appear _permanently_
> above (or, in a crazy scenario, below) the originating window. (This is
> the 'always on top' setting familiar to Windows' help users.) User
> agents should provide a way for users to close the window and to set the
> z-order to auto and back again.
>    Setting the > z-index < property affects the navigation aid's
> relationship with the originating window only (and any other floating
> windows it creates). In particular floating windows must not appear
> permanently on top of other browser windows (or any other windows).
> 
> Persistence
>    To be useful as a navigation aid, the floating window must remain in
> the same position when the user changes which page is being viewed.
> Therefore if a page contains a box in which (a) the > display < property
> has the value > floating < and (b) it has the same ID attribute value as
> a box in the previously-viewed window which also had display: floating,
> the floating window should not be removed. Otherwise, floating windows
> must be removed when the originating page is no longer being viewed.
> Thus during normal navigation using <A> links, floating windows remain
> open whilst the next page is being downloaded and displayed. Other
> operations, such as entering a URL manually, choosing a bookmark or
> closing the browser window, cause the floating window to close
> immediately.
>    In the situation as outlined above, the > z-index < , > left < , and
> > top <, properties should be ignored, so that they may be 'inherited'
> from the previous floating window. If the floating box has previously
> been closed (i.e. display had been given the value of none) then the new
> page's floating box should have display: none as well.
>   This persistence idea is admittedly a bit on the borders of what CSS
> should do but my whole concept is useless without it.
> 
> This proposal allows the creation of accessible web pages because the
> content of the box can be provided inline if necessary. There might be a
> case for defining a whole new property to initiate a floating window
> (rather than using display: floating) because that would allow users to
> create a stylesheet which explicitly forbade the creation floating
> windows.
> 
> The one big problem with this proposal is: adverts. But any given
> advertising company (e.g. Geocities) would probably use identical IDs
> for their pop-ups so a user could create an appropriate stylesheet to
> insist on display: none.
> 
> Ah well, I'd be interested in any comments.
> 
> 
> 
> [1] Whilst not specifically deprecated, the target attribute does not
> appear in the Strict DTD for HTML 4 <URL: http://www.w3.org/TR/REC-
> html40/strict.dtd >.
> -- 
> George Lund

Received on Friday, 30 July 1999 14:20:10 UTC