If the range is collapsed doesn't modify the font size

[frankai]

Hello! If the range is collapsed we can not increase/decrease the font size. For example, if the user want to start from the current caret position with a bigger font size...

Thanks!

[neilj]

I presume you are using Safari or Chrome. There is an issue with Webkit where you cannot focus the caret inside an empty text node: https://bugs.webkit.org/show_bug.cgi?id=15256. There are ugly hacks that can work around this, and I may consider adding one in the future (or if you'd like to write a patch, I will consider pull requests). However, really they need to fix this in Webkit. In the meantime, Opera and Firefox will work as expected (and I think IE9 does as well, but I can't remember and don't have access to it on the machine I'm using right now).

[neilj]

Ah, sod it. I decided to fix this myself. Just grab the latest version.

543abca

[frankai]

Thanks! Nice hack! ;)

[frankai]

Just a comment related with this fix, when you set a new size for the font and type something the caret is before the first character then jumps to the second, it's a bit weird, is it possible to insert the cursor after the first character and avoid the jump? Thanks!

[neilj]

I'm not entirely sure what you mean by that, but I've fixed a bug which could be what you're talking about. Try the latest version.

[frankai]

tried the latest version but the problem is still there. Try to replicate it yourself:
1- Open your demo.html with Safari
2- Click on the contenteditable area and change the size of the font to 100px
3- Press a key, for example "a", you can see the caret before the "a" character (the correct position of the caret is after the "a" character, not before)
4- press another key, you see how the caret jumps the "a" character
Hope this helps!

[neilj]

Works fine for me; Safari correctly puts the cursor after the A. Perhaps it's a bug in an older version of Safari? If so, there's not much I can do about it; run Software Update and check you have the latest version.

[frankai]

Opss, sorry, you are right, this only happens in Mobile Safari on iPad (iOS 5.1).

It seems that Squire doesn't work very well in Mobile Safari, it has a very weird problem with Newline characters too.

[neilj]

Mobile Safari currently has severe bugs with rich text editing. I can't work around these; for now I recommend not enabling rich text editing but falling back to plain text on iOS devices instead. Hopefully the bugs will be fixed in iOS6.