Re: A more detailed introduction to the proposal for overlay rendering boxes

It looks like you are trying to reinvent a very basic <dialog>:
https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element ?

Benjamin

On 12/6/14, 6:07 AM, Behrang Saeedzadeh wrote:
> Hi,
> 
> This is another attempt to hopefully start a dialog and discuss adding a
> new type of rendering box, namely |overlay|.
> 
> 
>   <https://gist.github.com/behrangsa/c30034c07d7adeee934d#introduction>Introduction
> 
> When building Web apps, every now and then we have to implement one or
> more of these features:
> 
>   * Putting a semi-transparent |<div>| over an element to /disable/ it
>     and consequently prevent user from interacting with it. This
>     semi-transparent div's size and location should be kept in-sync with
>     the element at all times and in all media query breakpoints.
>   * In a site builder (e.g. Jetstrap <https://jetstrap.com/>, online
>     diagramming tool (e.g. draw.io <http://draw.io/>, or something
>     similar we have a composite component, and we want to let the user
>     edit its properties by double clicking on it.
>   * When implementing carousels
>     <http://dimsemenov.com/plugins/royal-slider/slider-in-lightbox/>,
>     or lightboxes <http://lokeshdhakar.com/projects/lightbox2/>, we want
>     to put a semi-transparent overlay over all the content, and display
>     the images or the lightbox on top of this overlay.
> 
> At the moment, such tools rely on JavaScript to dynamically
> add /overlay/ elements to the DOM, or to show/hide them in response to
> user actions. In some cases, the size and location of the target element
> should be calculated and the overlay should be moved to the right
> location and set to the proper size accordingly. This by itself is not
> an easy task to achieve, and most implementations that I have seen break
> in various undocumented edge cases. What happens if the parent element
> is a float? What if somewhere in the hierarchy we have an absolute
> element? When you add media queries and responsive design to the mix,
> this suddenly becomes even more difficult to implement smoothly and in a
> sophisticated manner. But it doesn't really need to be this complex.
> 
> 
>   <https://gist.github.com/behrangsa/c30034c07d7adeee934d#the-display-overlay-alternative>/display:
>   overlay; /An alternative
> 
> My proposal is to add a new type or rendering box,
> called |overlay| using which we can achieve the same goals, without
> JavaScript, and in a way that works in harmony with media
> queries. |overlay |elements, have a z-index that is greater than the
> biggest z-index of the children of its parent element, as well as the
> parent itself so it always paints over its parent and the children of
> its parent.
> 
> In its simplest form, the |overlay| rendering box works like this.
> Consider the following HTML sctructure:
> 
> <style>
>   .overlay {
>     display: overlay;
>     background-color: rgba(100, 100, 100, 0.5);
>   }
> </style>
> <div class="complex-component">
>   <div class="overlay"></div>
>   <!-- Lots of elements that togehter make our complex component -->
> </div>
> 
> In this case the |div.overlay| element covers |div.complex-component| as
> well as its children. When the page renders, you'll see a bright,
> semi-transparent green box over the complex-component element. Then by
> configuring a mouse listener on the |div.overlay| it will be very easy
> to move the |div.complex-componenrt| around. Or in response to a double
> click on it, to show an editor to configure the properties of the
> component in our visual form builder, etc.
> 
> In order to hide the |div.overlay|, we can simply change
> its |display| back to |none|.
> 
> if |div.complex-component|'s size or location changes for whatever
> reason, its child overlay will automatically adjust itself to it.
> 
> For lightboxes, similarly, we can add an overlay div to
> the |<html>| element:
> 
> <html>
>   <div style="display:overlay;"></div>
>   <!-- Content -->
> </html>
> 
> I would really like to hear your opinion on this. Am I missing something
> here? Are there current or other proposesd CSS features that already can
> do this?
> 
> Thanks in advance, 
> Behrang
>

Received on Saturday, 6 December 2014 21:50:13 UTC