Re: [whatwg] Declarative web worker creation and communication?
On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews freda...@live.com wrote: 1. Declarative web worker creation. Feedback and suggestions for appropriate markup to declare web workers would be appreciated. The use case is a document with JS disabled or restricted so that it can not create web workers, yet still wants to create web workers to process page input and to update the document. Can you give some concrete examples where JS is disabled or restricted? -- Simon Pieters Opera Software
Re: [whatwg] URL: file: URLs
On Tue, Oct 30, 2012 at 10:46 PM, Simon Pieters sim...@opera.com wrote: My knee-jerk reaction is the same as Anne's; why not do this for all platforms? I now made it so that for URL's whose scheme is file, [a-Z] followed by either : or | as first path segment becomes [a-Z] followed by :. I also made it so that for URL's whose scheme is file, [a-Z] followed by either : or | as host get an empty host and use that as first path segment instead (applying the rules before, ending up with | converted to :). http://url.spec.whatwg.org/ (see file host state and relative path state, or search for file throughout) Cheers, -- http://annevankesteren.nl/
Re: [whatwg] Declarative web worker creation and communication?
Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP request - this might help support backwards compatibility or allow content to degrade gracefully if web workers are not supported. For example, if a form is declared to be submitted to a web work via a message post then it could also have a backup 'method' and 'action' to make a HTTP request to a server. The best path for supporting DOM updates from received web worker messages is not so clear to me. Perhaps an iframe, or a more general element extension that allows an innerHTML update to be received from web worker messages and perhaps from server sent events. cheers Fred To: wha...@whatwg.org; freda...@live.com ... On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews freda...@live.com wrote: ... 1. Declarative web worker creation. Feedback and suggestions for appropriate markup to declare web workers would be appreciated. The use case is a document with JS disabled or restricted so that it can not create web workers, yet still wants to create web workers to process page input and to update the document. Can you give some concrete examples where JS is disabled or restricted? -- Simon Pieters Opera Software
Re: [whatwg] Declarative web worker creation and communication?
On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews freda...@live.com wrote: Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. I guess I'm not convinced that a web worker (which has an architecture designed for asynchronous background processing) is the right vehicle for your shared context idea. My concern is that you're looking at the limited APIs currently available to web workers, and concluding that this makes them similar to shared contexts, when in reality the primary driver behind the limited worker APIs is thread safety, not UA privacy. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP request - this might help support backwards compatibility or allow content to degrade gracefully if web workers are not supported. For example, if a form is declared to be submitted to a web work via a message post then it could also have a backup 'method' and 'action' to make a HTTP request to a server. The best path for supporting DOM updates from received web worker messages is not so clear to me. Perhaps an iframe, or a more general element extension that allows an innerHTML update to be received from web worker messages and perhaps from server sent events. cheers Fred To: wha...@whatwg.org; freda...@live.com ... On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews freda...@live.com wrote: ... 1. Declarative web worker creation. Feedback and suggestions for appropriate markup to declare web workers would be appreciated. The use case is a document with JS disabled or restricted so that it can not create web workers, yet still wants to create web workers to process page input and to update the document. Can you give some concrete examples where JS is disabled or restricted? -- Simon Pieters Opera Software
[whatwg] [mimesniff] Review requested on MIME Sniffing Standard
Hey all, As you might have heard, I have taken over editorship of the MIME Sniffing Standard from Adam Barth. As a first step in my editorship, I have taken the opportunity to rewrite the document in a more procedural and modular way (IMO). The content and meaning itself is not supposed to have changed, and I need your help to verify that that is the case: http://mimesniff.spec.whatwg.org/ In addition, this now means that I am open to hearing your suggestions about how to improve the document beyond its current (i.e. former) semantics. You can file bugs here: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWGcomponent=MIME As this document was originally an IETF document, there are also old issues here: http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff It's not clear to me which of those remain outstanding on the current version of the document, and it would be helpful to me if individuals with a vested interest in them could migrate them to Bugzilla (with updated descriptions that reflect the current state of the document). This will ensure that I address them in a timely manner. Also, it would be helpful if you could mark them as blocking the general bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19746 And if you want to follow the commits as they happen, you can follow @mimesniff on Twitter: https://twitter.com/mimesniff Thanks! Gordon -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] Declarative web worker creation and communication?
Hi Andrew, Thank you for the feedback. The PUA 'shared context' will likely need to be a distinct web worker variant to cater for any required restrictions and also to ensure it does not entangle its specific requirements with other innovations to web workers. However the message API may be reusable, and trying to avoid gratuitous differences seems a worthy goal. Some concerns (lack of understanding) I have with the Web Worker spec. at: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html 9.2.3 The worker's lifetime ... Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. Does this mean that the Document object of the caller is made available to be web worker? I can't see an interface to it? 9.2.4 Processing model ... 5. A new script is now created, as follows. ... Set the script's browsing context to owner browsing context. ... Set the script's document to owner document. There does not appear to be an API to actually effect the owner browsing context or document? Is this just laying a foundation for future work? Are web workers expected to someday be able to cause navigation of the creators browsing context etc? 9.3 APIs available to workers ... The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification. Are there plans to allow web workers access to the DOM of their creator? Does this apply to documents created by the web worker, such as via XHR? Looking at the source code for some implementations will help clarify the current state, but it would also be of interest to know of planned web workers extensions? cheers Fred Date: Mon, 5 Nov 2012 10:41:00 +0100 From: atwil...@google.com To: freda...@live.com CC: wha...@whatwg.org; sim...@opera.com Subject: Re: [whatwg] Declarative web worker creation and communication? On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews freda...@live.com wrote: Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. I guess I'm not convinced that a web worker (which has an architecture designed for asynchronous background processing) is the right vehicle for your shared context idea. My concern is that you're looking at the limited APIs currently available to web workers, and concluding that this makes them similar to shared contexts, when in reality the primary driver behind the limited worker APIs is thread safety, not UA privacy. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP request - this might help support backwards compatibility or allow content to degrade gracefully if web workers are not supported. For example, if a form is declared to be submitted to a web work via a message post then it could also have a backup 'method' and 'action' to make a HTTP request to a server. The best path for supporting DOM updates from received web worker messages is not so clear to me. Perhaps an iframe, or a more general element extension that allows an innerHTML update to be received from web worker messages and perhaps from server sent events. cheers Fred To: wha...@whatwg.org; freda...@live.com ... On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews freda...@live.com wrote: ... 1. Declarative web worker creation. Feedback and suggestions for appropriate markup to declare web workers would be appreciated. The use case is a document with JS disabled or restricted so that it can not create web workers, yet still wants to create web workers to process page input and to update the document. Can you give some concrete examples where JS is disabled or restricted? -- Simon Pieters Opera Software
Re: [whatwg] Declarative web worker creation and communication?
On Tue, Nov 6, 2012 at 2:21 AM, Fred Andrews freda...@live.com wrote: Hi Andrew, Thank you for the feedback. The PUA 'shared context' will likely need to be a distinct web worker variant to cater for any required restrictions and also to ensure it does not entangle its specific requirements with other innovations to web workers. However the message API may be reusable, and trying to avoid gratuitous differences seems a worthy goal. I'd encourage you to look at the MessagePort APIs, if you have not already. Agreed that using messages to pass data between different contexts is a powerful mechanism. Some concerns (lack of understanding) I have with the Web Worker spec. at: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html 9.2.3 The worker's lifetime ... Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. Does this mean that the Document object of the caller is made available to be web worker? I can't see an interface to it? The Document is not made available - really, this section is just describing when it's safe to shutdown a worker (which can be quite complex when you have workers that create other workers, and shared workers). 9.2.4 Processing model ... 5. A new script is now created, as follows. ... Set the script's browsing context to owner browsing context. ... Set the script's document to owner document. There does not appear to be an API to actually effect the owner browsing context or document? Is this just laying a foundation for future work? Are web workers expected to someday be able to cause navigation of the creators browsing context etc? I don't think the plan is to allow navigation of the browsing context - I've always understood this section to mean that the worker shares a browsing context with the creating document for the purposes of cross-site XHR access, cookies, etc. I'm not at all sure what set the script's document means, but I'm not particularly fluent in spec-speak - I'm sure someone else on the list can explain the ramifications of that. 9.3 APIs available to workers ... The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification. Are there plans to allow web workers access to the DOM of their creator? There have been discussions about some aspects of this (you can check the list archives - some people have wanted to be able to pass portions of the DOM back and forth to workers) but fundamentally the DOM provides a non-thread-safe API so I don't see how this would ever be possible. Does this apply to documents created by the web worker, such as via XHR? Looking at the source code for some implementations will help clarify the current state, but it would also be of interest to know of planned web workers extensions? I know there has been discussion about more efficient ways to pass/share data between documents and workers - this would enable things like background rendering to canvas, etc. Some of the discussion has happened on the W3C lists (such as http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0744.html) so I'd suggest looking at those archives also. cheers Fred Date: Mon, 5 Nov 2012 10:41:00 +0100 From: atwil...@google.com To: freda...@live.com CC: wha...@whatwg.org; sim...@opera.com Subject: Re: [whatwg] Declarative web worker creation and communication? On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews freda...@live.com wrote: Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. I guess I'm not convinced that a web worker (which has an architecture designed for asynchronous background processing) is the right vehicle for your shared context idea. My concern is that you're looking at the limited APIs currently available to web workers, and concluding that this makes them similar to shared contexts, when in reality the primary driver behind the limited worker APIs is thread safety, not UA privacy. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP
