You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Emoji is now a new standard in Unicode 6.0. http://en.wikipedia.org/wiki/Emoji
iOS have supported it since iOS 3.0 if you're on a Japanese carrier (or used a hack to enable the keyboard), but now that Emoji is a standard in Unicodes latest specification iOS5 supports it on any carrier and OS X Lion also supports it.
So the idea is to use Emoji when supported, and tag fallbacks for those who don't. So the smiley areas will show as text, like :P before the js replaces them on first load.
Then, a cookie is set, and a session state, that sets wether Emoji is supported or not depending a string length check I came up with.
If the OS supports Emoji, "[insert emoji emoticon here]".length will return 2, while when unsupported it'll return 4 as the length.
This technique is basically the same as the well known technique used to detect wether the OS can support two-byte japanese characters or not, as they would return 1 as the length when supported, 2 when not.
Not only would this feature support converting regular smileys to emoji to reduce bandwidth and increase quality were plausible.
But also ensure that if an iOS device, or a Lion machine can enter Emoji symbols and have them display on devices that actually don't support them by converting them to regular smileys behind the scenes.
Other than that, the Emoji functionality would be hardcoded with only an on/off switch. No need to customize it.
The other smiley functionality we're planning are separate, but would be integrated. So if you have a :) smiley defined, the non-emoji fallback would use your custom smiley over the core one.
This feature is just for kicks, so setting to lowest priority.
Reported by @stipsan
Emoji is now a new standard in Unicode 6.0.
http://en.wikipedia.org/wiki/Emoji
iOS have supported it since iOS 3.0 if you're on a Japanese carrier (or used a hack to enable the keyboard), but now that Emoji is a standard in Unicodes latest specification iOS5 supports it on any carrier and OS X Lion also supports it.
So the idea is to use Emoji when supported, and
tag fallbacks for those who don't. So the smiley areas will show as text, like :P before the js replaces them on first load.
Then, a cookie is set, and a session state, that sets wether Emoji is supported or not depending a string length check I came up with.
If the OS supports Emoji, "[insert emoji emoticon here]".length will return 2, while when unsupported it'll return 4 as the length.
This technique is basically the same as the well known technique used to detect wether the OS can support two-byte japanese characters or not, as they would return 1 as the length when supported, 2 when not.
Not only would this feature support converting regular smileys to emoji to reduce bandwidth and increase quality were plausible.
But also ensure that if an iOS device, or a Lion machine can enter Emoji symbols and have them display on devices that actually don't support them by converting them to regular smileys behind the scenes.
Other than that, the Emoji functionality would be hardcoded with only an on/off switch. No need to customize it.
The other smiley functionality we're planning are separate, but would be integrated. So if you have a :) smiley defined, the non-emoji fallback would use your custom smiley over the core one.
This feature is just for kicks, so setting to lowest priority.
Here's something fun to read that's related: http://www.panic.com/blog/2011/07/the-worlds-first-emoji-domain/
Ref: #734
The text was updated successfully, but these errors were encountered: