Re: [webkit-dev] DOM methods that affect [[Prototype]]

2013-01-25 Thread Anne van Kesteren
On Fri, Jan 25, 2013 at 12:21 AM, Geoffrey Garen gga...@apple.com wrote:
 Anne, can you help me get those comments sent to the w3 list? I sent them 
 myself, but they seem to be held up or bounced?

Hey, I think they did make it, and Boris replied:
http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0068.html

Unfortunately I do not know the details of the compatibility story.
I'm just trying to work out what the specification should say.

(There can be delay with archiving your email on the W3C site when
posting to W3C lists if you never posted with the email address
before, since you need to approve that your messages will be archived
and that might take some time to be fully processed.)


-- 
http://annevankesteren.nl/
___
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)

2013-01-25 Thread Florin Malita
Looks like mirroring stopped on 1/23 (last commit:
https://github.com/WebKit/webkit/commit/d5c4f2bd4a80b397eade1ee53b39d738e5656598
).

Jesus, can you take a look?

Thanks,
Florin


On Wed, Jan 16, 2013 at 7:55 AM, Jesus Sanchez-Palencia je...@webkit.orgwrote:

 Hi,

 The mirror is finally ready again: https://github.com/WebKit/webkit
 It now follows the same hashes of git.webkit.org. People who have
 forked this repository on github before will now have to rebase their
 branches.

 I was hold back a bit because Github wasn't allowing me to push more
 than 2GB. I contacted them but before I could get answer I decide to
 'split' the push. First I git reset --hard the repository back to a
 commit from 2008, pushed this, then reset --hard to 2009 and pushed
 this, and so on.

 In the middle of the process the folks from github increased our push
 limit to 20GB and David (barrbrain) was kind enough to push one last
 sync, getting us back to 2012. After that I kept the syncing manullay
 for a few hours but now the repository is being updated automatically
 every 5 minutes to stay in sync with git.webkit.org .

 I will now coordinate with William so we can get Apple pushing to the
 mirror at the same time they push to git.webkit.org .

 Thanks everyone that got involved for the help!

 Cheers,
 jesus

 2013/1/14 Jesus Sanchez-Palencia je...@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] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Dirk Schulze
This is a followup to the multiple inheritance discussion.

Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not have 
multiple inheritances of interfaces that are exposed to bindings. But SVG2 
still uses the implements statement for [NoInterfaceObject] interfaces [2]. 
This should at least address your initial concern not to inherit from different 
interfaces exposed to bindings.

However, during a discussion on IRC I got the impression that we do not plan to 
support the implements statement because it can do weird things. If this is 
right, I would like to understand why this is the case? Have the concerns been 
submitted to the editor and the WG working on the WebIDL specification?

More and more specifications describe interfaces by using WebIDL, including 
HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general 
concerns on WebIDL, they should be addressed on the spec before leaving CR 
state. Not implementing WebIDL could not only block this specification in 
particular, but also all other specs relying on it. Or maybe worst, it gets a 
recommendation and we do not follow web standards anymore. It would be great to 
hear a clarification. Maybe it is just a misunderstanding on my site.

Greetings,
Dirk

[1] 
https://svgwg.org/svg2-draft/single-page.html#types-InterfaceSVGGraphicsElement
[2] http://www.w3.org/TR/WebIDL/#NoInterfaceObject


On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote:

 
 On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
 
 On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
 Eric Seidel points out that SVG uses multiple inheritance in its DOM
 interfaces.  However, the situation there is a bit different.
 Although SVGSVGElement implements SVGLocatable, there aren't any
 interfaces with methods that return SVGLocatable, which means we don't
 need to implement toJS(SVGLocatable*).
 
 SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
 behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED 
 soon.
 
 Do you anticipate adding properties or functions that return
 interfaces like SVGLocatable?
 Here is a Wiki what we plan to do: 
 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
 
 It might not reflect all changes that we discussed during the SVG WG meeting 
 today.
 
 Greetings,
 Dirk
 
 
 Adam
 
 
 He also points out that Node inherits from EventTarget, which already
 contains a virtual interfaceName() function similar to that used by
 Event.  That pushes us further towards using a common DOMInterface
 base class because introducing Region::interfaceName would mean that
 Element would see both EventTarget::interfaceName and
 Region::interfaceName.
 
 Adam
 
 
 On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth aba...@webkit.org wrote:
 The CSS Regions specification [1] defines a CSSOM interface named
 Region, which can be mixed into interfaces for other objets that can
 be CSS regions.  That means that Region introduces a form of multiple
 inheritance into the DOM.  For example, Element implements Region but
 Node does not implement Region.
 
 There's a patch up for review that implements Region using C++
 multiple inheritance [2]:
 
 - class Element : public ContainerNode {
 + class Element : public ContainerNode, public CSSRegion {
 
 One difficulty in implementing this feature how to determine the
 correct JavaScript wrapper return for a given Region object.
 Specifically, toJS(Region*) needs to return a JavaScript wrapper for
 an Element if the Region pointer actually points to an Element
 instance.
 
 We've faced a similar problem elsewhere in the DOM when implementing
 normal single inheritance.  For example, there are many subclass of
 Event and toJS(Event*) needs to return a wrapper for the appropriate
 subtype.  To solve the same problem, CSSRule has a m_type member
 variable and a bevy of isFoo() functions [3].
 
 A) Should we push back on the folks writing the CSS Regions
 specification to avoid using multiple inheritance?  As far as I know,
 this is the only instance of multiple inheritance in the platform.
 Historically, EventTarget used multiple inheritance, but that's been
 fixed in DOM4 [4].
 
 B) If CSS Regions continues to require multiple inheritance, should we
 build another one-off RTTI replacement to implement toJS(Region*), or
 should we improve our bindings to implement this aspect of WebIDL more
 completely?
 
 One approach to implementing toJS in a systematic way is to introduce
 a base class DOMInterface along these lines:
 
 class DOMInterface {
 public:
  virtual const AtomicString primaryInterfaceName() = 0;
 }
 
 That returns the name of the primary interface (i.e., as defined by
 WebIDL [5]).  When implementing toJS, we'd then call
 primaryInterfaceName to determine which kind of wrapper to use.
 
 One downside of this approach is that it introduces a near-universal
 

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Adam Barth
On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 This is a followup to the multiple inheritance discussion.

 Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
 have multiple inheritances of interfaces that are exposed to bindings. But 
 SVG2 still uses the implements statement for [NoInterfaceObject] 
 interfaces [2]. This should at least address your initial concern not to 
 inherit from different interfaces exposed to bindings.

 However, during a discussion on IRC I got the impression that we do not plan 
 to support the implements statement because it can do weird things. If 
 this is right, I would like to understand why this is the case?

We don't intend to support all the possible things that you can do
with implements.  With implements, you can define arbitrarily
complicated relationships between interfaces, including some that can
be implemented only with a QueryInterface-like mechanism.  We're not
going to implement QueryInterface, so we're not going to implement any
specifications that require it.

Have the concerns been submitted to the editor and the WG working on the 
WebIDL specification?

I haven't submitted my concerns.  There's nothing particularly wrong
with the WebIDL language, just like there's nothing particularly wrong
with English just because you can use it to write a terrible poem.

 More and more specifications describe interfaces by using WebIDL, including 
 HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general 
 concerns on WebIDL, they should be addressed on the spec before leaving CR 
 state.

I don't have any concerns with the WebIDL language.  The WebIDL
language is just a mechanism for writing precise specifications.

 Not implementing WebIDL could not only block this specification in 
 particular, but also all other specs relying on it.

That's nonsense.  Just because we don't implement some crazy corner
case of WebIDL that doesn't mean that we're unable to implement *all*
specs that reply upon it.  For example, HTML and DOM use WebIDL and
we're able to implement them just fine.

 Or maybe worst, it gets a recommendation and we do not follow web standards 
 anymore. It would be great to hear a clarification. Maybe it is just a 
 misunderstanding on my site.

There's no experiment that you can run using web content to detect
whether we implement WebIDL.  All you can detect is whether we
implement particular specifications that use WebIDL.  We can just
simply not implement the specifications that require COM-like
implementations and we can continue to lead a happy life.

Adam


 On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
 On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
 Eric Seidel points out that SVG uses multiple inheritance in its DOM
 interfaces.  However, the situation there is a bit different.
 Although SVGSVGElement implements SVGLocatable, there aren't any
 interfaces with methods that return SVGLocatable, which means we don't
 need to implement toJS(SVGLocatable*).

 SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
 behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 
 ED soon.

 Do you anticipate adding properties or functions that return
 interfaces like SVGLocatable?
 Here is a Wiki what we plan to do: 
 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization

 It might not reflect all changes that we discussed during the SVG WG meeting 
 today.

 Greetings,
 Dirk


 Adam


 He also points out that Node inherits from EventTarget, which already
 contains a virtual interfaceName() function similar to that used by
 Event.  That pushes us further towards using a common DOMInterface
 base class because introducing Region::interfaceName would mean that
 Element would see both EventTarget::interfaceName and
 Region::interfaceName.

 Adam


 On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth aba...@webkit.org wrote:
 The CSS Regions specification [1] defines a CSSOM interface named
 Region, which can be mixed into interfaces for other objets that can
 be CSS regions.  That means that Region introduces a form of multiple
 inheritance into the DOM.  For example, Element implements Region but
 Node does not implement Region.

 There's a patch up for review that implements Region using C++
 multiple inheritance [2]:

 - class Element : public ContainerNode {
 + class Element : public ContainerNode, public CSSRegion {

 One difficulty in implementing this feature how to determine the
 correct JavaScript wrapper return for a given Region object.
 Specifically, toJS(Region*) needs to return a JavaScript wrapper for
 an Element if the Region pointer actually points to an Element
 instance.

 We've faced a similar problem elsewhere in the DOM when implementing
 normal single inheritance.  For example, there are 

Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread William Siegrist
Here are the largest results sets on the master in GB. We currently store 6.8TB 
of total results, going back 14 months, and 1.1TB of archives going back 1 
week. 

1500Apple MountainLion (Leaks)
1018Chromium Mac Release (Tests)
857 Chromium Linux Release (Tests)
532 Chromium Win Release (Tests)
371 Apple MountainLion Debug WK2 (Tests)
324 Apple Lion Debug WK2 (Tests)
299 Chromium Linux Release (Grid Layout)
173 GTK Linux 64-bit Release
171 Chromium Android Release (Tests)
160 EFL Linux 64-bit Debug WK2
158 Apple Lion (Leaks)
145 EFL Linux 64-bit Release
113 EFL Linux 64-bit Debug
105 GTK Linux 32-bit Release
94  GTK Linux 64-bit Debug
94  GTK Linux 64-bit Release WK2 (Tests)
85  EFL Linux 64-bit Release WK2
80  Apple Lion Release WK1 (Tests)
77  Apple Lion Release WK2 (Tests)
60  Apple Lion Debug WK1 (Tests)
60  Apple MountainLion Debug WK1 (Tests)
59  Apple MountainLion Release WK1 (Tests)
53  Qt Linux Release

Archives are already pruning after 1 week. Next week, I'm going to start 
pruning results older than 14 months since we don't have much more space. If 
anyone thinks you need more than 14 months of results, let me know soon and we 
can see what our options are.

-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread Eric Seidel
I'm surprised that chromium mac is 3x the size of Apple Mac... debug
even!  Chromium build output should be much smaller... at least as of
late.

On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com wrote:
 Here are the largest results sets on the master in GB. We currently store 
 6.8TB of total results, going back 14 months, and 1.1TB of archives going 
 back 1 week.

 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)
 173 GTK Linux 64-bit Release
 171 Chromium Android Release (Tests)
 160 EFL Linux 64-bit Debug WK2
 158 Apple Lion (Leaks)
 145 EFL Linux 64-bit Release
 113 EFL Linux 64-bit Debug
 105 GTK Linux 32-bit Release
 94  GTK Linux 64-bit Debug
 94  GTK Linux 64-bit Release WK2 (Tests)
 85  EFL Linux 64-bit Release WK2
 80  Apple Lion Release WK1 (Tests)
 77  Apple Lion Release WK2 (Tests)
 60  Apple Lion Debug WK1 (Tests)
 60  Apple MountainLion Debug WK1 (Tests)
 59  Apple MountainLion Release WK1 (Tests)
 53  Qt Linux Release

 Archives are already pruning after 1 week. Next week, I'm going to start 
 pruning results older than 14 months since we don't have much more space. If 
 anyone thinks you need more than 14 months of results, let me know soon and 
 we can see what our options are.

 -Bill

 ___
 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] build.webkit.org down

2013-01-25 Thread Dirk Pranke
This is the output of the test bots, right? I'm guessing this is due
to (a) us running pixel tests and (b) not checking in the expected
failing baselines. If I ever get back to working on supporting
-failing.png, this could go down *a lot*.

Alternatively, we could just decide to check in the existing failures
as -expected and call it good enough ...

-- Dirk

On Fri, Jan 25, 2013 at 9:35 AM, Eric Seidel e...@webkit.org wrote:
 I'm surprised that chromium mac is 3x the size of Apple Mac... debug
 even!  Chromium build output should be much smaller... at least as of
 late.

 On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com wrote:
 Here are the largest results sets on the master in GB. We currently store 
 6.8TB of total results, going back 14 months, and 1.1TB of archives going 
 back 1 week.

 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)
 173 GTK Linux 64-bit Release
 171 Chromium Android Release (Tests)
 160 EFL Linux 64-bit Debug WK2
 158 Apple Lion (Leaks)
 145 EFL Linux 64-bit Release
 113 EFL Linux 64-bit Debug
 105 GTK Linux 32-bit Release
 94  GTK Linux 64-bit Debug
 94  GTK Linux 64-bit Release WK2 (Tests)
 85  EFL Linux 64-bit Release WK2
 80  Apple Lion Release WK1 (Tests)
 77  Apple Lion Release WK2 (Tests)
 60  Apple Lion Debug WK1 (Tests)
 60  Apple MountainLion Debug WK1 (Tests)
 59  Apple MountainLion Release WK1 (Tests)
 53  Qt Linux Release

 Archives are already pruning after 1 week. Next week, I'm going to start 
 pruning results older than 14 months since we don't have much more space. If 
 anyone thinks you need more than 14 months of results, let me know soon and 
 we can see what our options are.

 -Bill

 ___
 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] build.webkit.org down

2013-01-25 Thread William Siegrist
Yes, I'm referring to the test results that get uploaded to 
http://build.webkit.org/results/, presumably by the test slaves. The 
archives I refer to are http://build.webkit.org/archives/, which I believe 
are just the binaries built by the build slaves.

-Bill


On Jan 25, 2013, at 9:42 AM, Dirk Pranke dpra...@chromium.org wrote:

 This is the output of the test bots, right? I'm guessing this is due
 to (a) us running pixel tests and (b) not checking in the expected
 failing baselines. If I ever get back to working on supporting
 -failing.png, this could go down *a lot*.
 
 Alternatively, we could just decide to check in the existing failures
 as -expected and call it good enough ...
 
 -- Dirk
 
 On Fri, Jan 25, 2013 at 9:35 AM, Eric Seidel e...@webkit.org wrote:
 I'm surprised that chromium mac is 3x the size of Apple Mac... debug
 even!  Chromium build output should be much smaller... at least as of
 late.
 
 On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com 
 wrote:
 Here are the largest results sets on the master in GB. We currently store 
 6.8TB of total results, going back 14 months, and 1.1TB of archives going 
 back 1 week.
 
 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)
 173 GTK Linux 64-bit Release
 171 Chromium Android Release (Tests)
 160 EFL Linux 64-bit Debug WK2
 158 Apple Lion (Leaks)
 145 EFL Linux 64-bit Release
 113 EFL Linux 64-bit Debug
 105 GTK Linux 32-bit Release
 94  GTK Linux 64-bit Debug
 94  GTK Linux 64-bit Release WK2 (Tests)
 85  EFL Linux 64-bit Release WK2
 80  Apple Lion Release WK1 (Tests)
 77  Apple Lion Release WK2 (Tests)
 60  Apple Lion Debug WK1 (Tests)
 60  Apple MountainLion Debug WK1 (Tests)
 59  Apple MountainLion Release WK1 (Tests)
 53  Qt Linux Release
 
 Archives are already pruning after 1 week. Next week, I'm going to start 
 pruning results older than 14 months since we don't have much more space. 
 If anyone thinks you need more than 14 months of results, let me know soon 
 and we can see what our options are.
 
 -Bill
 
 ___
 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] Do any ports still disable SVG?

2013-01-25 Thread Eric Seidel
This question came up in:
https://bugs.webkit.org/show_bug.cgi?id=92393

Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
defines (and potentially unifying SVG and HTML style resolve more
closely)?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Jochen Eisinger
Many chromium developers disable svg for faster building.

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

2013-01-25 Thread Jesus Sanchez-Palencia
Sorry, we have been facing network issues here for the past few
days... Anyway, should be fixed now and it is pushing the current
git.webkit.org HEAD already.

Cheers,
jesus

