如何检查浏览器是否支持真正的触摸

发布于 2024-12-25 20:53:44 字数 423 浏览 0 评论 0原文

今天(或最近)我的 Chrome Beta 更新到了 17,有了它,我注意到我的网络应用程序中有一些有趣的地方。我注意到这是因为一个类被添加到 body 元素中,通常只有在有触摸事件支持时才会放在那里,我像这样检查:

  try {  
    document.createEvent("TouchEvent");
    _device.touch = true;
  } catch (e) {
    _device.touch = false;
  }

果然,我可以在 Chrome 17 上创建并触发触摸事件。第一个想法是曾经是,哦,我可以检查触摸,看看鼠标单击是否失败,因此,有一个鼠标,但也有 MouseEvents 触发器。

在没有用户代理嗅探的情况下,我还能如何检查它是一个实际的、可触摸的设备,而不仅仅是支持触摸事件的浏览器。

Today (or very recently) Chrome Beta updated to 17 for me and with it i noticed some funkiness in my web app. I noticed it was because a class was being added to the body element that normally only gets put there if there is touch event support which I check like this:

  try {  
    document.createEvent("TouchEvent");
    _device.touch = true;
  } catch (e) {
    _device.touch = false;
  }

And sure enough, i can create and trigger touch events on Chrome 17. First idea i had was, oh, i can check for touch, and see if a mouse click fails, therefore, there's a mouse, but MouseEvents trigger too.

How else can I check, without user agent sniffing, that it's an actual, touchable, device, and not just a browser that supports touch events.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

吾家有女初长成 2025-01-01 20:53:44

尝试:

'ontouchstart' in document.documentElement

Try:

'ontouchstart' in document.documentElement
梦太阳 2025-01-01 20:53:44

并不是说您可能不想仅仅因为浏览器“支持触摸”而改变行为。例如。 Windows 上的 Chrome 现在始终支持触摸,即使不一定连接触摸屏。即使连接了触摸屏,用户也不一定会使用它,因此您需要小心更改内容。

所以这实际上取决于您想知道的原因:

  1. 您想知道是否会收到 touchstart/touchmove/touchend 事件:
    确实没有办法提前确定这一点。例如。用户可以在页面加载后插入触摸屏。如果您可能对这些事件感兴趣,您应该监听它们。

  2. 您想知道是否应该显示网站的“移动”版本
    用户是否支持触摸并不是正确的信号 - 例如。使用触摸屏的 Windows 用户可能不想要您的移动网站。您可以使用 UserAgent 启发式方法,但请为用户提供一种切换网站版本的固定方式。

  3. 您想知道是否应该调整您的 UI,使其对触摸输入更加友好
    例如,如果用户可能使用触摸,也许一些按钮应该更大。一般来说,最好总是针对多种指针类型进行设计 - 毕竟当用户同时使用触摸和鼠标时,您无法知道用户的指针偏好。但是,如果您确实想使用可用的指针硬件知识作为做出最佳 UI 权衡的提示,那么您可以使用新的 CSS 媒体查询:

我为 Chrome 添加了部分支持Chrome 21 (crbug.com/123062)。据我所知,还没有其他浏览器支持它们。

Not that you probably don't want to change behavior just because a browser 'supports touch'. Eg. Chrome on Windows now supports touch all the time, even though there won't necessarily be a touch screen attached. Even if there is a touch screen attached, the user doesn't necessarily use it, so you need to be careful with what you change.

So this really comes down to why you want to know:

  1. You want to know whether you're going to get touchstart/touchmove/touchend events:
    There's really no way to know this in advance for sure. Eg. the user could plug in a touch screen after your page has loaded. If you might be interested in these events, you should just listen for them.

  2. You want to know if you should display a 'mobile' version of your site
    Whether or not the user has touch support is not the right signal for this - eg. a Windows user with a touch screen probably does NOT want your mobile site. You can use UserAgent heurstics, but please give the user a sticky way to switch versions of your site.

  3. You want to know if you should tweak your UI to be more friendly for touch input
    Eg., maybe some buttons should be larger if the user is likely to use touch. In general it may be best to always design for multiple pointer types - after all you have no way to know the user's pointer preference when they have both touch and mouse. But if you really want to use knowledge of the pointer hardware available as a hint to making the best UI tradeoff, then there are new CSS media queries you can use:

I added partial support to Chrome for these in Chrome 21 (crbug.com/123062). As far as I know, no other browser supports them yet.

星星的轨迹 2025-01-01 20:53:44
('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch
('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文