- From: Hawkeyes Wind <hawkeyes0.cn@gmail.com>
- Date: Mon, 28 Oct 2013 11:14:57 +0800
- To: John Hax <johnhax@gmail.com>
- CC: 中文HTML5同樂會ML <public-html-ig-zh@w3.org>
- Message-ID: <526DD6B1.3030904@gmail.com>
只有新手才分不清null和undefined，js里面的null从来都不是空，而且nullable
指的也不是null，而是 undefined。看js相关内容的时候必须转换思路。
于 2013/10/28 11:09, John Hax 写道:
> 都说了，这里是要探讨行为是否合理，而不是揣测开发者是不是“新手”。如果大
> 多数程序员的直觉对 img.src = null 是清空图片，那么现在规范就是不合理
> 的。这跟是不是新手没有关系。
>
> 这里和nullable也没有关系。问题在于是否要[TreatNullAs]。我的意见，DOM的
> 绝大多数 DOMString属性都应该[TreatNullAs=EmptyString]且最好
> [TreatUndefinedAs=Null]。在这一点上，WebKit的行为大多数是这样的。比如
> className = null。
>
> 所以问题出在标准上。WebIDL是逐步开发的，DOM标准是分开的。反过来浏览器
> 实现又逐步靠拢WebIDL。如FF等。这 些不同步导致nul的问题没有得到恰当的解决。
>
>
>
> 2013/10/28 Hawkeyes Wind <hawkeyes0.cn@gmail.com
> <mailto:hawkeyes0.cn@gmail.com>>
>
> 都说了啊，喜欢用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:或 <http:%E6%88
>> %96>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
>
>
--
Regards
Hawkeyes Wind
Received on Monday, 28 October 2013 03:15:31 UTC