2013/1/25 Florin Malita fmal...@google.com:
 Looks like mirroring stopped on 1/23 (last commit:
 https://github.com/WebKit/webkit/commit/d5c4f2bd4a80b397eade1ee53b39d738e5656598).

 Jesus, can you take a look?

 Thanks,
 Florin


 On Wed, Jan 16, 2013 at 7:55 AM, Jesus Sanchez-Palencia je...@webkit.org
 wrote:

 Hi,

 The mirror is finally ready again: https://github.com/WebKit/webkit
 It now follows the same hashes of git.webkit.org. People who have
 forked this repository on github before will now have to rebase their
 branches.

 I was hold back a bit because Github wasn't allowing me to push more
 than 2GB. I contacted them but before I could get answer I decide to
 'split' the push. First I git reset --hard the repository back to a
 commit from 2008, pushed this, then reset --hard to 2009 and pushed
 this, and so on.

 In the middle of the process the folks from github increased our push
 limit to 20GB and David (barrbrain) was kind enough to push one last
 sync, getting us back to 2012. After that I kept the syncing manullay
 for a few hours but now the repository is being updated automatically
 every 5 minutes to stay in sync with git.webkit.org .

 I will now coordinate with William so we can get Apple pushing to the
 mirror at the same time they push to git.webkit.org .

 Thanks everyone that got involved for the help!

 Cheers,
 jesus

 2013/1/14 Jesus Sanchez-Palencia je...@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
 
  _
  

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Glenn Adams
On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth aba...@webkit.org wrote:

 There's no experiment that you can run using web content to detect
 whether we implement WebIDL.  All you can detect is whether we
 implement particular specifications that use WebIDL.  We can just
 simply not implement the specifications that require COM-like
 implementations and we can continue to lead a happy life.


Speaking of implementing WebIDL (in the context of a spec that normatively
requires its support, e.g., CSSOM), what is your position on whether WK
will/should support the following? In the test at [1], neither of these are
currently supported, or at least don't yield expected results.

WebIDL 4.4.1 [2] states:

The interface object for a given non-callback
interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface is
a function objecthttp://dev.w3.org/2006/webapi/WebIDL/#dfn-function-object
.

WebIDL 4.4.3 [3] states:

If the 
[NoInterfaceObject]http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject
extended
attribute was not specified on the interface, then the interface prototype
object must also have a property named “constructor” with attributes
{ [[Writable]]:true, [[Enumerable]]: false, [[Configurable]]: true } whose
value is a reference to the interface object for the interface.

[1]
http://hg.csswg.org/test/raw-file/3d8f9c12b1c8/contributors/gadams/incoming/cssom/cssstylerule-interface.xht
[2] http://dev.w3.org/2006/webapi/WebIDL/#interface-object
[3] http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object

Regards,
Glenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Antonio Gomes
QtWebKit has a --minimal option where SVG is disabled IIRC.

On Fri, Jan 25, 2013 at 2:27 PM, Jochen Eisinger joc...@chromium.org wrote:
 Many chromium developers disable svg for faster building.

 Jochen


 ___
 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] Do any ports still disable SVG?

2013-01-25 Thread Arunprasad Rajkumar
Eric, Most of the resource constraint environments(embedded systems) still
disables the SVG. If the define is removed code size of WebKit will be
increased by atleast 3 to 4M.

On 26 January 2013 01:01, webkit-dev-requ...@lists.webkit.org wrote:

 This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393

 Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
 defines (and potentially unifying SVG and HTML style resolve more
 closely)?

 --
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread Tony Chang
On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.comwrote:

 Here are the largest results sets on the master in GB. We currently store
 6.8TB of total results, going back 14 months, and 1.1TB of archives going
 back 1 week.

 1500Apple MountainLion (Leaks)
 1018Chromium Mac Release (Tests)
 857 Chromium Linux Release (Tests)
 532 Chromium Win Release (Tests)
 371 Apple MountainLion Debug WK2 (Tests)
 324 Apple Lion Debug WK2 (Tests)
 299 Chromium Linux Release (Grid Layout)


The Grid Layout bot no longer exists.  We can delete these archived results.

tony
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Elliott Sprehn
Perhaps the time to remove ENABLE_SVG is in several years once many pages
depend on it and disabling it results in a busted browser...


On Fri, Jan 25, 2013 at 2:55 PM, Arunprasad Rajkumar ararunpra...@gmail.com
 wrote:

 Eric, Most of the resource constraint environments(embedded systems) still
 disables the SVG. If the define is removed code size of WebKit will be
 increased by atleast 3 to 4M.


 On 26 January 2013 01:01, webkit-dev-requ...@lists.webkit.org wrote:

 This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393

 Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
 defines (and potentially unifying SVG and HTML style resolve more
 closely)?

 --
 *Arunprasad Rajkumar*
 http://in.linkedin.com/in/ararunprasad

 ___
 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] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Dirk Schulze

On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:

 On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 This is a followup to the multiple inheritance discussion.
 
 Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
 have multiple inheritances of interfaces that are exposed to bindings. But 
 SVG2 still uses the implements statement for [NoInterfaceObject] 
 interfaces [2]. This should at least address your initial concern not to 
 inherit from different interfaces exposed to bindings.
 
 However, during a discussion on IRC I got the impression that we do not plan 
 to support the implements statement because it can do weird things. If 
 this is right, I would like to understand why this is the case?
 
 We don't intend to support all the possible things that you can do
 with implements.  With implements, you can define arbitrarily
 complicated relationships between interfaces, including some that can
 be implemented only with a QueryInterface-like mechanism.  We're not
 going to implement QueryInterface, so we're not going to implement any
 specifications that require it.

This sounds that you consider having implements in our WebIDL interpreter, or 
at least would not block adding this per se. This was my concern in the first 
place, since this is already in use in a lot of specifications (just with 
[NoInterfaceObject] as far as I saw).

 
 Have the concerns been submitted to the editor and the WG working on the 
 WebIDL specification?
 
 I haven't submitted my concerns.  There's nothing particularly wrong
 with the WebIDL language, just like there's nothing particularly wrong
 with English just because you can use it to write a terrible poem.

