-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ember 3.11: hammertime triggers syle binding warning #90
Comments
@st-h - I believe we're going to deprecate this addon - discussion on that is pending here #86 (more context available here, @runspired or perhaps myself need to ensure that comments in #74 no longer hold true though, for background.) And I agree with the issue u link to (emberjs/ember.js#18193) - this warning probably should have begun happening before ember 3.11. given ur using the
onclick={{action as well, which is likely easier. The latter will run the ast transformer and prevent style binding at runtime (the former, would remove the touch-action: ... property altogether, but span is not a 'focusable input' element and ios will thus not add 300ms to create a fake hover state (on older iphones, if ur targeting newer iphones only, u could just remove the addon completely per discussion via the first link in this comment, fyi).
(don't quote me verbatim on any of this, we're talking a couple years here in terms of human memory, but I believe those statements are correct, to best of my knowledge, w/o looking again more closely) leaving this for more context, although i edited the above, so this is mostly to re-iterate why it's like this and why -- whats happening is that for tags that are not focusable (aka, input tags) and that don't have |
@eriktrom thanks a lot for your reply. Honestly, I wasn't adding this addon because I was noticing delays but as a mere measure of preventing such things to show up unexpectedly. I have read through #74 back then and a few stackoverflow questions etc. but my conclusion pretty much was that there still are cases where hammertime would be helpful - but I never took the time to really look into this and its details. One thing that just comes to my mind is that quite some time back, I stripped all css hover styles on mobile, because they were causing clicks to delay or seemed to introduce the need to click twice (and there is not really a good way to make use of hover at all using touch screens). Personally, I think I will remove this addon for now and see if I run into anything that brings up a need to be fixed. Thanks again for the clarifications. |
@st-h - np -- also interesting about the hover css state findings u mention, thanks for sharing. |
@eriktrom pretty simple thing: I just wrap
Afaik (even though this was a few years ago) - when iOS safari notices that there is a hover style defined for an element, the first tap activates the hover style (not sure anymore if there just is a delay or a second tap is needed to trigger the actual click). At least removing hover selectors improved the mobile experience for my app. However, I do not really know anything if it still is needed today - I just kept it as it does not actually make much sense to me to define hover styles where hover is not supported. It just seems like a reasonable thing to do. |
As already reported to the ember repo here, when ember > 3.11 is used with this addon, code like
will trigger the following warning:
The text was updated successfully, but these errors were encountered: