Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?

2014-02-26 Thread Charles McCathie Nevile 
On Wed, 26 Feb 2014 21:47:19 +0100, Arthur Barstow   
wrote:



On 2/26/14 3:44 PM, ext Rafael Weinstein wrote:
It may be useful to mention in the note that the Template spec was  
"merged" to HTML (as opposed to simply becoming a concern of HTML,  
which might raise the question "did HTML do something different than  
what this spec used to say?").


Yes, I agree "merged" is a key operative word we would want to  
communicate in the Note.


Agreed - and yes, this would be a good thing to do in general.

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?

2014-02-26 Thread Arthur Barstow 

On 2/26/14 3:44 PM, ext Rafael Weinstein wrote:
It may be useful to mention in the note that the Template spec was 
"merged" to HTML (as opposed to simply becoming a concern of HTML, 
which might raise the question "did HTML do something different than 
what this spec used to say?").


Yes, I agree "merged" is a key operative word we would want to 
communicate in the Note.


-Thanks, AB

Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?

2014-02-26 Thread Rafael Weinstein 
No objections. It may be useful to mention in the note that the Template
spec was "merged" to HTML (as opposed to simply becoming a concern of HTML,
which might raise the question "did HTML do something different than what
this spec used to say?").


On Wed, Feb 26, 2014 at 12:25 PM, Ryosuke Niwa  wrote:

> Sounds great to me.
>
> On Feb 26, 2014, at 6:43 AM, Arthur Barstow  wrote:
>
> > Hi Robin, Dimitri, All,
> >
> > Since HTML Templates is now part of HTML5, to help avoid confusion, I
> think WebApps' last TR of the spec ([html-templates]) should be replaced
> with a WG Note that clearly indicates WebApps' work on the standalone spec
> has stopped and the feature is now part of HTML5. (The Note could also be
> void of any technical substance as DAP recently did f.ex. [contacts-api]).
> >
> > WDYT? Any objections?
> >
> > (If we agree to publish a WG Note, I'll create it).
> >
> > -Thanks, AB
> >
> > [html-templates] 
> > [contacts-api] 
> >
> >
>
>
>

Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?

2014-02-26 Thread Ryosuke Niwa 
Sounds great to me.

On Feb 26, 2014, at 6:43 AM, Arthur Barstow  wrote:

> Hi Robin, Dimitri, All,
> 
> Since HTML Templates is now part of HTML5, to help avoid confusion, I think 
> WebApps' last TR of the spec ([html-templates]) should be replaced with a WG 
> Note that clearly indicates WebApps' work on the standalone spec has stopped 
> and the feature is now part of HTML5. (The Note could also be void of any 
> technical substance as DAP recently did f.ex. [contacts-api]).
> 
> WDYT? Any objections?
> 
> (If we agree to publish a WG Note, I'll create it).
> 
> -Thanks, AB
> 
> [html-templates] 
> [contacts-api] 
> 
>

Indexed DB: Opening connections, versions, and priority

2014-02-26 Thread Joshua Bell 
While looking at a Chrome bug [1], I reviewed the Indexed DB draft, section
3.3.1 [2] Opening a database:

"These steps are not run for any other connections with the same origin and
name but with a higher version"

And the note: "This means that if two databases with the same name and
origin, but with different versions, are being opened at the same time, the
one with the highest version will attempt to be opened first. If it is able
to successfully open, then the one with the lower version will receive an
error."

I interpret that as (and perhaps the spec should be updated to read): "This
means that if two open requests are made to the database with the same name
and origin at the same time, the open request with the highest version will
be processed first. If it is able to successfully open, then the request
with the lower version will receive an error."

So far as I can tell with a test [3], none of Chrome (33), Firefox (27), or
IE (10) implement this per spec. Instead of processing the request with the
highest version first, they process the first request that was received.

Is my interpretation of the spec correct? Is my test [3] correct? If yes
and yes, should we update the spec to match reality?

[1] https://code.google.com/p/chromium/issues/detail?id=225850
[2] https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#opening
[3] http://jsfiddle.net/Nbg2K/2/

Re: [Bug 24823] New: [ServiceWorker]: "MAY NOT" is not defined in RFC 2119

2014-02-26 Thread Bjoern Hoehrmann 
* Brian Kardell wrote:
>On Feb 26, 2014 1:01 PM, "Bjoern Hoehrmann"  wrote:
>> If an agent "MAY $x" then it also "MAY not $x". It is possible that the
>> author meant "must not" or "should not" in this specific instance, but
>> in general such a reading would be incorrect. If course, specifications
>> should not use constructs like "may not".

>Your use of "should not" and the logic implies that actually they may use
>"may not" they just shouldn't.  Do you mean they may not?

I think that using phrases like "may not" is a bad practise. I think any
"may" in this context is mutually exclusive with "should not".
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: [Bug 24823] New: [ServiceWorker]: "MAY NOT" is not defined in RFC 2119

2014-02-26 Thread Brian Kardell 
On Feb 26, 2014 1:01 PM, "Bjoern Hoehrmann"  wrote:
>
> * bugzi...@jessica.w3.org wrote:
> >The section "Worker Script Caching" uses the term "MAY NOT", which is not
> >defined in RFC 2119.  I'm assuming this is intended to be "MUST NOT" or
maybe
> >"SHOULD NOT".
>
> If an agent "MAY $x" then it also "MAY not $x". It is possible that the
> author meant "must not" or "should not" in this specific instance, but
> in general such a reading would be incorrect. If course, specifications
> should not use constructs like "may not".
> --

Your use of "should not" and the logic implies that actually they may use
"may not" they just shouldn't.  Do you mean they may not?

> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

Re: [Bug 24823] New: [ServiceWorker]: "MAY NOT" is not defined in RFC 2119

2014-02-26 Thread Bjoern Hoehrmann 
* bugzi...@jessica.w3.org wrote:
>The section "Worker Script Caching" uses the term "MAY NOT", which is not
>defined in RFC 2119.  I'm assuming this is intended to be "MUST NOT" or maybe
>"SHOULD NOT".

If an agent "MAY $x" then it also "MAY not $x". It is possible that the
author meant "must not" or "should not" in this specific instance, but
in general such a reading would be incorrect. If course, specifications
should not use constructs like "may not".
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

[Bug 24823] New: [ServiceWorker]: "MAY NOT" is not defined in RFC 2119

2014-02-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24823

Bug ID: 24823
   Summary: [ServiceWorker]: "MAY NOT" is not defined in RFC 2119
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P2
 Component: Service Workers
  Assignee: slightly...@chromium.org
  Reporter: mme...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

The section "Worker Script Caching" uses the term "MAY NOT", which is not
defined in RFC 2119.  I'm assuming this is intended to be "MUST NOT" or maybe
"SHOULD NOT".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents]: Web Components in 2014

2014-02-26 Thread Arthur Barstow 

On 2/13/14 5:00 PM, ext Dimitri Glazkov wrote:
As promised, here's the "plans and expectations" summary for the Web 
Components spec umbrella. Apologies for taking so long.


Thanks for this information Dimitri! (I just updated the Plans column of 
[PubStatus] accordingly.)


To the extent WebApps has "Plans of Record", I consider your info the 
PoR for Web Components, at least for 2014.


-AB

[PubStatus]

[admin] Should WebApps' HTML Templates spec be published as a WG Note?

2014-02-26 Thread Arthur Barstow 

Hi Robin, Dimitri, All,

Since HTML Templates is now part of HTML5, to help avoid confusion, I 
think WebApps' last TR of the spec ([html-templates]) should be replaced 
with a WG Note that clearly indicates WebApps' work on the standalone 
spec has stopped and the feature is now part of HTML5. (The Note could 
also be void of any technical substance as DAP recently did f.ex. 
[contacts-api]).


WDYT? Any objections?

(If we agree to publish a WG Note, I'll create it).

-Thanks, AB

[html-templates] 
[contacts-api]

Re: what about this feature in template system in html5?

2014-02-26 Thread Arthur Barstow 
Yarco - WebApps is no longer working on the HTML Templates spec. That 
feature was moved to [HTML5] and that spec says feedback should be sent 
to public-html-comments @ w3.org.


-Regards, ArtB

[HTML5] 

On 2/19/14 5:24 AM, ext Yarco Wang wrote:

Hello, Guys:


there?


template system

template can be local and global.

  * local template parse and load on fly
  * global template works like cookie or localStorage for some
domain.(so, when you visit a website, if no global template should
be updated -- can re-use vtag, those templates could be fetched
from global template system which may be stored just in localStorage)



more thinkings: https://gist.github.com/yarcowang/8969090


well, if you accept one of my ideas, it means i changed the world, do i?
:)


Yarco

[gamepad] preventing default/capturing controller

2014-02-26 Thread Patrick H. Lauke 
"Currently, the only way for a gamepad to be used as input would be to 
emulate mouse or keyboard events"


I'm wondering if it's in scope for this spec to also address the 
situation where a UA *does* already do this natively (for instance, IE 
on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad 
firing cursor event.


A few precedents that may be worth looking at:

- Pointer Lock API http://www.w3.org/TR/pointerlock/

- Opera's spatial navigation on TV browsers, which can be 
preventDefault-ed if the website/app wants to handle d-pad input (mapped 
to cursor keys already, mind) on a remote control 
http://dev.opera.com/articles/view/functional-key-handling-in-opera-device-sdk-based-tv-browsers/#prevent-default


- Boxee's (discontinued) API to explicitly switch browser into different 
modes (cursor, keyboard, player) 
http://developer.boxee.tv/JavaScript_API#Browser_Modes


There's an argument that this should be left completely up to the UA, 
and that users should switch the UA into different modes. However, at 
the very least it would be nice then to have a way for a site/app to 
*signal* that it can handle direct gamepad input.


Thoughts?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke