- From: Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
- Date: Fri, 25 Oct 2013 10:15:43 +0800
- To: John Hax <johnhax@gmail.com>
- CC: 一丝 <yiorsi@gmail.com>, Leo Deng <myst.dg@gmail.com>, W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>
(2013/10/24 11:44), John Hax wrote: > 2013/10/24 Kang-Hao (Kenny) Lu <kanghaol@oupeng.com> >> 这个正解是在 CamanJS 的[1]的地方把 @srcset 也换掉或是设为空字符串,总 >> 之就是一个麻烦,而且可能很不好调试的坑。 > > 这就是我为什么希望 img.src 的行为应该是总是返回和设定最终显示图片,因 > 为这符合原来库开发者的期望,也就是有最大的backward compability。 这个情景是 .src 设定。返回的兼容问题 public-respimg 的 porneL[1] 提到了 Masonry 的 imagesLoaded 这个库有这种问题,可是我看了一下代码[2](用 .src 当成缓存的钥匙),怎么感觉是只有在 <img srcset="picture1.png, picture1-HD.png 2x" /> <img srcset="picture2.png, picture2-HD.png 2x" /> 这种没有 @src 的情况下问题比较大(这两个图片的 LoadingImage 的钥匙都是空 字符串,造成缓存碰撞)。其他的状况像是 <img src="picture.png" srcset="picture-HD1.png 2x" /> <img src="picture.png" srcset="picture-HD2.png 2x" /> 或是 <img src="picture.png" src1="(max-width: 300px) picture-300.png" /> <img src="picture.png" src1="(max-width: 600px) picture-600.png" /> 的情形感觉出现的几率都不大。.src 读取不向后兼容还有那种比较常出现的可能 么?还是说可以想像很多开发者会很快就会用没有 @src 的 <img />(虽然不兼容 没 @srcset 的浏览器)? [1] http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0059 [2] https://github.com/desandro/imagesloaded/blob/master/imagesloaded.js#L204 > [跳过隐私、安全问题,非专家] > >> 不管怎么样,还是来排序一下吧,你对 >> >> 1) image.src 设值总是更新图片,.src 永远返回当时真正显示图片。 >> 2) image.src 设值总是更新图片,.src 返回 @src。 >> 3) image.src 设值只更动 @src,.src 返回 @src。 >> >> 的排序是啥?我是 1 > 2 > 3。我知道你肯定是 1 最大,不过 2 跟 3 的排序 >> 如何?我 2 > 3 的理由主要就是上面讲的那个坑。 >> > > 我的选择就是1。2和3都有问题。 > > 2的问题是error-prone。考虑你如何同时更新src/srcset?用setAttribute?还 > 是按照特定顺序(先设src再设srcset)?或者,如果脚本设置了src属性就用 > src而不考虑@srcset,除非脚本也设置了srcset。 等等,你可以先说为什么 1 没有这个问题么? 同时更新 src/srcset 的状况的确像你说的有两种处理法。一种就是要求“强制顺 序、规定用 setAttribute、或是直接创建新的元素 $('<img src=xxx srcset=xxx/>') 其一”。另一种也就是你说的 “如果脚本同时设置了 src/setset,则 srcset 覆盖 src。否则,src 把 srcset 取消”。 > 但是我怎么知道脚本是否设置了src或srcset?总之,就是大坑一个。 这个 “我” 是谁?规范/实现当然是有方法的。类似 input.value 的处理法就行 了,也就是在 .srcset 设置的时候,加一个类似 input 的 “脏值标记”[3],即 | 如果 img 元素有 “srcset 脏值标记”,则 .srcset 设置的值总是覆盖 | .src 的值。否则,.src 覆盖 @srcset 的值。 总之这是规范/实现细节。没什么不可能的。倒是有这个坑: HTML 里有 <img /> + JS 库 1 进行了 .srcset 与 .src 的操作 + JS 库 2 只进行了 .src 的操作 那的确会回到 “JS 库 2”的 .src 操作改不了图片的问题。所以基本上我是支持强 制顺序。 还是继续问刚刚那个问题。为啥 1 没有这个问题么?如果真是 1 也有这个问题, 你还是 1 > 3 > 2 么?还是你会觉得 “强制顺序” 这个坑大到 3 或许比 1 好的 程度? 我个人是觉得 .src 设置已经够少用了,.srcset 的设置应该又会少了一个数量级。 [3] http://www.w3.org/html/ig/zh/wiki/HTML5/the-input-element#concept-input-value-dirty-flag > 3的问题是导致以前不考虑srcset的库无法用于具有srcset属性的内容。虽然也 > 是问题,但是至少是网站开发者可控的问题。 > > 如果一定要排序,或许是 1 > 3 > 2 。 以上 Kenny -- Web Specialist, Opera Sphinx Team, Oupeng Browser, Beijing Try Sphinx: http://sphinx.oupeng.com/
Received on Friday, 25 October 2013 02:16:15 UTC