Re: src 与 srcset（或是 src-N）的 JS 交互

更明确的讲：

方案1是严格保持了原本的img.src
property的意义的。变化在于，以前img.src只对应单个@src属性，现在对应的是@srcset和@src两个属性。所以方案1必然是兼容性最好的方案。




2013/10/25 John Hax <johnhax@gmail.com>

> 1的方法是把img.src明确为最终显示的图片，也就是排除了同时设置srcset/src的case。也就是说如果手动设置了src，就覆盖了srcset的设置。除非你再img.src
> =
> null（当前规范未对这样应该执行的行为做出明确规定，浏览器一般是忽略。但如果采取1，则取消对srcset的覆盖是比较合理的行为，且此行为与浏览器当前行为是兼容的）。
>
> 对于不用srcset的页面来说，1的方案不会有任何影响。
>
> 对于用srcset的html，但使用老的不支持srcset的库。库只修改src，固然一旦修改src就失去了srcset作用，但至少功能能保持预想的方式。
> 最后，使用支持srcset的库。脚本要改变图片，只操作srcset，不操作src。@src是给不支持srcset的fallback。表面上看，这也有同样问题，脚本如果要改变fallback的值，需要setAttribute('src',
> value)。但是实际上是不需要设fallback的，而是写成这样
> if ('srcset' in img) img.srcset = newSrcSet; else img.src = newSrcFallback
> 就可以了。注意这代码即使对现在的srcset实现也是对的。这里的要点是，html因为是静态的，需要同时写srcset和src，但是脚本不需要同时写入。
>
> 注意1和2的差别是：方案1的img.src永远override
> @srcset和@src，所以不存在优先级问题；方案2的src和srcset属性是和@src和@srcset对应的，就产生了优先级、顺序之类的问题。
>
>
> “我”是指开发者。我说的意思是，开发者不知道当前处于哪种状态。因为看src和srcset是不知道那是被覆盖的值还是默认的@attr的值，因此无法确定此刻到底是什么优先级或顺序。也就是这个行为是只写的。这跟input的脏值标记不一样，因为input不存在优先级问题，开发者是不需要知道是否处于脏值的。开发者最多需要知道值是否改变，拿input.value比较input.defaultValue就可以了。而img不行，开发者非常可能需要知道当前到底是src起作用，还是srcset起作用。
>
>
>
>
> 2013/10/25 Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
>
> (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/

>>
>
>