On Wed, Nov 16, 2011 at 11:06 PM, crocket wrote:
> For 1), most users don't know there is such a thing as user's default
> volume.
> Even I don't know where to find that setting in firefox or chrome.
> It seems to be a hidden configuration.
>
> Plus, some audio files are too loud at 100% which is
For 1), most users don't know there is such a thing as user's default
volume.
Even I don't know where to find that setting in firefox or chrome.
It seems to be a hidden configuration.
Plus, some audio files are too loud at 100% which is the default volume for
most users.
Since uploaders know the p
On Wed, Nov 16, 2011 at 6:55 PM, Daniel Cheng wrote:
> I see. I personally feel it's a little confusing to have two different
> ways to read files in DataTransfer, and now we're adding a third.
>
I don't think that's a good reason not to support this, but that said, it
may be possible to integra
On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng wrote:
> On Wed, Nov 16, 2011 at 15:31, Glenn Maynard wrote:
>
>> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng wrote:
>>
>>> I'm trying to better understand the use case for DataTransfer.entries.
>>> Using the example you listed in your first post,
On Wed, Nov 16, 2011 at 2:33 PM, Daniel Cheng wrote:
> I'm trying to better understand the use case for DataTransfer.entries.
> Using the example you listed in your first post, if I dragged those folders
> into a browser, I'd expect to see File objects with the following names in
> DataTransfer.fi
On Wed, Nov 16, 2011 at 15:31, Glenn Maynard wrote:
> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng wrote:
>
>> I'm trying to better understand the use case for DataTransfer.entries.
>> Using the example you listed in your first post, if I dragged those folders
>> into a browser, I'd expect to s
On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng wrote:
> I'm trying to better understand the use case for DataTransfer.entries.
> Using the example you listed in your first post, if I dragged those folders
> into a browser, I'd expect to see File objects with the following names in
> DataTransfer.f
On Wed, 16 Nov 2011, Gavin Kistner wrote:
>
> Can you provide an example in script of when the "found specs" would
> apply, and when the "other specs" would apply?
Hmm, good point. Now that we're using CORS explicitly, all of the stuff
about image origins for non-CORS cases doesn't really apply
From: Ian Hickson [mailto:i...@hixie.ch]
> On Wed, 16 Nov 2011, Gavin Kistner wrote:
> > Section 6.3 "Origin" of the HTML Living Standard has this text (excerpted):
> >
> > > For images:
> > >
> > > If an image was generated from a data: URL found in another Document
> > > or in a script The ori
On Wed, 16 Nov 2011, Gavin Kistner wrote:
> Section 6.3 "Origin" of the HTML Living Standard has this text (excerpted):
>
> > For images:
> >
> > If an image was generated from a data: URL found in another Document or in
> > a script
> > The origin is the origin of the Document or script that loa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/11/11 10:32 AM, Aaron Colwell wrote:
> Yeah it looks to me like starting at the requested position is the
> only option. I saw the text about media engine triggered seeks, but
> it seems like users would be very surprised to see the seeking &
>
I'm trying to better understand the use case for DataTransfer.entries.
Using the example you listed in your first post, if I dragged those folders
into a browser, I'd expect to see File objects with the following names in
DataTransfer.files:
trip/1.jpg
trip/2.jpg
trip/3.jpg
hallowee
Section 6.3 "Origin" of the HTML Living Standard has this text (excerpted):
> For images:
>
> If an image was generated from a data: URL found in another Document or in a
> script
> The origin is the origin of the Document or script that loaded that image.
>
> If an image was obtained in some oth
On Thu, Nov 17, 2011 at 3:41 AM, Anne van Kesteren wrote:
> On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan <
> rob...@ocallahan.org> wrote:
>
>> I'm not comfortable with punting the nested-fullscreen cases. It means
>> that if you have a document with an embedded video with fullscreen cont
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor wrote:
> It seems like we shouldn't assume that these are the only two features
> that will ever need this sort of rendering support. I'll get a www-style
> thread going.
>
Thanks. If multiple specs (or even multiple running instances of the same
>>> Hm, why would it require stacking-level changes? One obvious way to
>>> get it to act "correctly" is to make it wrap around the element, like
>>> the old ::outside pseudo-element proposal. Then it's trivial.
>>
>> The CP says "The dialog and its cover, taken together, are siblings within a
>
Here is another link where Ian mentions that the seek should be the exact
frame.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017225.html
This came up from 2 years ago, where I wanted to add an optional "strict"
parameter to the seek call, which would default to false. Exactly
On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking wrote:
> > That requires a full directory traversal in advance to find all of the
> > files, though; the tree could be very large.
>
> You need to do that anyway to implement the .files attribute, no?
>
.files shouldn't recursively include all files
On Tue, Nov 15, 2011 at 9:16 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda wrote:
>>
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the UR
On Tue, Nov 15, 2011 at 6:06 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda wrote:
>
>> The async nature of DirectoryEntry makes the code longer,
>> but webapps can work on the files incrementally and can show
>> progress UI while enumerating. For the apps that may dea
On Fri, Sep 30, 2011 at 7:56 PM, Erik Arvidsson wrote:
> On Fri, Sep 30, 2011 at 07:35, Henri Sivonen wrote:
>> On Fri, Sep 30, 2011 at 1:37 AM, Erik Arvidsson wrote:
>>> If the context object is in a detached state, then relax the parsing
>>> rules so that all elements are allowed at that level
On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking wrote:
> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard wrote:
>> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
>>>
>>> Adding FileEntry/DirectoryEntry seems confusing since those are
>>> generally writable in the FileSystem API spec, right?
On Wed, Nov 16, 2011 at 2:16 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda wrote:
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the URL t
On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan
wrote:
I'm not comfortable with punting the nested-fullscreen cases. It means
that if you have a document with an embedded video with fullscreen
controls,
fullscreening the video works fine when the document is not fullscreen,
but if yo
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard wrote:
> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking wrote:
>>
>> Adding FileEntry/DirectoryEntry seems confusing since those are
>> generally writable in the FileSystem API spec, right? Additionally,
>> DirectoryEntry is asynchronous, which makes
25 matches
Mail list logo