Well, it seems to be a bit different. Your poem would still be valid as long as 
it follows the grammar and can still be read, even if it does not make sense to 
you. You suggest not supporting everything from WebIDL, which means not 
accepting the full specified grammar. I think this is a concern where you would 
like to see limitations to the current grammar and which should be discussed.

 
 More and more specifications describe interfaces by using WebIDL, including 
 HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general 
 concerns on WebIDL, they should be addressed on the spec before leaving CR 
 state.
 
 I don't have any concerns with the WebIDL language.  The WebIDL
 language is just a mechanism for writing precise specifications.
 
 Not implementing WebIDL could not only block this specification in 
 particular, but also all other specs relying on it.
 
 That's nonsense.  Just because we don't implement some crazy corner
 case of WebIDL that doesn't mean that we're unable to implement *all*
 specs that reply upon it.  For example, HTML and DOM use WebIDL and
 we're able to implement them just fine.

You suggest not implementing some corner cases. And as you say, we won't be 
able to support specifications relying on these corner cases. It rather seems 
you agree with my statement, even if it does not block former named 
specifications yet. I am not questioning your arguments to not support all 
corner cases of WebIDL. I am asking for an open discussion about particular 
cases on the relevant mailing lists (public-webapps for WebIDL) to address 
these concerns in the specification before leaving CR.

 
 Or maybe worst, it gets a recommendation and we do not follow web standards 
 anymore. It would be great to hear a clarification. Maybe it is just a 
 misunderstanding on my site.
 
 There's no experiment that you can run using web content to detect
 whether we implement WebIDL.  All you can detect is whether we
 implement particular specifications that use WebIDL.  We can just
 simply not implement the specifications that require COM-like
 implementations and we can continue to lead a happy life.

This seems indeed a problem for WebIDL, since tests and testability is a 
requirement to leave CR. However, the WebApps WG might have a different thought.

Greetings,
Dirk

 
 Adam
 
 
 On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
 On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
 Eric Seidel points out that SVG uses multiple inheritance in its DOM
 interfaces.  However, the situation there is a bit different.
 Although SVGSVGElement implements SVGLocatable, there aren't any
 interfaces with methods that return SVGLocatable, which means we don't
 need to implement toJS(SVGLocatable*).
 
 SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
 behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 
 ED soon.
 
 Do you anticipate adding properties or functions that return
 interfaces like SVGLocatable?
 Here is a Wiki what we plan to do: 
 

Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Philip Rogers
We could reduce a bit of maintenance cost by removing all the defines. I
ran some numbers and I'm not sure we are there yet in terms of lost
productivity, even on the Chromium side. SVG adds around 20% to debug
compile times:

Linux, Z620, no goma, clean build, ninja, Debug DumpRenderTree, without
SVG: 4m05s
Linux, Z620, no goma, clean build, ninja, Debug DumpRenderTree, with SVG:
4m52s

Linux, Z620, no goma, clean build, ninja, Release DumpRenderTree, without
SVG: 3m58s
Linux, Z620, no goma, clean build, ninja, Release DumpRenderTree, with SVG:
4m36s

For Chromium developers not working on WebKit it is probably best to
continue building without SVG, even though I must warn you that you'll miss
out on the some sweet graphics.

Philip


On Fri, Jan 25, 2013 at 12:19 PM, Elliott Sprehn espr...@chromium.orgwrote:

 Perhaps the time to remove ENABLE_SVG is in several years once many pages
 depend on it and disabling it results in a busted browser...


 On Fri, Jan 25, 2013 at 2:55 PM, Arunprasad Rajkumar 
 ararunpra...@gmail.com wrote:

 Eric, Most of the resource constraint environments(embedded systems)
 still disables the SVG. If the define is removed code size of WebKit will
 be increased by atleast 3 to 4M.


 On 26 January 2013 01:01, webkit-dev-requ...@lists.webkit.org wrote:

 This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393

 Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
 defines (and potentially unifying SVG and HTML style resolve more
 closely)?

 --
 *Arunprasad Rajkumar*
 http://in.linkedin.com/in/ararunprasad

 ___
 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] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Adam Barth
On Fri, Jan 25, 2013 at 11:28 AM, Glenn Adams gl...@skynav.com wrote:
 On Fri, Jan 25, 2013 at 10:14 AM, Adam Barth aba...@webkit.org wrote:
 There's no experiment that you can run using web content to detect
 whether we implement WebIDL.  All you can detect is whether we
 implement particular specifications that use WebIDL.  We can just
 simply not implement the specifications that require COM-like
 implementations and we can continue to lead a happy life.

 Speaking of implementing WebIDL (in the context of a spec that normatively
 requires its support, e.g., CSSOM), what is your position on whether WK
 will/should support the following? In the test at [1], neither of these are
 currently supported, or at least don't yield expected results.

 WebIDL 4.4.1 [2] states:

 The interface object for a given non-callback interface is a function
 object.

 WebIDL 4.4.3 [3] states:

 If the [NoInterfaceObject] extended attribute was not specified on the
 interface, then the interface prototype object must also have a property
 named “constructor” with attributes { [[Writable]]:true, [[Enumerable]]:
 false, [[Configurable]]: true } whose value is a reference to the interface
 object for the interface.

I don't have a strong opinion on those topics.  I'm happy to review
patches in this area.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Adam Barth
On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:
 On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 This is a followup to the multiple inheritance discussion.

 Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
 have multiple inheritances of interfaces that are exposed to bindings. But 
 SVG2 still uses the implements statement for [NoInterfaceObject] 
 interfaces [2]. This should at least address your initial concern not to 
 inherit from different interfaces exposed to bindings.

 However, during a discussion on IRC I got the impression that we do not 
 plan to support the implements statement because it can do weird 
 things. If this is right, I would like to understand why this is the case?

 We don't intend to support all the possible things that you can do
 with implements.  With implements, you can define arbitrarily
 complicated relationships between interfaces, including some that can
 be implemented only with a QueryInterface-like mechanism.  We're not
 going to implement QueryInterface, so we're not going to implement any
 specifications that require it.

 This sounds that you consider having implements in our WebIDL interpreter, 
 or at least would not block adding this per se. This was my concern in the 
 first place, since this is already in use in a lot of specifications (just 
 with [NoInterfaceObject] as far as I saw).

WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
compiler.  If you spec something that requires a QueryInterface-like
mechanism in the implementation, we will not implement it regardless
of what language you write the specification in.  It's a conscious
design decision not to implement a COM-like (or XPCOM-like) system.

 Have the concerns been submitted to the editor and the WG working on the 
 WebIDL specification?

 I haven't submitted my concerns.  There's nothing particularly wrong
 with the WebIDL language, just like there's nothing particularly wrong
 with English just because you can use it to write a terrible poem.

 Well, it seems to be a bit different. Your poem would still be valid as long 
 as it follows the grammar and can still be read, even if it does not make 
 sense to you. You suggest not supporting everything from WebIDL, which means 
 not accepting the full specified grammar. I think this is a concern where you 
 would like to see limitations to the current grammar and which should be 
 discussed.

In this analogy, WebKit is like a collection of poems.  We can choose
not to include a terrible poem in our collection without needing to
form a judgement about the language in which the poem was written.

 More and more specifications describe interfaces by using WebIDL, including 
 HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general 
 concerns on WebIDL, they should be addressed on the spec before leaving CR 
 state.

 I don't have any concerns with the WebIDL language.  The WebIDL
 language is just a mechanism for writing precise specifications.

 Not implementing WebIDL could not only block this specification in 
 particular, but also all other specs relying on it.

 That's nonsense.  Just because we don't implement some crazy corner
 case of WebIDL that doesn't mean that we're unable to implement *all*
 specs that reply upon it.  For example, HTML and DOM use WebIDL and
 we're able to implement them just fine.

 You suggest not implementing some corner cases. And as you say, we won't be 
 able to support specifications relying on these corner cases. It rather seems 
 you agree with my statement, even if it does not block former named 
 specifications yet.

You're welcome to write whatever specifications you like.  I'm just
hoping to save you the effort by telling you that we're not going to
implement a feature that requires us to build COM.

 I am not questioning your arguments to not support all corner cases of 
 WebIDL. I am asking for an open discussion about particular cases on the 
 relevant mailing lists (public-webapps for WebIDL) to address these concerns 
 in the specification before leaving CR.

I have no concerns with WebIDL.  I have concerns with specifications
that require an implementation of QueryInterface regardless of whether
they're written in WebIDL or in English.

Adam


 On Jul 25, 2012, at 9:13 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
 On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
 Eric Seidel points out that SVG uses multiple inheritance in its DOM
 interfaces.  However, the situation there is a bit different.
 Although SVGSVGElement implements SVGLocatable, there aren't any
 interfaces with methods that return SVGLocatable, which means we don't
 need to implement toJS(SVGLocatable*).

 SVG 2 will use WebIDL. Therefore we also reorganize 

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Maciej Stachowiak

On Jan 25, 2013, at 4:13 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:
 On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 This is a followup to the multiple inheritance discussion.
 
 Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
 have multiple inheritances of interfaces that are exposed to bindings. But 
 SVG2 still uses the implements statement for [NoInterfaceObject] 
 interfaces [2]. This should at least address your initial concern not to 
 inherit from different interfaces exposed to bindings.
 
 However, during a discussion on IRC I got the impression that we do not 
 plan to support the implements statement because it can do weird 
 things. If this is right, I would like to understand why this is the case?
 
 We don't intend to support all the possible things that you can do
 with implements.  With implements, you can define arbitrarily
 complicated relationships between interfaces, including some that can
 be implemented only with a QueryInterface-like mechanism.  We're not
 going to implement QueryInterface, so we're not going to implement any
 specifications that require it.
 
 This sounds that you consider having implements in our WebIDL interpreter, 
 or at least would not block adding this per se. This was my concern in the 
 first place, since this is already in use in a lot of specifications (just 
 with [NoInterfaceObject] as far as I saw).
 
 WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
 compiler.  If you spec something that requires a QueryInterface-like
 mechanism in the implementation, we will not implement it regardless
 of what language you write the specification in.  It's a conscious
 design decision not to implement a COM-like (or XPCOM-like) system.

Setting aside the more general question, does the SVG2 set of interfaces 
effectively require a QueryInterface-like mechanism? What limitations, if any, 
on the use of implements would a spec have to follow to dodge this bullet? 
SVG2 is still evolving, so I suspect it could adjust its use of implements if 
it's an issue for us.

If SVG2 does happen to avoid the problem, would we want to use implements as 
the syntax in WebKitIDL or would we want a different syntax? I could see 
arguments either way.

(FWIW I agree that we don't want to end up in a position where we'd have to 
implement a QI-like mechanism for the sake of the bindings, but I can't tell 
from the conversation so far if this is an immediate issue with SVG2, or just a 
possible issue with other potential uses of implements).

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Dirk Schulze

On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak m...@apple.com wrote:

 
 On Jan 25, 2013, at 4:13 PM, Adam Barth aba...@webkit.org wrote:
 
 On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:
 On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 This is a followup to the multiple inheritance discussion.
 
 Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
 have multiple inheritances of interfaces that are exposed to bindings. 
 But SVG2 still uses the implements statement for [NoInterfaceObject] 
 interfaces [2]. This should at least address your initial concern not to 
 inherit from different interfaces exposed to bindings.
 
 However, during a discussion on IRC I got the impression that we do not 
 plan to support the implements statement because it can do weird 
 things. If this is right, I would like to understand why this is the case?
 
 We don't intend to support all the possible things that you can do
 with implements.  With implements, you can define arbitrarily
 complicated relationships between interfaces, including some that can
 be implemented only with a QueryInterface-like mechanism.  We're not
 going to implement QueryInterface, so we're not going to implement any
 specifications that require it.
 
 This sounds that you consider having implements in our WebIDL 
 interpreter, or at least would not block adding this per se. This was my 
 concern in the first place, since this is already in use in a lot of 
 specifications (just with [NoInterfaceObject] as far as I saw).
 
 WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
 compiler.  If you spec something that requires a QueryInterface-like
 mechanism in the implementation, we will not implement it regardless
 of what language you write the specification in.  It's a conscious
 design decision not to implement a COM-like (or XPCOM-like) system.
 
 Setting aside the more general question, does the SVG2 set of interfaces 
 effectively require a QueryInterface-like mechanism? What limitations, if 
 any, on the use of implements would a spec have to follow to dodge this 
 bullet? SVG2 is still evolving, so I suspect it could adjust its use of 
 implements if it's an issue for us.

