Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

2013-11-27 Thread Anne van Kesteren
On Tue, Nov 26, 2013 at 7:43 PM, Arthur Barstow art.bars...@nokia.com wrote: Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working

Re: New manifest spec - ready for FPWD?

2013-11-27 Thread Mounir Lamouri
On Wed, Nov 27, 2013, at 8:02, Marcos Caceres wrote: Over the last few weeks, a few of us folks in the Web Mob IG have been investigating the use cases and requirements for bookmarking web apps to home screen. The output of that research is this living document:

[screen-orientation] When window orientation != screen orientation...

2013-11-27 Thread John Mellor
How should the Screen Orientation API handle cases where the web page's window has the opposite orientation to the device's screen? Examples where this can occur include: - Split screen tablet (like Win 8 Metro) - Non-maximized window on tablet (like Win 8 non-Metro) - WebView embedded in native

Re: [screen-orientation] screen orientation angle

2013-11-27 Thread Mounir Lamouri
If Screen Orientation angle and Device Orientation have the same top for the device, it should be easy to make an angle relative to the top of screen instead of the top of the device. I would not recommend changing Device Orientation API. -- Mounir On Wed, Nov 27, 2013, at 7:41, Kenneth Rohde

RE: New manifest spec - ready for FPWD?

2013-11-27 Thread Jonathan Bond-Caron
On Tue Nov 26 04:02 PM, Marcos Caceres wrote: Over the last few weeks, a few of us folks in the Web Mob IG have been investigating the use cases and requirements for bookmarking web apps to home screen. The output of that research is this living document:

Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

2013-11-27 Thread Arthur Barstow
On 11/27/13 7:17 AM, ext Anne van Kesteren wrote: On Tue, Nov 26, 2013 at 7:43 PM, Arthur Barstow art.bars...@nokia.com wrote: Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of

Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

2013-11-27 Thread Anne van Kesteren
On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as anything different. (BTW, this is codified in Webapps'

Re: New manifest spec - ready for FPWD?

2013-11-27 Thread Mounir Lamouri
On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote: On Tue Nov 26 04:02 PM, Marcos Caceres wrote: Over the last few weeks, a few of us folks in the Web Mob IG have been investigating the use cases and requirements for bookmarking web apps to home screen. The output of that research

Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

2013-11-27 Thread Arthur Barstow
On 11/27/13 8:52 AM, ext Anne van Kesteren wrote: On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow art.bars...@nokia.com wrote: WebApps has a relatively long history of giving Editors quite a bit of artistic freedom aka edit-first-review-later policy so I don't see what Travis has done as

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

2013-11-27 Thread Travis Leithead
Fair enough. By the way, I don't see the reference to DOM L2 Core in the Editor's draft (there's a reference to it in the source code, but not in the rendered HTML). I did end up talking about the (historical) internalSubset property of the Doctype object for serialization--since browsers

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

2013-11-27 Thread Travis Leithead
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23936 to track this LC comment :-) -Original Message- From: Travis Leithead Sent: Wednesday, November 27, 2013 9:23 AM To: 'Arthur Barstow'; Anne van Kesteren Cc: public-webapps Subject: RE: CfC: publish LCWD of DOM Parsing and

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread Dimitri Glazkov
Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens. And for that matter, what rendering means. The original reason why script

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread Alex Russell
On Wed, Nov 27, 2013 at 9:46 AM, Dimitri Glazkov dglaz...@google.comwrote: Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens.

LINK only in HEAD?

2013-11-27 Thread Steve Souders
According to the HTML 4 spechttp://www.w3.org/TR/html401/struct/links.html#h-12.1.3LINK tags must appear in HEAD: *The LINK element may only appear in the head of a document.* The HTML Imports spechttp://www.w3.org/TR/custom-elements/#enqueuing-and-invoking-callbackscontains the following

Re: LINK only in HEAD?

2013-11-27 Thread Dimitri Glazkov
On Wed, Nov 27, 2013 at 11:35 AM, Steve Souders soud...@google.com wrote: According to the HTML 4 spechttp://www.w3.org/TR/html401/struct/links.html#h-12.1.3LINK tags must appear in HEAD: *The LINK element may only appear in the head of a document.* We probably need something more modern

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread Daniel Buchner
Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly, let's give it a shot! Alex, I completely agree that declarative features should play a huge role in the solution, and I love the power/granularity

Re: LINK only in HEAD?

2013-11-27 Thread Steve Souders
Given that most examples of Custom Elements are visible elements in the body and the spec doesn't indicate its example is in the HEAD, this example will likely increase the number of websites that put HTML Import LINK tags in the body. This has two downsides: 1. It's flagged as having errors

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread John J Barton
I just can't help thinking this is whole line of reasoning all too complicated to achieve wide adoption and thus impact. The supposed power of declarative languages is ability to reason from top to bottom. Creating all of these exceptions causes the very problems being discussed: FOUC occurs

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread Daniel Buchner
JJB, this is precisely why the paint concept seemed like a good idea to me: - Easy to use in just one or two places if needed, without a steep cliff - The choice shouldn't be: either put up with the browser's default render flow, or become a low-level, imperative, perf hacker

Re: LINK only in HEAD?

2013-11-27 Thread Boris Zbarsky
On 11/27/13 2:44 PM, Dimitri Glazkov wrote: If the rel attribute is used, the element is restricted to the head element. This is part of a non-normative content (a note), so I think we're off the hook here :) No. The normative bit is sort of scattered around the spec, but for example:

Re: LINK only in HEAD?

2013-11-27 Thread Dimitri Glazkov
On Wed, Nov 27, 2013 at 12:19 PM, Steve Souders soud...@google.com wrote: Given that most examples of Custom Elements are visible elements in the body and the spec doesn't indicate its example is in the HEAD, this example will likely increase the number of websites that put HTML Import LINK

Re: LINK only in HEAD?

2013-11-27 Thread Dimitri Glazkov
On Wed, Nov 27, 2013 at 12:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: http://www.whatwg.org/specs/web-apps/current-work/ multipage/sections.html#the-body-element says its content model (this part is normative!) is http://www.whatwg.org/specs/web-apps/current-work/

Re: LINK only in HEAD?

2013-11-27 Thread Boris Zbarsky
On 11/27/13 3:54 PM, Dimitri Glazkov wrote: I see. Do you know why? Because people wanted link to mean something, or something. I really can't say. It seems that all browsers support it anywhere And the spec requires them to, yes. and this looks like just validator hoop-jumping.

RE: New manifest spec - ready for FPWD?

2013-11-27 Thread Jonathan Bond-Caron
On Wed Nov 27 09:20 AM, Mounir Lamouri wrote: On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote: On Tue Nov 26 04:02 PM, Marcos Caceres wrote: Over the last few weeks, a few of us folks in the Web Mob IG have been investigating the use cases and requirements for bookmarking web

Re: RfC: LCWD of Custom Elements; deadline November 21

2013-11-27 Thread Dimitri Glazkov
Dear WebApps WG, The Last Call comment period had ended and we're ready to proceed to CR. Yay! The LC comments are tracked here: http://www.w3.org/wiki/Webapps/LCWD-custom-elements-20131024/ The following (minor) tweaks to the spec were made to the spec during this period: *

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread John J Barton
What if: head ... link rel=import href=elements/pi-app.html ... /head body ... pi-app theme=polymer-ui-light-theme div class=app-loading/div /pi-app ... was instead: pi-app import=elements/pi-app.html theme=polymer-ui-light-theme div class=app-loading/div /pi-app If I want to avoid

Re: Allow javascript: URIs for registerProtocolHandler

2013-11-27 Thread Ian Hickson
On Wed, 18 Sep 2013, Anne van Kesteren wrote: On Tue, Sep 17, 2013 at 4:34 PM, pira...@gmail.com pira...@gmail.com wrote: Really :-) I though the same, but since its a GET equivalent operation just like XHR and in fact Google Charts creates on-demand graphics based on the data on the URL

Re: Fixing appcache: a proposal to get us started

2013-11-27 Thread eli
The web is server + client sides. Trying to fix issues you have with client technologies only (appcache, JavaScript, ...) will always be a bad choice. I disagree, Javascript and web browsers are becoming powerful enough to delegate servers to their barebones, just offering storage or

Controling style of elements in Injection Points

2013-11-27 Thread Enrique Moreno Tent
Hello, I have been experimenting with Web Components and I have an issue, which I think I have represented fairly clear here: (Tested on Chrome) http://codepen.io/dbugger/pen/Hyihd If I understood correctly, one of the points of web components is to control the presentation of our component.

Re: Fixing appcache: a proposal to get us started

2013-11-27 Thread pira...@gmail.com
Json manifest seems a nice solution to me :-) Send from my Samsung Galaxy Note II El 28/11/2013 07:21, eli elib...@gmail.com escribió: The web is server + client sides. Trying to fix issues you have with client technologies only (appcache, JavaScript, ...) will always be a bad choice.