<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 5, 2013, at 11:18 AM, John Mellor <<a href="mailto:johnme@chromium.org">johnme@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of.<div>
<br></div><div>I'm of the opinion that we should use exactly one attribute for this feature.</div></div></blockquote><div><br></div><div>The thing is, srcN isn't a list, it's a list of lists. Consider the following srcN for a fixed-width image with art direction:</div>
<div><br></div><div><font face="courier new, monospace"><img src-1="(min-width: 640px) 0.5x photo@0.5x.jpg, 1x photo@1x.jpg, 2x photo@2x.jpg"</font></div><div><font face="courier new, monospace"> src-2="0.5x photo-crop@0.5x.jpg, 1x photo-crop@1x.jpg, 2x photo-crop@2x.jpg"></font></div>
<div><br></div><div>I guess one could combine it all into one attribute, e.g. by introducing "||" as an 3rd separator, in addition to the existing "," and ";". For example:</div><div><br></div>
<div><font face="courier new, monospace"><img srcset="(min-width: 640px) 0.5x photo@0.5x.jpg, 1x photo@1x.jpg, 2x photo@2x.jpg || 0.5x photo-crop@0.5x.jpg, 1x photo-crop@1x.jpg, 2x photo-crop@2x.jpg”></font></div></div></div></div></blockquote><div><br></div><div>I assume authors would just create a new line for each list. That is basically what you do with src-1 and src-2 as well in your example. Writing both beyond each other wouldn’t be very helpful for readability either. I personally do not see where authors would really care if the lists are in two attributes or one. It seems rather a matter of taste or even believe. The point is that srcset can be extended to support more as you suggest in your example.</div><div><br></div><div>Greetings,</div><div>Dirk</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>But that seems rather harder to read...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>- R. Niwa<br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss <span dir="ltr"><<a href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss <span dir="ltr"><<a href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><span style="color:rgb(80,0,80)">On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br>
<div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. <span dir="ltr"><<a href="mailto:jackalmage@gmail.com" target="_blank">jackalmage@gmail.com</a>></span> wrote:</div>
<div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <<a href="mailto:koivisto@iki.fi" target="_blank">koivisto@iki.fi</a>> wrote:<br>
> Ignoring other aspects of this, the idea of making attribute name an<br>
> enumeration is somewhat distasteful. It will require ugly special parsing.<br>
> The platform has plenty of attribute values that are lists already.<br>
<br>
</div>The parsing aspect isn't particularly new - parsing data-* attributes<br>
presents the same problem. You just need to filter the list of<br>
attributes on the element to look for things with a src- prefix. I've<br>
heard direct feedback from Yoav, implementing in Blink, that it's not<br>
a big problem.<br></blockquote><div><br></div></div><div>Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines.</div><div>If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10.</div>
<div>so that we can enumerate all parsed attributes statically at the compilation time.</div></div></div></div></blockquote><div> </div></div><div>Out of curiosity, what would be the benefits of such a restriction? <br>
</div></div></div></div></blockquote><div><br></div></div><div>We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time.</div><div><br></div>
<div>
Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states.</div><div>
<br>
</div><div>- R. Niwa</div></div></div></div></blockquote><div><br></div></div><div>Will setting the limit on the number of possible attributes at 99 still enable that optimization?</div><div>Many people (on the RICG's IRC and on Blink-dev) feel that setting the limit to 9, even if it'd be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you?</div>
</div><br></div></div>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
<br></blockquote></div><br></div></div>
_______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>https://lists.webkit.org/mailman/listinfo/webkit-dev<br></blockquote></div><br></body></html>