Re: Use cases for Range::createContextualFragment and script nodes
On Oct 20, 2010, at 9:41 PM, Adam Barth wrote: On Wed, Oct 20, 2010 at 7:14 AM, Stewart Brodie stewart.bro...@antplc.com wrote: Henri Sivonen hsivo...@iki.fi wrote: When WebKit or Firefox trunk create an HTML script element node via Range::createContextualFragment, the script has its 'already started' flag set, so the script won't run when inserted into a document. In Opera 10.63 and in Firefox 3.6.x, the script doesn't have the 'already started' flag set, so the script behaves like a script created with document.createElement(script) when inserted into a document. I'd be interested in use cases around createContextualFragment in order to get a better idea of which behavior should be the correct behavior going forward. Does the specification for createContextualFragment say anything about this? I don't believe such a spec exists, or at least I couldn't find one the other month. It is indeed not part of any standard. It was originally a Mozilla vendor extension, later copied by Opera and Safari. We added support for it in 2002 because at least at the time, some sites used it: http://trac.webkit.org/changeset/2940 It should probably be added to a spec at some point. Perhaps Web DOM Core could be expanded to cover Range Tranversal? Regards, Maciej
Re: Use cases for Range::createContextualFragment and script nodes
On 10/21/2010 09:43 AM, Maciej Stachowiak wrote: On Oct 20, 2010, at 9:41 PM, Adam Barth wrote: On Wed, Oct 20, 2010 at 7:14 AM, Stewart Brodie stewart.bro...@antplc.com wrote: Henri Sivonenhsivo...@iki.fi wrote: When WebKit or Firefox trunk create an HTML script element node via Range::createContextualFragment, the script has its 'already started' flag set, so the script won't run when inserted into a document. In Opera 10.63 and in Firefox 3.6.x, the script doesn't have the 'already started' flag set, so the script behaves like a script created with document.createElement(script) when inserted into a document. I'd be interested in use cases around createContextualFragment in order to get a better idea of which behavior should be the correct behavior going forward. Does the specification for createContextualFragment say anything about this? I don't believe such a spec exists, or at least I couldn't find one the other month. It is indeed not part of any standard. It was originally a Mozilla vendor extension, later copied by Opera and Safari. We added support for it in 2002 because at least at the time, some sites used it: http://trac.webkit.org/changeset/2940 It should probably be added to a spec at some point. Perhaps Web DOM Core could be expanded to cover Range Tranversal? I'd actually like to get rid of it. So perhaps browsers could start warn about using it. (That ofc doesn't solve the problem Henri has atm.) -Olli
Re: Use cases for Range::createContextualFragment and script nodes
On Oct 21, 2010, at 1:06 AM, Olli Pettay wrote: On 10/21/2010 09:43 AM, Maciej Stachowiak wrote: It is indeed not part of any standard. It was originally a Mozilla vendor extension, later copied by Opera and Safari. We added support for it in 2002 because at least at the time, some sites used it: http://trac.webkit.org/changeset/2940 It should probably be added to a spec at some point. Perhaps Web DOM Core could be expanded to cover Range Tranversal? I'd actually like to get rid of it. So perhaps browsers could start warn about using it. (That ofc doesn't solve the problem Henri has atm.) Even 8 years ago it was pretty frequently used by Web sites, and I would not expect things to be different now. Also, it is apparently used in a number of JavaScript libraries: http://www.google.com/codesearch?as_q=createContextualFragment I suspect getting rid of createContextualFragment is not a practical option at this point. And I expect a new entrant to the browser market would likely have to implement it to achieve sufficient Web compatibility. So I think it should be spec'd. Out of curiosity, though, what's the reason to get rid of it? Regards, Maciej
Re: createBlobURL
On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking jo...@sicking.cc wrote: The only real solution here is to abandon the use of URLs-strings (blob:...) and instead use some type of object which represents a reference to the blob/stream/whatever. Then make img.src, iframe.src, CSSStyleDeclaration.backgroundImage etc accept this new type in addition to a string. If that is the only real solution I suggest we do that. We can create some kind of DOMURL type which is either a DOMString or a URL/Blob/something and change the relevant APIs. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Draft agenda for 21 October 2010 voice conf
I think I had already sent regrets for this call, and although the reason has changed, I still have to send regrets (my youngest is ill, and I have to go to the hospital with him). Steven On Wed, 20 Oct 2010 13:27:54 +0200, Arthur Barstow art.bars...@nokia.com wrote: Below is the draft agenda for the October 21 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened or canceled meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/10/07-wam-minutes.html -Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. October 26 is the deadline for comments re October 5 LCWD of Widget Packaging and Configuration ( http://www.w3.org/TR/2010/WD-widgets-20101005/ ) 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20101005/ a. Comments from viji v...@borqs.com http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0130.html b. Issue-150 Email and param name and value as 'Keyword attributes' is causing confusion in Widgets PC Spec http://www.w3.org/2008/webapps/track/issues/150 c. Issue-151 If feature-name is not a valid IRI, and required-feature is true, then the user agent must treat this widget as an invalid widget package. but doesnt say anything about the case when it is not required. http://www.w3.org/2008/webapps/track/issues/151 d. Issue-152 test suite needs a few more XML entity cases to check for well-formed XML http://www.w3.org/2008/webapps/track/issues/152 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. Addison's October 14 e-mail: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0096.html 5. Widget Requirements: CfC to publish a new WD; only changes are updating references and the now obsolete spec titles (e.g. Widgets 1.0: Packaging and Configuration) http://dev.w3.org/2006/waf/widgets-reqs/ 6. AOB Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 60 minutes max Zakim Bridge:+1.617.761.6200, +33.4.26.46.79.03 or +44.203.318.0479 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public
[Bug 11113] New: [IndexedDB] The spec should be more explicit about the queuing of setVersion transactions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3 Summary: [IndexedDB] The spec should be more explicit about the queuing of setVersion transactions Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The resolution of the [IndexedDB] Calling setVersion while already in a setVersion transaction thread was that calling setVersion while in another setVersion transaction should simply queue up another setVersion transaction to run when the current is finished. It'd be nice if the spec could make this more explicit. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: createBlobURL
On 10/21/10 6:50 AM, Anne van Kesteren wrote: On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking jo...@sicking.cc wrote: The only real solution here is to abandon the use of URLs-strings (blob:...) and instead use some type of object which represents a reference to the blob/stream/whatever. Then make img.src, iframe.src, CSSStyleDeclaration.backgroundImage etc accept this new type in addition to a string. If that is the only real solution I suggest we do that. We can create some kind of DOMURL type which is either a DOMString or a URL/Blob/something and change the relevant APIs. This is an attractive direction that could help with the revocation problem (and maybe even spare some IANA work with registering/formalizing blob: if in the end we abandon URL strings, but I'd rather not skip ahead). I'm in favor of vendor-prefixing the create*URL revoke*URL methods, but I leave that to implementers.
Re: createBlobURL
On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking jo...@sicking.cc wrote: The only real solution here is to abandon the use of URLs-strings (blob:...) and instead use some type of object which represents a reference to the blob/stream/whatever. Then make img.src, iframe.src, CSSStyleDeclaration.backgroundImage etc accept this new type in addition to a string. If that is the only real solution I suggest we do that. We can create some kind of DOMURL type which is either a DOMString or a URL/Blob/something and change the relevant APIs. This means that you can't use File objects together with things like .innerHTML (neither the getter nor setter) or things like CSSStyleDeclaration.background. Actually, it doesn't even work with CSSStyleDeclaration.backgroundImage since it can be a list of URLs. And with the CSS Image Values spec [1] it can be something much more complex. If we don't want to use blob-URLs at all, we have to track down every single DOM property which deals with URLs and: A. Make sure that it doesn't use strings where URLs is part of the string (like .innerHTML or CSSStyleDeclaration.background). If it does, create a new object model that breaks down the string into components where the URL is a separate component. B. Make it take a DOMURL instead of a DOMString While I agree that memory management is a horrible thing to thrust upon developers, I really don't see an option here. It would complicate matters hugely in cases like CSSStyleDeclaration.backgroundImage. Can you even make a proposal for what the object model would look like which would work for [1]? And as stated before, I think a hugely mitigating factor here is that the amount of memory leaked is very small. What I think we should do is to fine the places where people are most likely to use blob-urls and in those cases change DOMString to DOMURL. Such as HTMLImageElement.src like Darin proposes. But for the remaining places keep createObjectURL/revokeObjectURL. I would imagine that by just fixing a handful of properties we can cover 95% of the use cases and make those not require the author to do memory management. [1] http://dev.w3.org/csswg/css3-images/ / Jonas
RE: CfC: publish a new Working Draft of Web IDL; deadline October 18
For IE9, we've adopted this attribute as well [msDoNotCheckDomainSecurity] It has different meanings for different types of properites (fields vs. accessors) and causes some proxies to be setup, but generally speaking it does allow requests for the property to go through without an access denied hard-stop. I'm not sure how far WebIDL should go toward specing the security aspects of this attribute if it decides to include it. There are a lot of considerations that IE had to put in place to ensure we were secure, and they are quite varied depending on the scenario. My recommendation, if this attribute gets included into the WebIDL syntax, would be merely to indicate what it's intended purpose is, and to leave a general note about further security precautions that should be taken by an implementation to avoid cross-domain problems (or something like that). Starting down the road of defining all the possible attacks and mitigations may not be the best route to take (for this spec anyway). -Travis -Original Message- From: public-script-coord-requ...@w3.org [mailto:public-script-coord-requ...@w3.org] On Behalf Of Shiki Okasaka Sent: Monday, October 11, 2010 5:48 PM To: Shiki Okasaka; public-script-coord; public-webapps Subject: Re: CfC: publish a new Working Draft of Web IDL; deadline October 18 Thanks, Cameron. [DoNotCheckDomainSecurity] is one of the WebKit IDL's attributes, briefly described here: http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf I think security related attributes like this would be very helpful, too. - Shiki 2010/10/12 Cameron McCormack c...@mcc.id.au: -minus various people Shiki Okasaka: You've been missed, Cameron! Just a reminder, my wish list is here (this doesn't have to be reflected in the very next WD, though): http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/00 03.html A signed 8 bit integer type has been required in WebGL. Thanks for pointing these out. I’ve made sure they all have issue boxes in the spec. The one I can find the least information about is [DoNotCheckDomainSecurity]. What are its requirements – just allow property accesses that would normally be blocked because they are cross origin? Is it something HTML5 would use? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Can we remove forminput and formchange events and related dispatch methods?
The forminput and formchange events are dispatched on all resettable elements in a form when any element associated with the form dispatches an input or a change event. Is this case really worth the cost of increasing the size of the API when it can easily be achieved with capturing events? erik
Re: CfC: publish a new Working Draft of Web IDL; deadline October 18
On Thu, Oct 21, 2010 at 1:38 PM, Travis Leithead tra...@microsoft.com wrote: For IE9, we've adopted this attribute as well [msDoNotCheckDomainSecurity] It has different meanings for different types of properites (fields vs. accessors) and causes some proxies to be setup, but generally speaking it does allow requests for the property to go through without an access denied hard-stop. I'm not sure how far WebIDL should go toward specing the security aspects of this attribute if it decides to include it. There are a lot of considerations that IE had to put in place to ensure we were secure, and they are quite varied depending on the scenario. My recommendation, if this attribute gets included into the WebIDL syntax, would be merely to indicate what it's intended purpose is, and to leave a general note about further security precautions that should be taken by an implementation to avoid cross-domain problems (or something like that). Starting down the road of defining all the possible attacks and mitigations may not be the best route to take (for this spec anyway). My gut reaction is to leave this out from the spec and not let WebIDL specify security aspects. It seems fine for implementations to add their own extended attributes in their own internal IDL, this is something that we've done for gecko forever. To me, the purpose of WebIDL is to specify behavior at a central place, as well as establish common and recommended usage patterns, not for implementations to be able to copy the IDL into the implementation directly. In fact, implementations doesn't have to use IDL at all. / Jonas
Re: CfC: publish a new Working Draft of Web IDL; deadline October 18
Jonas Sicking: My gut reaction is to leave this out from the spec and not let WebIDL specify security aspects. Agreed. It’d be fine even for other specs (HTML5?) to define their own security-related extended attributes to avoid writing prose that defines when SECURITY_ERRs get thrown, but I don’t think the place to define such an extended attribute is in Web IDL itself. -- Cameron McCormack ≝ http://mcc.id.au/
Re: CfC: publish a new Working Draft of Web IDL; deadline October 18
On Thu, Oct 21, 2010 at 2:39 PM, Cameron McCormack c...@mcc.id.au wrote: Jonas Sicking: My gut reaction is to leave this out from the spec and not let WebIDL specify security aspects. Agreed. It’d be fine even for other specs (HTML5?) to define their own security-related extended attributes to avoid writing prose that defines when SECURITY_ERRs get thrown, but I don’t think the place to define such an extended attribute is in Web IDL itself. Sounds good to me. / Jonas
Re: DOM3 Events last call comment
On Fri, 22 Oct 2010 01:38:28 +0200, Doug Schepers schep...@w3.org wrote: ... I'm saying that when DOMActivate was first specced, in 1999-2000, there wasn't a clean mobile-web model or significant use of inputs other than keyboard and mouse, so click seemed to serve content authors just as well as DOMActivate... they didn't need to think as much about an abstraction that covered keyboard, mouse, touch inputs, voice, and whatever, equally well. That dynamic has since shifted, and there is more need for an activation event... just not necessarily DOMActivate, because of the other problems with it. For what it is worth, DOMActivate is largely my fault (although credit for good stuff is due to Rich Schwerdtfeger, Al Gilman, Philippe le Hegaret and many others). The idea at the time was to replace the UI events around at the time with a set that were based on intentions rather than hardware-specific interactions, because I predicted that the existing problems of people building interactions that required a specific hardware paradigm would only get worse over time. I think that came true... In the meantime, abstract intention-based events were added in parallel. Given the lack of good interoperable implementation and the ability to continue doing what they had done and figuring it more or less worked, Web developers didn't take them up, and the hardware-based events became more and more common. Meanwhile, browser vendors and others worked to make the hardware-events sort of abstract (being able to fire a click in multiple ways, or adding extensions that synthesised events from a non-WIMP interface). So the abstract events continued to rot. (Again, that wasn't a surprise, as discussed at the time). I understand Doug's suggestion (in its strict relationship to this comment) to be give up DOMActivate as a failure, and accept that the click event has effectively taken the role, for now. The Web APIs group (one of the fore-runners to Web apps) actually resolved that in 2006 at its first meeting, and I think we were right at the time and still do. Meanwhile, there is now momentum to specify a better approach to events, and make it work. I think that deserves support as the best way to use our energy to get something better. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
