Re: Blob URL Origin
On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote: For blob URLs (and prolly filesystem and indexeddb) we put the origin in the URL and define a way to extract it again so new URL(blob).origin does the right thing. Yup. For fetching blob URLs (and prolly filesystem and indexeddb) we effectively act as if the request's mode was same-origin. Allowing tainted cross-origin requests would complicate UUID (for the UA) and memory (for the page) management in a multiprocess environment. Hmm.. I think that is effectively it yes. I.e. even though img says that it wants to permit cross-origin loads, we'd override that if the fetch is for a blob: URL and only permit same-origin loads. Is that what you mean? / Jonas
Data URL Origin (Was: Blob URL Origin)
On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote: How do we deal with data URLs? Obviously you can always get a resource out of them. But when should the response of fetching one be tainted and when should it not be? And there's a somewhat similar question for about URLs. Although only about:blank results in something per the specification at the moment. My proposal is something like this: * Add a new flag to the fetch algorithm allow inheriting origin * The default for this new flag is false * If the flag is set to false, the origin of the URL is a unique identifier. * When the origin is a unique identifier, it would not match any other origin and so responses would always be tainted. * If the flag is true, then the origin of the URL is equal to that of the page that initiated the load. * When the origin of the URL is inherited, it would always match the origin of the caller, and so responses would never be tainted. * I don't know what URL(data).origin should return. * Make APIs explicitly opt in to setting the allow inheriting origin flag to true based on whatever policies that we decide. So for example we could make img always set the allow inheriting origin flag to true. And for iframes the flag would only be true if some iframe allowinheritingoriginfordataurlsplease attribute was set. And then it would still only be set for the initial load. If the iframe navigated (through a link or through setting window.location) the flag would be set to falls. For `new Worker(...)` I'm not sure what would be web compatible. I'd prefer if the flag was set to false by default, but that the page could use some explicit syntax (similar to the iframe) to opt in to allowing inheriting. / Jonas
[Bug 24288] [Shadow]: Revert shadow element as a function call feature.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Hayato Ito hay...@chromium.org --- Looks outdated. Let me close this issue. If you feel to re-open this, please file a new issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24316] [Shadow]: implement :ancestor and change :host behavior
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24316 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|dglaz...@chromium.org |hay...@chromium.org --- Comment #3 from Hayato Ito hay...@chromium.org --- This should have been addressed in css-scoping spec. Let me close. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25915] New: Cross-origin requests
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915 Bug ID: 25915 Summary: Cross-origin requests Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org I'm not sure why http://dev.w3.org/2006/webapi/FileAPI/#cross-origin-requests-on-blobs is included in this specification. That should follow from URL / Fetch, no? Duplicate requirements are bad. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25914] New: No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914 Bug ID: 25914 Summary: No definition of parsing blob's scheme data Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org We'd need such a definition and it needs to return the origin and blob ID. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Bug 25376] - Web Components won't integrate without much testing
Yes, Tab, your below summary is correct. First, let me (again) stress the fact that my intention is NOT to give a critical judgment on Web Components. Many ways lead to Rome. Web Components is one way of implementing discrete components into a web page. And the HTML IFRAME element is just another. I wouldn't want to keep anyone from walking his way as long as I'm left to go mine. My sole intention (still) is to have the SEAMLESS attribute of the HTML IFRAME element amended for the given reasons. So I'm examining Web Components from this single perspective here. I'm not targeting on improving Web Components; I'm also not targeting to discuss Web Components when used in XML here, just HTML. So my wording here will not be a constructive one but one comparing advantages/disadvantages of one approach compared to the other within this constrained environment. So now here's an elaboration to my list: Web Components require a plethora of additional browser features and behaviours. Everything Web Components promise to provide already exists (e. g. by using HTML IFRAME elements). So any effort put into developing or using Web Components is a wasted amount of time because it'd just recreate existing features while bloating browser engine code, making the engine more sluggish and error prone. Moreover, Web Components put a hard load on client engines, requiring them to support a whole bunch of features flawlessly, making it a hell for programmers to test their websites against different browsers. Whereas HTML IFRAME elements just display arbitrarily simple HTML pages served by a single web server. Any server code displaying static data can be assumed to display the data correctly on all browsers when successfully tested once. Web Components require loads of additional HTML, CSS and client script code for displaying content. Let's start with Shadow DOM: The whole one hundred thousand ++ text character specification adds a heavy burden to the client's script engine. - And its implementation is completely unnecessary while using HTML IFRAME elements or anything else than Web Components. Custom Elements: It's unnecessary to have Custom Elements (please note the explicit capitalization here) to declaratively define complex components if you need ECMA script to get them to life. Just create an ECMA script class doing all the work to decorate dedicated elements and you're done. Custom Elements just add redundancy. CSS: I'm just going to name a few additional CSS constructs here: @host, :scope, ::distributed -- While IFRAME content can reuse a website's CSS, Web Components require their discrete CSS. IFRAME content can be displayed as a web page on their own, Web Components can't. End of Story. Web Components install complex concepts (e.g. decorators) by introducing unique, complex, opaque behaviours, abandoning the pure nature of presentation. As I've read on one of the replies I've received, decorators are deprecated by now, so I won't further elaborate on them. Still, Shadow DOM remains being an unnecessary and complex design, compared to using HTML IFRAME elements. Web Components require special script event handling, so existing script code cannot be reused. Decorators, Custom Elements and Shadow DOM require additional events for them to function properly. HTML IFRAME elements just use the existing events - if there is any event required at all to display their content. No further ado or implementation required when using HTML IFRAME elements. Web Components require special CSS handling, so existing CSS cannot be reused. Please refer to my above elaboration on CSS for details. Web Components unnecessarily introduce a new clumsy “custom”, or “undefined” element, leaving the path of presentation. Custom Elements could as easy be achieved using CSS classes, and querySelector() in ECMA Script. Please refer to my above elaboration on Custom Elements for details. The W3C DOM MutationObserver specification already provides functionality equivalent to insertedCallback()/readyCallback()/removeCallback(). Please refer to the W3C DOM MutationObserver specification for details. Cheers, Axel Dahmen -- Tab Atkins Jr. schrieb im Newsbeitrag news:caawbydcv6mrc2xx9xiupeagv7-r1dxae7yqwsnwg5lgb1-t...@mail.gmail.com... On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen bril...@hotmail.com wrote: I got redirected here from a HTML5 discussion on an IFrame's SEAMLESS attribute: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376 Ian Hickson suggested to publish my findings here so the Web Components team may consider to re-evaluate the draft and probably amending the spec. Could you post your findings here? Digging through the bug thread, it appears you might be
Fetch API
The plan is to implement and ship this fairly soon, so I figured I'd ask for review now, while we're still drafting the text: http://fetch.spec.whatwg.org/#fetch-api In particular I'd like feedback on the design of Request and Response classes, and the fetch() method. -- http://annevankesteren.nl/
Re: Fetch API
http://fetch.spec.whatwg.org/#dom-request Add steps to set client and context? http://fetch.spec.whatwg.org/#cors-preflight-fetch-0 Add steps to set client and context? http://fetch.spec.whatwg.org/#concept-legacy-fetch http://fetch.spec.whatwg.org/#concept-legacy-potentially-cors-enabled-fetch Steps to set url, client and context are missing here too. But not worth updating this section anymore? Termination reason is not handled intentionally (only supposed to be used by XHR's functionalities and nothing would be introduced for Fetch API?)? The promise is rejected with a TypeError which seems inconsistent with XHR. Is this intentional?
Re: Fetch API
On May 29, 2014 at 9:02:35 AM, Anne van Kesteren (ann...@annevk.nl) wrote:
The plan is to implement and ship this fairly soon, so I figured I'd
ask for review now, while we're still drafting the text:
http://fetch.spec.whatwg.org/#fetch-api
In particular I'd like feedback on the design of Request and Response
classes, and the fetch() method.
Having these interfaces exposed is going to be great!
Few small things that stood out for me...
enum RequestMode { same-origin, tainted cross-origin, CORS,
CORS-with-forced-preflight };
I think these are badly named (even though they use the names used in HTML and
Fetch). It's going to be annoying to type these out for developers.
I would change them to:
enum RequestMode { same-origin, cors, cors-tainted, cors-preflight };
And then map them to the appropriate concept in the specs.
enum RequestOmitCredentialsMode { always, CORS, never };
The item CORS here is not self evident (unlike always/never modes). Can
you find a better word?
Re: Fetch API
On Thu, May 29, 2014 at 4:58 PM, Marcos mar...@marcosc.com wrote:
enum RequestMode { same-origin, tainted cross-origin, CORS,
CORS-with-forced-preflight };
I think these are badly named (even though they use the names used in HTML
and Fetch). It's going to be annoying to type these out for developers.
I would change them to:
enum RequestMode { same-origin, cors, cors-tainted, cors-preflight
};
I like those better.
We want consistency with lowercasing or uppercasing cors/CORS in enums,
though.
--tobie
Re: Data URL Origin (Was: Blob URL Origin)
On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking jo...@sicking.cc wrote: My proposal is something like this: Thanks! * Add a new flag to the fetch algorithm allow inheriting origin same-origin data URL flag? Ideally we don't do another data URL mistake. * The default for this new flag is false * If the flag is set to false, the origin of the URL is a unique identifier. * When the origin is a unique identifier, it would not match any other origin and so responses would always be tainted. * If the flag is true, then the origin of the URL is equal to that of the page that initiated the load. * When the origin of the URL is inherited, it would always match the origin of the caller, and so responses would never be tainted. This does not clarify what happens if you end up at a data URL as a result of a redirect. If the redirect is cross-origin you'll end up tainted. If it's CORS you get a network error. But if it's same-origin that's fair game? * I don't know what URL(data).origin should return. Probably just null. I think we should make it about the origin of the request, not the URL. * Make APIs explicitly opt in to setting the allow inheriting origin flag to true based on whatever policies that we decide. So for example we could make img always set the allow inheriting origin flag to true. And for XMLHttpRequest? We decided a while back we wanted data URLs to work there. And for iframes the flag would only be true if some iframe allowinheritingoriginfordataurlsplease attribute was set. And then it would still only be set for the initial load. If the iframe navigated (through a link or through setting window.location) the flag would be set to falls. Seems fair. For `new Worker(...)` I'm not sure what would be web compatible. I'd prefer if the flag was set to false by default, but that the page could use some explicit syntax (similar to the iframe) to opt in to allowing inheriting. Given that workers execute script in a fairly contained way, it might be okay? -- http://annevankesteren.nl/
Re: [Bug 25376] - Web Components won't integrate without much testing
Excuse my unsolicited comment here, being new to the webapps mailing list, but here is my two cents feedback as a web developer... I think the idea behind Web Components is good regardless of the flaws on the spec. The idea is to create a standard built into the browser that will allow library--and framework--free, mass distribution of reusable components. Today, we can build components, without half broken stuff like iframes, using JS/CSS isolation patterns. So the issue IMO is not about doing something we couldn't do already, but standardizing the way things are done so that we can have the ability to build and share components without dependency on a certain library (e.g. jQuery) or framework (e.g. Angular) Marc On Thu, May 29, 2014 at 4:05 AM, Axel Dahmen bril...@hotmail.com wrote: Yes, Tab, your below summary is correct. First, let me (again) stress the fact that my intention is NOT to give a critical judgment on Web Components. Many ways lead to Rome. Web Components is one way of implementing discrete components into a web page. And the HTML IFRAME element is just another. I wouldn't want to keep anyone from walking his way as long as I'm left to go mine. My sole intention (still) is to have the SEAMLESS attribute of the HTML IFRAME element amended for the given reasons. So I'm examining Web Components from this single perspective here. I'm not targeting on improving Web Components; I'm also not targeting to discuss Web Components when used in XML here, just HTML. So my wording here will not be a constructive one but one comparing advantages/disadvantages of one approach compared to the other within this constrained environment. So now here's an elaboration to my list: Web Components require a plethora of additional browser features and behaviours. Everything Web Components promise to provide already exists (e. g. by using HTML IFRAME elements). So any effort put into developing or using Web Components is a wasted amount of time because it'd just recreate existing features while bloating browser engine code, making the engine more sluggish and error prone. Moreover, Web Components put a hard load on client engines, requiring them to support a whole bunch of features flawlessly, making it a hell for programmers to test their websites against different browsers. Whereas HTML IFRAME elements just display arbitrarily simple HTML pages served by a single web server. Any server code displaying static data can be assumed to display the data correctly on all browsers when successfully tested once. Web Components require loads of additional HTML, CSS and client script code for displaying content. Let's start with Shadow DOM: The whole one hundred thousand ++ text character specification adds a heavy burden to the client's script engine. - And its implementation is completely unnecessary while using HTML IFRAME elements or anything else than Web Components. Custom Elements: It's unnecessary to have Custom Elements (please note the explicit capitalization here) to declaratively define complex components if you need ECMA script to get them to life. Just create an ECMA script class doing all the work to decorate dedicated elements and you're done. Custom Elements just add redundancy. CSS: I'm just going to name a few additional CSS constructs here: @host, :scope, ::distributed -- While IFRAME content can reuse a website's CSS, Web Components require their discrete CSS. IFRAME content can be displayed as a web page on their own, Web Components can't. End of Story. Web Components install complex concepts (e.g. decorators) by introducing unique, complex, opaque behaviours, abandoning the pure nature of presentation. As I've read on one of the replies I've received, decorators are deprecated by now, so I won't further elaborate on them. Still, Shadow DOM remains being an unnecessary and complex design, compared to using HTML IFRAME elements. Web Components require special script event handling, so existing script code cannot be reused. Decorators, Custom Elements and Shadow DOM require additional events for them to function properly. HTML IFRAME elements just use the existing events - if there is any event required at all to display their content. No further ado or implementation required when using HTML IFRAME elements. Web Components require special CSS handling, so existing CSS cannot be reused. Please refer to my above elaboration on CSS for details. Web Components unnecessarily introduce a new clumsy “custom”, or “undefined” element, leaving the path of presentation. Custom Elements could as easy be achieved using CSS classes, and querySelector() in ECMA Script. Please refer to my above elaboration on Custom Elements for details.
[Bug 25916] New: [Explainer]: Custom pseudo elements are still used in the examples.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25916 Bug ID: 25916 Summary: [Explainer]: Custom pseudo elements are still used in the examples. Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dglaz...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14949 They are gone and have been replaced with ::shadow and /deep/. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Fetch API
On Thu, May 29, 2014 at 8:10 AM, Tobie Langel tobie.lan...@gmail.com wrote:
On Thu, May 29, 2014 at 4:58 PM, Marcos mar...@marcosc.com wrote:
enum RequestMode { same-origin, tainted cross-origin, CORS,
CORS-with-forced-preflight };
I think these are badly named (even though they use the names used in HTML
and Fetch). It's going to be annoying to type these out for developers.
I would change them to:
enum RequestMode { same-origin, cors, cors-tainted, cors-preflight
};
I like those better.
We want consistency with lowercasing or uppercasing cors/CORS in enums,
though.
Yes. Lowercasing always, please.
~TJ
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
Without default text input, the current proposal for contentEditable=minimal is essentially just enabling cursors (drawing them, dispatching events, performing default actions). Rather than calling the mode minimal, which is ill-defined, why not explicitly call it what it is: cursor-only? Or, have contentEditable take a list of features to turn enable: contentEditable=enable-cursors enable-CommandEvents. Or, rather than tying this concept to contentEditable, with all the assumptions and complications that brings up, why not expose this building block as a completely separate attribute? On Mon, May 26, 2014 at 1:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue yo...@chromium.org wrote: Range.style is cool idea! I assume Range.detach() removes styles added Range.style. detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach To implement text composition with this, I would like to have wave underline, dotted underline, thick underline etc. Range.prototype.style seems complex in the context of overlapping ranges and such. Suddenly you're no longer applying CSS to a tree. -- http://annevankesteren.nl/
Re: Data URL Origin (Was: Blob URL Origin)
On Thu, May 29, 2014 at 9:21 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 29, 2014 at 9:06 AM, Jonas Sicking jo...@sicking.cc wrote: * The default for this new flag is false * If the flag is set to false, the origin of the URL is a unique identifier. * When the origin is a unique identifier, it would not match any other origin and so responses would always be tainted. * If the flag is true, then the origin of the URL is equal to that of the page that initiated the load. * When the origin of the URL is inherited, it would always match the origin of the caller, and so responses would never be tainted. This does not clarify what happens if you end up at a data URL as a result of a redirect. If the redirect is cross-origin you'll end up tainted. If it's CORS you get a network error. But if it's same-origin that's fair game? For something like an iframe load I think the safe thing is to always clear the flag when a redirect happens. I.e. if someone does iframe src=http://example.com/a; allowinheritingoriginfordataurlsplease and example.com redirects to a data URL, we would have all sorts of messy questions if we allowed the flag to stay set an the origin to be inherited: * Should it be inherited from the owner of the iframe, who set the allowinheritingoriginfordataurlsplease attribute, or from example.com who is the one that generated the data URL. We don't want example.com to get XSSed either. * What if the owner of the iframe hadn't thought about redirects to data URLs and just checked the src URL for data: and verified that it didn't contain any bad stuff? Redirecting to a data URL feels like a very edge-casy thing. So lets keep it simple and safe rather than worry about cramming more features in. * I don't know what URL(data).origin should return. Probably just null. Given that the effective origin depends on which API you pass the data-url to, I agree that trying to return a real origin here is never going to be sensible. I don't know if returning null is the way to go, or if returning `undefined` is. I guess I don't have a strong opinion. * Make APIs explicitly opt in to setting the allow inheriting origin flag to true based on whatever policies that we decide. So for example we could make img always set the allow inheriting origin flag to true. And for XMLHttpRequest? We decided a while back we wanted data URLs to work there. I don't feel strongly. For `new Worker(...)` I'm not sure what would be web compatible. I'd prefer if the flag was set to false by default, but that the page could use some explicit syntax (similar to the iframe) to opt in to allowing inheriting. Given that workers execute script in a fairly contained way, it might be okay? Worker scripts aren't going to be very contained as we add more APIs to workers. They can already read any data from the server (through XHR) and much local data (through IDB). I'd definitely want them not to inherit the origin, the question is if that's web compatible at this point. Maybe we can allow them to execute but as a sandboxed origin? / Jonas
