Re: [testing] Seeking Test Facilitator(s) for Indexed Database API
On 11/26/13 1:45 AM, ext Zhang, Zhiqiang wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Saturday, November 23, 2013 2:58 AM Please contact me if you can commit to helping with this effort and you have `relevant` experience. After reconsidering your invitation at TPAC about this, I would like to take this role and to review the submissions from next week. This is excellent Zhiqiang, thanks! (I updated PubStatus accordingly.) BTW, I will backup Tina Zhao, the Test Facilitator for Server Sent Events, for about half a year during her maternity leave. Please contact me if you have any matters related to SSE. OK, thanks for your help here. Good luck Tina! -Cheers, ArtB
Re: publish LCWD of DOM Parsing and Serialization; deadline November 25
Travis - what is the plan for https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938? -Thanks, AB On 11/25/13 7:23 PM, ext Travis Leithead wrote: I've finished the major updates. Today's ED draft at: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html should be ready to use as the baseline for the Last Call CfC. Thanks, Travis -Original Message- From: Travis Leithead Sent: Monday, November 18, 2013 11:26 AM To: Webapps WG Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November 25 If possible, I'd like to delay this CfC, for a week--I have some major updates to the ED in-flight, and I want to make sure we base the CfC on the right ED content :-) Hopefully this is workable to the group. Thanks! - From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 18, 2013 4:00 AM This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and Serialization, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call 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 Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Currently, this spec has one Editorial bug [18939] that is open and Travis will fix this before the LCWD is published. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by November 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, please let me know. -Thanks, AB [18939] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938 Original Message Subject:ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) Date: Mon, 11 Nov 2013 01:59:39 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/701 On: Arthur Barstow Due: 2013-11-18 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
[screen-orientation] Locking to 'current' orientation
Hi,
I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.
From Javascript, that would allow writing
window.screen.lockOrientation('current');
instead of
window.screen.lockOrientation(window.screen.orientation);
Basically, a syntax sugar.
From the manifest, writing the following
'orientation': 'current',
would allow locking the application to the orientation it is loaded in
at startup.
It is a tiny use case but it seem that there are apps out there doing
that (like the iOS Task Switcher, I was told).
WDYT?
--
Mounir
Re: [screen-orientation] Locking to 'current' orientation
On Tuesday, 26 November 2013 at 15:16, Mounir Lamouri wrote:
Hi,
I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.
From Javascript, that would allow writing
window.screen.lockOrientation('current');
instead of
window.screen.lockOrientation(window.screen.orientation);
Basically, a syntax sugar.
the one with JavaScript seems more clear to me (as it's more evident that it's
dynamically derived). current is kinda weird because setting the orientation
is an async operation, so by the time you work out what current is, it might
not longer be the current one... so it's kind or a race condition.
From the manifest, writing the following
'orientation': 'current',
Apps can have multiple orientations and it appears to be somewhat media query
dependent. I'm cooking up something different for the manifest but would like
terms to align.
Re: [screen-orientation] Locking to 'current' orientation
hi,
On Tue, Nov 26, 2013 at 4:25 PM, Marcos Caceres w...@marcosc.com wrote:
On Tuesday, 26 November 2013 at 15:16, Mounir Lamouri wrote:
Hi,
I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.
From Javascript, that would allow writing
window.screen.lockOrientation('current');
instead of
window.screen.lockOrientation(window.screen.orientation);
Basically, a syntax sugar.
current is nice because it works for the manifest as well.
the one with JavaScript seems more clear to me (as it's more evident that
it's dynamically derived). current is kinda weird because setting the
orientation is an async operation, so by the time you work out what current
is, it might not longer be the current one... so it's kind or a race
condition.
Why? If it rotating at the moment you call it, it could just fail, if
it is not, it could lock immediately. It is no different from using
the window.screen.orientation.
Kenneth
--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆
Re: [screen-orientation] Locking to 'current' orientation
On Tuesday, 26 November 2013 at 15:30, Kenneth Rohde Christiansen wrote:
hi,
On Tue, Nov 26, 2013 at 4:25 PM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
On Tuesday, 26 November 2013 at 15:16, Mounir Lamouri wrote:
Hi,
I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.
From Javascript, that would allow writing
window.screen.lockOrientation('current');
instead of
window.screen.lockOrientation(window.screen.orientation);
Basically, a syntax sugar.
current is nice because it works for the manifest as well.
IMHO, it would be confusing to have an app that when you launch it the first
time locks one way... but when you launch it the next time, locks another way.
In the 300 apps we've been cataloguing for orientation [1], there is not a
single instance of that exhibits this behaviour. I've also never personally
seen any app do this on startup.
Mounir, what is the use case for locking to current on startup? Which
applications do you know that exhibit this behaviour?
the one with JavaScript seems more clear to me (as it's more evident that
it's dynamically derived). current is kinda weird because setting the
orientation is an async operation, so by the time you work out what
current is, it might not longer be the current one... so it's kind or a
race condition.
Why? If it rotating at the moment you call it, it could just fail, if
it is not, it could lock immediately. It is no different from using
the window.screen.orientation.
Sure, but it's more about setting expectations. For me personally, using
window.screen.orientation is more explicit about what I want... like:
var current = screen.orientation;
console.log(ok! locking it to:, current );
screen.lockOrientation(current);
current is more like requesting. That's just me tho.
[1]
https://docs.google.com/a/marcosc.com/spreadsheet/ccc?key=0Akv8gJijerFUdFQ4RVNibXNUNElWZU05THJ4NE9BSVE#gid=0
[screen-orientation] screen orientation angle
Hi, The Screen Orientation API defines an angle relationship between portrait-primary and landscape-primary. The reason for that is that developers would know which orientation is at 90 degrees from the current orientation, which one is at 180 degrees, etc. However, by forcing the two primary orientations to have a relationship, we prevent UA to do clever things like having landscape-primary being related to how the user uses his phone (eg. usually depending on which hand is used, the most common landscape is not going to be different). In addition, some use cases might need to know the angle between the current orientation and the native device orientation. For example, a compass using DeviceOrientation would need to know this angle to be able to draw the correct information on the screen [1]. This is also a UC that Mozilla has with Firefox OS where some apps want to lock the orientation to the native device orientation (ie. angle=0) [2]. So, the Screen Orientation API should allow locking to a specific orientation angle. For that, we could allow an integer to be passed to the lockOrientation() function, a modulo operation would be applied on the number to have it in the [0; 360[ range. If the UA is not able to lock to the specified angle, the method should fail (return false for the moment, the promise should fail in the future). The orientation angle should also be read. It would be possible to simply use window.orientation. I am not a big fan of that solution [3] but this is implemented by most Mobile UAs already so it might as well be the best thing to do. An alternative would be to have something like screen.orientationAngle or screen.orientation.angle (and screen.orientation.name). WDYT? [1] http://oldworld.fr/google/compass.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058 [3] the value can be negative, which is a footgun and the having this value living in window and the rest in window.screen is odd -- Mounir
Re: [screen-orientation] Locking to 'current' orientation
On Wed, Nov 27, 2013, at 2:52, Marcos Caceres wrote: IMHO, it would be confusing to have an app that when you launch it the first time locks one way... but when you launch it the next time, locks another way. In the 300 apps we've been cataloguing for orientation [1], there is not a single instance of that exhibits this behaviour. I've also never personally seen any app do this on startup. Mounir, what is the use case for locking to current on startup? Which applications do you know that exhibit this behaviour? Eh... My understanding was that there was a consensus for this to be added. I was told that you pointed the iOS UC. I quite agree with you that it does not sound like a nice UX. I was willing to spec that because I assumed there was a consensus. If there is not, we should discuss it further ;) the one with JavaScript seems more clear to me (as it's more evident that it's dynamically derived). current is kinda weird because setting the orientation is an async operation, so by the time you work out what current is, it might not longer be the current one... so it's kind or a race condition. Why? If it rotating at the moment you call it, it could just fail, if it is not, it could lock immediately. It is no different from using the window.screen.orientation. Sure, but it's more about setting expectations. For me personally, using window.screen.orientation is more explicit about what I want... like: var current = screen.orientation; console.log(ok! locking it to:, current ); screen.lockOrientation(current); current is more like requesting. That's just me tho. If 'current' is added, I wouldn't say that there is a race condition issue because if you lock to 'current' you do not really care about the actual orientation. This said, I do not think that 'current' is very useful from the JS API, it only saves a few characters. -- Mounir
Re: [screen-orientation] screen orientation angle
I am OK with this. When discussing with John Mellor, we also concluded that screen.orientationAngle was useful, due to the exact same reasons. Allowing lockOrientation to take either a string (with simple to use defaults) and take an angle for the more advanced use-cases, sounds like a pretty good compromise. Some questions: a) Will this be a delta from the current orientation? or relative to the default device orientation? I guess the former makes the most sense. b) What should happen if the device is already busy changing orientation when the request is done? I think failing might make the most sense. When we are moving to promises I would rename it to requestOrientationLock though as it fits more inline with other APIs. Kenneth On Tue, Nov 26, 2013 at 5:38 PM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, The Screen Orientation API defines an angle relationship between portrait-primary and landscape-primary. The reason for that is that developers would know which orientation is at 90 degrees from the current orientation, which one is at 180 degrees, etc. However, by forcing the two primary orientations to have a relationship, we prevent UA to do clever things like having landscape-primary being related to how the user uses his phone (eg. usually depending on which hand is used, the most common landscape is not going to be different). In addition, some use cases might need to know the angle between the current orientation and the native device orientation. For example, a compass using DeviceOrientation would need to know this angle to be able to draw the correct information on the screen [1]. This is also a UC that Mozilla has with Firefox OS where some apps want to lock the orientation to the native device orientation (ie. angle=0) [2]. So, the Screen Orientation API should allow locking to a specific orientation angle. For that, we could allow an integer to be passed to the lockOrientation() function, a modulo operation would be applied on the number to have it in the [0; 360[ range. If the UA is not able to lock to the specified angle, the method should fail (return false for the moment, the promise should fail in the future). The orientation angle should also be read. It would be possible to simply use window.orientation. I am not a big fan of that solution [3] but this is implemented by most Mobile UAs already so it might as well be the best thing to do. An alternative would be to have something like screen.orientationAngle or screen.orientation.angle (and screen.orientation.name). WDYT? [1] http://oldworld.fr/google/compass.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058 [3] the value can be negative, which is a footgun and the having this value living in window and the rest in window.screen is odd -- Mounir -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [screen-orientation] screen orientation angle
On Wed, Nov 27, 2013, at 3:49, Kenneth Rohde Christiansen wrote: a) Will this be a delta from the current orientation? or relative to the default device orientation? I guess the former makes the most sense. Orientation angle compared to the native device orientation. b) What should happen if the device is already busy changing orientation when the request is done? I think failing might make the most sense. That sounds a bit orthogonal to the thread but I would say that if you do screen.lockOrientation(0); screen.lockOrientation(90); both calls should succeed even though the orientation might never be locked to the 0 angle. When we are moving to promises I would rename it to requestOrientationLock though as it fits more inline with other APIs. I was not aware of that convention. Do you have examples? (other than fullscreen) -- Mounir
Re: [screen-orientation] screen orientation angle
Hi On Tue, Nov 26, 2013 at 5:55 PM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, Nov 27, 2013, at 3:49, Kenneth Rohde Christiansen wrote: a) Will this be a delta from the current orientation? or relative to the default device orientation? I guess the former makes the most sense. Orientation angle compared to the native device orientation. OK, that is fine with me, and it would allow for things like requestOrientationLock(screen.orientationAngle), and we can get rid of portrait-secondary etc for advanced use-cases. b) What should happen if the device is already busy changing orientation when the request is done? I think failing might make the most sense. That sounds a bit orthogonal to the thread but I would say that if you do screen.lockOrientation(0); screen.lockOrientation(90); both calls should succeed even though the orientation might never be locked to the 0 angle. and what if I do, -90 and 90 300ms after? so it will start rotating in one direction, and it might flip direction? It could of course continue on its current path. So it should succeed if the target value is possible. I am fine with that. When we are moving to promises I would rename it to requestOrientationLock though as it fits more inline with other APIs. I was not aware of that convention. Do you have examples? (other than fullscreen) That was my example. I like it more as it really is a request which might be rejected. There are other examples in Blink though: MIDIAccessPromise requestMIDIAccess(optional Dictionary options); and non-promise based requestQuota, requestPermission, requestAnimationFrame, requestAutocomplete. Kenneth -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
RE: [screen-orientation] screen orientation angle
It would be a shame to continue the trend of verbose web APIs. lockOrientation is nice. If it fails, the promise is rejected. Many operations can fail; this is not an argument for prefixing them with request. Just lock the orientation. If there's a problem locking it, we'll deal with it :) (But I admit the ship may have sailed and verbose web APIs is the precedent we must stick with.) MIDIAccessPromise requestMIDIAccess(optional Dictionary options); I am very curious what a MIDIAccessPromise is and how Blink implements it. It is not part of the ES6 promises spec.
Re: [screen-orientation] screen orientation angle
This all sounds reasonable; it's great that we'll be able to remove the spec's artificial requirement that if the device is in landscape-primary and is rotated 90 degrees clockwise, that should be represented as portrait-primary. And it potentially opens the door to using a less error-prone selection of keywords too. On Tue, Nov 26, 2013 at 4:38 PM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, The Screen Orientation API defines an angle relationship between portrait-primary and landscape-primary. The reason for that is that developers would know which orientation is at 90 degrees from the current orientation, which one is at 180 degrees, etc. However, by forcing the two primary orientations to have a relationship, we prevent UA to do clever things like having landscape-primary being related to how the user uses his phone (eg. usually depending on which hand is used, the most common landscape is not going to be different). In addition, some use cases might need to know the angle between the current orientation and the native device orientation. For example, a compass using DeviceOrientation would need to know this angle to be able to draw the correct information on the screen [1]. This is also a UC that Mozilla has with Firefox OS where some apps want to lock the orientation to the native device orientation (ie. angle=0) [2]. So, the Screen Orientation API should allow locking to a specific orientation angle. For that, we could allow an integer to be passed to the lockOrientation() function, a modulo operation would be applied on the number to have it in the [0; 360[ range. If the UA is not able to lock to the specified angle, the method should fail (return false for the moment, the promise should fail in the future). The orientation angle should also be read. It would be possible to simply use window.orientation. I am not a big fan of that solution [3] but this is implemented by most Mobile UAs already so it might as well be the best thing to do. An alternative would be to have something like screen.orientationAngle or screen.orientation.angle (and screen.orientation.name). WDYT? [1] http://oldworld.fr/google/compass.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058 [3] the value can be negative, which is a footgun and the having this value living in window and the rest in window.screen is odd -- Mounir
Re: [screen-orientation] screen orientation angle
+1 to this new angle ;) Seriously, it would be great if we can finally get closer to a solution where (especially) new web apps developers will not get too confused about different representations of orientation between different specs and devices. It would be great with some reference apps to hold this up against while the spec is still possible to change. If anyone feels it makes sense, I'd be happy to chip in with that. One thing that is not 100% clear to me if handled yet though: IMO, it would make sense to agree on portrait or landscape to be *the* primary orientation for all devices - and let everything else be a relative angle (in degrees) to that. Most cases where developers will need this feature will be for games utilizing the accelerometer (xyz readings) AND they will most likely design the game for portrait or landscape use. Not having to deal with differences between landscape/portrait devices but just be able to rely on (X,Y,Z) = (0,1,0) when holding the device portrait up in all cases will eliminate one layer of mapping. If this is already handled here, I am sorry for repeating myself. best wishes Lars On Tue, Nov 26, 2013 at 9:25 AM, John Mellor joh...@google.com wrote: This all sounds reasonable; it's great that we'll be able to remove the spec's artificial requirement that if the device is in landscape-primary and is rotated 90 degrees clockwise, that should be represented as portrait-primary. And it potentially opens the door to using a less error-prone selection of keywords too. On Tue, Nov 26, 2013 at 4:38 PM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, The Screen Orientation API defines an angle relationship between portrait-primary and landscape-primary. The reason for that is that developers would know which orientation is at 90 degrees from the current orientation, which one is at 180 degrees, etc. However, by forcing the two primary orientations to have a relationship, we prevent UA to do clever things like having landscape-primary being related to how the user uses his phone (eg. usually depending on which hand is used, the most common landscape is not going to be different). In addition, some use cases might need to know the angle between the current orientation and the native device orientation. For example, a compass using DeviceOrientation would need to know this angle to be able to draw the correct information on the screen [1]. This is also a UC that Mozilla has with Firefox OS where some apps want to lock the orientation to the native device orientation (ie. angle=0) [2]. So, the Screen Orientation API should allow locking to a specific orientation angle. For that, we could allow an integer to be passed to the lockOrientation() function, a modulo operation would be applied on the number to have it in the [0; 360[ range. If the UA is not able to lock to the specified angle, the method should fail (return false for the moment, the promise should fail in the future). The orientation angle should also be read. It would be possible to simply use window.orientation. I am not a big fan of that solution [3] but this is implemented by most Mobile UAs already so it might as well be the best thing to do. An alternative would be to have something like screen.orientationAngle or screen.orientation.angle (and screen.orientation.name). WDYT? [1] http://oldworld.fr/google/compass.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058 [3] the value can be negative, which is a footgun and the having this value living in window and the rest in window.screen is odd -- Mounir
Re: [screen-orientation] screen orientation angle
Lars wrote: it would make sense to agree on portrait or landscape to be *the* primary orientation for all devices Hmm, but some devices don't have a primary portrait orientation. For example the Motorola Xoom has a clear primary landscape orientation, but users are equally likely to hold it in either portrait orientation (depending on handedness, etc). So games would at least need to deal with 180 degree rotations of the device orientation. It seems a better option would be for the Device Orientation API to provide values relative to the current screen up direction. This could be optional if anyone can think of use cases where you both a) need absolute device orientation, and b) wouldn't have already locked the screen orientation. On Tue, Nov 26, 2013 at 5:59 PM, Lars Knudsen lar...@gmail.com wrote: +1 to this new angle ;) Seriously, it would be great if we can finally get closer to a solution where (especially) new web apps developers will not get too confused about different representations of orientation between different specs and devices. It would be great with some reference apps to hold this up against while the spec is still possible to change. If anyone feels it makes sense, I'd be happy to chip in with that. One thing that is not 100% clear to me if handled yet though: IMO, it would make sense to agree on portrait or landscape to be *the* primary orientation for all devices - and let everything else be a relative angle (in degrees) to that. Most cases where developers will need this feature will be for games utilizing the accelerometer (xyz readings) AND they will most likely design the game for portrait or landscape use. Not having to deal with differences between landscape/portrait devices but just be able to rely on (X,Y,Z) = (0,1,0) when holding the device portrait up in all cases will eliminate one layer of mapping. If this is already handled here, I am sorry for repeating myself. best wishes Lars On Tue, Nov 26, 2013 at 9:25 AM, John Mellor joh...@google.com wrote: This all sounds reasonable; it's great that we'll be able to remove the spec's artificial requirement that if the device is in landscape-primary and is rotated 90 degrees clockwise, that should be represented as portrait-primary. And it potentially opens the door to using a less error-prone selection of keywords too. On Tue, Nov 26, 2013 at 4:38 PM, Mounir Lamouri mou...@lamouri.frwrote: Hi, The Screen Orientation API defines an angle relationship between portrait-primary and landscape-primary. The reason for that is that developers would know which orientation is at 90 degrees from the current orientation, which one is at 180 degrees, etc. However, by forcing the two primary orientations to have a relationship, we prevent UA to do clever things like having landscape-primary being related to how the user uses his phone (eg. usually depending on which hand is used, the most common landscape is not going to be different). In addition, some use cases might need to know the angle between the current orientation and the native device orientation. For example, a compass using DeviceOrientation would need to know this angle to be able to draw the correct information on the screen [1]. This is also a UC that Mozilla has with Firefox OS where some apps want to lock the orientation to the native device orientation (ie. angle=0) [2]. So, the Screen Orientation API should allow locking to a specific orientation angle. For that, we could allow an integer to be passed to the lockOrientation() function, a modulo operation would be applied on the number to have it in the [0; 360[ range. If the UA is not able to lock to the specified angle, the method should fail (return false for the moment, the promise should fail in the future). The orientation angle should also be read. It would be possible to simply use window.orientation. I am not a big fan of that solution [3] but this is implemented by most Mobile UAs already so it might as well be the best thing to do. An alternative would be to have something like screen.orientationAngle or screen.orientation.angle (and screen.orientation.name). WDYT? [1] http://oldworld.fr/google/compass.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058 [3] the value can be negative, which is a footgun and the having this value living in window and the rest in window.screen is odd -- Mounir
RE: publish LCWD of DOM Parsing and Serialization; deadline November 25
Resolved it today. Took one more change to the ED draft to update the SOTD, Acknowledgements section, and document headers. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 26, 2013 5:46 AM To: Travis Leithead Cc: Webapps WG Subject: Re: publish LCWD of DOM Parsing and Serialization; deadline November 25 Travis - what is the plan for https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938? -Thanks, AB On 11/25/13 7:23 PM, ext Travis Leithead wrote: I've finished the major updates. Today's ED draft at: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html should be ready to use as the baseline for the Last Call CfC. Thanks, Travis -Original Message- From: Travis Leithead Sent: Monday, November 18, 2013 11:26 AM To: Webapps WG Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November 25 If possible, I'd like to delay this CfC, for a week--I have some major updates to the ED in-flight, and I want to make sure we base the CfC on the right ED content :-) Hopefully this is workable to the group. Thanks! - From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 18, 2013 4:00 AM This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and Serialization, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call 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 Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Currently, this spec has one Editorial bug [18939] that is open and Travis will fix this before the LCWD is published. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by November 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, please let me know. -Thanks, AB [18939] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938 Original Message Subject: ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) Date: Mon, 11 Nov 2013 01:59:39 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/701 On: Arthur Barstow Due: 2013-11-18 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
Earlier today Travis closed the last open bug for DOM Parsing and Serialization so this is a Call for Consensus (CfC) to publish a LCWD of that spec, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call 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 Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by December 3 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) or external SDOs we should ask to review the LCWD, please let us know. -Thanks, AB
Re: [screen-orientation] screen orientation angle
On Wed, 27 Nov 2013 01:22:47 +0700, John Mellor joh...@google.com wrote: Lars wrote: it would make sense to agree on portrait or landscape to be *the* primary orientation for all devices Hmm, but some devices don't have a primary portrait orientation. For example the Motorola Xoom has a clear primary landscape orientation, but users are equally likely to hold it in either portrait orientation (depending on handedness, etc). So games would at least need to deal with 180 degree rotations of the device orientation. In fact, if you know the handedness of the user (heuristically available from the orientations the user chooses freely), you can request the e.g. portrait orientation that makes sense. On some devices (e.g. with game controllers) this is almost irrelevant, as virtually nobody uses them upside down, but on phones with a couple of extra keys - e.g. most camera apps, or where you primarily move from talking to looking and back, it seems like a reasonable use case. It seems a better option would be for the Device Orientation API to provide values relative to the current screen up direction. This could be optional if anyone can think of use cases where you both a) need absolute device orientation, and b) wouldn't have already locked the screen orientation. Initialising an app that uses visual display and the accelerometer, or where you use two orientations (e.g. portrait for entering data, followed by switching to landscape)... cheers Chaals On Tue, Nov 26, 2013 at 5:59 PM, Lars Knudsen lar...@gmail.com wrote: +1 to this new angle ;) Seriously, it would be great if we can finally get closer to a solution where (especially) new web apps developers will not get too confused about different representations of orientation between different specs and devices. It would be great with some reference apps to hold this up against while the spec is still possible to change. If anyone feels it makes sense, I'd be happy to chip in with that. One thing that is not 100% clear to me if handled yet though: IMO, it would make sense to agree on portrait or landscape to be *the* primary orientation for all devices - and let everything else be a relative angle (in degrees) to that. Most cases where developers will need this feature will be for games utilizing the accelerometer (xyz readings) AND they will most likely design the game for portrait or landscape use. Not having to deal with differences between landscape/portrait devices but just be able to rely on (X,Y,Z) = (0,1,0) when holding the device portrait up in all cases will eliminate one layer of mapping. If this is already handled here, I am sorry for repeating myself. best wishes Lars On Tue, Nov 26, 2013 at 9:25 AM, John Mellor joh...@google.com wrote: This all sounds reasonable; it's great that we'll be able to remove the spec's artificial requirement that if the device is in landscape-primary and is rotated 90 degrees clockwise, that should be represented as portrait-primary. And it potentially opens the door to using a less error-prone selection of keywords too. On Tue, Nov 26, 2013 at 4:38 PM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, The Screen Orientation API defines an angle relationship between portrait-primary and landscape-primary. The reason for that is that developers would know which orientation is at 90 degrees from the current orientation, which one is at 180 degrees, etc. However, by forcing the two primary orientations to have a relationship, we prevent UA to do clever things like having landscape-primary being related to how the user uses his phone (eg. usually depending on which hand is used, the most common landscape is not going to be different). In addition, some use cases might need to know the angle between the current orientation and the native device orientation. For example, a compass using DeviceOrientation would need to know this angle to be able to draw the correct information on the screen [1]. This is also a UC that Mozilla has with Firefox OS where some apps want to lock the orientation to the native device orientation (ie. angle=0) [2]. So, the Screen Orientation API should allow locking to a specific orientation angle. For that, we could allow an integer to be passed to the lockOrientation() function, a modulo operation would be applied on the number to have it in the [0; 360[ range. If the UA is not able to lock to the specified angle, the method should fail (return false for the moment, the promise should fail in the future). The orientation angle should also be read. It would be possible to simply use window.orientation. I am not a big fan of that solution [3] but this is implemented by most Mobile UAs already so it might as well be the best thing to do. An alternative would be to have something like screen.orientationAngle or
Re: [screen-orientation] screen orientation angle
Hi, It seems a better option would be for the Device Orientation API to provide values relative to the current screen up direction. This could be optional if anyone can think of use cases where you both a) need absolute device orientation, and b) wouldn't have already locked the screen orientation. I think it would be great if the device orientation could have an argument or setting like 'followOrientation or similar. Kenneth
New manifest spec - ready for FPWD?
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: http://w3c-webmob.github.io/installable-webapps/ That (ongoing) research is helping to inform the manifest spec. A bunch of us have been working together on IRC, twitter, etc. on a new version of the manifest spec: http://w3c.github.io/manifest/ The Editors would appreciate if people take a look and see if you agree with the feature set. ** Right now, please refrain from bike-shedding! ** Unless anyone objects, the Editors would like to request the start of a CFC towards publishing a FPWD of the manifest spec. -- Marcos Caceres
Re: New manifest spec - ready for FPWD?
On 11/26/13, 1:02 PM, Marcos Caceres w...@marcosc.com 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: http://w3c-webmob.github.io/installable-webapps/ That (ongoing) research is helping to inform the manifest spec. A bunch of us have been working together on IRC, twitter, etc. on a new version of the manifest spec: http://w3c.github.io/manifest/ The Editors would appreciate if people take a look and see if you agree with the feature set. Are there any connections between the new Manifest spec and the configuration document specified [1] in Packaged Web Apps? Have all of the attributes that go into a configuration been considered as possible Manifest members? Going by the use cases document, there are at least two characteristics (offline, no navigation bar) that define a standalone app. Are there any more characteristics that a standalone app should have? Should these be noted in the spec? Could there be any benefit to enumerating these characteristics in the manifest? I¹m wondering whether it would be useful to say that the web app provides a native app UI but still requires the device to be online. Thanks, Alan [1] http://www.w3.org/TR/2012/REC-widgets-20121127/#configuration-document
Re: New manifest spec - ready for FPWD?
Hi, The idea is that the manifest as described in the current spec should be as simple as possible, and just cover the use-cases of bookmarks and hosted web apps (save to home screen and the like). This allows for the spec to be more broadly applicable and hopefully get support from most vendors. The base manifest as described in the spec, can be extended by other extension specs; and we are considering doing exactly that for packaged apps as part of the SysApps work. Cheers, Kenneth On Tue, Nov 26, 2013 at 11:00 PM, Alan Stearns stea...@adobe.com wrote: On 11/26/13, 1:02 PM, Marcos Caceres w...@marcosc.com 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: http://w3c-webmob.github.io/installable-webapps/ That (ongoing) research is helping to inform the manifest spec. A bunch of us have been working together on IRC, twitter, etc. on a new version of the manifest spec: http://w3c.github.io/manifest/ The Editors would appreciate if people take a look and see if you agree with the feature set. Are there any connections between the new Manifest spec and the configuration document specified [1] in Packaged Web Apps? Have all of the attributes that go into a configuration been considered as possible Manifest members? Going by the use cases document, there are at least two characteristics (offline, no navigation bar) that define a standalone app. Are there any more characteristics that a standalone app should have? Should these be noted in the spec? Could there be any benefit to enumerating these characteristics in the manifest? I¹m wondering whether it would be useful to say that the web app provides a native app UI but still requires the device to be online. Thanks, Alan [1] http://www.w3.org/TR/2012/REC-widgets-20121127/#configuration-document -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [HTML Imports]: Sync, async, -ish?
(way behind, slowly catching up...) On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote: Steve and I talked at the Chrome Dev Summit today and generated an idea that may align the stars for our async/sync needs: link rel=import elements=x-foo, x-bar / +1. I think this is the right default: async by default, and the wrong thing to do (i.e. blocking) requires additional code and explicit opt-in. If you end up with a super-long elements list (as shown by dfreedm@), then that also serves as a great indicator that you're likely doing it wrong -- you have too many blocking elements and a performance liability on your hands.
Re: New manifest spec - ready for FPWD?
That's a great overview! There's 2 points I think haven't fully been addressed. 1. Section 8. Navigation Much of this work (and HTML5 in general) is about bringing the Web Platform up to being equal with native apps. But one thing that the Web does that native apps can't do is deep linking (ignoring the fustercluck of intents). I think it would provide a significant advantage if it was also possible to deep link into installed web apps. I understand this is very complex and I'm not proposing any solution right now. But if we don't include this then we are in effect cutting web applications down to the level of native apps instead of leaping ahead of them. Use Case: Social sharing User A and User B both have the same web app installed on the devices they are using. User A finds a resource they like inside the app and decide to share this from within the app through one of their social networks. User B sees this link in their social feed and taps on it. Since User B also has this web app installed it would be nice to be able to open that resource directly within the installed app. Otherwise User X's browser would just open it like a normal web resource. This can also be relevant for the same user using the same web app across multiple devices. NOTE: This is one of the key drivers we have found for building business cases of Web instead of Native. 2. Section 6. Start page This is lightly touched on and slightly related to the point above, but the common experience especially on iOS is that even when you background an installed app and then foreground it again it reloads the entire state. This effectively breaks the UX and makes this mode almost unusable. It's definitely possible to use localStorage, etc. to work around this but the UX is horrible. Allowing installed apps to persist their resources and loaded state across background/foreground (and ideally even launches) would be a massive step forward. Perhaps naming this a First use page would help clarify this focus? roBman On 27/11/13 8:02 AM, 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: http://w3c-webmob.github.io/installable-webapps/ That (ongoing) research is helping to inform the manifest spec. A bunch of us have been working together on IRC, twitter, etc. on a new version of the manifest spec: http://w3c.github.io/manifest/ The Editors would appreciate if people take a look and see if you agree with the feature set. ** Right now, please refrain from bike-shedding! ** Unless anyone objects, the Editors would like to request the start of a CFC towards publishing a FPWD of the manifest spec.
Re: Cross Origin Web Components: Fixing iframes
On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, I have been having informal discussions of our earlier proposal for cross-orign use cases and declarative syntax for web components, and I realized there was a lot of confusion about our motivations and decision decisions. So I wanted to explain why/how we came up that proposal in this email. *Problem*: A lot of websites embed SNS widgets, increasing the security surface of embedders. The old version of techcrunch.com, for example, had 5+ social share buttons on each article. If any one of those SNS websites got compromised, then the embedder will also get compromised. This is a valid problem. Does anyone have related use cases that might be in-scope for this discussion? *What if we used iframe?* What if we replaced each such instance with an iframe? That would give us a security boundary. On the other hand, using an iframe for each social button is very expensive because each iframe loads a document, creates its own security origin, JS global object, and so forth. Initializing new script context (a.k.a. VM, world, isolate, etc…) for every single SNS widget on a page is quite expensive. If we had 10 articles, and each article had 5 social buttons, we'll have 50 iframes, each of which needs to load megabytes of JavaScript. iframe is also heavily restricted in terms of its ability to layout itself. Comment widgets (e.g. DISQUS) for example need to stretch themselves to the height of its content. We also need a better mechanism to pass arguments and communicate with cross-origin frames than postMessage. *What if we made iframe lighter used seamless iframe?* The cost of iframe could be reduced substantially if we cached and internally shared each page's JavaScript. However, we still have to instantiate its own script context, document, and window objects. We can also use seamless iframe to address the comment widget use case. *What if we let each iframe create multiple views?* The problem with using an iframe for a cross-origin widget is that each iframe creates its own document, window, etc… even if there are multiple widgets from the same origin. e.g. if we had a tweet button on 10 different articles, we have to create its own document ,window, etc… for each tweet button. We can reduce this cost if we could share the single frame, and have it render multiple views. Naturally, each such view will be represented as a separate DOM tree. In this model, a single iframe owns multiple DOM trees, each of which will be displayed at different locations in the host document. Each such a DOM tree is inaccessible from the host document, and the host document is inaccessible from the iframe. This model dramatically reduces the cost of having multiple widgets from the same origin. e.g. if we have 10 instances of widgets from 5 different social networks, then we'll have only 5 iframes (each of which will have 10 views) as opposed to 50 of them. *What if we provided a declarative syntax to create such a view?* Providing a better API proved to be challenging. We could have let page authors register a custom element for each cross-origin widget but that would mean that page authors have to write a lot of script just to embed some third-party widgets. We need some declarative syntax to let authors wrap an iframe. Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll need a mechanism to declare where each instance of such a view is placed in the host document with arguments/configuration options for each view. A custom element seemed like a natural fit for this task but the prototype/element object cannot be instantiated in the host document since the cross-origin widgets' script can't run in the host document and prototype objects, etc… cannot be shared between the host document and the shared iframes. So we'll need some mechanism for the shared iframe to define custom element names, and have the host document explicitly import them as needed. At this point, the set of features we needed looked very similar to the existing custom element and shadow DOM. Each view of the shared iframe was basically a shadow DOM with a security boundary sitting between the host element and the shadow root. The declarative syntax for the view was basically a declarative syntax of a custom element that happens to instantiate a shadow DOM with a caveat that the shadow host is inaccessible form the component, and the shadow DOM is inaccessible from the host document. It also seemed natural for such an shared iframe to be loaded using HTML imports. You can think of our proposal as breaking iframe down into two pieces: 1. Creating a new document/window 2. Creating a new view I think decomposing the problem this way is a good step. Re: creating a new document/window, purely in terms of *mechanics*, IFRAME does this already. Is
Re: Cross Origin Web Components: Fixing iframes
On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote: On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, I have been having informal discussions of our earlier proposal for cross-orign use cases and declarative syntax for web components, and I realized there was a lot of confusion about our motivations and decision decisions. So I wanted to explain why/how we came up that proposal in this email. Problem: A lot of websites embed SNS widgets, increasing the security surface of embedders. The old version of techcrunch.com, for example, had 5+ social share buttons on each article. If any one of those SNS websites got compromised, then the embedder will also get compromised. This is a valid problem. Does anyone have related use cases that might be in-scope for this discussion? Comment forms (e.g. DISQUS) is another important use case. What if we used iframe? What if we replaced each such instance with an iframe? That would give us a security boundary. On the other hand, using an iframe for each social button is very expensive because each iframe loads a document, creates its own security origin, JS global object, and so forth. Initializing new script context (a.k.a. VM, world, isolate, etc…) for every single SNS widget on a page is quite expensive. If we had 10 articles, and each article had 5 social buttons, we'll have 50 iframes, each of which needs to load megabytes of JavaScript. iframe is also heavily restricted in terms of its ability to layout itself. Comment widgets (e.g. DISQUS) for example need to stretch themselves to the height of its content. We also need a better mechanism to pass arguments and communicate with cross-origin frames than postMessage. What if we made iframe lighter used seamless iframe? The cost of iframe could be reduced substantially if we cached and internally shared each page's JavaScript. However, we still have to instantiate its own script context, document, and window objects. We can also use seamless iframe to address the comment widget use case. What if we let each iframe create multiple views? The problem with using an iframe for a cross-origin widget is that each iframe creates its own document, window, etc… even if there are multiple widgets from the same origin. e.g. if we had a tweet button on 10 different articles, we have to create its own document ,window, etc… for each tweet button. We can reduce this cost if we could share the single frame, and have it render multiple views. Naturally, each such view will be represented as a separate DOM tree. In this model, a single iframe owns multiple DOM trees, each of which will be displayed at different locations in the host document. Each such a DOM tree is inaccessible from the host document, and the host document is inaccessible from the iframe. This model dramatically reduces the cost of having multiple widgets from the same origin. e.g. if we have 10 instances of widgets from 5 different social networks, then we'll have only 5 iframes (each of which will have 10 views) as opposed to 50 of them. What if we provided a declarative syntax to create such a view? Providing a better API proved to be challenging. We could have let page authors register a custom element for each cross-origin widget but that would mean that page authors have to write a lot of script just to embed some third-party widgets. We need some declarative syntax to let authors wrap an iframe. Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll need a mechanism to declare where each instance of such a view is placed in the host document with arguments/configuration options for each view. A custom element seemed like a natural fit for this task but the prototype/element object cannot be instantiated in the host document since the cross-origin widgets' script can't run in the host document and prototype objects, etc… cannot be shared between the host document and the shared iframes. So we'll need some mechanism for the shared iframe to define custom element names, and have the host document explicitly import them as needed. At this point, the set of features we needed looked very similar to the existing custom element and shadow DOM. Each view of the shared iframe was basically a shadow DOM with a security boundary sitting between the host element and the shadow root. The declarative syntax for the view was basically a declarative syntax of a custom element that happens to instantiate a shadow DOM with a caveat that the shadow host is inaccessible form the component, and the shadow DOM is inaccessible from the host document. It also seemed natural for such an shared iframe to be loaded using HTML imports. You can think of our proposal as breaking iframe down into two pieces: Creating a new document/window
Re: Cross Origin Web Components: Fixing iframes
On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote: On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, I have been having informal discussions of our earlier proposal for cross-orign use cases and declarative syntax for web components, and I realized there was a lot of confusion about our motivations and decision decisions. So I wanted to explain why/how we came up that proposal in this email. *Problem*: A lot of websites embed SNS widgets, increasing the security surface of embedders. The old version of techcrunch.com, for example, had 5+ social share buttons on each article. If any one of those SNS websites got compromised, then the embedder will also get compromised. This is a valid problem. Does anyone have related use cases that might be in-scope for this discussion? Comment forms (e.g. DISQUS) is another important use case. *What if we used iframe?* What if we replaced each such instance with an iframe? That would give us a security boundary. On the other hand, using an iframe for each social button is very expensive because each iframe loads a document, creates its own security origin, JS global object, and so forth. Initializing new script context (a.k.a. VM, world, isolate, etc…) for every single SNS widget on a page is quite expensive. If we had 10 articles, and each article had 5 social buttons, we'll have 50 iframes, each of which needs to load megabytes of JavaScript. iframe is also heavily restricted in terms of its ability to layout itself. Comment widgets (e.g. DISQUS) for example need to stretch themselves to the height of its content. We also need a better mechanism to pass arguments and communicate with cross-origin frames than postMessage. *What if we made iframe lighter used seamless iframe?* The cost of iframe could be reduced substantially if we cached and internally shared each page's JavaScript. However, we still have to instantiate its own script context, document, and window objects. We can also use seamless iframe to address the comment widget use case. *What if we let each iframe create multiple views?* The problem with using an iframe for a cross-origin widget is that each iframe creates its own document, window, etc… even if there are multiple widgets from the same origin. e.g. if we had a tweet button on 10 different articles, we have to create its own document ,window, etc… for each tweet button. We can reduce this cost if we could share the single frame, and have it render multiple views. Naturally, each such view will be represented as a separate DOM tree. In this model, a single iframe owns multiple DOM trees, each of which will be displayed at different locations in the host document. Each such a DOM tree is inaccessible from the host document, and the host document is inaccessible from the iframe. This model dramatically reduces the cost of having multiple widgets from the same origin. e.g. if we have 10 instances of widgets from 5 different social networks, then we'll have only 5 iframes (each of which will have 10 views) as opposed to 50 of them. *What if we provided a declarative syntax to create such a view?* Providing a better API proved to be challenging. We could have let page authors register a custom element for each cross-origin widget but that would mean that page authors have to write a lot of script just to embed some third-party widgets. We need some declarative syntax to let authors wrap an iframe. Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll need a mechanism to declare where each instance of such a view is placed in the host document with arguments/configuration options for each view. A custom element seemed like a natural fit for this task but the prototype/element object cannot be instantiated in the host document since the cross-origin widgets' script can't run in the host document and prototype objects, etc… cannot be shared between the host document and the shared iframes. So we'll need some mechanism for the shared iframe to define custom element names, and have the host document explicitly import them as needed. At this point, the set of features we needed looked very similar to the existing custom element and shadow DOM. Each view of the shared iframe was basically a shadow DOM with a security boundary sitting between the host element and the shadow root. The declarative syntax for the view was basically a declarative syntax of a custom element that happens to instantiate a shadow DOM with a caveat that the shadow host is inaccessible form the component, and the shadow DOM is inaccessible from the host document. It also seemed natural for such an shared iframe to be loaded using HTML imports. You can think of our proposal as breaking iframe down into two pieces: 1. Creating a
