This commit is contained in:
chrosey
2017-09-13 07:52:34 +02:00
parent a1f16c37f4
commit 2340b0226b
24621 changed files with 2912161 additions and 149 deletions
+43
View File
@@ -0,0 +1,43 @@
## Why You Should Use Tether
Virtually every app includes some sort of overlay attached to an element on the page.
Things like [tooltips](http://github.hubspot.com/tooltip/docs/welcome),
[dropdowns](http://github.hubspot.com/select/docs/welcome), [hover-activated info boxes](http://github.hubspot.com/drop/docs/welcome), etc.
Those elements need to be attached to something on the page. Actually placing them next to
the element in the DOM causes problems though, if any parent element is anything
but `overflow: visible`, the element gets cut off. So you need absolute positioning
in the body.
Some of the time absolute positioning is right, but what about if the thing we're
attached to is fixed to the center of the screen? We'll have to move it every
time the user scrolls. What about if the element is in a scrollable container,
if the overlay is inside of it (so no clipping), it would be cool if the code
were smart enough to move it inside when that area is scrolled. That way we
need to reposition it even less.
It would also be nice if the code could somehow figure out whether positioning it
from the top, bottom, left, or right would result in the fewest repositionings
as the user scrolls or resizes.
Most of the time you're building these elements it would be nice for the element to
flip to the other side of the element if it hits the edge of the screen, or a scrollable
container it might be in. It would be nice if we could confine the element
to within some area, or even hide it when it leaves.
It would be nice for the element to be repositioned with CSS transforms
rather than top and left when possible, to allow the positioning to be done entirely
in the GPU.
Now that the positioning is so fancy, you're going to use it for more and more
elements. It would be cool if the library could optimize all of their repositioning
into a single repaint.
All of that is baked into Tether.
### tl;dr
- Optimized GPU-accelerated repositioning for 60fps scrolling
- Reliable positioning on any possible corner, edge or point in between.
- Support for repositioning or pinning the element when it would be offscreen
- Designed to be embeddable in other libraries
+46
View File
@@ -0,0 +1,46 @@
Repositioning
-----
Tethers will be automatically repositioned when the page is resized, and when any element containing the Tether is scrolled.
If the element moves for some other reason (e.g. with JavaScript), Tether won't know to reposition the element.
#### Manually Repositioning
The simplest way to reposition every Tether on the page is to call `Tether.position()`. It will efficiently reposition every
Tether in a single repaint, making it more efficient than manually repositioning many Tethers individually.
```javascript
Tether.position()
```
#### Repositioning a Single Tether
If you have many Tethers on screen, it may be more efficient to just reposition the tether that needs it. You can do this
by calling the `.position` method on the Tether instance:
```javascript
tether = new Tether({ ... })
// Later:
tether.position()
```
#### Tethering Hidden Elements
If you are creating a tether involving elements which are `display: none`, or not actually in the DOM,
your Tether may not be able to position itself properly. One way around this is to
ensure that a position call happens after all layouts have finished:
```javascript
myElement.style.display = 'block'
tether = new Tether({ ... })
setTimeout(function(){
tether.position();
})
```
In general however, you shouldn't have any trouble if both the element and the target are visible and in the DOM when you
create the Tether. If that is not the case, create the Tether disabled (option `enabled`: `false`), and enable it when
the elements are ready.
+47
View File
@@ -0,0 +1,47 @@
Why we don't support IE 8
-------------------------
We've been living in 2007 for a while now, pretending that new browser features don't
exist because they aren't in IE8. You might not even know about some of these features,
or think they are only enabled by jQuery or underscore, simply because it hasn't
been an option to rely upon them.
Here is the list of features you don't have if you choose to support IE 8:
- HTML5 audio and video
- SVG
- Canvas
- TrueType fonts
- Media Queries
- CSS Transforms
- Multiple Backgrounds
- CSS3 Units (vh, vw, rem)
- Custom DOM events
- Hardware accelerated graphics
- The DOMContentLoaded event
- addEventListener
- Object.create, .seal, .freeze, .defineProperty
- Array.isArray, .indexOf, .every, .some, .forEach, .map, .filter, .reduce
- A modern JavaScript engine
- A real developer tools
- A consistent box model
- jQuery 2
- Google Apps
- Tether
It's true that IE 8 still holds a big chunk of the browsing population, but the reasons
why they can't update are dwindling. There are two big reasons for continuing IE 8 support.
#### Enterprises
Microsoft is dropping support for XP in April, organizations who want security updates will have to upgrade.
#### China uses XP
Chrome, Firefox and Opera all support XP. Nothing prevents users from upgrading, except the inertia of
organizations who still support IE 8.
#### The Future
We are skating towards where the puck will be, and we hope that as you decide to drop IE 8 support,
you choose to add Tether to the list of awesome things you can do.