Skip to content

<dialog> in stacking elements #258

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

<dialog> in stacking elements #258

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a1b2871
Stacking Elements: Remove hard wrapping
scottgonzalez Mar 27, 2015
48e9d53
Stacking Elements: Consider `<dialog>` a stacking element
scottgonzalez Mar 27, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 12 additions & 26 deletions pages/theming/stacking-elements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,40 +6,26 @@
}
}</script>

Widgets that stack, or move in front of other elements, often present challenges
when placed into real world pages. It's usually easy to either change the `z-index`
or parent of the stacked element to avoid any collisions on the page. However,
jQuery UI needs a generic solution that doesn't require manually playing with
`z-index` values. This is accomplished via the `ui-front` class, and usually an
accompanying `appendTo` option on stacking widgets.
Widgets that stack, or move in front of other elements, often present challenges when placed into real world pages. It's usually easy to either change the `z-index` or the parent of the stacked element to avoid any collisions on the page. However, jQuery UI needs a generic solution that doesn't require manually playing with `z-index` values. This is accomplished via the `ui-front` class, and usually an accompanying `appendTo` option on stacking widgets.



## The `ui-front` class

The `ui-front` class is very basic. It just sets a static `z-index` value on the
element. However, the existence of the class is used to indicate where stacking
elements should be appended. This allows us to take advantage of nested stacking
contexts, resulting in a default DOM position that works for most use cases.
The `ui-front` class is very basic. It just sets a static `z-index` value on the element. However, the existence of the class is used to indicate that an element is a stacking element, which indicates where additional stacking elements should be appended. This allows us to take advantage of nested stacking contexts, resulting in a default DOM position that works for most use cases.

*Note: When using `ui-front`, you must also set `position` to `relative`,
`absolute` or `fixed` in order for the `z-index` to be applied.*
*Note: When using `ui-front`, you must also set `position` to `relative`, `absolute` or `fixed` in order for the `z-index` to be applied.*



## The stacking technique

Any widget that appends a stacking element to the page must use the `ui-front`
class, and in many cases should have an `appendTo` option. The following logic
should be applied to the stacking element:

* If a value is provided for the `appendTo` option, then append the stacking
element to the specified element.
* If the `appendTo` option is set to `null` (default), then the widget should
walk up the DOM from the associated element. For example, when the autocomplete
menu is appended to the DOM, the walking starts from the associated input element.
* If an element with the `ui-front` class is found, append to that element.
* If no element with the `ui-front` class is found, append to the body.
* The stacking element must also have `position` set to `relative`, `absolute`,
or `fixed` in order for the `z-index` from the `ui-front` class to be applied.
Using [.position()](/position/) will automatically set `position`.
Any widget that appends a stacking element to the page must use the `ui-front` class, and in many cases should have an `appendTo` option. The following logic should be applied to the stacking element:

* If a value is provided for the `appendTo` option, then append the stacking element to the specified element.
* If the `appendTo` option is set to `null` (default), then the widget should walk up the DOM from the associated element. For example, when the autocomplete menu is appended to the DOM, the walking starts from the associated input element.
* If another stacking element is found, append to that element.
* If no other stacking elements are found, append to the body.
* The stacking element must also have `position` set to `relative`, `absolute`, or `fixed` in order for the `z-index` from the `ui-front` class to be applied. Using [.position()](/position/) will automatically set `position`.

Stacking elements are defined as elements with the `ui-front` class, or any native element that creates a new stacking context. Currently, `<dialog>` is the only native element that is considered a stacking element.