Re: [webkit-dev] The SrcN responsive images proposal
Hi all, srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport (not implemented yet, but it is planned, it is in my todo list) why don't you propose improvements to the original specification/implementation instead of reinventing the wheel ? Syntaxically-speaking, it's not smart. I agree with Maciej. Regards, Romain 2013/10/20 Maciej Stachowiak m...@apple.com My initial impression is that it seems a bit overengineered. - Maciej On Oct 19, 2013, at 4:39 PM, Yoav Weiss y...@yoav.ws wrote: Hello WebKiteers, I'd like to get the project's opinion on a recent responsive image proposal by Tab Atkins dubbed srcN: http://tabatkins.github.io/specs/respimg/Overview.html This proposal covers all the major responsive images use-cases: DPR based resource selection, viewport dimensions based resource selection and art-direction. It does so while avoiding previous implementor concerns regarding the picture element and its complexity, and while providing better authoring tools for viewport based resource selection than previous proposals. The srcN proposal does come to replace the srcset DPR switching syntax which recently landed in WebKit (an effort I was a part of). OTOH, srcN's x-based URL syntax replicates srcset's DPR syntax, so I believe large parts of that code can be reused in srcN's implementation. Will the project welcome patches implementing the srcN proposal? (Possibly behind a flag) Thanks, Yoav ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Oct 20, 2013 11:31 AM, PERIER Romain romain.per...@gmail.com wrote: Hi all, srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport The reasoning behind the new proposal was detailed by John Melloer at http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/ In short, srcset's viewport syntax doesn't cover the art-direction use-case and doesn't really cover the viewport based resource selection use case either. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Le 20 oct. 2013 à 14:39, Yoav Weiss y...@yoav.ws a écrit : On Oct 20, 2013 11:31 AM, PERIER Romain romain.per...@gmail.com wrote: Hi all, srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport In short, srcset's viewport syntax doesn't cover the art-direction use-case and doesn't really cover the viewport based resource selection use case either. So, it is a good enough reason to rewrite everything from scratch without even trying to propose an improvement to the specification ? As far I know the spec and the implementation are still work in progress, so… Regards, Romain ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. antti On Sun, Oct 20, 2013 at 4:00 AM, Maciej Stachowiak m...@apple.com wrote: My initial impression is that it seems a bit overengineered. - Maciej On Oct 19, 2013, at 4:39 PM, Yoav Weiss y...@yoav.ws wrote: Hello WebKiteers, I'd like to get the project's opinion on a recent responsive image proposal by Tab Atkins dubbed srcN: http://tabatkins.github.io/specs/respimg/Overview.html This proposal covers all the major responsive images use-cases: DPR based resource selection, viewport dimensions based resource selection and art-direction. It does so while avoiding previous implementor concerns regarding the picture element and its complexity, and while providing better authoring tools for viewport based resource selection than previous proposals. The srcN proposal does come to replace the srcset DPR switching syntax which recently landed in WebKit (an effort I was a part of). OTOH, srcN's x-based URL syntax replicates srcset's DPR syntax, so I believe large parts of that code can be reused in srcN's implementation. Will the project welcome patches implementing the srcN proposal? (Possibly behind a flag) Thanks, Yoav ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On 10/20/13, 9:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. I was thinking the same thing last night. In addition to weirdness on the engine side, it looks like a nightmare for authoring/tooling. Is there a precedent for this strange notation? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Sun, Oct 20, 2013 at 11:08 PM, Benjamin Poulain benja...@webkit.orgwrote: On 10/20/13, 9:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. I was thinking the same thing last night. In addition to weirdness on the engine side, it looks like a nightmare for authoring/tooling. Is there a precedent for this strange notation? Also CSS selectors only support matching exact attribute names. There is no way to write universal elements with some srcN attribute query for example. This might not be important for practical uses here but it does demonstrate that the approach is a poor fit to the platform. antti Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
