Emoji react button: right side style incorrect when clicked #1366

Closed
opened 2025-03-14 04:39:54 +00:00 by tusooa · 12 comments
Member
  1. go to an emoji react button
  2. hover on it
  3. click on it
  4. see that the styles of the two are different (the clicked one is almost unstyled)
  5. image{width=82 height=30}
  6. when it is no longer hovered, the style does not change
<!-- please use one of the templates if applicable, otherwise - type out here in free-form --> 0. go to an emoji react button 1. hover on it 2. click on it 3. see that the styles of the two are different (the clicked one is almost unstyled) 4. ![image](/attachments/dbbccb46-e787-4755-860b-f0d8d48ff81f){width=82 height=30} 5. when it is no longer hovered, the style does not change
3.9 KiB
Member

can't exactly reproduce, but clicking on counter does make it unstyled, so it's probably missing focused styles. I'm not sure if it's worth keeping counter separate, i'll combine the two into one button, should make things easier for us.

can't exactly reproduce, but clicking on counter does make it unstyled, so it's probably missing `focused` styles. I'm not sure if it's worth keeping counter separate, i'll combine the two into one button, should make things easier for us.
Author
Member

the point of keeping it separate is to allow mobile clients click on the counter, and see who have reacted.

the point of keeping it separate is to allow mobile clients click on the counter, and see who have reacted.
Author
Member

if we make them one, then users without a mouse will have no way to "hover on" it to show the reacted users list (without actually reacting to it). that is why i made them separate in the first place.

if we make them one, then users without a mouse will have no way to "hover on" it to show the reacted users list (without actually reacting to it). that is why i made them separate in the first place.
Member

right, but at the same time it's so tiny it's hard to tap on mobile. I wonder if we could do a long-tap handler for this case

right, but at the same time it's so tiny it's hard to tap on mobile. I wonder if we could do a long-tap handler for this case
Author
Member

i can reliably tap it when emoji scale is 2x. also, long tap does not work for keyboard users, and on mobile, long tap will trigger the context menu or selection or other weird things, so i don't think it is a good idea.

i can reliably tap it when emoji scale is 2x. also, long tap does not work for keyboard users, and on mobile, long tap will trigger the context menu or selection or other weird things, so i don't think it is a good idea.
Member

ok. we'll keep them separate.

ok. we'll keep them separate.
Author
Member

what might be the problem could be that, when the focused style is missing, it should fall back to the style without focused?

what might be the problem could be that, when the `focused` style is missing, it should fall back to the style without `focused`?
Member

there is no proper inheritance between states, I just need to fill in the blanks myself with shadow variables i.e. defaultButtonBevel etc. I guess i forgot to do it for focused+active case

there is no proper inheritance between states, I just need to fill in the blanks myself with shadow variables i.e. `defaultButtonBevel` etc. I guess i forgot to do it for focused+active case
Member

No inheritance is by design, mostly because it's not always clear which state takes priority and how to mix-and-match different shadows, it's much cleaner and easier to do it manually with shadow variables and then just tweak those.

No inheritance is by design, mostly because it's not always clear which state takes priority and how to mix-and-match different shadows, it's much cleaner and easier to do it manually with shadow variables and then just tweak those.
Author
Member

What's css's behaviour when it comes to multiple states?

What's css's behaviour when it comes to multiple states?
Member

"keep original unless specified, then override", i think priority (i.e. :hover or :focused) follows order of rules specified in file because they have same specificity, which is also confusing and also require you to write every combination possible yourself just to be sure, partially why there's a lot of styles related to :disabled as it gets overriden by :hover.

"keep original unless specified, then override", i think priority (i.e. `:hover` or `:focused`) follows order of rules specified in file because they have same specificity, which is also confusing and also require you to write every combination possible yourself just to be sure, partially why there's a lot of styles related to `:disabled` as it gets overriden by `:hover`.
Author
Member

I see where the problem lies. The right side is a .button-unstyled, because at that time i made some hacks to allow the side-by-side button styling. It doesn't work with themes 3. because at that time there was no way for a Popover to have a button-default trigger, so I did a class hack with it. normalButton option was added later, and this was skipped through, so it has become both button-unstyled and button-default.

I see where the problem lies. The right side is a `.button-unstyled`, ~~because at that time i made some hacks to allow the side-by-side button styling. It doesn't work with themes 3.~~ because at that time there was no way for a Popover to have a `button-default` trigger, so I did a `class` hack with it. `normalButton` option was added later, and this was skipped through, so it has become both `button-unstyled` and `button-default`.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
pleroma/pleroma-fe#1366
No description provided.