* Include Array.prototype.includes polyfill
In https://github.com/ianstormtaylor/slate/commit/070a700
the `default` feature set was added
and the `Array.prototype.includes` feature removed
from the polyfill.io request.
I think it's great to include the `default` feature set,
but, `Array.prototype.includes` is not included in the `default` set,
so we have to explicitly request it.
IE 11 needs an `Array.prototype.includes` polyfill
in order for the examples to work.
* Update dev.html
* Update index.html
This reverts commit 6f676d67712b15216cf611e01dead990ee0dd8c1.
This behavior should be in userland, because there isn't agreement
among text editors on how it should behave.
Resolves#1269.
Slate uses `Array.prototype.includes`
in at least one place:
https://github.com/ianstormtaylor/slate/blob/b558872/packages/slate/src/schemas/core.js#L62
So, request an `Array.prototype.includes` polyfill
from polyfill.io
if the user's browser needs it,
which is the case with IE 11.
Also requests minified JavaScript,
since this code is used
for the slatejs.org website,
and there's no need to serve
non-minified code there.
If you have, for example, a bold mark, and you hit "Enter", the new
block won't carry over the formatting. Instead, it should (at least if
you start typing right away).
Fixes#1269.
* provide polyfill for btoa and atob
* add fallback for Buffer.from
* fix listing issues
* remove window usage for URIComponent
* remove monkeyPatching and add window check
* fix linter warnings
* update to use isomorphic-base64
In `slate-react@0.6.0`: The data argument to event handlers has been removed...
The event handlers generated in the slate-simulator `Simalator` object was
still passing a data argument.
* Save marks when creating native ranges in onNativeBeforeInput
When we used native ranges in onNativeBeforeInput, we weren't carrying
over the marks from Slate's selection. This made it impossible to know
that the next character typed should have a set of marks.
Fixes#1270.
* Ensure marks are cleared after successfully entering text
* Stop setting marks in findRange
Adding the selection's marks inside findRange was too broad of a
change, and would keep marks after doing things like moving a
selection around. We should use selection.marks directly in
insertTextAtRange instead.
* Update find-range.js
