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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
21 matches
Mail list logo
