Re: img.src = null(原:src 与 srcset(或是 src-N)的 JS 交互)

都说了啊,喜欢用null的都是从其他语言刚转过来的新手,他们这样写的目的就是 
要清空src属性。

对于src属性,你也看到了,那是个DOMString的,而不是DOMString?的[1],所以 
它必须有个值。
另外这个属性在Getter里认定其内容是个path或xpath,而path只分为具有schema 
的绝对地址和没有schema的相对地址, 空字符串就是没有任何指向的相对地址。
而实际上如果src没有值的时候就不显示图片。但如果当前地址是个图片,而 
img.src是空字符串的时候,js能得到图片地址,而浏览器却不显 示图片。

这里矛盾的地方在于:渲染的时候判断了src是否是空字符串,而get属性的时候却 
进行这项没判断。
这是HTML和JS,两个标准之间的不一致。


[1]:http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type

于 2013/10/28 0:57, John Hax 写道:
> 拜托。这里不是要解释行为背后的技术原因(你说的那些我早就知道),而是这 
> 些行为是否符合开发者的预期。比如 img.src = null ,开发者这样写是想达到 
> 什么目的?
> FF的行为也是最近才改的,原来是和webkit一样的。
>
> 至于 img.src = '' ,我认为现在浏览器的行为其实是诡异的。因为当前url也 
> 可能返回真的图片(http内容协商可以做到的)。
> 如果让我选择,应该选择 img.src = '' 之后 img.src 仍旧返回空字符串而不 
> 是当前网页地址。
>
>
>
> 2013/10/27 Hawkeyes Wind <hawkeyes0.cn@gmail.com 
> <mailto:hawkeyes0.cn@gmail.com>>
>
>
>     于 2013/10/27 21:57, John Hax 写道:
>>     img.src = '' 的行为在现在浏览器里貌似是:
>>
>>     img.src返回当前网页的绝对地址,但是不发请求,当然也没有图片显示。
>>     应该说是比较诡异的。
>>
>>
>     src为空字符串的时候,首先英文没有http:或https:的schema头,而判定为
>     相对引用,而空字符串在于当前页地址进行路径 计算的时
>     <https:%E7%9A%84schema%E5%A4%B4%EF%BC%8C%E8%80%8C%E5%88%A4%E5%AE%9A%E4%B8%BA%E7%9B%B8%E5%AF%B9%E5%BC%95%E7%94%A8%EF%BC%8C%E8%80%8C%E7%A9%BA%E5%AD%97%E7%AC%A6%E4%B8%B2%E5%9C%A8%E4%BA%8E%E5%BD%93%E5%89%8D%E9%A1%B5%E5%9C%B0%E5%9D%80%E8%BF%9B%E8%A1%8C%E8%B7%AF%E5%BE%84%E8%AE%A1%E7%AE%97%E7%9A%84%E6%97%B6>
>     候没有做任何改变,因此返回网页地址是正确的,不发送请求也是正确的,
>     因为这个地址的东西正在显示。
>
>>
>>     我倒是没有注意到按照现在的规范 img.src = null 实际成了 img.src =
>>     'null'。
>>     我认为规范应该改变这个行为。反正应该在现实中没有人依赖 img.src =
>>     null 的行为。
>>
>>
>     这个行为在Javascript中也是正确的,因为在js中真正为空的是
>     undefined,而不是null,用if就可以 明显的看出来。js中 null表示一个
>     特殊的对象,那么在转换为字符串的时候会直接调用toString()方法,null
>     本身的描述就是"null",所以这个赋值 行为没错,通常这么写的都是刚从
>     别的语言转过来的新手。
>
>>
>>
>>
>>     2013/10/26 Kang-Hao (Kenny) Lu <kanghaol@oupeng.com
>>     <mailto:kanghaol@oupeng.com>>
>>
>>         (2013/10/25 21:52), John Hax wrote:
>>         > 1的方法是把img.src明确为最终显示的图片,也就是排除了同时设
>>         置srcset/src
>>         > 的case。也就是说如果手动设置了src,就覆盖了srcset的设置。除
>>         非你再
>>         > img.src = null(当前规范未对这样应该执行的行为做出明确规
>>         定,浏览器一般
>>         > 是忽略。但如果采取1,则取消对srcset的覆盖是比较合理的行为,
>>         且此行为与
>>         > 浏览器当前行为是兼容的)。
>>
>>         当前规范们有对 "img.src = null" 对这样应该执行的行为做出明确
>>         规定,请参考
>>         WebIDL 属性设值算法[1]与 ECMAScript 值转成 IDL DOMString 值的
>>         算法[2]。这
>>         里的关键是
>>
>>         interface HTMLImageElement : HTMLElement {
>>                    ...
>>                    attribute DOMString src;
>>                    ...
>>         }
>>
>>         的 attribute 前面有没有 [TreatNullAs=EmptyString] 标签。没有
>>         就是 null 会
>>         被转成 "null"。
>>
>>         当然,有明确规定跟合不合实现或是合不合理是两回事,src 属性该
>>         不该有
>>         [TreatNullAs=EmptyString] 也有争过[3]。目前是
>>
>>           规范 = 新 Firefox = IE ≠ 旧 Firefox = WebKit
>>
>>         的样子。
>>
>>         [1] http://www.w3.org/html/ig/zh/wiki/WebIDL#dfn-attribute-setter
>>         [2]
>>         http://dev.w3.org/2006/webapi/WebIDL/#dfn-convert-idl-to-ecmascript-value
>>         [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21668
>>
>>         (2013/10/25 23:39), Kang-Hao (Kenny) Lu wrote:
>>         >    HTML                       <img src=xxx srcset=xxx />
>>         > +  不支持 srcset 的 JS 库 1   设置了 .src
>>         > +  支持 srcset 的 JS 库 2     设置了 .srcset
>>         >
>>         > 那这个时候 JS 库 2 会不起作用。支持 .srcset 的 JS 库的完整
>>         正确写法是
>>         >
>>         >   img.src = null;†
>>         >   img.srcset = 新值;
>>
>>         所以这里的正确写法应该是
>>
>>           img.src = "";
>>           img.srcset = 新值;
>>
>>         。不过我换个方向问,应该很多人都有注意到在 DOM 里 null 大多会变成
>>         "null",img.src 的特别之处在哪?
>>
>>
>>         话说,我感觉多了解 WebIDL 对很多人看规范都很有帮助,比如之前
>>         [ArrayClass] 的讨论[4]或许我们应该优先翻译 WebIDL?
>>
>>         [4]
>>         http://lists.w3.org/Archives/Public/public-html-ig-zh/2012Jun/thread#msg18
>>
>>         以上
>>
>>         Kenny
>>         --
>>         Web Specialist, Opera Sphinx Team, Oupeng Browser, Beijing
>>         Try Sphinx: http://sphinx.oupeng.com/
>>
>>
>
>     -- 
>     Regards
>
>     Hawkeyes Wind
>
>

-- 
Regards

Hawkeyes Wind

Received on Monday, 28 October 2013 02:32:02 UTC