SVG2 does not require any inter process communication. The QueryInterface was 
an example of Adam what we should not implement. SVG2 uses WebIDL's 
implements statement for [NoInterfaceObject] interfaces, as the HTML 
specification is doing it. But SVG uses multiple implements statements per 
interface:

interface SVGViewSpec
 {
  readonly attribute SVGTransformList transform;
  readonly attribute SVGElement viewTarget;
  readonly attribute DOMString viewBoxString;
  readonly attribute DOMString preserveAspectRatioString;
  readonly attribute DOMString transformString;
  readonly attribute DOMString viewTargetString;
};
SVGViewSpec implements SVGFitToViewBox;
SVGViewSpec implements SVGZoomAndPan;

SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.

I hope that I am not mistaken and that this is not what you mean with 
QueryInterface.

 
 If SVG2 does happen to avoid the problem, would we want to use implements 
 as the syntax in WebKitIDL or would we want a different syntax? I could see 
 arguments either way.

I think it would be desirable to follow WebIDL and the syntax of this 
specifications as long as the goals overlap.

 
 (FWIW I agree that we don't want to end up in a position where we'd have to 
 implement a QI-like mechanism for the sake of the bindings, but I can't tell 
 from the conversation so far if this is an immediate issue with SVG2, or just 
 a possible issue with other potential uses of implements).

If I understand Adam correctly, then the later. If there are problems with the 
SVG2 specification, then I am happy to talk with the SVG WG and find solutions. 
But the SVG WG still needs to cover the behavior of SVG 1.1 as much as possible.

Greetings,
Dirk

 
 Regards,
 Maciej
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Elliott Sprehn
On Fri, Jan 25, 2013 at 8:09 PM, Dirk Schulze dschu...@adobe.com wrote:


 On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak m...@apple.com wrote:

 
  On Jan 25, 2013, at 4:13 PM, Adam Barth aba...@webkit.org wrote:
 
  On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com
 wrote:
  On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:
  On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com
 wrote:
  This is a followup to the multiple inheritance discussion.
 
  Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2
 do not have multiple inheritances of interfaces that are exposed to
 bindings. But SVG2 still uses the implements statement for
 [NoInterfaceObject] interfaces [2]. This should at least address your
 initial concern not to inherit from different interfaces exposed to
 bindings.
 
  However, during a discussion on IRC I got the impression that we do
 not plan to support the implements statement because it can do weird
 things. If this is right, I would like to understand why this is the case?
 
  We don't intend to support all the possible things that you can do
  with implements.  With implements, you can define arbitrarily
  complicated relationships between interfaces, including some that can
  be implemented only with a QueryInterface-like mechanism.  We're not
  going to implement QueryInterface, so we're not going to implement any
  specifications that require it.
 
  This sounds that you consider having implements in our WebIDL
 interpreter, or at least would not block adding this per se. This was my
 concern in the first place, since this is already in use in a lot of
 specifications (just with [NoInterfaceObject] as far as I saw).
 
  WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
  compiler.  If you spec something that requires a QueryInterface-like
  mechanism in the implementation, we will not implement it regardless
  of what language you write the specification in.  It's a conscious
  design decision not to implement a COM-like (or XPCOM-like) system.
 
  Setting aside the more general question, does the SVG2 set of interfaces
 effectively require a QueryInterface-like mechanism? What limitations, if
 any, on the use of implements would a spec have to follow to dodge this
 bullet? SVG2 is still evolving, so I suspect it could adjust its use of
 implements if it's an issue for us.

 SVG2 does not require any inter process communication. The QueryInterface
 was an example of Adam what we should not implement. SVG2 uses WebIDL's
 implements statement for [NoInterfaceObject] interfaces, as the HTML
 specification is doing it. But SVG uses multiple implements statements
 per interface:

 interface SVGViewSpec
  {
   readonly attribute SVGTransformList transform;
   readonly attribute SVGElement viewTarget;
   readonly attribute DOMString viewBoxString;
   readonly attribute DOMString preserveAspectRatioString;
   readonly attribute DOMString transformString;
   readonly attribute DOMString viewTargetString;
 };
 SVGViewSpec implements SVGFitToViewBox;
 SVGViewSpec implements SVGZoomAndPan;

 SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.

 I hope that I am not mistaken and that this is not what you mean with
 QueryInterface.


Since they're NoInterfaceObjects we can just merge the idl into the file in
WebKit or use Supplemental in WebkitIDL. You've written it with multiple
implements to be DRY in the WebIDL, that's not a problem for WebKit.

See: HTMLInputElementFileSystem.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Dirk Schulze

On Jan 25, 2013, at 8:16 PM, Elliott Sprehn espr...@chromium.org wrote:

 interface SVGViewSpec
  {
   readonly attribute SVGTransformList transform;
   readonly attribute SVGElement viewTarget;
   readonly attribute DOMString viewBoxString;
   readonly attribute DOMString preserveAspectRatioString;
   readonly attribute DOMString transformString;
   readonly attribute DOMString viewTargetString;
 };
 SVGViewSpec implements SVGFitToViewBox;
 SVGViewSpec implements SVGZoomAndPan;
 
 SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.
 
 I hope that I am not mistaken and that this is not what you mean with 
 QueryInterface.
 
 
 Since they're NoInterfaceObjects we can just merge the idl into the file in 
 WebKit or use Supplemental in WebkitIDL. You've written it with multiple 
 implements to be DRY in the WebIDL, that's not a problem for WebKit.
 
 See: HTMLInputElementFileSystem.

