+ Select all text via CTRL+A (or triple click). Now type a character or press backspace.
+ Expected: event.getTargetRanges()[0].startContainer should be equal to window.getSelection().anchorNode
+ Actual (in Firefox): window.getSelection().anchorNode is the div, while event.getTargetRanges()[0].startContainer is the text node.
+ Select the wrongly spelled "wrld" and replace it using the native spell
+ checker of browsers.
+ Expects inputType: 'insertReplacementText' (not fired on Safari Desktop)
+
+ Expected: Switches to 'deleteWordBackward' after around 20 characters.
+ Actual: Deletes whole words, but still triggers 'deleteContentBackward'
+
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse justo odio, posuere ac sem ac, tempus sagittis diam. Maecenas maximus ornare turpis, sit amet sodales orci rutrum sed. Duis quis lacinia tellus, at suscipit felis. Vivamus sodales pretium enim, non tristique enim auctor ac. Aliquam ac dolor aliquet, dignissim justo quis, volutpat mi. Integer a varius eros. Vestibulum eget ipsum erat. Nunc pulvinar magna risus, quis tempus sapien rhoncus nec. Aenean finibus consequat ante vitae tempus. Quisque bibendum tellus arcu, a faucibus turpis eleifend quis. Donec dictum ipsum consectetur mi ultricies tincidunt. Proin mollis lacinia nisl a pharetra. Proin auctor id eros eget dapibus. Mauris auctor dui quis mauris tristique feugiat. Mauris posuere aliquam blandit. Aliquam nec rhoncus ligula. Donec in urna fermentum, efficitur mauris nec, tempus lectus. Quisque venenatis feugiat ante eu aliquam.
+ When you open this in Safari on the Desktop (I used 26.1), and start a
+ composition in the empty contenteditable field.
+ E.g. use the dead key ^ and then press
+ a).
+ Notice how the original editable-field div gets destroyed (the blue dashed
+ border disappears).
+ Now, comment out the position: relative rule, and try again. Now it works
+ as expected. Placing a position: relative rule changes the behavior of
+ contenteditable. 😱😱😱
+ Safari & Firefox render the cursor after the placeholder (desired)
+ Chrome renders the cursor before the placeholder
+
+
+
+
+
+
+ However, ultimately, editor developer will search for a solution,
+ where placeholders "just work" in all situations. E.g. for elements with centered text.
+ This currently only works when the <br/> element is removed as soon as a field is focused.
+ See also: https://github.com/michael/web-editing/issues/5
+
+ When the br is removed, Safari/Chrome render this correctly,
+ but in Firefox the cursor is always rendered at the very beginning, ignoring the centering.
+ By adding a placeholder, one can make an empty element selectable and
+ addressable.
+ NOTE: This is an alternative to adding a <br> element to make a
+ field addressable.
+ In Chrome and Safari, you can select each empty field using the up/down
+ arrow keys.
+ However, in Firefox, some fields are missed.
+
+ CONTEXT: By adding a placeholder, one can make an empty element selectable
+ and addressable.
+ NOTE: This is an alternative to adding a <br> element to make a
+ field addressable.
+ In Firefox, however, the cursor is aligned at the left edge of the field,
+ even though the text is centered. In Chrome/Safari this works as expected.
+
+ CONTEXT: By adding a placeholder, one can make an empty element selectable
+ and addressable.
+ NOTE: This is an alternative to adding a <br> element to make a
+ field addressable.
+ Clicking the placeholder "Heading 3" does not focus the element in
+ Firefox. However, in Chrome/Safari it does.
+