Re: Fixing appcache: a proposal to get us started
I'm writing a web application that uses the AppCache API for offline browsing. But I'm also using the Audio API to play back-ground music and a few audio effects. For audio support in different browsers I'm delivering each sound/music in two different file formats: OGG and MP3. The problem is regarding the cache manifest file. If we add all audio files (MP3 and OGG) in the cache manifest file, all browsers will cache all files. Including the unsupported ones. So, we end up with a huge storage requirement. Which is really bad if you are on a 3G connection for example. To prevent browser caching unsupported resources, the best approach I've found was to split the manifest file. This way we can tell browsers that sopport OGG files to cache only OGG files, and do tha same for other formats like MP3. But it is a ugly solution. Now I have two manifest cache files, one with all OGG files listed (ogg.appcache) and the other one with the MP3 files (mp3.appcache). Good luck guys! Best regards, Emerson Estrella
Re: File API: why is there same-origin restriction on blob URLs?
On Wed, Mar 27, 2013 at 12:30 AM, Jonas Sicking jo...@sicking.cc wrote: I think the original concern was that implementations might not be able to reliably generate unguessable URLs. Potentially that's something that we could require though. Yeah, think so. However we'd still need to nail down what the new behavior should be. Should it behave like data: URLs? The main advantage of those is that implementations still don't agree on how those should behave. I'm not sure what that means. I can easily postMessage() a data URL to an iframe of another origin and that iframe can then load the data URL in an img and have it work (obviously, as the data URL is self-contained). -- http://annevankesteren.nl/
RfC: 2nd LCWD of HTML Media Capture; deadline 19 April
The DAPWG asked WebApps to submit comments on LC#2 of HTML Media Capture: http://www.w3.org/TR/2013/WD-html-media-capture-20130326/ Individual WG members are encouraged to provide individual feedback. If anyone in WebApps wants to propose an official WG response, please do so ASAP, in reply to this email so the WebApps WG can discuss it. Comments should be sent to public-device-a...@w3.org by April 19. -Thanks, AB
[webcomponents] style hooks for custom elements
Hey all, are style hooks still part of any spec relating to web components? Someone pointed out an older demo mentioning them (http://html5-demos.appspot.com/static/webcomponents/index.html) and I can't seem to find mention of them any more. (I like the idea, although the syntax from the demo is truly dire if you value not-designed-for-programmers-by-programmers syntax... =x) - Mike
Re: [webcomponents] style hooks for custom elements
It's in Shadow DOM. These are the droids you're looking for: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-301/ On Wed, Mar 27, 2013 at 9:52 AM, Mike Kamermans niho...@gmail.com wrote: Hey all, are style hooks still part of any spec relating to web components? Someone pointed out an older demo mentioning them (http://html5-demos.appspot.com/static/webcomponents/index.html) and I can't seem to find mention of them any more. (I like the idea, although the syntax from the demo is truly dire if you value not-designed-for-programmers-by-programmers syntax... =x) - Mike
Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM
Scott Miles wrote: This is a thorny problem, but my initial reaction is that you threaded the needle appropriately. I don't see how we avoid some lossiness in this situation. Note that if you're using offsetWith/Height/Top/Bottom you already lose, because they return integers. I think we should be doing what we can to discourage use of these broken APIs, for what it's worth, instead of worrying how we can extend their already-incorrect behavior to cover more cases well. -Boris
Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM
On 3/27/13 2:02 PM, Boris Zbarsky wrote: Note that if you're using offsetWith/Height/Top/Bottom you already lose, s/Bottom/Left/, of course. -Boris
Re: [webcomponents]: Naming the Baby
The problem I'm trying to get at, is that while a 'custom element' has a chance of meeting your 1-6 criterion, the thing on the other end of link rel='to-be-named'... has no such qualifications. As designed, the target of this link is basically arbitrary HTML. This is why I'm struggling with link rel='component' ... Scott On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.comwrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.com wrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.com wrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.comwrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: [webcomponents]: Naming the Baby
The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.comwrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.com wrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.com wrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.comwrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: File API: why is there same-origin restriction on blob URLs?
On Wed, Mar 27, 2013 at 2:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
However we'd still need to nail down what the new behavior should be.
Should it behave like data: URLs? The main advantage of those is that
implementations still don't agree on how those should behave.
I'm not sure what that means. I can easily postMessage() a data URL to
an iframe of another origin and that iframe can then load the data
URL in an img and have it work (obviously, as the data URL is
self-contained).
The question is, what happens if you do:
iframe src=blob:... id=iframe
iframe.onload = function() {
iframe.contentWindow.document; // throws or not?
}
What if the blob-url was created in another origin, does that make a difference?
For data: URIs different browsers behave differently in the example above.
Same question applies if you create an img src=blob:... and then
drawImage it into a canvas, does the canvas get tainted? Again, I
think different browsers do different things for data: URLs here.
/ Jonas
Re: [webcomponents]: Naming the Baby
Changing my vote to 'web import'. I think that works just as well, if not better, than 'include'. On Wed, Mar 27, 2013 at 11:50 AM, Eric Bidelman ericbidel...@google.comwrote: My association for HTML links is a. Seems too confusing. FWIW, I conducted a small survey to see what the broader community's mental model of this is: https://plus.google.com/u/0/118075919496626375791/posts/3GYkmd4UqLC. Got about 42 responses; the top 3 being: 1. Web Import link rel=import - 14 votes 2. Web Package link rel=package - 6 votes 3. Web Include link rel=include - 5 votes Do we foresee link rel=?? loading other types of resources in the future, not just .html? I like the idea of some sort of import or include, especially seeing that other web developers are aligned with this lingo. My 0$.02 On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell sorv...@google.com wrote: The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.comwrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.comwrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect
Re: [webcomponents]: Naming the Baby
On Mar 27, 2013 2:27 PM, Scott Miles sjmi...@google.com wrote: The problem I'm trying to get at, is that while a 'custom element' has a chance of meeting your 1-6 criterion, the thing on the other end of link rel='to-be-named'... has no such qualifications. As designed, the target of this link is basically arbitrary HTML. This is why I'm struggling with link rel='component' ... Scott On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.com wrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.com wrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.com wrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG This is why I suggested prototype.. It might be an arbitrary doc, but it's intent really is to serve as kinda a way to get things you intend to insert into your page may or not be components to the definition... I saw no uptake, but that was the rationale: it's hard to not use widget or component.
Re: File API: why is there same-origin restriction on blob URLs?
On Mar 26, 2013, at 8:30 PM, Jonas Sicking wrote: On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren ann...@annevk.nl wrote: Hi, Is there any particular reason why we restrict blob URLs to the same origin as the script that created them? In effect they are pretty much like capability URLs (containing an unguessable token). So if someone decides to share one, that should be okay I think. This would be useful in the context of sandboxed code (iframe sandbox) and presumably elsewhere too. I think the original concern was that implementations might not be able to reliably generate unguessable URLs. Potentially that's something that we could require though. We already require this -- opaque strings should be globally unique. However we'd still need to nail down what the new behavior should be. Should it behave like data: URLs? The main advantage of those is that implementations still don't agree on how those should behave. They're very different than data URLs. What's a good use case for making them cross-origin, that isn't addressed by use of postMessage? -- A*
Re: File API for Review
On Mar 25, 2013, at 1:52 PM, Anne van Kesteren wrote: On Mon, Mar 25, 2013 at 5:45 PM, Arun Ranganathan aranganat...@mozilla.com wrote: So just to be clear, do you think we should remove 500-style responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs? I'm ok with that if so. Yeah, I would prefer if we used network error consistently throughout the platform for something went wrong with this URL rather than try to re-imagine a non-HTTP situation in terms of HTTP. Because it gives nicer to work with events and such out of the box and because it makes exposing more detailed information in the future easier. Done. http://dev.w3.org/2006/webapi/FileAPI/#NetworkError -- A*
Re: [webcomponents]: Naming the Baby
Err, yeah, thanks for pointing that out. I also like import or imports. This makes sense given that the rel attribute is described as defining the relationship between the resource being loaded and the document (likely outdated spec: http://www.w3.org/TR/html401/struct/links.html#adef-rel). On Wed, Mar 27, 2013 at 11:50 AM, Eric Bidelman ericbidel...@google.comwrote: My association for HTML links is a. Seems too confusing. FWIW, I conducted a small survey to see what the broader community's mental model of this is: https://plus.google.com/u/0/118075919496626375791/posts/3GYkmd4UqLC. Got about 42 responses; the top 3 being: 1. Web Import link rel=import - 14 votes 2. Web Package link rel=package - 6 votes 3. Web Include link rel=include - 5 votes Do we foresee link rel=?? loading other types of resources in the future, not just .html? I like the idea of some sort of import or include, especially seeing that other web developers are aligned with this lingo. My 0$.02 On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell sorv...@google.com wrote: The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.comwrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.comwrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good
Re: [webcomponents] style hooks for custom elements
If you're looking for specs, they're a bit scattered. If you look in the top right corner of some of the slides in that deck, you'll see a gears icon pointing to the relevant spec. e.g.: http://html5-demos.appspot.com/static/webcomponents/index.html#36 I used the term styling hooks to describe the various ways you can use the different pieces: custom pseudo elements, css variables, @host,...to style a component. I ended up wrinting an article about styling Shadow DOM over at html5rocks. Might be useful to you: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/. That stuff still applies here, as Shadow DOM is the basis for Custom Elements. On Wed, Mar 27, 2013 at 9:52 AM, Mike Kamermans niho...@gmail.com wrote: Hey all, are style hooks still part of any spec relating to web components? Someone pointed out an older demo mentioning them (http://html5-demos.appspot.com/static/webcomponents/index.html) and I can't seem to find mention of them any more. (I like the idea, although the syntax from the demo is truly dire if you value not-designed-for-programmers-by-programmers syntax... =x) - Mike
Re: [webcomponents]: Naming the Baby
My association for HTML links is a. Seems too confusing. FWIW, I conducted a small survey to see what the broader community's mental model of this is: https://plus.google.com/u/0/118075919496626375791/posts/3GYkmd4UqLC. Got about 42 responses; the top 3 being: 1. Web Import link rel=import - 14 votes 2. Web Package link rel=package - 6 votes 3. Web Include link rel=include - 5 votes Do we foresee link rel=?? loading other types of resources in the future, not just .html? I like the idea of some sort of import or include, especially seeing that other web developers are aligned with this lingo. My 0$.02 On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell sorv...@google.com wrote: The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.com wrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.comwrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: [webcomponents] writing some pages that use webcomponents, and blogging along the way
This is great stuff Mike, thanks for making it available. I think we are all #facepalm at the notion of self-documenting component files, very clever. making things that use components and custom elements is proving extremely fun =) Music to my ears. Scott On Tue, Mar 26, 2013 at 11:48 AM, Mike Kamermans niho...@gmail.com wrote: Hey all, I've been playing with web components and custom elements for a bit, blogging about my understanding of it at http://pomax.nihongoresources.com/index.php?entry=1364168314 and writing a demo for the Mozilla webmaker dev group to see what we can do with them, which is hosted at http://pomax.github.com/WebComponentDemo/ This demo has a stack of custom elements that all tack onto a media element on the page, if there is one, with two pages, one with a media element, the other with an image instead, but identical code outside of that difference, using the components defined in http://pomax.github.com/WebComponentDemo/webmaker-components.html One thing we're wondering about how to play with is self-documenting components. Was there already work done on this, or has anyone else already played with that idea? Right now we've hardcoded the documentation as plain HTML, trying to come up with a nice way of autogenerating it by having some JS that checks whether the components were loaded as the document itself and if so, generate the documentation from the element definitions, but finding a clean way to include a general description as well as attribute documentation is tricky. If anyone has good ides for doing this, I'd be delighted to hear from you! Also, if there's anything on those pages that we did wrong, or that can be done better, I'd also love to hear from you. These things feel like game-changers, and making things that use components and custom elements is proving extremely fun =) - Mike Pomax Kamermans
Re: File API: why is there same-origin restriction on blob URLs?
On Wed, Mar 27, 2013 at 6:35 PM, Jonas Sicking jo...@sicking.cc wrote:
The question is, what happens if you do:
iframe src=blob:... id=iframe
iframe.onload = function() {
iframe.contentWindow.document; // throws or not?
}
What if the blob-url was created in another origin, does that make a
difference?
For data: URIs different browsers behave differently in the example above.
Same question applies if you create an img src=blob:... and then
drawImage it into a canvas, does the canvas get tainted? Again, I
think different browsers do different things for data: URLs here.
I think both of those should work, including for data URLs (unless you
get either the blob or data URL as a result of a non same-origin
redirect (maybe any redirect?)). I need to sort a few things out in
http://fetch.spec.whatwg.org/ but then hopefully that can be used to
define this at least for data URLs. It's still a bit unclear to me how
we want to define blob URLs, but maybe that fits right in.
--
http://annevankesteren.nl/
Re: File API: why is there same-origin restriction on blob URLs?
On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan a...@mozilla.com wrote: They're very different than data URLs. What's a good use case for making them cross-origin, that isn't addressed by use of postMessage? Well, the question we started with was why they're restricted to same origin. That does not appear to be answered yet. As for a use case, you could have a widget that does something given a URL. E.g. put Googly eyes on the image resource. This widget could be embedded anywhere and all you'd need to do is postMessage() it a URL. Requiring a special code path for URLs generated from a Blob seems annoying for both the consumer of the widget and the producer of it. -- http://annevankesteren.nl/
Re: [webcomponents]: Naming the Baby
import sounds good. Dominic On Thu, Mar 28, 2013 at 6:14 AM, Steve Orvell sorv...@google.com wrote: Err, yeah, thanks for pointing that out. I also like import or imports. This makes sense given that the rel attribute is described as defining the relationship between the resource being loaded and the document (likely outdated spec: http://www.w3.org/TR/html401/struct/links.html#adef-rel). On Wed, Mar 27, 2013 at 11:50 AM, Eric Bidelman ericbidel...@google.comwrote: My association for HTML links is a. Seems too confusing. FWIW, I conducted a small survey to see what the broader community's mental model of this is: https://plus.google.com/u/0/118075919496626375791/posts/3GYkmd4UqLC. Got about 42 responses; the top 3 being: 1. Web Import link rel=import - 14 votes 2. Web Package link rel=package - 6 votes 3. Web Include link rel=include - 5 votes Do we foresee link rel=?? loading other types of resources in the future, not just .html? I like the idea of some sort of import or include, especially seeing that other web developers are aligned with this lingo. My 0$.02 On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell sorv...@google.comwrote: The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.comwrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.comwrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and
