Is This an Emoji?(spiffy.tech)
spiffy.tech
Is This an Emoji?
https://spiffy.tech/is-this-an-emoji
27 comments
I ended just comparing against a map of emoji strings.
https://github.com/makew0rld/go-isemoji
https://github.com/makew0rld/go-isemoji
> Its job is “when a mommy code point loves a daddy code point very much, they come together and make a whole new glyph”.
Can't stand this style of writing. But it's just me.
Can't stand this style of writing. But it's just me.
But why? You even asked at the very beginning "I shouldn't accept just anything, right?" But why not? Like what is going to happen if someone uses a "non emoji?" Nothing. Nothing will happen. Well now you will tell at the person and tell them to use an emoji. But if you just accepted everything, it would just work. It would save you time and your users grief.
My main question here is, how future proof is this?
Their vision for their tool is that you tag stuff with emoji instead of characters, an arbitrary, deliberate limitation. Should they adjust that just because of a Unicode implementation detail?
I think the point is that there’s no need to go to such lengths to enforce it. They build the picker UI so most users will just pick an emoji using that. Sometimes it’s important to limit degrees of freedom with strict validation but in this case I’d wonder if a non emoji would really cause a problem.
I think that's all fine, but implementing this restriction comes at a cost of maintainability. I'd say a much more pragmatic solution would be to allow a maximum of a few characters on the backend (say 10, because unicode) and then restrict the input on the front-end. If someone is willing enough to put other characters in that field by submitting the API request themselves, so be it - but it's also completely reasonable to turn around and tell them the reason their views don't look correct is because they submitted invalid data.
The reality is these users will be very few and far between, and as long as it doesn't pose a security risk there are very few benefits to strongly enforcing this limitation.
The reality is these users will be very few and far between, and as long as it doesn't pose a security risk there are very few benefits to strongly enforcing this limitation.
"what's an emoji" will also be different depending on the users, and while a service provider can just stand their ground on the whatever definition they want, that brings undue stress for the user.
For instance try explaining to a user why :heart: is ok but not ♥
For instance try explaining to a user why :heart: is ok but not ♥
I was thinking the same thing. Why not limit input through the api to 1 grapheme if misuse is the worry?
Or why accept all emoji and not a sensible sublist like Notion?
The end of The article describes how 1 grapheme is a mostly good solution except that not all emoji work with the JS used to validate that, and the JS to validate it isn’t available in Firefox.
But this would be a back-end check, not a front-end check. Why would lack of support in Firefox matter?
A minor correction:
> Let's say we want to display the emoji for a brown man, “<brown man>”. There isn't a code point for that. Instead we use “<man> ZWJ <brown>”.
(with the emoji replaced, as I expect HN would strip them).
That's inaccurate: skin tone modifiers are used directly after a base emoji character, without a zero-width joiner in between.
> Let's say we want to display the emoji for a brown man, “<brown man>”. There isn't a code point for that. Instead we use “<man> ZWJ <brown>”.
(with the emoji replaced, as I expect HN would strip them).
That's inaccurate: skin tone modifiers are used directly after a base emoji character, without a zero-width joiner in between.
[deleted]
So much work just to take away people's choice to name their reading lists anything they want. Considering they even mention the database needing to be involved way more than it should be, maybe they should rethink this.
Isn't it all font dependent anyway? A lot of "non emoji" symbols get stylized like emojis in many popular fonts.
Similarly the length of a string or what is considered 1 grapheme is font dependent which can also be hard to handle server side.
Ironically, Hacker News purged the emoji from the title of this post.
Maybe its just an illustration of whatever the name of the law is that says when the title is a yes/no question, the answer is always no.
This is one of the cases where they've spent so long trying to solve.... a problem which wasn't a problem in the first place. Just let users tag the content with any character they want, and maybe limit it to 1 or 2 characters. Way simpler and way more user-friendly than trying to limit it to emojis.
The single-grapheme emoji represented here [0] is 11 characters.
[0] https://emojipedia.org/family-man-woman-girl-boy/
[0] https://emojipedia.org/family-man-woman-girl-boy/
> Just
whenever i hear this word in relation to product design, it simply means the person hasn't thought through the entire problem.
whenever i hear this word in relation to product design, it simply means the person hasn't thought through the entire problem.
99% of the time you might be right but in this case there is literally no benefit to the work described in the article.
https://blog.librarything.com/2016/07/introducing-dewmojis/
A mapping of emoji to different Dewey Decimal Classes e.g. 7 : Arts and Leisure : https://emojipedia.org/artist-palette/