[webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
Hi, I have been looking at HTML5 Microdata implementation in Webkit. Microdata is a specification used to nest semantics within existing content on web pages. Search engines, web crawlers, and browsers can extract and process Microdata from a web page and use it to provide a richer browsing experience for users. Microdata helps technologies such as search engines and web crawlers better understand what information is contained in a web page, providing better search results. Here is the spec : http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata I have logged a bug for this and also attached a basic implementation patch for the same. Master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Please let me know your suggestions/views regarding this. Thanks in advance. Arko Saha ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
Just so I understand, you're talking about the DOM APIs for interacting with microdata, right? I know there was some controversy in the HTML working group about Microdata versus RDFa. It's not 100% clear to me which of those technologies will win out in the end, but it seems valuable to implement this feature behind an ENABLE flag. Adam On Thu, Sep 22, 2011 at 4:48 AM, Arko Saha ngh...@motorola.com wrote: Hi, I have been looking at HTML5 Microdata implementation in Webkit. Microdata is a specification used to nest semantics within existing content on web pages. Search engines, web crawlers, and browsers can extract and process Microdata from a web page and use it to provide a richer browsing experience for users. Microdata helps technologies such as search engines and web crawlers better understand what information is contained in a web page, providing better search results. Here is the spec : http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata I have logged a bug for this and also attached a basic implementation patch for the same. Master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Please let me know your suggestions/views regarding this. Thanks in advance. Arko Saha ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
Regardless of an ENABLE flag, be certain to use the webkit prefix. document.getItems(typeNames) turns into document.webkitGetItems(typeNames) Note that it's easy to implement this in pure javascript as a prototype. -Charles On 9/22/2011 8:00 AM, Adam Barth wrote: Just so I understand, you're talking about the DOM APIs for interacting with microdata, right? I know there was some controversy in the HTML working group about Microdata versus RDFa. It's not 100% clear to me which of those technologies will win out in the end, but it seems valuable to implement this feature behind an ENABLE flag. Adam On Thu, Sep 22, 2011 at 4:48 AM, Arko Sahangh...@motorola.com wrote: Hi, I have been looking at HTML5 Microdata implementation in Webkit. Microdata is a specification used to nest semantics within existing content on web pages. Search engines, web crawlers, and browsers can extract and process Microdata from a web page and use it to provide a richer browsing experience for users. Microdata helps technologies such as search engines and web crawlers better understand what information is contained in a web page, providing better search results. Here is the spec : http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata I have logged a bug for this and also attached a basic implementation patch for the same. Master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Please let me know your suggestions/views regarding this. Thanks in advance. Arko Saha ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Early deletion of DocumentLoader instances
It looks like this was resolved in https://bugs.webkit.org/show_bug.cgi?id=61494, which resulted in http://trac.webkit.org/changeset/87756. I can't access the bug, so I'm following up here ... This change is causing problems on Android. We use the AllowLocalLoadsForLocalAndSubstituteData policy but Document::initSecurityContext() no longer calls securityOrigin().grantLoadLocalResources() because of the check for 'm_frame-document() == this' added by this change in DocumentLoader::loader(). In DocumentWriter::begin(), we create a new Document, and the Document constructor calls Document::initSecurityContext(). However, at this point the Frame has not yet been updated with the new Document, so we fail the new check in DocumentLoader::loader(). However, it looks like the Frame does have the correct DocumentLoader at this point. So it seems wrong for Document::loader() to return 0 and seems that the new check isn't valid in all cases? Or am I missing something? Any advice would be greatly appreciated. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Starting implementation on W3C Filter Effects
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. Here's the tracking bugzilla: https://bugs.webkit.org/show_bug.cgi?id=68469 It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name. The implementation plan that I have in mind is: - start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?) Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere. It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?). If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :) -eric On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson d...@apple.com wrote: Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. Here's the tracking bugzilla: https://bugs.webkit.org/show_bug.cgi?id=68469 It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name. The implementation plan that I have in mind is: - start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?) Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
Maybe the best course of action is to remove ENABLE(FILTERS) by always enabling the code and then have the CSS API for filters developed behind ENABLE(CSS_FILTERS)? Adam On Thu, Sep 22, 2011 at 11:38 AM, Eric Seidel e...@webkit.org wrote: I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere. It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?). If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :) -eric On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson d...@apple.com wrote: Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. Here's the tracking bugzilla: https://bugs.webkit.org/show_bug.cgi?id=68469 It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name. The implementation plan that I have in mind is: - start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?) Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
On Thu, Sep 22, 2011 at 11:44 AM, Dean Jackson d...@apple.com wrote: On 23/09/2011, at 4:38 AM, Eric Seidel wrote: I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere. Sorry to bring bad news, but Apple currently turns off ENABLE(FILTERS) on desktop and iOS. In that case, please disregard my previous message. I was misinformed. :) Adam It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?). If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :) I don't mind either way. I'll take this message as a suggestion to add a new define, at least for the moment. Dean -eric On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson d...@apple.com wrote: Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. Here's the tracking bugzilla: https://bugs.webkit.org/show_bug.cgi?id=68469 It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name. The implementation plan that I have in mind is: - start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?) Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
On Thu, Sep 22, 2011 at 11:44 AM, Dean Jackson d...@apple.com wrote: On 23/09/2011, at 4:38 AM, Eric Seidel wrote: I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere. Sorry to bring bad news, but Apple currently turns off ENABLE(FILTERS) on desktop and iOS. I guess I'm misinformed. Oops. We should probably fix the defaults: http://trac.webkit.org/browser/trunk/Tools/Scripts/build-webkit#L184 This makes me think they're enabled for Mac, but not windows? http://trac.webkit.org/browser/trunk/Source/WebCore/Configurations/FeatureDefines.xcconfig#L43 In either case, this seems like excellent prompting to clean up ENABLE_FILTERS and add something new for these CSS_FILTERS. It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?). If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :) I don't mind either way. I'll take this message as a suggestion to add a new define, at least for the moment. Dean -eric On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson d...@apple.com wrote: Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. Here's the tracking bugzilla: https://bugs.webkit.org/show_bug.cgi?id=68469 It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name. The implementation plan that I have in mind is: - start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?) Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On Thu, 22 Sep 2011, Charles Pritchard wrote: Regardless of an ENABLE flag, be certain to use the webkit prefix. document.getItems(typeNames) turns into document.webkitGetItems(typeNames) Note that it's easy to implement this in pure javascript as a prototype. Assuming the patch implements the spec correctly, no need to use a prefix -- I'll track the implementations and ensure no conflicts. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
The settings in TOT are the settings for nightly builds. They don't necessarily make it clear what Apple does for releases. There are features like this one that we’ve been turning off on release branches. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On 23/09/2011, at 5:59 AM, Ian Hickson wrote: On Thu, 22 Sep 2011, Charles Pritchard wrote: Regardless of an ENABLE flag, be certain to use the webkit prefix. document.getItems(typeNames) turns into document.webkitGetItems(typeNames) Note that it's easy to implement this in pure javascript as a prototype. Assuming the patch implements the spec correctly, no need to use a prefix -- I'll track the implementations and ensure no conflicts. That's an interesting approach to prefixing - I commend the volunteering of your time. However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(experimental-webgl); Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
Dean, do you want to reuse the existing filter code, or do you plan to write another filter implementation just for CSS? Would be interesting if we would need to nest CSS_FILTERS and FILTERS, or if they could get enabled independent of each other. Like previous comments mention, Apple still does not enable SVG Filters for Safari or Safari mobile. Once you reuse some code and enable CSS_ENABLE, it would force FILTERS to get enabled as well. Cheers Dirk Am 22.09.2011 um 22:06 schrieb Darin Adler: The settings in TOT are the settings for nightly builds. They don't necessarily make it clear what Apple does for releases. There are features like this one that we’ve been turning off on release branches. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
Hello, Work has started on a Gamepad (Joystick) spec in the W3C WebEvents WG. If you're interested in commenting or participating, the mailing list can be found at http://lists.w3.org/Archives/Public/public-webevents/ For reference, the draft in-progress can be found at http://dvcs.w3.org/hg/webevents/raw-file/tip/gamepad.html scott On Thu, Aug 25, 2011 at 8:44 AM, Scott Graham scot...@chromium.org wrote: Thanks Simon and Dimitri, I wasn't familiar with the procedure for attacking these sorts of things. I've started a discussion on public-webapps, which will hopefully help to clarify a sensible API. Please add your voice if you have the time and inclination: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1019.html If the discussion proves fruitful, I will re-approach the WebKit community to figure out the best way to work on a prototype implementation. I've closed the previously mentioned bug for now. scott On Wed, Aug 24, 2011 at 11:25 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We should do this right, you won't hear any arguments from me. But I am also sure that W3C time investment is a code word for years of soul-sucking bureaucratic drudgery. As such, I don't think you meant we should be using W3C process as the measuring stick for doing things right in WebKit. There would not be WebKit if we did. What I hope you meant instead is: * study the problem in the larger context of a Web platform * come up with a set of use cases that cover the problem * design a solution based on the use cases * build consensus with browser vendors while prototyping it in WebKit * write a spec and a test suite that makes sense * submit this to W3C as time permits. That's what we've always done, right? :DG On Wed, Aug 24, 2011 at 10:21 AM, Simon Fraser simon.fra...@apple.com wrote: My main objection to adding this is that it's just one of many different types of input device, and if we add these piecemeal for each device that takes our fancy, we'll end up with a horrible mishmash of different input events. I'd prefer a more general strategy of thinking about all the various types of input events (e.g. joysticks, remote controls, assistive devices), and having an API that caters for all of them. This of course would require significant W3C time investment. Simon On Aug 24, 2011, at 9:43 AM, Dimitri Glazkov wrote: On Wed, Aug 24, 2011 at 9:39 AM, Scott Graham scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.com wrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. There's certainly work to be done in improving the design. I'm not proposing to slavishly implement the API exactly as specified there. However, I would like to prototype and help with the design of this API by iterating an implementation in the Chromium port. Is a feature flag inappropriate for this? i.e. Should that sort of prototype work be kept downstream indefinitely or until we have a draft spec? FWIW, keeping implementation downstream (that is in Chromium) is basically an equivalent of forking, and we should work hard to avoid that. But certainly not by just rejecting prototyping outright -- because the only workaround for that is forking. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
Interesting. It is unfortunate that we currently have no easy way to tell which ports are shipping with which defines enabled. I didn't think to check the settings on the branch. Thank you for the clarification. -eric On Thu, Sep 22, 2011 at 1:06 PM, Darin Adler da...@apple.com wrote: The settings in TOT are the settings for nightly builds. They don't necessarily make it clear what Apple does for releases. There are features like this one that we’ve been turning off on release branches. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On Fri, 23 Sep 2011, Dean Jackson wrote: However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. It's designed to ensure that authors can reliably use a name and expect to get the same result in any UA that supports that name. I'm not going to change the spec in a way that conflicts with that -- if the spec has to change, it'll change either in a compatible way (e.g. to match what was actually implemented), or in a way that doesn't conflict (e.g. by changing the name in the spec). Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(experimental-webgl); That'll just result in that name becoming the standard. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
21.09.2011, в 12:52, Darin Fisher написал(а): True, although there are still questions about how the user experience will work for non-fullscreen. I think we only feel confident that we have a decent fullscreen solution at this point, and the plan was to restrict the initial implementation to fullscreen mode for that reason. Would it make sense to simplify the API too? Parts of it seem unnecessary if mouse lock only works in full screen - all additions to MouseEvent in particular can likely be dropped. Security considerations are also substantially different. It might be more productive to treat fullscreen mouse lock as a complete API, with only a potential for being some day extended to support windowed mode. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
On Thu, Sep 22, 2011 at 2:23 PM, Alexey Proskuryakov a...@webkit.org wrote: 21.09.2011, в 12:52, Darin Fisher написал(а): True, although there are still questions about how the user experience will work for non-fullscreen. I think we only feel confident that we have a decent fullscreen solution at this point, and the plan was to restrict the initial implementation to fullscreen mode for that reason. Would it make sense to simplify the API too? Parts of it seem unnecessary if mouse lock only works in full screen - all additions to MouseEvent in particular can likely be dropped. Security considerations are also substantially different. It might be more productive to treat fullscreen mouse lock as a complete API, with only a potential for being some day extended to support windowed mode. - WBR, Alexey Proskuryakov Our next step is to extend this to non-fullscreen, so I think it would be counter-productive to preclude non-fullscreen at this time. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On 9/22/2011 2:13 PM, Ian Hickson wrote: On Fri, 23 Sep 2011, Dean Jackson wrote: However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. It's designed to ensure that authors can reliably use a name and expect to get the same result in any UA that supports that name. I'm not going to change the spec in a way that conflicts with that -- if the spec has to change, it'll change either in a compatible way (e.g. to match what was actually implemented), or in a way that doesn't conflict (e.g. by changing the name in the spec). Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(experimental-webgl); That'll just result in that name becoming the standard. I would like some kind of fast track method for these kind of issues. Something like a Request for dropping prefix RfDP protocol would be super. RfDP: Microdata. First the spec editor would have to vouch for it, then, if Moz, MS, Opera, Apple and Google reps can give a nod within a few weeks, we've got something. I'd really like to avoid repeats of the CSS -vnd-transform baggage, when possible. WebKit went back and forth on BlobBuilder. Now it's at: WebKitBlobBuilder. That was not so fun. That's another situation I'd like to avoid. For this particular method, the microdata section, I'm happy enough hearing that the spec editor will vouch for it. If that's the precedent, I'll take it. I'd like to learn how we can build on that precedent. Reps from the major vendors have been quite responsive this year. I know they can't commit to supporting an API in a short time frame (such as the File API), but they have been great about voicing issues. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
22.09.2011, в 14:25, Darin Fisher написал(а): Our next step is to extend this to non-fullscreen, so I think it would be counter-productive to preclude non-fullscreen at this time. I think that adding an API for non-fullscreen mouse lock would be a detriment to the Web platform. So gating fullscreen API on it seems pretty controversial. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
On Thu, Sep 22, 2011 at 2:38 PM, Alexey Proskuryakov a...@webkit.org wrote: 22.09.2011, в 14:25, Darin Fisher написал(а): Our next step is to extend this to non-fullscreen, so I think it would be counter-productive to preclude non-fullscreen at this time. I think that adding an API for non-fullscreen mouse lock would be a detriment to the Web platform. So gating fullscreen API on it seems pretty controversial. - WBR, Alexey Proskuryakov Would you mind raising your concerns with the working group? I believe there is a fair bit of interest in providing mouse lock in the non-fullscreen case too. I can imagine it may require some additional UI. It makes sense to me to design the mouse lock API with the idea that it could work in either fullscreen or non-fullscreen mode. Then it just becomes a question of policy and UI as to whether it runs in neither, one or both. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard ch...@jumis.com wrote: On 9/22/2011 2:13 PM, Ian Hickson wrote: On Fri, 23 Sep 2011, Dean Jackson wrote: However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. It's designed to ensure that authors can reliably use a name and expect to get the same result in any UA that supports that name. I'm not going to change the spec in a way that conflicts with that -- if the spec has to change, it'll change either in a compatible way (e.g. to match what was actually implemented), or in a way that doesn't conflict (e.g. by changing the name in the spec). Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(**experimental-webgl); That'll just result in that name becoming the standard. I would like some kind of fast track method for these kind of issues. Something like a Request for dropping prefix RfDP protocol would be super. Please post this feedback to some thread where it's relevant, not on a WebKit development mailing list discussion about a specific feature. - James RfDP: Microdata. First the spec editor would have to vouch for it, then, if Moz, MS, Opera, Apple and Google reps can give a nod within a few weeks, we've got something. I'd really like to avoid repeats of the CSS -vnd-transform baggage, when possible. WebKit went back and forth on BlobBuilder. Now it's at: WebKitBlobBuilder. That was not so fun. That's another situation I'd like to avoid. For this particular method, the microdata section, I'm happy enough hearing that the spec editor will vouch for it. If that's the precedent, I'll take it. I'd like to learn how we can build on that precedent. Reps from the major vendors have been quite responsive this year. I know they can't commit to supporting an API in a short time frame (such as the File API), but they have been great about voicing issues. -Charles __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Early deletion of DocumentLoader instances
On Thu, Sep 22, 2011 at 3:07 PM, Darin Adler da...@apple.com wrote: On Sep 22, 2011, at 11:07 AM, Steve Block wrote: This change is causing problems on Android. We use the AllowLocalLoadsForLocalAndSubstituteData policy but Document::initSecurityContext() no longer calls securityOrigin().grantLoadLocalResources() because of the check for 'm_frame-document() == this' added by this change in DocumentLoader::loader(). I tried to look into this, but couldn’t find a function named DocumentLoader::loader. Maybe he means Document::loader? http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.h#L583 Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit
On 9/22/2011 2:42 PM, James Robinson wrote: On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 9/22/2011 2:13 PM, Ian Hickson wrote: On Fri, 23 Sep 2011, Dean Jackson wrote: However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. It's designed to ensure that authors can reliably use a name and expect to get the same result in any UA that supports that name. I'm not going to change the spec in a way that conflicts with that -- if the spec has to change, it'll change either in a compatible way (e.g. to match what was actually implemented), or in a way that doesn't conflict (e.g. by changing the name in the spec). Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(experimental-webgl); That'll just result in that name becoming the standard. I would like some kind of fast track method for these kind of issues. Something like a Request for dropping prefix RfDP protocol would be super. Please post this feedback to some thread where it's relevant, not on a WebKit development mailing list discussion about a specific feature. James Robinson, this thread is about introducing a specific feature, Microdata, into the WebKit code base. ENABLE flags are present, vendor prefixing is absent. https://bugs.webkit.org/attachment.cgi?id=108313action=review https://bugs.webkit.org/attachment.cgi?id=108313action=review I have no intention of sending irrelevant e-mails to your inbox, nor derailing this conversation. I think we can all agree that Arko Saha's work is welcome. The patch is quite simple, it's easy to review. I do not believe I've stepped outside the thread, nor do I believe Dean Jackson was being counter-productive when he pointed out that vendor prefixing is not an issue particular to this feature. Dean Jackson and Ian Hickson spoke about whether or not the vendor prefix should be included. Ian suggested that vendors should skip vendor prefixing. Dean is a bit more cautious, and has good reason to be. WebKit's experience with File API encountered quite a bit of criticism from other vendors. Both Adam Barth and Dean would like to avoid controversy with other vendors. That's the impression I'm getting. My concern, on this WebKit development mailing list, is that introducing another method -without- vendor prefixing may create some tension that WebKit developers would like to avoid. It simple patch. As far as I can tell, vendor prefixing is exactly what should be discussed. The patch can be approved by one person, the decision on whether or not to prefix the method name should be discussed by multiple vendors. WebKit serves multiple vendors. Again, I'm not trying to get in your inbox, James. If this still makes no sense to you, or I've misunderstood other WebKit developers, I do apologize. I'm trying to contribute, I'm not always successful at it. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
Hey Dirk, On 23/09/2011, at 6:24 AM, Dirk Schulze wrote: Dean, do you want to reuse the existing filter code, or do you plan to write another filter implementation just for CSS? Would be interesting if we would need to nest CSS_FILTERS and FILTERS, or if they could get enabled independent of each other. I plan to use the existing filter code. It's nicely neutral of SVG. This would mean that CSS_FILTERS does require FILTERS, but I could also change the #ifs to use ||. BTW - the Filter Effects specification (ENABLE_CSS_FILTERS) does support What was previously known as SVG Filters (ENABLE_FILTERS), so there is a dependency. When hardware acceleration comes we'll obviously begin diverging. As you mentioned elsewhere, buried in the depths of SVN is a Core Image-based version. Like previous comments mention, Apple still does not enable SVG Filters for Safari or Safari mobile. Once you reuse some code and enable CSS_ENABLE, it would force FILTERS to get enabled as well. That's right. This new specification is mostly adding some new syntax and exposing filters to HTML/CSS. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit
TL;DR (from Charles himself): My concern, on this WebKit development mailing list, is that introducing another method -without- vendor prefixing may create some tension that WebKit developers would like to avoid. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] starting implementation of postMessage tranferables
*Summary*: Implementing postMessage with transferable support as webkitPostMessage. *Details*: *Spec*: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages This describes window.postMessage and the same is true for Message Ports and Worker Context. It doesn't mention Array Buffers but that will be mentioned soon and is in the spec that talks about Array Buffers. Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=64629 *Plan*: 1. Add webkitPostMessage to all of these places to isolate us from possible spec changes. It will have the same functionality as postMessage. 2. Add the ability to transfer Message Ports. 3. Add the ability to transfer Array Buffers. We don't plan to put ifdef's around this as we'll do an implementation for all ports and js engines and each patch is complete by itself. (Even when using webkitPostMessage, one has to be careful to verify that the items being transfered may be transfered. After step 1, the answer is no to everything.) I didn't send this earlier because we were doing this in postMessage and it was in the spec but it would have been good to send out the email even then. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] new APIs for strokes with dash in Canvas
Hi all, I have a patch to add webkitLineDash and webkitLineDashOffset APIs on CanvasRenderingContext2D on https://bugs.webkit.org/show_bug.cgi?id=63933 The purpose of these APIs is to support for strokes with dash in Canvas. Although the API is not specified in the HTML Canvas specification yet, I believe it would be great to support the API. As Dirk said in the above bug, Mozilla already implemented the APIs named mozDash and mozDashOffset[1], and there seems to be many needs for the API. Some people even implemented their own javascript functions to draw strokes with dash in Canvas[2,3]. As GraphicsContext already have an interface for strokes with dash, setLineDash, all we have to do is exposing it to the JS level. So the syntax and meaning of the new APIs is the same with the arguments of the setLineDash. webkitLineDash is an array of float, and webkitLineDashOffset is a float. I uploaded a patch for JSC first. After the patch is landed, I will make a follow-up patch for V8. Any thought? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=662038 [2] http://davidowens.wordpress.com/2010/09/07/html-5-canvas-and-dashed-lines/ [3] http://stackoverflow.com/questions/7352769/dashed-curves-on-html5-canvas-bezier ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new APIs for strokes with dash in Canvas
On Thu, Sep 22, 2011 at 7:31 PM, Young Han Lee joybro...@gmail.com wrote: Hi all, I have a patch to add webkitLineDash and webkitLineDashOffset APIs on CanvasRenderingContext2D on https://bugs.webkit.org/show_bug.cgi?id=63933 The purpose of these APIs is to support for strokes with dash in Canvas. Although the API is not specified in the HTML Canvas specification yet, I believe it would be great to support the API. As Dirk said in the above bug, Mozilla already implemented the APIs named mozDash and mozDashOffset[1], and there seems to be many needs for the API. Some people even implemented their own javascript functions to draw strokes with dash in Canvas[2,3]. As GraphicsContext already have an interface for strokes with dash, setLineDash, all we have to do is exposing it to the JS level. So the syntax and meaning of the new APIs is the same with the arguments of the setLineDash. webkitLineDash is an array of float, and webkitLineDashOffset is a float. I uploaded a patch for JSC first. After the patch is landed, I will make a follow-up patch for V8. Any thought? Has this proposal been raised in the WHATWG, which specifies the canvas 2d interface? It sounds like in this email you have done most of the work necessary for a good spec proposal (see http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F ). - James [1] https://bugzilla.mozilla.org/show_bug.cgi?id=662038 [2] http://davidowens.wordpress.com/2010/09/07/html-5-canvas-and-dashed-lines/ [3] http://stackoverflow.com/questions/7352769/dashed-curves-on-html5-canvas-bezier ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] starting implementation of postMessage tranferables
On Thu, 22 Sep 2011, David Levin wrote: *Summary*: Implementing postMessage with transferable support as webkitPostMessage. *Details*: *Spec*: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages This describes window.postMessage and the same is true for Message Ports and Worker Context. It doesn't mention Array Buffers but that will be mentioned soon and is in the spec that talks about Array Buffers. Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=64629 *Plan*: 1. Add webkitPostMessage to all of these places to isolate us from possible spec changes. It will have the same functionality as postMessage. 2. Add the ability to transfer Message Ports. 3. Add the ability to transfer Array Buffers. After step 2, webkitPostMessage can be renamed to postMessage quite safely. The spec isn't going to change in a way that breaks you. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] starting implementation of postMessage tranferables
On Sep 22, 2011, at 7:46 PM, Ian Hickson wrote: On Thu, 22 Sep 2011, David Levin wrote: *Summary*: Implementing postMessage with transferable support as webkitPostMessage. *Details*: *Spec*: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages This describes window.postMessage and the same is true for Message Ports and Worker Context. It doesn't mention Array Buffers but that will be mentioned soon and is in the spec that talks about Array Buffers. Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=64629 *Plan*: 1. Add webkitPostMessage to all of these places to isolate us from possible spec changes. It will have the same functionality as postMessage. 2. Add the ability to transfer Message Ports. 3. Add the ability to transfer Array Buffers. After step 2, webkitPostMessage can be renamed to postMessage quite safely. The spec isn't going to change in a way that breaks you. I think we should wait and see -- spec changes have caused issues for us in the past (eg. localStorage :-/ ) There is not any substantive harm in prefixing, whereas there can be real problems down the road if we don't prefix. --Oliver -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new APIs for strokes with dash in Canvas
Do you know if anyone is working to add this to the spec for Canvas? It seems like it may not take much to get it added, given that FF already has an implementation. -Darin On Thu, Sep 22, 2011 at 7:31 PM, Young Han Lee joybro...@gmail.com wrote: Hi all, I have a patch to add webkitLineDash and webkitLineDashOffset APIs on CanvasRenderingContext2D on https://bugs.webkit.org/show_bug.cgi?id=63933 The purpose of these APIs is to support for strokes with dash in Canvas. Although the API is not specified in the HTML Canvas specification yet, I believe it would be great to support the API. As Dirk said in the above bug, Mozilla already implemented the APIs named mozDash and mozDashOffset[1], and there seems to be many needs for the API. Some people even implemented their own javascript functions to draw strokes with dash in Canvas[2,3]. As GraphicsContext already have an interface for strokes with dash, setLineDash, all we have to do is exposing it to the JS level. So the syntax and meaning of the new APIs is the same with the arguments of the setLineDash. webkitLineDash is an array of float, and webkitLineDashOffset is a float. I uploaded a patch for JSC first. After the patch is landed, I will make a follow-up patch for V8. Any thought? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=662038 [2] http://davidowens.wordpress.com/2010/09/07/html-5-canvas-and-dashed-lines/ [3] http://stackoverflow.com/questions/7352769/dashed-curves-on-html5-canvas-bezier ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] starting implementation of postMessage tranferables
On Thu, 22 Sep 2011, Oliver Hunt wrote: There is not any substantive harm in prefixing, whereas there can be real problems down the road if we don't prefix. The harm in prefixing is that people can't use the feature for years after it's implemented; q.v. CSS. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new APIs for strokes with dash in Canvas
On Thu, 22 Sep 2011, Darin Fisher wrote: Do you know if anyone is working to add this to the spec for Canvas? It seems like it may not take much to get it added, given that FF already has an implementation. Dashed lines are on my list but were not a high priority. If there are implementations then I'm happy to add it -- the only reason I hadn't added it is because the moment I add anything to canvas, everyone implements it, dropping whatever else they were working on, and so if I keep adding canvas features nothing else gets done... :-) Is there any documentation on how this patch and Gecko's implementation work and what they support? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new APIs for strokes with dash in Canvas
On Fri, Sep 23, 2011 at 1:44 PM, Ian Hickson i...@hixie.ch wrote: Is there any documentation on how this patch and Gecko's implementation work and what they support? I spent some time trying to find it, but couldn't. This bugzilla seems to be the only place we can get information at the moment. https://bugzilla.mozilla.org/show_bug.cgi?id=662038 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
