For normal navigation mode (thus inside the browser with chrome) I
would agree, but locking to other than current orientation makes sense
for apps which are standalone or in combination with the Fullscreen
API.
Kenneth
> The whole point is that the API must not allow locking to a particular
> ori
On Tue, Dec 3, 2013 at 4:52 AM, Jonas Sicking wrote:
> The strongest argument that I can think of is that it would be nice to
> keep the manifest spec and the API spec for orientations aligned. So
> if we think this is common enough that apps will want to use it in the
> manifest, then allowing
On 02/12/2013 23:26 , Arun Ranganathan wrote:
Mozilla is willing to remove lastModifiedDate completely, and migrate
developers to file.lastModified, which is an attribute that returns
an integer (long long) representing milliseconds since the epoch.
The Date API provides syntactic sugar for worki
On Tue, Dec 3, 2013 at 4:48 AM, Jonas Sicking wrote:
> As I understand it, the main use case for putting orientation in the
> manifest is to enable the UA to launch the app in the correct
> orientation from the get-go. It seems very hard for an implementation
> to do that with this solution. You
I am aware of [1], and really waiting for this to be available.
So you are suggesting something like {id:file_id, chunk1:chunk1,
chunk2:chunk2, etc}?
Related to [1] I have tried a "workaround" (not for fun, because I
needed to test at least with two different browsers): store the chunks
as A
On Tue, Dec 3, 2013, at 16:13, Jonas Sicking wrote:
> So I could see apps wanting to lock to that orientation (like you
> pointed out, we found at least one example in Firefox OS).
>
> However I don't understand the use case of locking to 90/180/270
> degrees off of the "normal" orientation?
>
>
On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
> My impression has been that the vast majority of apps only need a
> single orientation that is independent of media-query results. If
> that's the case, then I think the above is too complicated. I.e. if
> that is the common case, then we should
On Tue, Dec 3, 2013 at 12:20 PM, Mounir Lamouri wrote:
> On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
> > My impression has been that the vast majority of apps only need a
> > single orientation that is independent of media-query results. If
> > that's the case, then I think the above is t
On Tue, Dec 3, 2013, at 23:32, John Mellor wrote:
> > I definitely agree with that. Though, we should allow both syntaxes
> > (array and string).
> > If we want a more complex system later, we could move to that. For the
> > moment, I think we should keep it simple.
>
>
> It seems an even simpler
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23974
Bug ID: 23974
Summary: [Streams API] Don't inherit object URL feature
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Se
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23975
Bug ID: 23975
Summary: [Streams API] Remove read as Blob support
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severit
Dear Webapps folks,
The Web Performance Working Group published a new version of High
Resolution Time (performance.now()) to add support for Web Workers:
[[
interface WorkerPerformance {
DOMHighResTimeStamp now();
};
partial interface WorkerGlobalScope {
readonly attribute WorkerPerformance
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23977
Bug ID: 23977
Summary: [Streams API] Generic object stream
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: nor
Hmm. Does this take us back to viewmodes [1]? For example you also have the
ability on Windows Phone to have the live tiles view, with primary and
secondary tiles, and both square and wide tiles...
Also it may be necessary to consider where apps are intended not to take over
the device, but as
On Tue, Dec 3, 2013 at 2:50 AM, John Mellor wrote:
> On Tue, Dec 3, 2013 at 4:52 AM, Jonas Sicking wrote:
>>
>> The strongest argument that I can think of is that it would be nice to
>> keep the manifest spec and the API spec for orientations aligned. So
>> if we think this is common enough that
On Tue, Dec 3, 2013 at 4:10 AM, Mounir Lamouri wrote:
> On Tue, Dec 3, 2013, at 16:13, Jonas Sicking wrote:
>> So I could see apps wanting to lock to that orientation (like you
>> pointed out, we found at least one example in Firefox OS).
>>
>> However I don't understand the use case of locking to
On Mon, Dec 2, 2013 at 9:40 PM, Marcos Caceres wrote:
>> What I think we should have is something like:
>>
>> "chrome": {
>> "back": true
>> }
>
> Yep, this is currently captured here:
> https://github.com/w3c/manifest/issues/76
>
> Those of us working on this still need to investigate FxOS a bit
It seems that there are two distinct questions being discussed on this
thread:
1. should tags that come after block their
execution on load of the completing?
2. should rendering of page content block on the load of
These are related, but dif
Second question: should *rendering* of page content block on the load of
Steve Souders wrote another nice post about this topic:
http://www.stevesouders.com/blog/2013/11/26/performance-and-custom-elements/which
I recommend reading (read the comments too).
We should start by looking to how the we
3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri wrote:
> On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
>> My impression has been that the vast majority of apps only need a
>> single orientation that is independent of media-query results. If
>> that's the case, then I think the above is too c
I don't know how Apple feels, but I still don't feel like we at
Mozilla has had the ability to do a thorough enough review of the spec
to say that it's ready for CR. I believe both Mozilla and Apple raised
this concern when we went into LC.
/ Jonas
On Wed, Nov 27, 2013 at 2:39 PM, Dimitri Glazkov
* Bryan McQuade wrote:
>Steve Souders wrote another nice post about this topic:
>http://www.stevesouders.com/blog/2013/11/26/performance-and-custom-elements/which
>I recommend reading (read the comments too).
That should be
http://www.stevesouders.com/blog/2013/11/26/performance-and-custom-elem
On Tue, Dec 3, 2013 at 4:07 AM, Aymeric Vitte wrote:
> I am aware of [1], and really waiting for this to be available.
>
> So you are suggesting something like {id:file_id, chunk1:chunk1,
> chunk2:chunk2, etc}?
>
No, because you'd still have to fetch, modify, and re-insert the value each
time. H
On Tue, Dec 3, 2013 at 11:55 AM, Joshua Bell wrote:
> On Tue, Dec 3, 2013 at 4:07 AM, Aymeric Vitte
> wrote:
>>
>> I am aware of [1], and really waiting for this to be available.
>>
>> So you are suggesting something like {id:file_id, chunk1:chunk1,
>> chunk2:chunk2, etc}?
>
> No, because you'd s
On Tue, 03 Dec 2013 19:27:15 +0100, Jonas Sicking wrote:
On Mon, Dec 2, 2013 at 9:40 PM, Marcos Caceres wrote:
What I think we should have is something like:
"chrome": {
"back": true
}
Yep, this is currently captured here:
https://github.com/w3c/manifest/issues/76
Those of us working on t
Internal Subset:
The latest Firefox, Chrome and IE all support the doctype.internalSubset
property in the DOM. Their behavior diverges slightly when parsing and
serializing:
For HTML parsing the internalSubset is ignored as specified in HTML5. This
property returns null. For XHTML parsing, IE a
On Wednesday, December 4, 2013 at 4:27 AM, Jonas Sicking wrote:
> > > I also think that we need a way to put the manifest in-line in the
> > > main document. In part, technologies tend to be a lot easier to
> > > understand if you can create a single-file demo. In part, for small
> > > simple ap
unsubscribe
On Fri, 22 Nov 2013 03:33:51 +0100, Jonas Sicking wrote:
Hi all,
There has been some amount of debate about the virtue of sync IO APIs
in workers. Or sync APIs in workers in general.
One of the arguments made against sync APIs in workers made in [1] is
that even for workers, it i
On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
> On Tue, 03 Dec 2013 19:27:15 +0100, Jonas Sicking (mailto:jo...@sicking.cc)> wrote:
>
> > On Mon, Dec 2, 2013 at 9:40 PM, Marcos Caceres > (mailto:w...@marcosc.com)> wrote:
> > > > What I think we should have is some
On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
> Yes. In-apge Search is something that might also be useful within an app -
> especially if you can find out it is happening and respond to it
> intelligently if the app hides things by default.
The ability to do this
On Wednesday, December 4, 2013 at 9:17 AM, Marcos Caceres wrote:
>
>
>
> On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
>
> > Yes. In-apge Search is something that might also be useful within an app -
> > especially if you can find out it is happening and respo
On Tue, Dec 3, 2013 at 2:18 PM, Marcos Caceres wrote:
>> > Would it suffice to use the API? It’s much simpler than trying to write
>> > out JSON by hand and wouldn’t require us to create any new special script
>> > type, etc.
>> >
>> >
>> > if(“requestBookmark” in navigator){
>> >
>> > var appD
We share the same concern Jonas raised here.
In addition, we had been postponing reviewing the Web Components specifications
due to the "heavy" refactoring of the Shadow DOM specification announced in
July:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0161.html
Now we know that
On Nov 26, 2013, at 10:15 PM, Dominic Cooney wrote:
> On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa wrote:
>
> On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote:
>
>> On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote:
>> Hi,
>>
>> I have been having informal discussions of our earlier pr
On Oct 7, 2013, at 12:24 PM, Rafael Weinstein wrote:
> On Mon, Oct 7, 2013 at 3:24 AM, James Graham wrote:
> On 06/10/13 17:25, Dimitri Glazkov wrote:
>
> And, if the script is executed against the global/window object of
> the main document, can and should you be able to access the imp
On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa wrote:
> On Oct 7, 2013, at 12:24 PM, Rafael Weinstein wrote:
>
> On Mon, Oct 7, 2013 at 3:24 AM, James Graham wrote:
>
>> On 06/10/13 17:25, Dimitri Glazkov wrote:
>>
>> And, if the script is executed against the global/window object of
>>>
On Dec 3, 2013, at 8:02 PM, Eric Bidelman wrote:
> On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa wrote:
> On Oct 9, 2013, at 10:42 AM, Scott Miles wrote:
>
>> On Mon, Oct 7, 2013 at 3:24 AM, James Graham wrote:
>> On 06/10/13 17:25, Dimitri Glazkov wrote:
>>
>> And, if the script is execut
I don't have any objections to waiting for the folks to catch up. We'll
just keep it in LC until next year.
:DG<
On Tue, Dec 3, 2013 at 5:52 PM, Ryosuke Niwa wrote:
> We share the same concern Jonas raised here.
>
> In addition, we had been postponing reviewing the Web Components
> specificati
tl;dr - a few counter points for consideration, but I’m generally ok with
adding both the declarative inline alternative and with dropping the arguments
on the API in V1. For the declarative solution, we would drop using in
favor of entirely.
On Wednesday, December 4, 2013 at 9:40 AM, Jonas
On Dec 3, 2013 9:25 PM, "Marcos Caceres" wrote:
> On Wednesday, December 4, 2013 at 9:40 AM, Jonas Sicking wrote:
> > We currently have both ... and , as
> > well as both and