Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Oct 24, 2013 at 7:06 PM, Maciej Stachowiak wrote: > > On Oct 23, 2013, at 11:24 PM, Yoav Weiss wrote: > > > On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa wrote: > >> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: >> >>> On Sun, Oct 20, 2013 at 10: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. >>> >>> 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
Re: [webkit-dev] The SrcN responsive images proposal
On Oct 24, 2013, at 1:35 AM, Michael[tm] Smith wrote: > Ryosuke Niwa , 2013-10-23 13:22 -0700: > >> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: >>> On Sun, Oct 20, 2013 at 10: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. >>> >>> 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. > > If you're going to do that, and especially if seems like other engines > might end up doing that for similar reasons, it seems like we'd be better > off dispensing with the N part of the proposal and instead have the spec > just define a discrete set of attribute names, e.g., just src1 to src9. > > A recent discussion thread on the public-resp...@w3.org list suggests that > in practice even 10 would be higher than the high end of what sites would > currently actually use: > > http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0019.html > > Most sites that were looked at just use 2 image source alternatives, and > the two sites found with the highest number of alternatives just used 6. > > Doing discrete src1 to src9 would still be ugly but it seems less ugly for > everybody overall than src-N. It did seem gratuitous to me that the proposal in principle requires sorting of arbitrary-precision decimal integers when there is no obvious use case that requires it. (Fortunately you can probably fake it by doing a length comparison and then a string comparison, but still.) Regards, Maciej ___ 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 23, 2013, at 11:24 PM, Yoav Weiss wrote: > > On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa wrote: > On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: > On Sun, Oct 20, 2013 at 10: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. > > 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-") and it's O(N^2) for srcN attributes added dynamically with script. It's likely not the best way to implement the feature. I think the authoring complexity is a more relevant consideration than the implementation complexity, though. Cheers, Maciej > 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 ___ 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
Ryosuke Niwa , 2013-10-23 13:22 -0700: > On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: > > On Sun, Oct 20, 2013 at 10: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. > > > > 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. If you're going to do that, and especially if seems like other engines might end up doing that for similar reasons, it seems like we'd be better off dispensing with the N part of the proposal and instead have the spec just define a discrete set of attribute names, e.g., just src1 to src9. A recent discussion thread on the public-resp...@w3.org list suggests that in practice even 10 would be higher than the high end of what sites would currently actually use: http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0019.html Most sites that were looked at just use 2 image source alternatives, and the two sites found with the highest number of alternatives just used 6. Doing discrete src1 to src9 would still be ugly but it seems less ugly for everybody overall than src-N. --Mike -- Michael[tm] Smith http://people.w3.org/mike ___ 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 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 Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss wrote: > On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa wrote: > >> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. wrote: >> >>> On Sun, Oct 20, 2013 at 10: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. >>> >>> 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
