如何克服WhatWG / W3C / Chrome版本33.0.1750.146“回归bug” with< input type =“number”/>领域 [英] How to overcome WhatWG/W3C/Chrome version 33.0.1750.146 "regression bug" with <input type="number"/> fields

查看:141
本文介绍了如何克服WhatWG / W3C / Chrome版本33.0.1750.146“回归bug” with< input type =“number”/>领域的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我把回归错误这个词放在引号中,因为在这方面显然有不同的意见。有关详细信息,请参阅Bugzilla中的 Bug 24796



简而言之,Google Chrome 根据WhatWG规范的最新版本实施更改: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element .html#input-type-attr-summary
删除 以下属性和方法来自<输入类型=数字/> 字段。



属性


  • selectionStart

  • selectionEnd



  • 方法:


    • select()

    • setSelectionRange(start,end)



    (还有其他的但这些是常用的关键字)

    如果您检查,方法将被定义但是尝试调用方法或请求属性的 HTMLInputElement 的数字实例将引发异常。 : - (

    恕我直言这是一个错误(因为功能已被删除,没有获得任何东西......并且有1,000个网页通过JavaScript为这些数字输入字段提供扩展行为的站点/应用程序...但我离题了(对于那些希望与之对抗的人,请使用上面列出的错误帖子))



    TL; DR

    出于可用性目的,我非常想要并计划继续使用< input type =number/> 字段,因为它们向用户代理提供提示,如果在移动设备(智能手机/平板电脑/?)上,



    然而,对于当前版本的Chrome(版本33.0.1750.146)和任何其他浏览器盲目实现此规范更改我想安全地将渲染的字段转换回
    < input type =text/>



    注意s:


    • 尝试在修改内容时动态更改这些字段已被证明不成功,因为当字段属性丢失时,字段丢失了选择范围

    • 我有一个解决方案,我想到了,我很快就会发布,但我想确保这个问题/答案适用于所有遇到此问题的开发人员


    解决方案

    我已经用下面的代码解决了这个问题:

      function checkForInputTypeNumberBug(){
    var dummy = document.createElement('input');
    尝试{
    dummy.type ='number';
    } catch(ex){
    //旧的IE版本将无法设置类型
    }
    if(typeof(dummy.setSelectionRange)!='undefined'&& amp ; typeof(dummy.createTextRange)=='undefined'){
    // Chrome,Firefox,Safari,Opera only!
    try {
    var sel = dummy.setSelectionRange(0,0);
    } catch(ex){
    //这个例外现在抛出在Chrome v33.0.1750.146中,因为他们已经在数字字段中删除了支持
    //的此方法。因此我们需要将所有数字字段还原为文本字段。
    $('input [type = number]')。each(function(){
    this.type ='text';
    });


    $ b $(document).ready(function(){
    checkForInputTypeNumberBug();
    });

    我将它设置为独立函数,因为我有一些情况是通过AJAX加载字段需要能够即时调用该函数。



    此代码处理较旧的IE版本,尝试设置该类型将会失败以及处理Chrome中的异常在一个虚拟元素上),以便页面可以克服这种行为改变。



    更新:根据@Andy E关于使用inputmode属性的建议目前不支持)我已经创建了一个bug,在用户代理删除选择API之前尝试优先实现inputmode: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26695


    I put the words "regression bug" in quotes as there is obviously some mixed opinions on this. For full details track Bug 24796 in Bugzilla.

    In short Google Chrome implemented changes according to the latest version of the WhatWG specs: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary that removed the following properties and methods from <input type="number"/> fields.

    Properties:

    • selectionStart
    • selectionEnd

    Methods:

    • select()
    • setSelectionRange(start, end)

    (there are others but these are the common key ones used)

    The methods are defined if you inspect a "numeric" instance of the HTMLInputElement however attempting to call the methods or request the properties will throw an exception. :-(

    IMHO this is a bug (since functionality has been removed with nothing gained... and there are 1,000's of web sites/applications that provide extended behavior to these numeric input fields via JavaScript... but I digress (for those that wish to battle it out please use the bug post listed above))

    TL;DR

    For usability purposes I most certainly want and plan to continue using <input type="number"/> fields as they provide a "hint" to the user agent that if on a mobile device (smartphone/tablet/?) that I would like to present the numeric keyboard when the field is focused vs. the default alpha keyboard.

    However for the current version of Chrome (ver 33.0.1750.146) and any other browser that blindly implements this spec change I'd like to safely convert the rendered fields back to <input type="text"/>

    Notes:

    • Attempting to change these fields on the fly when modifying their contents has proven unsuccessful as the field loses it's selection range when the type attribute is changed.
    • I do have a workaround solution I came up with which I'll post shortly, but I wanted to ensure this question/answer was here for all developers that encounter this issue

    解决方案

    I've solved this with the following code:

    function checkForInputTypeNumberBug(){
      var dummy = document.createElement('input');
      try {
        dummy.type = 'number';
      } catch(ex){
        //Older IE versions will fail to set the type
      }
      if(typeof(dummy.setSelectionRange) != 'undefined' && typeof(dummy.createTextRange) == 'undefined'){
        //Chrome, Firefox, Safari, Opera only!
        try {
          var sel = dummy.setSelectionRange(0,0);
        } catch(ex){
          //This exception is currently thrown in Chrome v33.0.1750.146 as they have removed support
          //for this method on number fields. Thus we need to revert all number fields to text fields.
          $('input[type=number]').each(function(){
            this.type = 'text';
          });
        }
      }
    }
    $(document).ready(function(){
      checkForInputTypeNumberBug();
    });
    

    I've made it a standalone function as I have cases where the fields are loaded via AJAX and I need to be able to call the function on the fly.

    This code handles older IE versions where attempting to set the type will fail as well as handle the exception in Chrome (on a dummy element) so that pages can overcome this behavior change.

    Update: As per @Andy E's suggestion around using the inputmode attribute (currently unsupported) I've created a bug to try and prioritize the implementation of inputmode before user agents remove the selection APIs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26695

    这篇关于如何克服WhatWG / W3C / Chrome版本33.0.1750.146“回归bug” with&lt; input type =“number”/&gt;领域的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