Re: [selectors-api] Reference to obsolete ECMAScript Language spec version
On 2012-10-29 14:38, Norbert Lindenberg wrote: The current drafts of the Selectors API specifications [1, 2, 3] refer to the third edition of the ECMAScript Language Specification, The references have been updated. Thank you. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
[Bug 19969] New: clarify some user name/password and setRequestHeader() Authorize header issues
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19969 Priority: P2 Bug ID: 19969 CC: m...@w3.org, public-webapps@w3.org Assignee: ann...@annevk.nl Summary: clarify some user name/password and setRequestHeader() Authorize header issues QA Contact: public-webapps-bugzi...@w3.org Severity: normal Classification: Unclassified OS: Linux Reporter: hallv...@opera.com Hardware: PC Status: NEW Version: unspecified Component: XHR Product: WebAppsWG IMO we should clarify the following: 1) Add a note (maybe just informative?) saying user name / password from open() method will only be sent to a site if it first uses a 401 response to indicate that authentication is required. 2) Figure out what should happen if a script calls open() with user name/password arguments, then sets an Authorize header with setRequestHeader(). Which wins? Will it depend on whether the site says 401 or not? (IMO: setRequestHeader() should win if this is compatible with implementations, simplifies things. Whether or not there is a 401 response should make no difference. Hope that's sufficiently aligned with implementations..) 3) I assume that if setRequestHeader() adds an Authorize header, it's sent to the server whether or not a 401 request has been returned. Perhaps this should also be noted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 19969] clarify some user name/password and setRequestHeader() Authorize header issues
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19969 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Anne ann...@annevk.nl --- *** This bug has been marked as a duplicate of bug 15418 *** -- You are receiving this mail because: You are on the CC list for the bug.
[selectors-api] Editoral Changes and Test Suite Progress
Hi, The test suite has been reviewed by a colleague at Opera, which resulted in a few minor corrections. No corrections required any changes to the implementation report. However, it did result in a few editorial changes to Selectors API spec. These changes should not affect conformance of any implementations. In particular, I fixed the algorithm for processing selectors to explicitly refer to the definition for invalidity in Selectors, with regards to throwing a syntax error. This was always implied, and is what browsers do, but now the spec is clearer. I also updated the Acknowledgements section to include people who have submitted comments over the years who had been missed. I tried to at least include people who's comments resulted in changes to the spec. I believe we can now finally proceed with publishing this as PR, as discussed at TPAC. I will co-ordinate with Chaals to make this happen as soon as possible. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
[css-regions] Fwd: Scheduling multiple types of end-of-(micro)task work
Hello, CCing www-style and BCCing public-webapps I have given some thoughts to the regionlayoutupdate event - what condition triggers it and when it should be dispatched. For the current version of the spec I think it is sufficient to consider the event is triggered only by changes of the overset value of the NamedFlow (so it could be renamed to flowoversetchanged). This covers most of the use-cases I can think of. In my opinion, having something more generic brings a lot of complexity without much value. We could discuss more about how regionlayoutupdate can be extended when there will be strong use cases that need a more powerful event (e.g. to detect subtle layout changes). The timing of the event is a bit tricky to get right. The overset value of the NamedFlow object is a result of the layout (see the discussion in the original thread). As a consequence there aren't many options to pick from. I'm imagining something like this: 1. The event needs to be synchronous to allow scripts to update the layout in a responsive manner by interleaving with other events that cause a layout change. 2. I think the event must be dispatched on the same task queue of the resize event. The reason is to allow smooth updates of the layout when the user resizes the browser window. Thoughts? Thanks, Andrei. Begin forwarded message: From: Andrei Bucur abu...@adobe.com Subject: Re: Scheduling multiple types of end-of-(micro)task work Date: October 19, 2012 5:53:27 PM GMT+03:00 To: Webapps WG public-webapps@w3.org Cc: Jonas Sicking jo...@sicking.cc, Alan Stearns stea...@adobe.com, o...@pettay.fi o...@pettay.fi, Rafael Weinstein rafa...@google.com, Ian Hickson i...@hixie.ch, Ryosuke Niwa rn...@webkit.org, Ojan Vafai o...@chromium.org, James Robinson jam...@google.com Hello, I agree using micro-tasks for the regionLayoutUpdate event is not a very good option and we should respecify the event behaviour. One idea that comes in my mind is to specialize the regionLayoutEvent into something more measurable (basically, having a better answer to what are the conditions that trigger the event). My suggestion is to use the region flow ranges: the event is scheduled (I'll come back to this later) when the flow ranges in any region in the chain change. Conceptually this is similar to mutation observers - e.g. when the content of a DOM node changes, a callback can be invoked. The same way, when the fragment of content flowing into a region has changed, the regionLayoutUpdate event is dispatched (I quoted it because I'm not sure this name would fit it any more). Trying to include this proposal in one of the categories James nicely defined, it unfortunately remains a layout output event. The scheduling issue is still here, but I think specializing the trigger condition this way allows us to simplify the wording to something like the event is dispatched after all the effects of the range changes in the region chain have been applied (see [1]), thus masking the fact a layout was made. However, with this wording I wonder why the event can't be made synchronous. It would become more like the resize event and allow real-time operations over the named flows/regions. The regionLayoutUpdate would also chain nicely with the resize event - the user resizes the window, a layout is triggered, the ranges change, regionLayoutUpdate is dispatched, other changes apply (tricky one), the resize event is dispatched. Thoughts? Thanks, Andrei. [1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-resize On Oct 19, 2012, at 2:41 AM, James Robinson jam...@google.com wrote: On Thu, Oct 18, 2012 at 4:16 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Oct 18, 2012 at 3:34 PM, James Robinson jam...@google.com wrote: On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns stea...@adobe.com wrote: On 10/18/12 2:51 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 10/19/2012 12:08 AM, Rafael Weinstein wrote: CSS Regions regionLayoutUpdate brings up an issue I think we need to get ahead of: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16391 For context: Mutation Observers are currently spec'd in DOM4 http://dom.spec.whatwg.org/#mutation-observers and delivery timing is defined in HTML http://www.whatwg.org/specs/web-apps/current-work/#perform-a-microtask-ch eckpoint The timing here is described as a microtask checkpoint and is conceptually deliver all pending mutation records immediately after any script invocation exits. TC-39 has recently approved Object.observe http://wiki.ecmascript.org/doku.php?id=harmony:observe (Not sure how that will work with native objects.) for inclusion in ECMAScript. It is conceptually modeled on Mutation Observers, and delivers all pending change records immediately *before* the last script stack frame exits. Additionally, although I've seen various discussion of dispatching
[css3-conditional] Last Call Working Draft for @supports and CSS.supports()
Hello WebApps, The CSSWG expects to publish a Last Call Working Draft of CSS Conditional Rules Level 3 within the next week. We would appreciate your review, particularly of the API parts: http://dev.w3.org/csswg/css3-conditional/#apis The LCWD will likely appear here: http://www.w3.org/TR/2012/WD-css3-conditional-20121120/ with a deadline for comments of 18 December 2012. For now, you can reference the editor's draft: http://dev.w3.org/csswg/css3-conditional/ Comments should be sent to www-st...@w3.org, with the tag '[css3-conditional]' in the subject line along with the topic of your comment, as I have done here. Thanks! ~fantasai
Call for Consensus: CORS to Candidate Recommendation
WebApps and WebAppSec WG members, (and copied security interest groups who we invite to provide comments) Following discussion at TPAC, I've resolved outstanding changes in the security considerations section agreed to by WebAppSec as well as differences between the W3C and WHATWG versions of CORS, and believe we are ready to go to Candidate Recommendation. We probably have enough implementations to proceed directly to Proposed Recommendation, but our test suite still needs better documentation of its coverage and some test cases need repairs, so I believe moving to CR first, and as soon as possible, is the right next step, while we work out those details. I have placed a draft for review at: http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. Please send comments to public-webapp...@w3.orgmailto:public-webapp...@w3.org , positive feedback is encouraged. This CfC will end on November 23, 2012. Substantive changes from the last published version (both pulled from the WHATWG version) include: 1.updating the redirect status codes to include the newly defined 308 2. adding the referrer source header as input to the fetch algorithm Non-substantive changes include: 1. Clarified text defining 5.1, Access-Control-Origin allow header to read: the value of the Origin request header, *, or null 2. Updated certificates differ reason for algorithm abort to certificate errors 3. Replaced ambient authority with user credentials sent with cross-origin requests 4. Replaced a number of instances of server with more consistent usage of resource 5. Updated language slightly about OWS in header value definitions in HTTP/1.1 spec 6. Removed reference in security considerations to Origin header as a credential, as it is explicitly defined as not being a credential 7. Deleted paragraph in security considerations section on forwarding attacks as on further consideration it is not a genuine concern 8. Removed language about validating data in the security considerations section comparing CORS to JSONP 9. Removed safe and idempotent language in security considerations and replaced with significance other than retrieval 10. Changed implicit credentials language to user credentials automatically attached to the request by the user agent 11. Updated language in security considerations on path-distinguished application principals vs. origin-distinguished principals 12. Merged updated thanks and acknowledgements from WHATWG version 13. Removed language about multiple origins in security considerations as that is now forbidden by the redirect steps 14. Added a non-normative Implementation Considerations as Section 6.4 under the Resource Processing Model with the following text: Resources that wish to enable themselves to be shared with multiple codeOrigins/code but do not respond uniformly with code*/code must in practice generate the codeAccess-Control-Allow-Origin/code header dynamically in response to every request they wish to allow. As a consequence, authors of such resources should send a codeVary: Origin/code HTTP header or provide other appropriate control directives to prevent caching of such responses, which may be inaccurate if re-used across-origins. Thank you, Brad Hill WebAppSec WG Co-Chair
FileSystem compromise spec
As discussed at TPAC, there's little support for the current FileSystem API, but some support for a new API, and I promised to put forth a compromise proposal. In order to do that, I'd like to hear 1) what kinds of changes would make it more popular; 2) who I'm trying to convince. There are a number of folks who have said that they're not interested in a FileSystem API at all, so I'd rather concentrate my efforts on those with skin in the game. So far I've been hearing: * It's too complicated. A number of the methods aren't absolutely necessary if the user's willing to do a bit more work, so they should be dropped. * Even for what functionality we keep, it could be simpler. * The synchronous [worker-only] interface is superfluous. It's not necessary for 1.0, and it's a lot of extra implementation work. * It's designed to handle both the sandbox and the outside-the-sandbox use cases. For folks interested in just the sandbox and no future expansions, that seems like wasted effort, and a sandbox-only API could be simpler. It's not clear to me that there is anyone interested in just the sandbox and no future expansions, but if there is, please speak up. I've certainly heard from folks with the opposite goal. Does that sum it up? I'd like to hear from folks who are interested, but not in the current spec. Thanks, Eric
[PE] Start working on Progress Events
Hi all, I came to start working on Progress Events spec to move it towards REC. Because the spec is already a CR, I am planning to focus on satisfying the exit criteria to ship it. Please see inline comments and questions. Jungkee From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Thursday, November 15, 2012 10:51 PM On 11/15/12 3:11 AM, ext Jungkee Song wrote: Hi Art, Charles and Anne, At this stage, it will be of great help if you give me some comments on any issues, concerns, expected actions, etc. Since the spec is already a CR (with exit criteria http://www.w3.org/TR/2011/CR-progress-events-20110922/#crec), some questions ... * Are there any significant differences between the CR and Anne's WHATWG spec? If yes, what are they and should they postponed to v.next? As I've gone through it, there's no significant change. There are only a few minor ones including term (octets to bytes) and xref (to event definition) things. * What is the implementation status of the CR? Are there at least two independent implementations that can be tested? This is my question at the moment. Can anyone share implementation data for this spec? * Are the tests in the test suite sufficient to test the CR http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/? If not, what is the plan to fill the gaps? I will scope it out. BTW, I have a relatively strong preference to have this conversation on public-webapps so please feel free to copy any part of what I say above to that list. -Thanks, Art
