CSS3/FixedPosition: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "== Mobile and Tablets == * Mobile effectively has two viewports: what content layout sees and what the user sees. * What behavior do we want to support for position: fixed on mo...")
 
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
There are a few areas where it's become clear we need to make improvements on the currently specified/implemented behavior of position:fixed:
== Mobile and Tablets ==
== Mobile and Tablets ==
The problem of zooming some content and not others.


* Mobile effectively has two viewports: what content layout sees and what the user sees.
* Mobile effectively has two viewports: what content layout sees and what the user sees.
Line 5: Line 10:
** Backward compatible with desktop (i.e., leaves most pages usable that weren't designed with zooming in mind)
** Backward compatible with desktop (i.e., leaves most pages usable that weren't designed with zooming in mind)
** ...
** ...
* http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html
 
* Proposal 1: As simple as possible
** Only allow position fixed elements for zoomable non-1.0-scale pages.
** This hides position fixed elements for legacy desktop sites, which normally has extraneous content that can get in the way of viewing content.
** This allows developers to use position fixed in mobile and tablets from here on out.
** This adds no new CSS attributes.
** This removes any complications of trying to figure out which viewport to tie a fixed element to (and its confusing UX implications), because there is effectively only one.
** Cons: do any mobile-designed sites take advantage of zooming at all? This proposal doesn't help them.
 
* Links
** http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html
*** Ben's critique: web developers would need to create two elements for every position: fixed element, even if the elements behave the same on all devices. We already have media queries that can be used to not apply position: fixed.


== Patterns like fixed position ==
== Patterns like fixed position ==
Elements you want to scroll up and then stack up against the top of the viewport (or the inverse elements you want to scroll down and stack up against the bottom of the viewport).


* An element that remains in place until it is about to be displaced off the page, and then is fixed position.
* An element that remains in place until it is about to be displaced off the page, and then is fixed position.
** Example: "show page contents" on http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html
** Example: "show page contents" on http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html
** Example: Fennec's URL bar when the page is loading
** Example: Fennec's URL bar when the page is loading

Latest revision as of 21:17, 7 December 2010

There are a few areas where it's become clear we need to make improvements on the currently specified/implemented behavior of position:fixed:


Mobile and Tablets

The problem of zooming some content and not others.

  • Mobile effectively has two viewports: what content layout sees and what the user sees.
  • What behavior do we want to support for position: fixed on mobile devices and tablet devices? Goals:
    • Backward compatible with desktop (i.e., leaves most pages usable that weren't designed with zooming in mind)
    • ...
  • Proposal 1: As simple as possible
    • Only allow position fixed elements for zoomable non-1.0-scale pages.
    • This hides position fixed elements for legacy desktop sites, which normally has extraneous content that can get in the way of viewing content.
    • This allows developers to use position fixed in mobile and tablets from here on out.
    • This adds no new CSS attributes.
    • This removes any complications of trying to figure out which viewport to tie a fixed element to (and its confusing UX implications), because there is effectively only one.
    • Cons: do any mobile-designed sites take advantage of zooming at all? This proposal doesn't help them.

Patterns like fixed position

Elements you want to scroll up and then stack up against the top of the viewport (or the inverse elements you want to scroll down and stack up against the bottom of the viewport).