Re: [webkit-dev] The SrcN responsive images proposal
On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi 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. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? When thinking about the feature's implementation for Blink, I found it easier to iterate once over the element's attribute, create a vector containing all the srcN attributes (so all attrs that start with src-), sort it according to attribute numeric order, and return that vector when the srcN attributes are requested from the element. For the HTMLPreloadScanner, I'd probably need to create a similar vector attribute by attribute, sort it at the tag's end, and send it to the main thread. Wouldn't a similar approach work for WebKit? ___ 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 Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi 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. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. 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. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Wink browser
Can I run the wink browser now ? Though I tried to install it to my window7 PC using WinkInstaller.msi, installation was failed. Gyuyoung. On Fri, Oct 11, 2013 at 1:42 PM, Brent Fulgham bfulg...@gmail.com wrote: Fantastic work! I can't wait to see what you do with it. -Brent Sent from my iPad On Oct 10, 2013, at 6:08 PM, Alex Christensen alex.christen...@flexsim.com wrote: With the removal of Chromium and Qt, there are no projects of which I am aware that allow Windows users to use WebKit with content from the open internet. I've started a web browser project I'm calling Wink to get the public to use WebKit on Windows, and I'm collecting crash reports with stack traces to allow me to locate and fix common crashes. I've created Winkbrowser.org and Winkbrowser.org/nightly.php as a start. Could whoever manages nightly.webkit.org please send me some example code? You might have noticed that writing aesthetically pleasing php isn't exactly my strength. I hope this will be seen as beneficial to the WebKit community. Alex Christensen ___ 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 Thu, Oct 24, 2013 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 23, 2013, at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi 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. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? When thinking about the feature's implementation for Blink, I found it easier to iterate once over the element's attribute, create a vector containing all the srcN attributes (so all attrs that start with src-), sort it according to attribute numeric order, and return that vector when the srcN attributes are requested from the element. Your described strategy is both not quite correct (srcN attributes are not all attributes that start with src-) I left out the followed by an integer part. Obviously, that should be part of the algorithm. and it's O(N^2) for srcN attributes added dynamically with script. The typical case for dynamically added srcN attributes would be adding them in order (since otherwise, a wasteful resource download might be triggered). That is very similar to srcset, which when added dynamically, must be added before the src attribute. For that case, adding N dynamic attributes to the end of the vector would have O(N) complexity. The case for unordered addition can be optimized to O(NlgN) by replacing the vector with a linked list and adding each new attribute in its order using binary search. I think the authoring complexity is a more relevant consideration than the implementation complexity, though. I agree. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
