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
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
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);
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');
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
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
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
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
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
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
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.
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 :)
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
+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
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
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:
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
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
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
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
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:
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
(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
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
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
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
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
27 matches
Mail list logo
