Re: [webkit-dev] Implementing Complex webform Widgets using ShadowDom

[Hajime Morrita]

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  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

[webkit-dev] Implementing Complex webform Widgets using ShadowDom

[Hema Chidanand]

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] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)

[Jesus Sanchez-Palencia]

Hi,

Just yet another quick heads-up:

> 2013/1/14 Jesus Sanchez-Palencia :
>> 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 :
>>> Hi,
>>>
>>> 2012/12/4 Tor Arne Vestbø :

 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  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ø
> 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
>  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
> , 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
> , 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 , and make the GitHub mirror
>
> an official mirror?
>
> tor arne
>
> _
> 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 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?

[Adam Barth]

On Mon, Jan 14, 2013 at 8:39 AM, Dominik Röttsches
 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)

[Jesus Sanchez-Palencia]

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 :
> 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 :
>> Hi,
>>
>> 2012/12/4 Tor Arne Vestbø :
>>>
>>> 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  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ø
 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
  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
 , 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
 , 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 , and make the GitHub mirror

 an official mirror?

 tor arne

 _
 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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] HTML5 Body onLoad event not firing

[Eric Carlson]

On Jan 14, 2013, at 2:29 AM, ankit srivastav  wrote:

> 
> I'm working for Webkit WIN32 port.
> I'm facing an issue :
> 
> 1) For HTML5 video tag:
> 
> onload = 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)

[Dominik Röttsches]

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

[webkit-dev] Recommended commit procedure for large EFL rebaseline?

[Dominik Röttsches]

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 

___
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

[Filip Pizlo]

Sent from my PDP-11

On Jan 14, 2013, at 12:51 AM, Steve Williams 
 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 
>>  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
>>> ___
>>> 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.

[Alexis Menard]

On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers  wrote:
> On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard  wrote:
>>
>> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers  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  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 
>> >> 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

Re: [webkit-dev] SVG external referencing not working as of latest chrome canary

[Dirk Schulze]

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" 
mailto: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 
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 Wil

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Rick Byers]

On Mon, Jan 14, 2013 at 9:56 AM, Alexis Menard  wrote:

> On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers  wrote:
> > On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard 
> wrote:
> >>
> >> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers 
> 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 
> 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 
> >> >> 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 ti

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Rick Byers]

On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard  wrote:

> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers  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  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 
> 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

[webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)

[Jesus Sanchez-Palencia]

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 :
> Hi,
>
> 2012/12/4 Tor Arne Vestbø :
>>
>> 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  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ø
>>> 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
>>>  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
>>> , 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
>>> , 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 , and make the GitHub mirror
>>>
>>> an official mirror?
>>>
>>> tor arne
>>>
>>> _
>>> 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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Alexis Menard]

On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers  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  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  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]

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Alexis Menard]

On Sat, Jan 12, 2013 at 10:07 PM, Ryosuke Niwa  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  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

[webkit-dev] HTML5 Body onLoad event not firing

[ankit srivastav]

Hi All,


I'm working for Webkit WIN32 port.
I'm facing an issue :

1) For HTML5 video tag:

onload = 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] SVG external referencing not working as of latest chrome canary

[Adam Barth]

On Mon, Jan 14, 2013 at 12:51 AM, Steve Williams
 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
>  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
> ___
> 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] SVG external referencing not working as of latest chrome canary

[Steve Williams]

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 
> 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
___
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