Re: File API for Review

[Anne van Kesteren]

On Wed, Mar 27, 2013 at 8:18 PM, Arun Ranganathan  wrote:
> Done.
>
> http://dev.w3.org/2006/webapi/FileAPI/#NetworkError

Awesome!


-- 
http://annevankesteren.nl/

Re: [webcomponents]: Naming the Baby

[Dominic Cooney]

"import" sounds good.

Dominic


On Thu, Mar 28, 2013 at 6:14 AM, Steve Orvell  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 
> wrote:
>
>> My association for HTML links is . 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  - 14 votes
>> 2. Web Package  - 6 votes
>> 3. Web Include  - 5 votes
>>
>> Do we foresee  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 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:

 

 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 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 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  (note the plural). When it 
>>> was
>>> changed to  was when the rain began.
>>>
>>> Scott
>>>
>>>
>>> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 
>>> 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 f

Re: File API: why is there same-origin restriction on blob URLs?

[Anne van Kesteren]

On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan  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: File API: why is there same-origin restriction on blob URLs?

[Anne van Kesteren]

On Wed, Mar 27, 2013 at 6:35 PM, Jonas Sicking  wrote:
> The question is, what happens if you do:
>
> 
> 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  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: [webcomponents] writing some pages that use webcomponents, and blogging along the way

[Scott Miles]

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  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  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?

[Jonas Sicking]

On Tue, Mar 26, 2013 at 5:30 PM, Jonas Sicking  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 meant to say "The main *problem* of those..." here!

/ Jonas

Re: [webcomponents] style hooks for custom elements

[Eric Bidelman]

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  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

[Eric Bidelman]

My association for HTML links is . 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  - 14 votes
2. Web Package  - 6 votes
3. Web Include  - 5 votes

Do we foresee  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  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:
>>
>> 
>>
>> 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  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 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  (note the plural). When it was
> changed to  was when the rain began.
>
> Scott
>
>
> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 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 > > wrote:
>>
>>> Hello folks!
>>>
>>> It seems that we've had a bit of informal feedback on the "Web
>>> Components" as the name for the  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 >> 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

Re: [webcomponents]: Naming the Baby

[Steve Orvell]

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 wrote:

> My association for HTML links is . 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  - 14 votes
> 2. Web Package  - 6 votes
> 3. Web Include  - 5 votes
>
> Do we foresee  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  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:
>>>
>>> 
>>>
>>> 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 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 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  (note the plural). When it was
>> changed to  was when the rain began.
>>
>> Scott
>>
>>
>> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 
>> 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  spec (cc'd some
 of the "feedbackers").

 So... these malcontents are suggesting that "Web C

Re: File API for Review

[Arun Ranganathan]

On Mar 25, 2013, at 1:52 PM, Anne van Kesteren wrote:

> On Mon, Mar 25, 2013 at 5:45 PM, Arun Ranganathan
>  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: File API: why is there same-origin restriction on blob URLs?

[Arun Ranganathan]

On Mar 26, 2013, at 8:30 PM, Jonas Sicking wrote:

> On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren  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 () 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: [webcomponents]: Naming the Baby

[Brian Kardell]

On Mar 27, 2013 2:27 PM, "Scott Miles"  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  has no such qualifications. As designed, the target
of this link is basically arbitrary HTML.
>
> This is why I'm struggling with .
>
> 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:
>>
>> 
>>
>> 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  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 
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  (note the plural). When it was
changed to  was when the rain began.
>
> Scott
>
>
> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 
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 
wrote:
>>>
>>> Hello folks!
>>>
>>> It seems that we've had a bit of informal feedback on the "Web
>>> Components" as the name for the  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 >> 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: [webcomponents]: Naming the Baby

[Angelina Fabbro]

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 wrote:

> My association for HTML links is . 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  - 14 votes
> 2. Web Package  - 6 votes
> 3. Web Include  - 5 votes
>
> Do we foresee  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  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:
>>>
>>> 
>>>
>>> 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 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 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  (note the plural). When it was
>> changed to  was when the rain began.
>>
>> Scott
>>
>>
>> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 
>> 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  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 >>> rel=component> should be called something more specific, having to
 do
 wit

Re: File API: why is there same-origin restriction on blob URLs?

[Jonas Sicking]

On Wed, Mar 27, 2013 at 2:41 AM, Anne van Kesteren  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  of another origin and that  can then load the data
> URL in an  and have it work (obviously, as the data URL is
> self-contained).

The question is, what happens if you do:


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  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

[Steve Orvell]

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
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:
>
> 
>
> 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  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  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  (note the plural). When it was
 changed to  was when the rain began.

 Scott


 On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 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 
> wrote:
>
>> Hello folks!
>>
>> It seems that we've had a bit of informal feedback on the "Web
>> Components" as the name for the  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 > 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

[Scott Miles]

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  has no such qualifications. As designed, the target
of this link is basically arbitrary HTML.

This is why I'm struggling with .

Scott


On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro
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:
>
> 
>
> 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  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  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  (note the plural). When it was
 changed to  was when the rain began.

 Scott


 On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 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 
> wrote:
>
>> Hello folks!
>>
>> It seems that we've had a bit of informal feedback on the "Web
>> Components" as the name for the  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 > 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] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

[Boris Zbarsky]

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] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

[Boris Zbarsky]

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] style hooks for custom elements

[Dimitri Glazkov]

http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/

:DG<

Re: [webcomponents] style hooks for custom elements

[Dimitri Glazkov]

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  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

[Angelina Fabbro]

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:



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  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  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  (note the plural). When it was
>>> changed to  was when the rain began.
>>>
>>> Scott
>>>
>>>
>>> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 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 
 wrote:

> Hello folks!
>
> It seems that we've had a bit of informal feedback on the "Web
> Components" as the name for the  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  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<
>


>>>
>>
>

[webcomponents] style hooks for custom elements

[Mike Kamermans]

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

RfC: 2nd LCWD of HTML Media Capture; deadline 19 April

[Arthur Barstow]

The DAPWG asked WebApps to submit comments on LC#2 of "HTML Media Capture":

 

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

Re: File API: why is there same-origin restriction on blob URLs?

[Anne van Kesteren]

On Wed, Mar 27, 2013 at 12:30 AM, Jonas Sicking  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  of another origin and that  can then load the data
URL in an  and have it work (obviously, as the data URL is
self-contained).


-- 
http://annevankesteren.nl/

Re: Fixing appcache: a proposal to get us started

[Emerson Estrella]

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