- From: Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
- Date: Thu, 24 Oct 2013 01:56:48 +0800
- To: 一丝 <yiorsi@gmail.com>, John Hax <johnhax@gmail.com>, Leo Deng <myst.dg@gmail.com>
- CC: W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>
(2013/10/23 15:37), 一丝 wrote: > 从直观上来说,我倾向于1, 如果可以的话,能详细讲解心路历程么? 我可能没讲清楚。我担心的情景是如果某个前端在 HTML 里面各个 <img> 已经开 始用 @srcset,但是该前端用的 JS 库还没跟上 @srcset 的情形(需要作一次 .srcset = ""; 拿掉),要去改那个 JS 库可能不是一个选择。 举个很假的例子: 假设现在有一个网页对一个画面上的跨域的 <img> 用了 CamanJS 这个 jQuery 插件,然后,现在一个前端同学想在这个 <img> 上加上 srcset 的高 清版本,但是不清楚 CamanJS 的实现。最后就会导致 CamanJS 在读取 getImageData 的时候抛出 SecurityError,因为 CamanJS 把 <img> 的 @src 换掉的时候,没有把 @srcset 也给换掉。 这个正解是在 CamanJS 的[1]的地方把 @srcset 也换掉或是设为空字符串,总之 就是一个麻烦,而且可能很不好调试的坑。 (举这个假例子只是想说明我很努力从一个 jQuery 插件列表[2]列出的图像处理 插件里面一个一个看代码,看了 5 个之后终于找到一个有问题了。其他 4 个都是 用 $('<img/') 创建新的 <img>,所以不会有这个问题。我没有完整做过一个网站 的前端经验,还希望前端同学看看手上的图像插件看看有没有类似的问题。) [1] https://github.com/meltingice/CamanJS/blob/master/src/core/caman.coffee#L280 [2] http://tutorialzine.com/2013/04/50-amazing-jquery-plugins/ > 而且现在Chrome 的实现也是和1相同。 我真不觉得当前的 Chrome 实现跟这个行为是好是坏有什么关系。 > [恕删] > > 我写了一个更加直观的Demo:http://jsbin.com/OVUQoXO/4/edit > > 请用最新的 Chrome canary 测试。 这个 Demo 着重在 getAttribute('src') 是什么的问题(这重要么?),连新的 src 都是假的…… (2013/10/23 16:15), John Hax wrote: > 关于 src 属性,注意 image.src 本来就不是 @src 属性的值,就好像 > input.value 不是 @value。所以应该让 image.src 永远返回当时真正显示图片 > 的绝对地址。修改 image.src 也就总是更新图片。 对,input.value 是个好例子。现在的规范与 Chrome 的实现就是说 image.src 在读取的时候要是 @src 转成的绝对 URL,修改 image.src 的时候即成为 @src 属性的值。所以我可以确认一下你觉得当前的规范还有 Chrome 的实现是有问题的 么?具体规范该是什么行为的细节可以再讨论。 image.src 的返回值不能是真正显示图片的地方主要是隐私权的问题,因为 srcset 的规范有说浏览器可以透过用户当前的宽带好坏决定要选择哪个图像,所 以有可能可以透过读取 .src 知道用户当前的宽带好坏的隐私问题。不过这个部分 我想本来就相当有漏洞,不管怎么样把 <img> 放大画到一个 <canvas> 再 getImageData 出来还是可以知道选到什么东西。 不管怎么样,还是来排序一下吧,你对 1) image.src 设值总是更新图片,.src 永远返回当时真正显示图片。 2) image.src 设值总是更新图片,.src 返回 @src。 3) image.src 设值只更动 @src,.src 返回 @src。 的排序是啥?我是 1 > 2 > 3。我知道你肯定是 1 最大,不过 2 跟 3 的排序如 何?我 2 > 3 的理由主要就是上面讲的那个坑。 (2013/10/23 15:37), 一丝 wrote: > 另外,@米粽 倾向于img.srcList.set('2x', 'url')这样的语法,欢迎大家一起 > 讨论! (2013/10/23 15:59), Leo Deng wrote:> 我的意见是: > 1)能不引入新标签就不引入。因此我认为 src-N 的方向优于 <picture> 标 > 签。 > 2)对于 src/src-N,我倾向于通过一个统一的接口来操作,比如说增加一个 > srcList 对象,这样我们就可以通过类似 srcList.set('1x', 'url-to- > image.png')、srcList.set('2x', 'url-to-hd-image.png') 这样的方式来更 > 改属性。相应的也可以用 getter 来获取某种缩放比例的使用图片,或通过 key > 枚举来判断某种比例是否已设置。 (2013/10/23 16:15), John Hax wrote: > picture的优点也不容忽视,有更好的accessibility,fallback结构和 > video/audio/object一致。 如果可以的话,我是觉得 .srcList 这个应该开一个新的讨论串分开讨论,不过 @ 米棕在群里的意见是这个: 米粽 (Leo Deng): 12:07:44 如果是有srcList这类玩意,那我倾向于结果 1) 米粽 (Leo Deng): 12:07:52 否则2) 这个逻辑有点复杂了,可以解释一下么?假设说 2014 年浏览器实现了 @srcset, 但是到了 2015 年才有 .srcList 的情况下,2014 年的 .src 也应该是 1) 么? 还是你觉得浏览器在没有 .srcList 之前,不该发出有 @srcset 的版本? 至于 <picture> vs. src-N vs. srcset 的问题请在《响应式图片的讨论》继续,某 种意义上 <picture>.src 没这种兼容包袱也是一个有点。不过假设最后 src-N 或 是 srcset 获胜的话,这个 .src 的问题我还是挺担心的,希望能早点解决(在 这个邮件组有大致的共识)。 以上 Kenny -- Web Specialist, Opera Sphinx Team, Oupeng Browser, Beijing Try Sphinx: http://sphinx.oupeng.com/
Received on Wednesday, 23 October 2013 17:57:16 UTC