[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"content-why-browsers-not-build-more-selectors":3,"$f1ezfbmszgqncl":21},{"id":4,"type":5,"slug":6,"title":7,"date":8,"category":9,"tags":10,"body_markdown":13,"permalink":14,"excerpt_src":14,"media_type":14,"media_title":14,"media_author":14,"media_url":14,"rating":14,"layout":14,"pv":15,"admin_only":15,"created_at":16,"updated_at":16,"deleted_at":14,"status":17,"html":18,"excerpt":19,"cover":20},159,"article","why-browsers-not-build-more-selectors","为什么浏览器不内建更多选择器","2012-09-06 09:27","web",[11,12],"浏览器","JavaScript","\n来自知乎问题[JavaScript 为什么不内建选择器？](https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F20433809\u002Fanswer\u002F15189900)\n\n首先，与这个问题有关的浏览器中的技术概念其实大致有这些：\n\n1. BOM，即浏览器对象模型，简单说就是浏览器提供的环境，包括各种对象及其方法，比如window\n2. DOM，即文档对象模型，它是由HTML经解析后生成的一个模型，我们对页面可视部分进行操作实际上就是在操作DOM\n3. JavaScript，浏览器提供了BOM，也解析了DOM，那么，开发者如何去操作它们呢？这时候就轮到JavaScript出场了，所以JavaScript（在这个例子中）是用来操作DOM和BOM的\n\n那么所谓的选择器，`getElement(s)ByXXXX`实际上是由DOM提供的，而且对DOM的level实现的程度不一样，这些方法也不一样，比如DOM level 0中主要的方法（确切说是属性）就是`document.images`，`document.links`之类。而DOM level 3中则提供了`querySelector(All)`之类更为方便的API。\n\n\u003C!-- more -->\n\n第二个想说的点是关于为什么没有更精简的API和写法：\n\n1. 在DOM中，所有的方法必须隶属于DOM对象，所以在非别名实现的情况下，以`$`函数来实现是不可能的，即使实现，也会是类似`document.$`之类的方法\n2. 假设使用别名方法实现（即`window.$ = document.$`），那么会有一个很严重的后果——染污全局空间，即jQuery（或者prototype或者其它的任何类库）再也不能使用`$`函数\n3. 即使不纠结是否别名实现的问题，假设可以用`$classname`这样的函数来选择，那么也是有问题的。第一，方法名字不够直观，作为一个浏览器（确切地说，是一份标准），引入一个名称含义不确定的方法是不可以接受的，虽然`getElementById`很长，但是任何人都能一眼看明白它是做什么的，对不对？第二，使用`$`开头似乎不符合JavaScript中的要求，`$`开头的应该是留给机器编译后的代码来避免冲突。（这一点是听说的，我没有自己去看规范。）\n\n第三个想说的是关于jQuery（及风格类似）的选择器。事实上jQuery的选择器的确很方便，但它也引起了很多的争议，包括占用$符号和承载太多重载的jQuery方法（即$），可能跟jQuery的理念有关，“write less, do more”，而一份web标准因为它强大的影响力和不可随意更新（bug就只能bug了，在下一份标准出来前不可能有修复的机会）的特性，显然还要在API设计的方方面面考虑更多的东西。\n",null,0,"2026-08-28 04:37:17","published","\u003Cp>来自知乎问题\u003Ca href=\"https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F20433809\u002Fanswer\u002F15189900\">JavaScript 为什么不内建选择器？\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>首先，与这个问题有关的浏览器中的技术概念其实大致有这些：\u003C\u002Fp>\n\u003Col>\n\u003Cli>BOM，即浏览器对象模型，简单说就是浏览器提供的环境，包括各种对象及其方法，比如window\u003C\u002Fli>\n\u003Cli>DOM，即文档对象模型，它是由HTML经解析后生成的一个模型，我们对页面可视部分进行操作实际上就是在操作DOM\u003C\u002Fli>\n\u003Cli>JavaScript，浏览器提供了BOM，也解析了DOM，那么，开发者如何去操作它们呢？这时候就轮到JavaScript出场了，所以JavaScript（在这个例子中）是用来操作DOM和BOM的\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>那么所谓的选择器，\u003Ccode>getElement(s)ByXXXX\u003C\u002Fcode>实际上是由DOM提供的，而且对DOM的level实现的程度不一样，这些方法也不一样，比如DOM level 0中主要的方法（确切说是属性）就是\u003Ccode>document.images\u003C\u002Fcode>，\u003Ccode>document.links\u003C\u002Fcode>之类。而DOM level 3中则提供了\u003Ccode>querySelector(All)\u003C\u002Fcode>之类更为方便的API。\u003C\u002Fp>\n\u003Cp>第二个想说的点是关于为什么没有更精简的API和写法：\u003C\u002Fp>\n\u003Col>\n\u003Cli>在DOM中，所有的方法必须隶属于DOM对象，所以在非别名实现的情况下，以\u003Ccode>$\u003C\u002Fcode>函数来实现是不可能的，即使实现，也会是类似\u003Ccode>document.$\u003C\u002Fcode>之类的方法\u003C\u002Fli>\n\u003Cli>假设使用别名方法实现（即\u003Ccode>window.$ = document.$\u003C\u002Fcode>），那么会有一个很严重的后果——染污全局空间，即jQuery（或者prototype或者其它的任何类库）再也不能使用\u003Ccode>$\u003C\u002Fcode>函数\u003C\u002Fli>\n\u003Cli>即使不纠结是否别名实现的问题，假设可以用\u003Ccode>$classname\u003C\u002Fcode>这样的函数来选择，那么也是有问题的。第一，方法名字不够直观，作为一个浏览器（确切地说，是一份标准），引入一个名称含义不确定的方法是不可以接受的，虽然\u003Ccode>getElementById\u003C\u002Fcode>很长，但是任何人都能一眼看明白它是做什么的，对不对？第二，使用\u003Ccode>$\u003C\u002Fcode>开头似乎不符合JavaScript中的要求，\u003Ccode>$\u003C\u002Fcode>开头的应该是留给机器编译后的代码来避免冲突。（这一点是听说的，我没有自己去看规范。）\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>第三个想说的是关于jQuery（及风格类似）的选择器。事实上jQuery的选择器的确很方便，但它也引起了很多的争议，包括占用$符号和承载太多重载的jQuery方法（即$），可能跟jQuery的理念有关，“write less, do more”，而一份web标准因为它强大的影响力和不可随意更新（bug就只能bug了，在下一份标准出来前不可能有修复的机会）的特性，显然还要在API设计的方方面面考虑更多的东西。\u003C\u002Fp>\n","\u003Cp>来自知乎问题\u003Ca href=\"https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F20433809\u002Fanswer\u002F15189900\">JavaScript 为什么不内建选择器？\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>首先，与这个问题有关的浏览器中的技术概念其实大致有这些：\u003C\u002Fp>\n\u003Col>\n\u003Cli>BOM，即浏览器对象模型，简单说就是浏览器提供的环境，包括各种对象及其方法，比如window\u003C\u002Fli>\n\u003Cli>DOM，即文档对象模型，它是由HTML经解析后生成的一个模型，我们对页面可视部分进行操作实际上就是在操作DOM\u003C\u002Fli>\n\u003Cli>JavaScript，浏览器提供了BOM，也解析了DOM，那么，开发者如何去操作它们呢？这时候就轮到JavaScript出场了，所以JavaScript（在这个例子中）是用来操作DOM和BOM的\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>那么所谓的选择器，\u003Ccode>getElement(s)ByXXXX\u003C\u002Fcode>实际上是由DOM提供的，而且对DOM的level实现的程度不一样，这些方法也不一样，比如DOM level 0中主要的方法（确切说是属性）就是\u003Ccode>document.images\u003C\u002Fcode>，\u003Ccode>document.links\u003C\u002Fcode>之类。而DOM level 3中则提供了\u003Ccode>querySelector(All)\u003C\u002Fcode>之类更为方便的API。\u003C\u002Fp>\n","",{"total":15,"totalRoots":15,"comments":22,"pv":15},[]]