As far as I understood it, HTMLInputElementFileSystem extends HTMLInputElement. 
In WebIDL it would be:

HTMLInputElement implements HTMLInputElementFileSystem;

The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above are 
implemented by a lot of other interfaces as well. Supplemental is just supposed 
to be set once per interface. That is why Supplemental doesn't work for SVG. 
The alternative would be to implement the attributes and operations of 
SVGFitToViewBox and SVGZoomAndPan into every class that implements them. This 
would be a lot of code copies. And these are not the only interfaces that would 
need to be merged.

Greetings,
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Elliott Sprehn
On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze dschu...@adobe.com wrote:

 ...
 The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
 are implemented by a lot of other interfaces as well. Supplemental is just
 supposed to be set once per interface. That is why Supplemental doesn't
 work for SVG. The alternative would be to implement the attributes and
 operations of SVGFitToViewBox and SVGZoomAndPan into every class that
 implements them. This would be a lot of code copies. And these are not the
 only interfaces that would need to be merged.


That's an issue of being DRY though, which we can certainly solve in
WebKit. I don't think Adam has an issue with extending webkit IDL to help
with that, or at least I'd hope not.

We could probably use multiple inheritance in C++ and copy/paste the idl
defs, or add some new IDL feature for it.

- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do any ports still disable SVG?

2013-01-25 Thread Arunprasad Rajkumar
I agree with you guys. Most of the sites now uses SVG. But I'm worrying
about the resource constraint platforms where browser is not intended for
open Internet browsing, rather it is used for building user interfaces(like
navigation systems, tv, set-top-box). Though using SVG in the constraints
environments increases the productivity, but most of the platforms still
lacks OpenGL ES2 or OpenVG  survives only with 2D accelerators!!. As far I
know most of the pages still uses SVG to show only very basic graphics
elements like buttons,... and it may be lack of proper tools to author svg
documents.

On 26 January 2013 03:47, Philip Rogers p...@google.com wrote:

 We could reduce a bit of maintenance cost by removing all the defines. I
 ran some numbers and I'm not sure we are there yet in terms of lost
 productivity, even on the Chromium side. SVG adds around 20% to debug
 compile times:

 Linux, Z620, no goma, clean build, ninja, Debug DumpRenderTree, without
 SVG: 4m05s
 Linux, Z620, no goma, clean build, ninja, Debug DumpRenderTree, with SVG:
 4m52s

  Linux, Z620, no goma, clean build, ninja, Release DumpRenderTree,
 without SVG: 3m58s
 Linux, Z620, no goma, clean build, ninja, Release DumpRenderTree, with
 SVG: 4m36s

  For Chromium developers not working on WebKit it is probably best to
 continue building without SVG, even though I must warn you that you'll miss
 out on the some sweet graphics.

 PhilipI agree with you guys



 On Fri, Jan 25, 2013 at 12:19 PM, Elliott Sprehn espr...@chromium.orgwrote:

 Perhaps the time to remove ENABLE_SVG is in several years once many pages
 depend on it and disabling it results in a busted browser...


 On Fri, Jan 25, 2013 at 2:55 PM, Arunprasad Rajkumar 
 ararunpra...@gmail.com wrote:

 Eric, Most of the resource constraint environments(embedded systems)
 still disables the SVG. If the define is removed code size of WebKit will
 be increased by atleast 3 to 4M.


 On 26 January 2013 01:01, webkit-dev-requ...@lists.webkit.org wrote:

 This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393

 Do any ports still disable SVG?  Should we be removing the ENABLE_SVG
 defines (and potentially unifying SVG and HTML style resolve more
 closely)?

 --
 *Arunprasad Rajkumar*
 http://in.linkedin.com/in/ararunprasad

 ___
 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





-- 
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

2013-01-25 Thread Adam Barth
On Fri, Jan 25, 2013 at 8:59 PM, Elliott Sprehn espr...@chromium.org wrote:
 On Fri, Jan 25, 2013 at 11:32 PM, Dirk Schulze dschu...@adobe.com wrote:
 ...
 The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above
 are implemented by a lot of other interfaces as well. Supplemental is just
 supposed to be set once per interface. That is why Supplemental doesn't work
 for SVG. The alternative would be to implement the attributes and operations
 of SVGFitToViewBox and SVGZoomAndPan into every class that implements them.
 This would be a lot of code copies. And these are not the only interfaces
 that would need to be merged.

 That's an issue of being DRY though, which we can certainly solve in WebKit.
 I don't think Adam has an issue with extending webkit IDL to help with that,
 or at least I'd hope not.

Nope.  :)

 We could probably use multiple inheritance in C++ and copy/paste the idl
 defs, or add some new IDL feature for it.

We already have support for that in WebKitIDL (albeit using a
different syntax).  See, for example,

http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGGElement.idl

The problem arises if there's an API somewhere that returns, e.g.,
SVGTransformable.  When implementing such an API, we wouldn't know
which concrete type we actually have and would need to use something
like QueryInterface to find out.  Fortunately, no such APIs exist
currently.

I should also say that we've caved slightly on this stance for
interaces like Event that have many subclasses and are often returned
by APIs.  The way we handle this case is by introducing a virtual
function called interfaceName that returns the name of the
most-derived interface that the concrete object supports:

http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.h#L121

At runtime, we use that information to static_cast the C++ object
appropriately.  It's not as general as QueryInterface, and I'm not
sure how far we want to extend that mechanism given that it's
relatively slow.  Certainly we wouldn't want to introduce a universal
base class (a la IUnknown or nsISupports) as required in COM and
XPCOM, respectively.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev