Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
Hi Maciej, 1. It's been on your bug database for ages hence filing another entry won't move anything forwards. 2. svg 1.1 spec seems a little over the top in places so not personally interested in full support - just the good stuff. 3. Have provided you with a minimal test case in the previous post. 4. Cite real-world sites using the functionality to the relevant bugs. ? chicken and egg. that's not how we make progress ! I'll use it in our site when it works but can't until it does. For now I have to iframe as a workaround but that sucks because iframes grab the entire rect for mouse input which means you can't subtly blend svg over html. 5. Like you, I am busy. I don't have time to fix this (really). Sorry, appreciate you don't like that but it is what it is. 6. Would be great if this could be advanced in priority to enable us to raise the bar, cross browser. Am sure you won't appreciate this fired back at the mailing list I realise I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel :) Thanks for all your hard work. FF has svg bugs too - different (lower priority niggles). Will go hassle them next. IE9 a bit wobbly too, but well ... :) If basic support can be solidified cross browser, we have an interesting platform over above html5. Best regards, Steve. On 13/01/2013 21:37, Maciej Stachowiak wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.com mailto:stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web standard - please address this. Best regards, Steve Williams root.svgobject.svg___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
On Mon, Jan 14, 2013 at 12:51 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: 1. It's been on your bug database for ages hence filing another entry won't move anything forwards. 2. svg 1.1 spec seems a little over the top in places so not personally interested in full support - just the good stuff. 3. Have provided you with a minimal test case in the previous post. 4. Cite real-world sites using the functionality to the relevant bugs. ? chicken and egg. that's not how we make progress ! I'll use it in our site when it works but can't until it does. For now I have to iframe as a workaround but that sucks because iframes grab the entire rect for mouse input which means you can't subtly blend svg over html. Have you considered using SVG-in-HTML? https://developer.mozilla.org/en-US/docs/SVG_In_HTML_Introduction Adam 5. Like you, I am busy. I don't have time to fix this (really). Sorry, appreciate you don't like that but it is what it is. 6. Would be great if this could be advanced in priority to enable us to raise the bar, cross browser. Am sure you won't appreciate this fired back at the mailing list I realise I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel :) Thanks for all your hard work. FF has svg bugs too - different (lower priority niggles). Will go hassle them next. IE9 a bit wobbly too, but well ... :) If basic support can be solidified cross browser, we have an interesting platform over above html5. Best regards, Steve. On 13/01/2013 21:37, Maciej Stachowiak wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web standard - please address this. Best regards, Steve Williams root.svgobject.svg___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] HTML5 Body onLoad event not firing
Hi All, I'm working for Webkit WIN32 port. I'm facing an issue : 1) For HTML5 video tag: videoonload = onLoad() src = E:/xyz.mp4 for the above mentioned code onLoad fucntion is not firing. but if I remove src tag value onLoad event will start firing. I have debugged and found that, :checkCompleted() is exiting from if (m_frame-document()-isDelayingLoadEvent()) return; and thus Implicit Close is not firing. Please let me know if there is any solution. Regards, Ankit Srivastava ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Sat, Jan 12, 2013 at 10:07 PM, Ryosuke Niwa rn...@webkit.org wrote: What happens to corresponding event constructors (e.g. WebKitTransitionEvent) and content attributes (e.g. onwebkittransitionend)? As I said in the mail we'll need to add them (could be done in a separate patch). There is also some objective-c bindings that I need to look at. On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something new because it never happens in the past so we don't have support for having such a mechanism for event delivery. I thought that we could somewhere in the Animation/Transition code be smart and try to figure which event to send but it practically impossible to access the EventListenerMap so I thought we could support it somehow generically in the DOM events code. It will be useful for the animations and maybe in the future (we're not really sure if prefixed event will again show but who knows). So I did a first patch there [2] and I would like to gather feedback whether the approach is correct (I don't know much the DOM related code) or if somebody has a better idea on how to resolve the problem. Also if I have missed something, please point it to me. The patch doesn't include the support for HTML ontransitionend attribute which I prefer to do in a later patch. Thanks. [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property [2] https://bugs.webkit.org/show_bug.cgi?id=105647 -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org wrote: I've been wondering about the implications of prefixed events. Do we have other examples of events that had prefixed names and were later unprefixed? We've never had such a case in the past. It's the first time we have to unprefix DOM events. In particular, what are the composition implications of your solution? When you say depending if someone is listening to it or not you mean whether there is a handler attached that will be triggered by this event, not whether there is a handler for that type of event anywhere on the page, right? Is it likely I'm not sure to understand this part. What is the difference you are talking about? Do you mean whether the user added an event listener on an element or on the document. If it's the case then WebKit event delivery code does not make any difference from what I can see. that existing code might put handlers on the document (eg. maybe as a sort of polling mechanism when there are many elements that may be involved in transitions?), and if so are we likely to have trouble with different libraries that used to co-exist peacefully in the same site no longer working together? The philosophy of forcing a site to update to the unprefixed name really only makes sense to me if you think of a site as a single application, not as a collection of separately maintained libraries and components. Well usually libraries tend to support multiple vendors so if we send the unprefixed version then I'm pretty sure it's handled somewhere. For example, Opera and Mozilla ship unprefixed for some time so I believe anyway the web is slowly updating. Worst I believe that because WebKit does not ship unprefixed transitions and animations they end up having code extra to support us. Rick On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth aba...@webkit.org wrote: That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something new because it never happens in the past so we don't have support for having such a mechanism for event delivery. I thought that we could somewhere in the Animation/Transition code be smart and try to figure which event to send but it practically impossible to access the EventListenerMap so I thought we could support it somehow generically in the DOM events code. It will be useful for the animations and maybe in the future (we're not really sure if prefixed event will again show but who knows). So I did a first patch there [2] and I would like to gather feedback whether the approach is correct (I don't know much the DOM related code) or if somebody has a better idea on how to resolve the problem. Also if I have missed something, please point it to me. The patch doesn't include the support for HTML ontransitionend attribute which I prefer to do in a later patch. Thanks. [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property [2] https://bugs.webkit.org/show_bug.cgi?id=105647 -- Software Engineer @ Intel Open Source
[webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
Hi, This email is a heads-up about the repository change we are starting today in github. In summary, now the github webkit repository will actually mirror git.webkit.org and they will finally have the same git hashes. I won't go into the benefits of this change since this has been widely discussed in the past. Since last week me, Tor Arne, William Siegrist, Adam Barth and Lucas Forschler have been discussing the steps to move on with this and since no one has raised any issues so far on previous discussions, I will start this today. We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard ale...@webkit.org wrote: On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org wrote: I've been wondering about the implications of prefixed events. Do we have other examples of events that had prefixed names and were later unprefixed? We've never had such a case in the past. It's the first time we have to unprefix DOM events. In particular, what are the composition implications of your solution? When you say depending if someone is listening to it or not you mean whether there is a handler attached that will be triggered by this event, not whether there is a handler for that type of event anywhere on the page, right? Is it likely I'm not sure to understand this part. What is the difference you are talking about? Do you mean whether the user added an event listener on an element or on the document. If it's the case then WebKit event delivery code does not make any difference from what I can see. Sorry, what I'm trying to ask is, what happens when: - e1 has a 'webkitTransitiionEnd' handler, and - e2 has a 'transitionend' handler You made it clear that if e1==e2 then you'd dispatch only transitionend. But what about when e1 is neither an ancestor or descendant of e2? I.e. are you looking at all handlers on the page to determine which events to dispatch, or only some subset of them specific to the context of the event being dispatched? that existing code might put handlers on the document (eg. maybe as a sort of polling mechanism when there are many elements that may be involved in transitions?), and if so are we likely to have trouble with different libraries that used to co-exist peacefully in the same site no longer working together? The philosophy of forcing a site to update to the unprefixed name really only makes sense to me if you think of a site as a single application, not as a collection of separately maintained libraries and components. Well usually libraries tend to support multiple vendors so if we send the unprefixed version then I'm pretty sure it's handled somewhere. For example, Opera and Mozilla ship unprefixed for some time so I believe anyway the web is slowly updating. Worst I believe that because WebKit does not ship unprefixed transitions and animations they end up having code extra to support us. Oh, if most important libraries have already updated to always listen for the unprefixed events (and most important sites using those libraries have updated to a version that does this), then I agree there shouldn't be any such composition concerns. I don't have any data, but I just assumed with the history of CSS animations on webkit-dominated mobile, that there could still be a lot of deployed code (especially in the mobile space) that looks only for webkitTransitionEnd. Rick On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth aba...@webkit.org wrote: That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Mon, Jan 14, 2013 at 9:56 AM, Alexis Menard ale...@webkit.org wrote: On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers rby...@chromium.org wrote: On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard ale...@webkit.org wrote: On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org wrote: I've been wondering about the implications of prefixed events. Do we have other examples of events that had prefixed names and were later unprefixed? We've never had such a case in the past. It's the first time we have to unprefix DOM events. In particular, what are the composition implications of your solution? When you say depending if someone is listening to it or not you mean whether there is a handler attached that will be triggered by this event, not whether there is a handler for that type of event anywhere on the page, right? Is it likely I'm not sure to understand this part. What is the difference you are talking about? Do you mean whether the user added an event listener on an element or on the document. If it's the case then WebKit event delivery code does not make any difference from what I can see. Sorry, what I'm trying to ask is, what happens when: - e1 has a 'webkitTransitiionEnd' handler, and - e2 has a 'transitionend' handler You made it clear that if e1==e2 then you'd dispatch only transitionend. But what about when e1 is neither an ancestor or descendant of e2? I.e. are you looking at all handlers on the page to determine which events to dispatch, or only some subset of them specific to the context of the event being dispatched? In that particular case, from my testing e1 handler will be called and e2 handler too. The case I was raising is if you have an event handler installed on the same element for both events. Perfect, thanks. I think that means the majority of composition scenarios I was worried about should be fine... that existing code might put handlers on the document (eg. maybe as a sort of polling mechanism when there are many elements that may be involved in transitions?), and if so are we likely to have trouble with different libraries that used to co-exist peacefully in the same site no longer working together? The philosophy of forcing a site to update to the unprefixed name really only makes sense to me if you think of a site as a single application, not as a collection of separately maintained libraries and components. Well usually libraries tend to support multiple vendors so if we send the unprefixed version then I'm pretty sure it's handled somewhere. For example, Opera and Mozilla ship unprefixed for some time so I believe anyway the web is slowly updating. Worst I believe that because WebKit does not ship unprefixed transitions and animations they end up having code extra to support us. Oh, if most important libraries have already updated to always listen for the unprefixed events (and most important sites using those libraries have updated to a version that does this), then I agree there shouldn't be any such composition concerns. I don't have any data, but I just assumed with the history of CSS animations on webkit-dominated mobile, that there could still be a lot of deployed code (especially in the mobile space) that looks only for webkitTransitionEnd. Adam proposed a solution to gather data, I think we should do it. Rick On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth aba...@webkit.org wrote: That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if
Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
Hi Steve, Thank you for your interest on WebKit. Of course we would like to fix as many bugs as possible in a time frame as short as possible. With limited resources, this does not work very well for some bugs. So we need to prioritize our work. Even if external resources might be a priority for you, it doesn't need to be for others. We currently focus on performance and security. And external references in SVG have their security issues on their own (why we are very careful on implementing them). After all, WebKit is an open source project. Even if you already contributed by reporting bugs (thank you for that), you are very welcome to commit patches. I see that you may have limited time, as we do as well. A lot of people on this project still contribute in their spare time, even if they are employed to work on WebKit. Please join us to make webkit better. I am happy to review your SVG patches. Greetings, Dirk On Jan 14, 2013, at 12:52 AM, Steve Williams stephen.j.h.willi...@googlemail.commailto:stephen.j.h.willi...@googlemail.com wrote: Hi Maciej, 1. It's been on your bug database for ages hence filing another entry won't move anything forwards. 2. svg 1.1 spec seems a little over the top in places so not personally interested in full support - just the good stuff. 3. Have provided you with a minimal test case in the previous post. 4. Cite real-world sites using the functionality to the relevant bugs. ? chicken and egg. that's not how we make progress ! I'll use it in our site when it works but can't until it does. For now I have to iframe as a workaround but that sucks because iframes grab the entire rect for mouse input which means you can't subtly blend svg over html. 5. Like you, I am busy. I don't have time to fix this (really). Sorry, appreciate you don't like that but it is what it is. 6. Would be great if this could be advanced in priority to enable us to raise the bar, cross browser. Am sure you won't appreciate this fired back at the mailing list I realise I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel :) Thanks for all your hard work. FF has svg bugs too - different (lower priority niggles). Will go hassle them next. IE9 a bit wobbly too, but well ... :) If basic support can be solidified cross browser, we have an interesting platform over above html5. Best regards, Steve. On 13/01/2013 21:37, Maciej Stachowiak wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.commailto:stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers rby...@chromium.org wrote: On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard ale...@webkit.org wrote: On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org wrote: I've been wondering about the implications of prefixed events. Do we have other examples of events that had prefixed names and were later unprefixed? We've never had such a case in the past. It's the first time we have to unprefix DOM events. In particular, what are the composition implications of your solution? When you say depending if someone is listening to it or not you mean whether there is a handler attached that will be triggered by this event, not whether there is a handler for that type of event anywhere on the page, right? Is it likely I'm not sure to understand this part. What is the difference you are talking about? Do you mean whether the user added an event listener on an element or on the document. If it's the case then WebKit event delivery code does not make any difference from what I can see. Sorry, what I'm trying to ask is, what happens when: - e1 has a 'webkitTransitiionEnd' handler, and - e2 has a 'transitionend' handler You made it clear that if e1==e2 then you'd dispatch only transitionend. But what about when e1 is neither an ancestor or descendant of e2? I.e. are you looking at all handlers on the page to determine which events to dispatch, or only some subset of them specific to the context of the event being dispatched? In that particular case, from my testing e1 handler will be called and e2 handler too. The case I was raising is if you have an event handler installed on the same element for both events. that existing code might put handlers on the document (eg. maybe as a sort of polling mechanism when there are many elements that may be involved in transitions?), and if so are we likely to have trouble with different libraries that used to co-exist peacefully in the same site no longer working together? The philosophy of forcing a site to update to the unprefixed name really only makes sense to me if you think of a site as a single application, not as a collection of separately maintained libraries and components. Well usually libraries tend to support multiple vendors so if we send the unprefixed version then I'm pretty sure it's handled somewhere. For example, Opera and Mozilla ship unprefixed for some time so I believe anyway the web is slowly updating. Worst I believe that because WebKit does not ship unprefixed transitions and animations they end up having code extra to support us. Oh, if most important libraries have already updated to always listen for the unprefixed events (and most important sites using those libraries have updated to a version that does this), then I agree there shouldn't be any such composition concerns. I don't have any data, but I just assumed with the history of CSS animations on webkit-dominated mobile, that there could still be a lot of deployed code (especially in the mobile space) that looks only for webkitTransitionEnd. Adam proposed a solution to gather data, I think we should do it. Rick On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth aba...@webkit.org wrote: That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote: Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event transitionend as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart webkitTransitionEnd. Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the
Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
Sent from my PDP-11 On Jan 14, 2013, at 12:51 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: Hi Maciej, 1. It's been on your bug database for ages hence filing another entry won't move anything forwards. 2. svg 1.1 spec seems a little over the top in places so not personally interested in full support - just the good stuff. 3. Have provided you with a minimal test case in the previous post. 4. Cite real-world sites using the functionality to the relevant bugs. ? chicken and egg. that's not how we make progress ! I'll use it in our site when it works but can't until it does. For now I have to iframe as a workaround but that sucks because iframes grab the entire rect for mouse input which means you can't subtly blend svg over html. While step (4) is helpful, it is not a necessary prerequisite for a bug to be filed, assigned to the relevant people, and fixed. We understand and appreciate the chicken-and-egg problem you speak of. ;-) I think the point is that if you know of a site that uses SVG and the site doesn't work right in WebKit, then this is a highly relevant piece of information to put in the bug report. 5. Like you, I am busy. I don't have time to fix this (really). Sorry, appreciate you don't like that but it is what it is. We're all busy. ;-) 6. Would be great if this could be advanced in priority to enable us to raise the bar, cross browser. The act of filing bugs is a pretty good way of raising the priority. Am sure you won't appreciate this fired back at the mailing list I realise I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel :) Thanks for all your hard work. FF has svg bugs too - different (lower priority niggles). Will go hassle them next. IE9 a bit wobbly too, but well ... :) If basic support can be solidified cross browser, we have an interesting platform over above html5. Best regards, Steve. On 13/01/2013 21:37, Maciej Stachowiak wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web standard - please address this. Best regards, Steve Williams root.svgobject.svg___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Recommended commit procedure for large EFL rebaseline?
Hi, when we land https://bugs.webkit.org/show_bug.cgi?id=106774 we'll have to do a large rebaseline of EFL results. (subpixel and FreeType related change) Now, for landing, what we had in mind is, (optionally) take our bots offline, 1) land the actual patch, 2) then manually land the new baselines. Then restart the bots. Regarding step 2) there: Would you recommend to land the rebaselines in smaller chunks or in one big SVN commit? If in chunks - what sizes work well? Thanks, Dominik -- Dominik Röttsches dominik.rottsc...@intel.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
On 01/14/2013 03:19 PM, Jesus Sanchez-Palencia wrote: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. Great to see this, thanks! Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HTML5 Body onLoad event not firing
On Jan 14, 2013, at 2:29 AM, ankit srivastav ank@gmail.com wrote: I'm working for Webkit WIN32 port. I'm facing an issue : 1) For HTML5 video tag: videoonload = onLoad() src = E:/xyz.mp4 for the above mentioned code onLoad fucntion is not firing. but if I remove src tag value onLoad event will start firing. I have debugged and found that, :checkCompleted() is exiting from if (m_frame-document()-isDelayingLoadEvent()) return; and thus Implicit Close is not firing. Please let me know if there is any solution. Please file a bug at https://bugs.webkit.org with a reproducible test case. eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
The github repository has stopped being updated and will remain like that for the next hours until I have finished the new setup. cheers, jesus 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: Hi, This email is a heads-up about the repository change we are starting today in github. In summary, now the github webkit repository will actually mirror git.webkit.org and they will finally have the same git hashes. I won't go into the benefits of this change since this has been widely discussed in the past. Since last week me, Tor Arne, William Siegrist, Adam Barth and Lucas Forschler have been discussing the steps to move on with this and since no one has raised any issues so far on previous discussions, I will start this today. We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Recommended commit procedure for large EFL rebaseline?
On Mon, Jan 14, 2013 at 8:39 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: when we land https://bugs.webkit.org/show_bug.cgi?id=106774 we'll have to do a large rebaseline of EFL results. (subpixel and FreeType related change) Now, for landing, what we had in mind is, (optionally) take our bots offline, 1) land the actual patch, 2) then manually land the new baselines. Then restart the bots. I probably wouldn't take your bots offline. Instead, I would add the tests to TestExpectations so that the bots expect them to fail. As you land new baselines, you can remove the tests for TestExpectations. That way you'll be able to incrementally check your work. Regarding step 2) there: Would you recommend to land the rebaselines in smaller chunks or in one big SVN commit? If in chunks - what sizes work well? Generally it's a good idea to land the baselines in chunks. If you're landing image baselines, I'd probably try chunks between 100 and 500 baselines. If you're landing text baselines, it's less important to use chunks because they are much smaller. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
Hi, Just yet another quick heads-up: 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I had to change my strategy here after talking to a few people on #github. It seems that doing a git push -f to the current repository (https://github.com/WebKit/webkit) will actually have less impact on people branching/forking it on github. In other words, it should be less painful to rebase your fork on github for the new hashes after I'm done with the setup. I will let you know when the switching is done. Cheers, jesus I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Implementing Complex webform Widgets using ShadowDom
Hi All, What is your view in Implemeting Complex webform widgets like CalendarPicker Widget , Colorpicker widget using ShadowDom . May i know the pro's and con's ? How to start off with it. Thanks Regards, Hema. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementing Complex webform Widgets using ShadowDom
Hi Hema, If you are talking about WebKit and HTML, it already does it for some of its built-in HTML elements. Some UI controls, which are modal and don't fit into the page layout, are implemented using native UI controls. These modal controls shouldn't constrained by WebKit rendering area like iframes. In such case, OS native controls are suited. File chooser is a perfect example of this. Some other controls like progress bars and spin buttons are implemented using Shadow DOM. They aren't modal and need to be parts of the page layout. The decision which of native-controls/shadow-dom should be used for implementing HTML form controls is case by case and in't that simple. You can see how input element is implemented. When you try to implement any new control for HTML, it would be good to file a bug and have further discussion there. See http://www.webkit.org/coding/adding-features.html If you are talking about Web-app or JS library development, webkit-dev isn't a place for that. Sites like stackoverflow.com will work well. There are also some good tutorials. For example: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ Hope this helps. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
