Re: I18N comments on Manifest for Web applications
As far as I know, you can watch individual issues with GitHub, so you could create a GitHub account with that email address and then watch relevant issues. Also it would mean that an email would be sent if someone mentioned the user (ie @www-international) in any issue Kenneth On Tue, Mar 24, 2015 at 3:25 PM Richard Ishida ish...@w3.org wrote: is it possible to send mail to www-internatio...@w3.org each time someone adds somethign to the github issue? (this is the list where we track and discuss issues). if so, i see no real difference between using github or bugzilla – our process is designed to cope with both bugzilla and email based comments (though it would normally be better to start with the right one rather than switch part way, so changing the SOD would indeed help). we should also ensure, however, that the titles of the issues and any associated notification mails always contain the i18n-issue-xxx string that will allow us and tracker to locate information for a given thread. ri On 20/03/2015 16:40, Christiansen, Kenneth R wrote: Marcos, Anssi, what do you think? I would prefer the comments on GitHub as it seems to be a great place for interacting with the web community, judging from our success so far. Kenneth -Original Message- From: Phillips, Addison [mailto:addi...@lab126.com] Sent: Friday, March 20, 2015 4:43 PM To: Christiansen, Kenneth R; public-webapps@w3.org Cc: public-i18n-c...@w3.org Subject: RE: I18N comments on Manifest for Web applications Hi Kenneth, Thanks for the reply. I know you're using GitHub. However, whenever I'm filing/forwarding comments on a document on behalf of the Working Group, I always look at the SOTD in the document in question to see what instructions the receiving WG has. In this case, you have a fairly generic SOTD, which says in part: -- This document was published by the Web Applications (WebApps) Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). All comments are welcome. -- If you prefer to have comments filed to GitHub, perhaps modify your instructions? Thanks! Addison Addison Phillips Globalization Architect (Amazon Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. -Original Message- From: Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com] Sent: Friday, March 20, 2015 1:15 AM To: Phillips, Addison; public-webapps@w3.org Cc: public-i18n-c...@w3.org Subject: RE: I18N comments on Manifest for Web applications Hi there, The spec authors use GitHub for issue tracking. I duplicated your issues there: https://github.com/w3c/manifest/issues Thanks for looking into internationalization issues with the current spec. Cheers, Kenneth -Original Message- From: Phillips, Addison [mailto:addi...@lab126.com] Sent: Thursday, March 19, 2015 6:20 PM To: public-webapps@w3.org Cc: public-i18n-c...@w3.org Subject: I18N comments on Manifest for Web applications Hello Webapps, As previously mentioned, I am about to send you comments from the Internationalization Working Group on your document (whose current iteration lives at [1]). Because we use Tracker for our comments, I will be sending each comment under separate cover. The I18N WG is always happy to discuss our comments or ways to address same. Please let me know if you prefer to receive comments in a different format (such as Bugzilla) or if you need additional information. If you want to see a summary of our comments, you can find them tracked at [2] Regards (for I18N) Addison [1] http://www.w3.org/TR/appmanifest/ [2] http://www.w3.org/International/track/products/74 Addison Phillips Globalization Architect (Amazon Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture.
Re: [manifest] RE: Manifest for web application; review deadline March 5
Hi Claes, The web app manifest spec allows extensions (it has extension points), so we would expect the Permissions WG/CG to come up with a proper way to deal with permissions. If they come to the conclusion that we need some permission field in the manifest, their spec can add that. It is not yet clear at this point that that is the solution that they are aiming at. Cheers, Kenneth On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: Hi, We support that this version of the specification is moved to Candidate status but we have a few comments/questions: In this version 1 we miss: * A permissions field * A content security policy field. This is only included as a way to state allowed origins from which the manifest file itself could be loaded. However, there is, in this first version, no CSP-field defined for the manifest document, allowing restriction of origins the web app could download scripts and other content types from. There is also a draft companion document, http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest. We consider the above features important for allowing server hosted web apps access to more sensitive APIs and have been experimenting with this for FFOS: https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/ att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. Accordingly we want to discuss these features for the further work on the manifest specification. We also would like to ask the WG if it has been discussed if https: transport should be required for downloading the manifest? Other specifications are moving towards requirement for https:. See for example the discussion https://lists.w3.org/Archives/Public/public-device-apis/ 2015Feb/0045.html. For the manifest version 1 this may not be critical but if above features are added the transport probably have to be protected. However, once again note that these comments do not prevent that we support that the current version of the manifest is moved to candidate status, I am just taking the opportunity state our views on the further work on the manifest specification. Best regards Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nils...@sonymobile.com sonymobile.com -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: den 13 februari 2015 01:31 To: public-webapps Subject: RfC: Manifest for web application; review deadline March 5 [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps, public-digipub-ig, public-pfwg, public-web-mobile, www-international, chairs^1, public-review-announce; Reply-to: public-webapps ] This is a Request for Comments (RfC) for WebApp's Manifest for web application specification: http://www.w3.org/TR/2015/WD-appmanifest-20150212/ This specification defines a JSON-based manifest that provides developers with a centralized place to put metadata associated with a web application. This Working Draft is intended to meet the wide review requirements as defined in the 2014 Process Document. The deadline for comments is 5 March 2015 and all comments should be sent to the public-webapps @ w3.org mail list [Archive] with a Subject: prefix of [manifest]. The next anticipated publication of this specification is a Candidate Recommendation. (See [CR-Plan] for the specification's Candidate Recommendation status.) WebApps welcomes review and comments from all individuals and/or groups and we explicitly ask the following groups to review the document and to submit comments: WebAppSec, CSS WG (in particular, the display mode media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User Agent, Authoring Tools), and I18N WG. In addition to substantive comments, to help us get a sense of how much review the document receives, we also welcome data about silent reviews, f.ex. I reviewed section N.N and have no comments. -Thanks, AB ^1 RfC is the new LCWD TransAnn [CR-Plan] https://github.com/w3c/manifest/issues/308 [Archive] https://lists.w3.org/Archives/Public/public-webapps/
Re: Minimum viable custom elements
Anne, maybe you could write on the wiki what the current Web Components implementation in Chrome is using. That would make it a bit easier to follow for people who didn't follow all of the discussion so far. Kenneth On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com wrote: FWIW, I think that element upgrade is sort of fundamental to the usefulness of custom elements. In a world where most scripts are non-blocking (that's hopefully the modern world we should aim for), I'll effectively expect to walk the tree anyway. And if I walk the tree anyway, what's the point of custom elements in the first place? One of the key features (at least, to me) of custom elements was being able to harness the HTML Parser to instantiate your object tree. If that's not going happen consistently, then I am not sure custom elements are worth the trouble. IOW, if you're walking the tree, just do the work of callbacks as you encounter dash-separated elements. My rationale is this: * Unlike you I think lifecycle callbacks are the main selling point of a custom element. They give you access to hooks that normal elements have but are not otherwise exposed. * I think we could iterate towards a v2 that has an aspect of upgrading but perhaps works a bit differently from the current setup. E.g. a way to include an entire subtree of custom elements with a fallback mechanism of sorts. Or perhaps something inspired by JavaScript modules. * Upgrading can be added, but moving from Brain transplants to a more normal working constructor would be impossible after the fact. Now, given the discussion so far, it does seem that synchronous or almost-synchronous constructors have a number of hard issues and it's not entirely clear to me anymore those are worth pushing over Brain transplant or Dummy replacement, using the terminology from: https://wiki.whatwg.org/wiki/CustomElements#Upgrading -- https://annevankesteren.nl/
Re: Minimum viable custom elements
Thanks, this is very useful! On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Anne, maybe you could write on the wiki what the current Web Components implementation in Chrome is using. That would make it a bit easier to follow for people who didn't follow all of the discussion so far. I updated the page to point this out where it wasn't necessarily obvious (and ended up adding a row to the table): https://wiki.whatwg.org/wiki/CustomElements (I also gave Brain transplant an alternative name Dmitry as he made it look rather elegant :-)) -- https://annevankesteren.nl/
Re: [screen-orientation] Remove the ability to lock to multiple orientations?
I agree, and it was also a surprise to me when I first noticed that. I believe Wonsuk might know the history behind that decision. Kenneth On Fri, Mar 14, 2014 at 2:55 PM, Mounir Lamouri mou...@lamouri.fr wrote: On Fri, 14 Mar 2014, at 6:44, Kenneth Rohde Christiansen wrote: I am cc'ing Wonsuk and Christophe as Tizen is currently implementing (and shipping?) the API as well; it's even unprefixed. We are also supporting the current API in Crosswalk, but I am OK with the change as most of our current users are using Android which doesn't allow these specific locks. It is a bit surprising to see that API shipping un-prefixed given the current status of the specification. -- Mounir -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [screen-orientation] Remove the ability to lock to multiple orientations?
I am cc'ing Wonsuk and Christophe as Tizen is currently implementing (and shipping?) the API as well; it's even unprefixed. We are also supporting the current API in Crosswalk, but I am OK with the change as most of our current users are using Android which doesn't allow these specific locks. Cheers Kenneth On Thu, Mar 13, 2014 at 7:21 PM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, I would like to change the Screen Orientation API to make the locking steps a bit simpler. Currently, the API tries to be flexible and allow locking to any combination of values like portrait, landscape, portrait-primary but also [ portrait, landscape-primary ], [ portrait-primary, landscape-primary ]. The three first orientations are very common. The others are pretty odd and I doubt I ever saw that in the wild. Allowing to pass an array of orientation has a lot of impact on the specification: - given that the combinations are pretty exotic, we should assume that some UA will not be able to lock because the system will not allow it [1]; - we have the problem of whether all the items in the array should be available or only one of them to work. The specifacation currently answer the question of whether portrait = [ portrait-primary, portrait-secondary ] but what about [ landscape-primary, portrait-primary ]. Removing this feature will allow the specification to enforce that all states are working because it is fair to assume that the system will not block the UA to lock to those basic orientations. In addition, this would be a future-compatible change in the sense that adding this later will be smooth. I am really eager to make the specification a bit less flexible because right now, implementing this specification without being able to lock would be following the specification. I am particularly interested to hear feedback from Microsoft and Mozilla who have prefixed implementations. I know that Firefox Android only allows the basic orientations but Firefox OS allows any orientation to be passed I believed [2]. I unfortunately can't test IE11 on mobile. [1] Very likely, any UA could simply re-write the mechanism that listen for device orientation changes and do manual screen locking based on that, though... [2] http://mxr.mozilla.org/mozilla-central/source/widget/gonk/OrientationObserver.cpp -- Mounir -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review
I am fine with adding it (as CSP), but like Marcos, it would be great to know the plans for IE and Safari regarding ServiceWorker. Would it be an option to immediately work on L2 in parallel with L1 being moved to LC? Kenneth On Sun, Feb 16, 2014 at 11:16 AM, Marcos Caceres mar...@marcosc.com wrote: On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote: On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres w...@marcosc.com wrote: tl;dr: I strongly agree (and data below shows) that installable web apps without offline capabilities are essentially useless. Things currently specified in the manifest are supposed to help make these apps less useless (as I said in the original email, they by no means give us the dream of installable web apps, just one little step closer) - even if we had SW tomorrow, we would still need orientation, display mode, start URL, etc. So yes, SW and manifest will converge... questions for us to decide on is when? And if appcache can see us through this transitional period to having SW support in browsers? I believe we can initially standardize a limited set of functionality, while we continue to wait for SW to come into fruition which could take another year or two. SW will becoming to chrome ASAP. We're actively implementing. Jonas or Nikhil can probably provide more Mozilla context. I'm also interested in the WebKit and Microsoft context. I just don't know who to ask there. Have their been any public signals of their level of interest in SW? My personal view is that isn't not a good user experience to offer the affordance if the resulting system can't be trusted. That is to say, if we plow on with V1 without a (required) offline story, I'm not sure what we've really won. Happy for this to go to LC, but wouldn't recommend that Chrome For Android implement. I think this is good feedback. I'm happy to add (or for you to add;)) SW support to the manifest format. At least from Moz perspective it's fine as we are doing SW already. Anyone object to adding SW support to V1 of the manifest spec? Anything else that should be prioritized for V1? On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote: I further think that the marginal utility in bookmarking something to the homescreen (sorry, yes, I'm focusing on mobile first) is low if it doesn't have a Service Worker / Appcache associated. Although I've not published this research yet, this is strongly backed by evidence. Nearly all applications in the top 78,000 websites that opt. into being standalone applications via apple-mobile-web-app-capable do not, in fact, work as standalone applications. If anyone is interested to try this for themselves, here is the raw dataset listing all the sites [1] - you will need an iPhone to test them. The data set is from Oct. 2013, but should still be relevant. Just pick some at random and add to homescreen; it makes for depressing viewing. There are a few exceptions (listed below) - but those are the exceptions, not the rule. It's strictly second-class-citizen territory to have web bookmarks that routinely don't do anything meaningful when offline. Yes, but there are a number of factors that contribute to this: not just offline (e.g., flexbox support is still fairly limited, dev tools still suck, cross-browser is a nightmare, even how navigation works differs across UAs!, limited orientation-locking support, etc.). However, to your point the data we have shows that about 50 sites in the top 78K declare an appcache [2], while there are 1163 sites that declare apple-mobile-web-app-capable. So yeah, appcache, as we all know, is a bit of a failure. Some of the sites that declare it actually have it commented out... like they tried it and just gave up. Interestingly, only 10 sites in the dataset are both capable of running standalone AND declare offline: 1. forecast.io 2. timer-tab.com 3. capitalone.com 4. rachaelrayshow.com 5. delicious.com 6. forbesmiddleeast.com 7. shopfato.com.br 8. ptable.com 9 authenticjobs.com 10. swedenabroad.com So, yeah... 10 / 1163 = 0.0085... or, :_(. Anyway... do you think it's ok for us to just standardize the limited things in the manifest? We could have those at LC like in 2 weeks and then spin up V2 to have convergence with SW. Better still, the SW spec can just specify how it wants to work with manifests. [1] https://gist.github.com/marcoscaceres/7419589 [2] https://gist.github.com/marcoscaceres/9018819 -- Marcos Caceres -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [screen-orientation] Locking to 'current' orientation
For normal navigation mode (thus inside the browser with chrome) I would agree, but locking to other than current orientation makes sense for apps which are standalone or in combination with the Fullscreen API. Kenneth The whole point is that the API must not allow locking to a particular orientation at all, only to the current orientation. Allowing web pages to cause my phone to *switch* orientations is crazy. (You'd end up with half of the web locking to one orientation or another, because the page looks better that way, and you'll have the browser jumping between orientations as you hit browser back, causing the browser UI itself to jump around.) Locking to the current orientation deals with the use cases surrounding gyro-based games, where you don't want the phone shifting orientations as you move the device, without exposing something as insane as letting pages actually force a particular orientation. -- Glenn Maynard -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [screen-orientation] When window orientation != screen orientation...
not think that needs to change. Why not introduce a device-orientation MQ. There are already plenty of existing Screen/Device related MQs. http://dev.w3.org/csswg/mediaqueries4/#mf-dimensions Kenneth -- Mounir -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [manifest] orientation member
Hi there
On Fri, Nov 29, 2013 at 4:41 PM, Marcos Caceres mar...@marcosc.com wrote:
TLDR; orientation is hard. We've temporarily removed it from the spec. We
have two proposals below.
Sounds good to me.
Orientation of an application is dependent on the media features of the
display. For example an application might need to be launched in landscape on
phones (in order to have sufficient display width), but prefer to be in
portrait on tablets.
When analyzing applications across various runtimes, we've found evidence
that such applications are common (e.g., basically any application on the
iPhone that has an iPad counterpart will be designed to constrain to a
particular orientation based on the device being used: LinkedIn, Flipboard,
GoodReads, etc. will all go from portrait-primary on the iPhone to allowing
any orientation on the iPad. A more extreme example is BBC iPlayer - which
supports portrait-primary on the iPhone, but both landscape orientations on
iPad. The same can be seen on Android devices. Unlike native apps, Web Apps
should not target devices/OS's - they have to be device neutral.
In order to address the use cases, we currently have two proposals.
Option 1: Provide a list of orientation sets in the manifest. The user agent
uses the first one with a matching media query. The order in which the
orientations are listed by a developer does not imply a preference for
setting the orientation - it is always left up to the user agent to pick the
best orientation given, for example, how the user is holding the device. In
the example below, no orientation is given for widths of 721px or above, so
the default is used: allowing all orientations supported by the device.
{
orientations: [{
media: max-width: 320px,
supported: [portrait-primary, landscape]
}, {
media: max-width: 720px,
supported: [landscape]
}]
}
In this example, a device with a screen width of 320px or below would start
either portrait-primary or landscape with the abilty to be flipped
depending on how the user is holding the device (and OS permitting). A device
with a screen width of 321px through 720px would request to be launched in
landscape (leaving it up to the UA to pick either landscape-primary or
landscape-secondary, while allowing flippability), and a device with a
screen width of 721px and above would start in any orientation chosen by the
UA (ideally, one that matches how the user is holding the device).
I am not much of a fan for duplicating parts of option 2 in JSON.
Option 2: The second proposal is to remove orientation from the manifest and
use CSS @viewport instead. This would mean:
head
style
/*set it by default to portrait primary for small screens */
@media (max-width: 320px) {
@viewport {
orientation: portrait-primary, landscape;
}
}
/*Tablet, switch to landscape only*/
@media (max-width: 720px) {
@viewport {
orientation: landscape;
}
}
/* similarly on screens with a width of 721px or more, all
orientations are allowed */
/style
/head
Problem with using @viewport at the moment is that the specification is
progressing a bit slowly and no one has implemented the orientation
descriptor. It also lacks definitions for -primary and -secondary
contraints, which are important for various applications, and doesn't
currently allow providing multiple allowed orientations - hopefully the CSS
Device Adaption spec can align with the Screen Orientation spec.
Let's finish up the Screen Orientation spec first and then see how the
same solution will fit with CSS Device Adaptation aka @viewport rule.
Kenneth
--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆
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] 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
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
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
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: Define window.orientation
Because it will be portrait or landscale and not numbers like 0, 90, ... which might start counting from portrait or landscape. Kenneth
Re: Define window.orientation
They are somewheat different things. The former is basically a way to get accelerometer info (useful for games etc) and the latter is about actual OS(/Screen) orientation, in which the window.orientation (Browser orientation) falls. Kenneth On Tue, Nov 5, 2013 at 12:03 PM, Anne van Kesteren ann...@annevk.nl wrote: It seems either http://dev.w3.org/geo/api/spec-source-orientation.html or https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html needs to define and standardize the proprietary window.orientation feature because not having it defined is a problem: https://bugzilla.mozilla.org/show_bug.cgi?id=920342 As an aside, any chance we could have those two drafts be a single draft covering that whole spectrum? -- http://annevankesteren.nl/ -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
Re: [screen-orientation] Seeking status and plans
I have some additional feedback from discussing with people from Intel and Google. I will discuss with Marcos next week or file bugs Kenneth On Oct 27, 2013 8:02 AM, Marcos Caceres w...@marcosc.com wrote: On October 27, 2013 at 12:45:26 PM, Arthur Barstow (art.bars...@nokia.com) wrote: On 10/26/13 9:03 AM, ext Kenneth Rohde Christiansen wrote: Yes, Tizen and IE11 implements it Thanks Kenneth. Marcos - is the following what Mounir means re screen-orientation issues you raised: Yes. The TAG was supposed to expand on them, but hasn’t yet. Also, Mounir has addressed a bunch already. Please create Bugzilla bugs for these issues (if applicable). I’ll check what is outstanding still and do that.
Re: [screen-orientation] Seeking status and plans
Yes, Tizen and IE11 implements it Kenneth On Oct 25, 2013 5:30 AM, Arthur Barstow art.bars...@nokia.com wrote: On 10/2/13 12:31 PM, ext Arthur Barstow wrote: Hi Mounir, If any of the data for the Screen Orientation API in [PubStatus] is not accurate, please provide corrections. Also, if you have any new information re your plans for the spec - last published 06-Dec-2012 - or the spec's status with respect to being feature complete, implementation status, etc., please let us know. Marcos - Mounir just indicated in [IRC] that you submitted a Screen Orientation bug in GH. Can you please add that to W3C Bugzilla for this spec? Also, I think it would be helpful if you expanded on what you think needs to be spec'ed re [23072] (the only open bug for this spec). All - besides FireFoxOS and FF on Android, are there any other implementations of this spec? -Thanks, ArtB [IRC] http://krijnhoetmer.nl/irc-**logs/webapps/20131025http://krijnhoetmer.nl/irc-logs/webapps/20131025 [23072] https://www.w3.org/Bugs/**Public/show_bug.cgi?id=23072https://www.w3.org/Bugs/Public/show_bug.cgi?id=23072
Re: Polished FileSystem API proposal
Hi there!
A new file system API with a lot of promise :-)
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we previously sent [1] and tightened it up.
Executive Summary (aka TL;DR):
Below is the mozilla proposal for a simplified filesystem API. It
contains two new abstractions, a Directory object which allows
manipulating files and directories within it, and a FileHandle object
which allows holding an exclusive lock on a file while performing
multiple read/write operations on it.
It's largely modeled after posix, but because we've tried to keep it
author friendly despite it's asynchronous nature, it differs in a few
cases.
There are opportunities for further simplifications by straying
further from posix. It's unclear if this is desired or not.
Detailed proposal:
partial interface Navigator {
PromiseDirectory getFilesystem(optional FilesystemParameters parameters);
};
interface Directory {
readonly attribute DOMString name;
PromiseFile createFile(DOMString path, MakeFileOptions options);
Why not CreateFileOptions? the method is called createFile and not makeFile
PromiseDirectory createDirectory(DOMString path);
You have a data as part of the MakeFileOptions, would that be useful here?
Promise(File or Directory) get(DOMString path);
Then shouldn't we have a convenience to see if a path is a directly or
not, like python has os.path.isdir(fileordirectoryname)
Promisevoid move((DOMString or File or Directory) entry,
(DOMString or Directory or DestinationDict) dest);
Promisevoid copy((DOMString or File or Directory) entry,
(DOMString or Directory or DestinationDict) dest);
Promiseboolean remove((DOMString or File or Directory) path,
optional DeleteMode recursive = nonrecursive);
I don't like all these weird arguments like DeleteMode etc... just
make a separate method
removeRecursively(
PromiseFileHandle openRead((DOMString or File) file);
PromiseFileHandleWritable openWrite((DOMString or File) file,
optional CreateMode createMode = createifneeded);
Can't the user not just handle the creation in the error case of the
promise. or create it before... It would so very easy to create a
openWriteCreateIfNeeded method on top of the existing API. So such an
argument should only be needed if there would be performance benefits
- otherwise keep the API simple.
PromiseFileHandleWritable openAppend((DOMString or File) file,
optional CreateMode createMode = createifneeded);
EventStream(File or Directory) enumerate();
EventStreamFile enumerateDeep();
It is not obvious for me what that method does.
};
interface FileHandle
{
readonly attribute FileOpenMode mode;
readonly attribute boolean active;
attribute long long? location;
PromiseFile getFile();
AbortableProgressPromiseArrayBuffer read(unsigned long long size);
AbortableProgressPromiseDOMString readText(unsigned long long
size, optional DOMString encoding = utf-8);
void abort();
};
interface FileHandleWritable : FileHandle
{
AbortableProgressPromisevoid write((DOMString or ArrayBuffer or
ArrayBufferView or Blob) value);
Promisevoid setSize(optional unsigned long long size);
Promisevoid flush();
};
partial interface URL {
static DOMString? getPersistentURL(File file);
}
// WebIDL cruft that's largely transparent
enum PersistenceType { temporary, persistent };
Is temporary a kind of persistence? (sorry not native speaker)
dictionary FilesystemParameters {
PersistenceType storage = temporary;
};
dictionary MakeFileOptions {
boolean overwriteIfExists = false;
(DOMString or Blob or ArrayBuffer or ArrayBufferView) data;
};
enum CreateMode { createifneeded, dontcreate }
enum DeleteMode { recursive, nonrecursive }
dictionary DestinationDict {
Directory dir;
DOMString name;
};
enum FileOpenMode { read, write, append };
So this API introduces 2 classes: Directory and FileHandle. Directory
allows manipulation of the files and directories stored inside that
directory. FileHandle represents an exclusively opened file and allows
manipulation of the file contents.
The behavior is hopefully mostly obvious. A few general comments:
The functions on Directory that accept DOMString arguments for
filenames allow names like path/to/file. If the function creates a
file, then it creates the intermediate directories. Such paths are
always interpreted as relative to the directory itself, never relative
to the root.
We were thinking of *not* allowing paths that walk up the directory
tree. So paths like ../foo, .., /foo/bar or foo/../bar are not
allowed. This to keep things simple and avoid security issues for the
page.
Likewise, passing a File object to an operation of Directory where the
File object isn't contained in that
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, On Mon, Jun 10, 2013 at 10:58 AM, Lars Knudsen lar...@gmail.com wrote: IMO, this would be a much more clean and easy to understand solution than providing a separate API for orientation lock. It would also remove 1 unknown element when game developers try to juggle mappings between xyz-accelerometer data vs media query orientation vs device normal orientation (as some propose to have natural landscape and natural portrait devices - something I really think would just add to the confusion). That is good to hear; it is very important that all this feel natural to developers without digging into a lot of spec details. Kenneth
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
As I understand it, the CSS specs never refer to device pixels, but always to CSS pixels which are basically your DIPs, so the confusion only arises from the fact that browsers did DPI adjustment (upscaled the content to use real CSS values in CSS units - aka DIPs) but forgot to do it for everything. As Apple did the upscaling in their core system/toolkit, everything stayed in CSS units from day one, where as other browsers such as Android and Qt (Nokia N9) did the upscaling in the browser itself and forgot to adjust all web facing values. Kenneth On Wed, Jun 5, 2013 at 4:34 PM, John Mellor joh...@chromium.org wrote: Sounds reasonable. I think the main things that are missing are explanations of the knock-on effects of Device Adaptation (and the meta viewport tag). For example the CSSOM View module claims that all its dimensions are in CSS pixels. But if you look at what mobile browsers return for something like screen.width, they either return Device Independent Pixels (DIPs) or physical device pixels. It's only for things like window.innerWidth that mobile browsers actually return a value in CSS pixels. Now, returning DIPs does in fact best match the intent of the spec for screen.width (indeed the definition of a CSS pixel is actually the definition of a DIP, and they used to be the same thing until pinch zoom and viewports made them scale independently); but the CSS specs need to accept that there are more kinds of pixels than there used to be, and fix these ambiguities, if we want mobile browsers to converge on a single behaviour. On Wed, Jun 5, 2013 at 2:59 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I think it should be. You think anything is missing? Kenneth On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@intel.com wrote: I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. There's currently http://dev.w3.org/csswg/css-device-adapt/#dom-interfaces Is that sufficient? -- Simon Pieters Opera Software -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆ -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
In order for CSS Device Adaptation and Fullscreen to work better
together and work with orientation lock in fullscreen mode, I suggest
(idea by Rune) we extend the view-mode media feature with the
following syntax
@media all and (view-mode: fullscreen(#element1)) {
@viewport {
orientation: portrait;
}
}
@media all and (view-mode: fullscreen(#element2)) {
@viewport {
orientation: landscape;
}
}
This way a page can have multiple fullscreen enabled elements which
each their viewport configuration which will be applied when they
enter fullscreen.
Cheers
Kenneth
On Thu, Jun 6, 2013 at 11:04 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
As I understand it, the CSS specs never refer to device pixels, but
always to CSS pixels which are basically your DIPs, so the confusion
only arises from the fact that browsers did DPI adjustment (upscaled
the content to use real CSS values in CSS units - aka DIPs) but forgot
to do it for everything.
As Apple did the upscaling in their core system/toolkit, everything
stayed in CSS units from day one, where as other browsers such as
Android and Qt (Nokia N9) did the upscaling in the browser itself and
forgot to adjust all web facing values.
Kenneth
On Wed, Jun 5, 2013 at 4:34 PM, John Mellor joh...@chromium.org wrote:
Sounds reasonable. I think the main things that are missing are explanations
of the knock-on effects of Device Adaptation (and the meta viewport tag).
For example the CSSOM View module claims that all its dimensions are in CSS
pixels. But if you look at what mobile browsers return for something like
screen.width, they either return Device Independent Pixels (DIPs) or
physical device pixels. It's only for things like window.innerWidth that
mobile browsers actually return a value in CSS pixels. Now, returning DIPs
does in fact best match the intent of the spec for screen.width (indeed the
definition of a CSS pixel is actually the definition of a DIP, and they used
to be the same thing until pinch zoom and viewports made them scale
independently); but the CSS specs need to accept that there are more kinds
of pixels than there used to be, and fix these ambiguities, if we want
mobile browsers to converge on a single behaviour.
On Wed, Jun 5, 2013 at 2:59 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
I think it should be. You think anything is missing?
Kenneth
On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters sim...@opera.com wrote:
On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen
kenneth.r.christian...@intel.com wrote:
I support adding some CSSOM API's for CSS Device Adaptation, but I would
not do so for the viewport meta tag, which has its share of issues.
There's currently
http://dev.w3.org/csswg/css-device-adapt/#dom-interfaces
Is that sufficient?
--
Simon Pieters
Opera Software
--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone +45 4294 9458 / E-mail kenneth at webkit.org
﹆﹆﹆
--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone +45 4294 9458 / E-mail kenneth at webkit.org
﹆﹆﹆
--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone +45 4294 9458 / E-mail kenneth at webkit.org
﹆﹆﹆
[css3-mediaqueries][css-device-adapt] Combining @viewport with the Fullscreen API
In order for CSS Device Adaptation and Fullscreen to work better
together and work with orientation lock in fullscreen mode, I suggest
(idea by Rune) we extend the view-mode media feature with the below
syntax. I also suggest that we move the view-mode media feature into
Media Queries Level 4.
@media all and (view-mode: fullscreen(#element1)) {
@viewport {
orientation: portrait;
}
}
@media all and (view-mode: fullscreen(#element2)) {
@viewport {
orientation: landscape;
}
}
This way a page can have multiple fullscreen enabled elements which
each their viewport configuration which will be applied when they
enter fullscreen.
Cheers
Kenneth
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@chromium.org wrote: There is a distinction to be made between DIPs and CSS pixels. Take a portrait iPhone 4 for example: - screen is 640 device pixels wide - device pixel ratio is 2 CSS pixels are affected by pinch zooming: If you use meta name=viewport content=width=device-width, initial-scale=1 then: - screen.width is fixed at 320 DIPs - document.documentElement.clientWidth is fixed* at 320 CSS pixels - window.innerWidth is initially 320 CSS pixels, but decreases when the user pinch zooms in, since zooming in makes CSS pixels larger, and hence less of them fit onscreen at once. The units are still in CSS units. If you query the (-webkit-device-pixel-ratio) it will still be 2. The innerWidth is showing how many CSS units you are seeing of the contents inside the viewport,, and that is still calculated in CSS units, not device units. CSS pixels are also affected by viewports: If you have no meta viewport or @viewport rule, then mobile browsers will set your page width to a fallback value of around 980 CSS pixels, and so: - screen.width is still fixed at 320 DIPs - document.documentElement.clientWidth is fixed* at 980 CSS pixels - window.innerWidth is initially 980 CSS pixels, but decreases when the user pinch zooms in. When zoomed to a scale of 1, CSS pixels are the same size as DIPs, window.innerWidth is 320, and content is now as legible as it would have been if width=device-width had been used. *: the reason that document.documentElement.clientWidth remains fixed, even though it's unit is CSS pixels, is that when you zoom you're no longer measuring the same distance, instead the distance being measured (the page width) scales in proportion to the page. On Thu, Jun 6, 2013 at 10:04 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: As I understand it, the CSS specs never refer to device pixels, but always to CSS pixels which are basically your DIPs, so the confusion only arises from the fact that browsers did DPI adjustment (upscaled the content to use real CSS values in CSS units - aka DIPs) but forgot to do it for everything. As Apple did the upscaling in their core system/toolkit, everything stayed in CSS units from day one, where as other browsers such as Android and Qt (Nokia N9) did the upscaling in the browser itself and forgot to adjust all web facing values. Kenneth On Wed, Jun 5, 2013 at 4:34 PM, John Mellor joh...@chromium.org wrote: Sounds reasonable. I think the main things that are missing are explanations of the knock-on effects of Device Adaptation (and the meta viewport tag). For example the CSSOM View module claims that all its dimensions are in CSS pixels. But if you look at what mobile browsers return for something like screen.width, they either return Device Independent Pixels (DIPs) or physical device pixels. It's only for things like window.innerWidth that mobile browsers actually return a value in CSS pixels. Now, returning DIPs does in fact best match the intent of the spec for screen.width (indeed the definition of a CSS pixel is actually the definition of a DIP, and they used to be the same thing until pinch zoom and viewports made them scale independently); but the CSS specs need to accept that there are more kinds of pixels than there used to be, and fix these ambiguities, if we want mobile browsers to converge on a single behaviour. On Wed, Jun 5, 2013 at 2:59 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I think it should be. You think anything is missing? Kenneth On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@intel.com wrote: I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. There's currently http://dev.w3.org/csswg/css-device-adapt/#dom-interfaces Is that sufficient? -- Simon Pieters Opera Software -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆ -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆ -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
You can say that screen.width expresses the screen size in CSS px units and independently of the document scale, unlike window.innerWidth which expresses the amount of CSS px units (horizontally) of the document which you see given the current document scale. Maybe you have suggestions for how to clarify this in the specs? On Thu, Jun 6, 2013 at 12:32 PM, John Mellor joh...@chromium.org wrote: The innerWidth is showing how many CSS units you are seeing of the contents inside the viewport I agree. My point was that screen.width is measured in DIPs not CSS pixels, and hence screen.width often returns different values from window.innerWidth -- depending on zoom and viewport -- even though screen.width and window.innerWidth are both measuring the same distance: the width of the device. not device units Indeed, nothing exposed to the web should be in device pixels (the very existence of device pixels should only be detectable using the device pixel ratio, which exposes the ratio between device pixels and DIPs, and things like CSS4 image-set). On Thu, Jun 6, 2013 at 11:21 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Hi there On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@chromium.org wrote: There is a distinction to be made between DIPs and CSS pixels. Take a portrait iPhone 4 for example: - screen is 640 device pixels wide - device pixel ratio is 2 CSS pixels are affected by pinch zooming: If you use meta name=viewport content=width=device-width, initial-scale=1 then: - screen.width is fixed at 320 DIPs - document.documentElement.clientWidth is fixed* at 320 CSS pixels - window.innerWidth is initially 320 CSS pixels, but decreases when the user pinch zooms in, since zooming in makes CSS pixels larger, and hence less of them fit onscreen at once. The units are still in CSS units. If you query the (-webkit-device-pixel-ratio) it will still be 2. The innerWidth is showing how many CSS units you are seeing of the contents inside the viewport,, and that is still calculated in CSS units, not device units. CSS pixels are also affected by viewports: If you have no meta viewport or @viewport rule, then mobile browsers will set your page width to a fallback value of around 980 CSS pixels, and so: - screen.width is still fixed at 320 DIPs - document.documentElement.clientWidth is fixed* at 980 CSS pixels - window.innerWidth is initially 980 CSS pixels, but decreases when the user pinch zooms in. When zoomed to a scale of 1, CSS pixels are the same size as DIPs, window.innerWidth is 320, and content is now as legible as it would have been if width=device-width had been used. *: the reason that document.documentElement.clientWidth remains fixed, even though it's unit is CSS pixels, is that when you zoom you're no longer measuring the same distance, instead the distance being measured (the page width) scales in proportion to the page. On Thu, Jun 6, 2013 at 10:04 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: As I understand it, the CSS specs never refer to device pixels, but always to CSS pixels which are basically your DIPs, so the confusion only arises from the fact that browsers did DPI adjustment (upscaled the content to use real CSS values in CSS units - aka DIPs) but forgot to do it for everything. As Apple did the upscaling in their core system/toolkit, everything stayed in CSS units from day one, where as other browsers such as Android and Qt (Nokia N9) did the upscaling in the browser itself and forgot to adjust all web facing values. Kenneth On Wed, Jun 5, 2013 at 4:34 PM, John Mellor joh...@chromium.org wrote: Sounds reasonable. I think the main things that are missing are explanations of the knock-on effects of Device Adaptation (and the meta viewport tag). For example the CSSOM View module claims that all its dimensions are in CSS pixels. But if you look at what mobile browsers return for something like screen.width, they either return Device Independent Pixels (DIPs) or physical device pixels. It's only for things like window.innerWidth that mobile browsers actually return a value in CSS pixels. Now, returning DIPs does in fact best match the intent of the spec for screen.width (indeed the definition of a CSS pixel is actually the definition of a DIP, and they used to be the same thing until pinch zoom and viewports made them scale independently); but the CSS specs need to accept that there are more kinds of pixels than there used to be, and fix these ambiguities, if we want mobile browsers to converge on a single behaviour. On Wed, Jun 5, 2013 at 2:59 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I think it should be. You think anything is missing? Kenneth On Wed, Jun 5, 2013
Re: [css3-mediaqueries][css-device-adapt] Combining @viewport with the Fullscreen API
Yes, for fullscreen you want to be able to control whether it should change orientation or not. Just like a fullscreen HTML5 video playing on the iPhone never changes direction (or at least it didn't use to, don't know about latest version). On my older iPhone, when you click on a HTML5 video element, it opens up and transitions into landscape+fullscreen mode while doing so and then locks in that mode. The 'orientation' property is a hint and should be ignored in normal chrome mode. From the editor's draft: This descriptor is used to request that a document is displayed in portrait or landscape mode. For a UA/device where the orientation is changed upon tilting the device, an author can use this descriptor to inhibit the orientation change. The descriptor should be respected for standalone web applications, and when the document is displayed in fullscreen. It is recommended that it is ignored for normal web navigation to avoid confusing the user. On Thu, Jun 6, 2013 at 12:29 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jun 6, 2013 at 11:12 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: ... Is it accurate to tie this to @viewport? When I rotate my iPhone the chrome also rotates, not just the viewport. -- http://annevankesteren.nl/ -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
I think it should be. You think anything is missing? Kenneth On Wed, Jun 5, 2013 at 3:51 PM, Simon Pieters sim...@opera.com wrote: On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christiansen@intel.**com kenneth.r.christian...@intel.com wrote: I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. There's currently http://dev.w3.org/csswg/css-** device-adapt/#dom-interfaceshttp://dev.w3.org/csswg/css-device-adapt/#dom-interfaces Is that sufficient? -- Simon Pieters Opera Software -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, On Wed, Apr 24, 2013 at 2:35 PM, Tobie Langel to...@w3.org wrote: On Wednesday, April 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen wrote: Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. *Sigh* MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. Understandably given the above. Outside of the IE10 implementation mentioned above, have other implementors committed to implement the CSS part of CSS Device Adaptation? We are looking at enabling it for Chromium, no ETA on that though, as there seems to be some interest from Android and Opera as well. I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Agreed. These should work together as much as possible. Thanks for your comments. --tobie -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Cheers Kenneth On Wed, Apr 24, 2013 at 12:13 PM, Tobie Langel to...@w3.org wrote: Hi, Screen orientation lock is critical to a whole set of mobile games (especially those which rely on the accelerometer to control the gameplay). It's great that it is now considered for specification and implementation. I had collected some use cases a while back[1], some of which led to use-cases[2], requirements[3] and suggestions[4] in the Coremob report. While some of the original use cases required dynamically modifying orientation lock (e.g. the Game within a game experience[5]), key use cases simply require a declarative, page-wide setting, as described by David Bruant on the WHAT WG mailing list[6]. The current proposal[7] only targets the dynamic setting through a JS API and leaves the more declarative approach to other specs[8]. It mentions the Web Application Manifest Format and Management APIs[9] and CSS Device Adaptation[10]. Now, CSS Device Adaptation, as used in the Viewport META element[11] is ubiquitous on mobile. It seems like a natural fit for a declarative orientation lock, so much so that it's already specified in the spec[12]. However, the syntax to dynamically read or modify the Viewport META element is cumbersome and error prone (you're talking document.cookie-like string splitting/concatenation with unspecified separators, etc.[12]). Instead of providing a dedicated API to cater strictly for the screen orientation lock use case, wouldn't it make more sense and be more consistent to provide a CSSOM[14] API for the whole Viewport META element, and use matchMedia listeners[15] instead of orientationchange events? This would allow declarative setting through the Viewport META element, dynamic modification through the CSSOM API, and event handling through the matchMedia interface, all of which are well known and commonly used by developers. Thanks for your time. --tobie --- [1]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html [2]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#play-a-2d-game [3]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#req-orientation-lock [4]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#screen-orientation [5]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html#game-within-a-game-experience [6]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0078.html [7]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html [8]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html#declarative-orientation-locking [9]: https://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html [10]: http://dev.w3.org/csswg/css-device-adapt/ [11]: http://dev.w3.org/csswg/css-device-adapt/#viewport-meta [12]: http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor [13]: https://developer.mozilla.org/en-US/docs/Mobile/Viewport_meta_tag#Background [14]: http://dev.w3.org/csswg/cssom/ [15]: http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface -- - Intel Denmark Aps Langelinie Alle 35, DK-2100 Copenhagen CVR No. 76716919 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
CSS Device Adaption and Fullscreen
Hi there, The CSS Device Adaption spec has a good method for deciding how to control the viewport of the main frame. A good question is how this should relate to subframe and elements going fullscreen. One way would be to inherit the viewport of the main frame, but I wonder whether this covers the use-cases that web developers have. iframe going fullscreen could define a different viewport and maybe that is sufficient. Any thought about that? and could we add some clarification to the proper specs? -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆
Re: CfC Re: Charter addition proposal: screen orientation lock
I can help if needed, though I have never been an editor before. Kenneth On Tue, Jan 31, 2012 at 3:22 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 01/31/2012 03:19 PM, Arthur Barstow wrote: Robin agreed to take the lead on testing but I don't see a commitment for the Editor role. If someone can commit to being an Editor, please speak up. I could try that. -- Mounir -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆
Re: Charter addition proposal: screen orientation lock
Hi there, Orientation lock is already part of the CSS Device Adaption spec as part of the viewport meta tag, though this is only going to be optional and should be ignored for normal web browsing due to the effect on usability (think about navigating session history). It is thus mostly useful for fullscreen applications and stand alone web apps. On the other hand, I think it would be nice to have a hint to the fullscreen api requestFullscreen where you could define a preferred orientation (which it would then lock to), something like requestFullscreen(HORIZONTAL). It would even be nice if the UA could tell whether it was possible to enter horizontal fullscreen mode or not, so that there can be some kind of fallback. Having it this way, it would be possible to click/tap on some element and animate the transition (scale + rotation) into the final state. Currently with the viewport meta addition it is possible for web apps to define their target orientation and even test via javascript (matchMedia) whether the orientation hint was granted or not. If not, the web app can request to enter a fullscreen mode, preferable first asking the user. Cheers, Kenneth On Mon, Jan 30, 2012 at 12:22 PM, Robin Berjon ro...@berjon.com wrote: Hi all! Sorry for bringing this to the group this late, but it's a topic that's been discussed in other places and that I believe is both useful and mature enough to be ready for standardisation. Some applications are designed in such a way that they only make sense in one device orientation. The archetypical example would be a game that only works in landscape mode, but there are other examples. Right now native apps can support this rather easily, but web apps have been stuck with silly hacks such as detecting that the orientation is wrong and asking the user to rotate. This further leads to trouble when the device itself is used as a controller (e.g. in racing games) as this can sometimes trigger an undesired orientation change mid-game — hardly a user-friendly experience. Note that this is not about system-level orientation lock (which would be fodder for another group) but application-level orientation. Options to address this have been discussed (amongst other places) here: http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/f38bb05e66c01a77# There is discussion as to whether this ought to be only an API or if it should use a meta element (which would also give it an API since it could be changed dynamically), with an overall leaning towards the latter. I am rather confident that we should be able to agree on the best approach relatively quickly. I will let implementers speak for themselves, but my understanding is that there is interest in this feature. It is certainly a regular request from developers. In previous discussions we haven't hashed out who would stand up as editor and test facilitator, but I'm confident that we can find people. If no one else steps up, I'll take the testing hat. WDYT? -- Robin Berjon - http://berjon.com/ - @robinberjon -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆
Re: Charter addition proposal: screen orientation lock
Hi there, On Mon, Jan 30, 2012 at 1:22 PM, Robin Berjon ro...@berjon.com wrote: Hi, On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote: Orientation lock is already part of the CSS Device Adaption spec as part of the viewport meta tag Sorry, I should indeed have mentioned that as part of the background. The problem with specifying orientation as part of the viewport at rule is that it leads to circular dependencies (you can set an orientation inside a media query that changes the viewport and triggers and endless loop). The spec tries (meekly) to defend against that, but I find it difficult not to get the impression that this leads to a tangled mess and that it will confuse developers (it certainly confuses me when I try to make sense of the circularity avoidance recommendations made in the specification itself). This could be solved if it were only to appear in meta elements, but right now that's not the case and the section on meta elements in CSS DA isn't normative. I see that that is a problem yes, but I guess that can be a problem with the CSS DA in other cases? My understanding has therefore been that orientation might get dropped from CSS DA. If that's not the case and if people are confident that it can be better addressed there (perhaps by being only a meta element solution) then I'm fine with it. My sole concern is that this be solved *somewhere* (and preferably not in a manner that makes it possible to construct a GOTO instruction in CSS). I think we have some additional use cases for web apps on mobile devices. On mobile phones it is common that apps take a little while to start and thus people often show screenshots of the actual app while loading and then fades the screenshot out and fades the actual app in. That gives a pretty nice user experience. In order to do something like this for web apps, it would be needed to first show the app when the web app actually asks to, and thus be able to execute media queries, javascripts before so. This would also make it possible for the app to do something like requestFullscreen(HORIZONTAL) before the app becomes visible. It would be possible to do it so that if requestFullscreen is called before the app is visible when run as standalone, then no user permission is needed. This would mean that we can do without the meta tag. For a web browser it would be quite bad usability to respect a orientation meta tag, because it can lead to cases where you click on a link and suddently your whole browser chrome rotates, and it can even do so when pressing the forward/back button or selecting an page from the browser history. This is why I said that this makes most sense for either stand-alone web apps, or for apps entering fullscreen (pending on some user action, user permission granting). , though this is only going to be optional and should be ignored for normal web browsing due to the effect on usability (think about navigating session history). It is thus mostly useful for fullscreen applications and stand alone web apps. I can certainly see how this would be ignored in a number of contexts, but I wouldn't restrict it to stand alone web apps. Web apps in the browser ought to be able to use it, though it might require them to be identified as apps (using whatever heuristics). They can, they just need to go fullscreen first, which I think is a pretty ok requirement. From our user testing on the Nokia N9, we had many confused users because pages could turn off scaling of the web page (pinch zoom etc) by setting the minimum-scale and maximum-scale of the viewport meta tag. If users see the web browser chrome and the browser suddently doesn't want to change orientation (which normally works) they become confused. They simply don't associate pinch zoom and orientation change with the exact web page, they associate it with the browser chrome. On the other hand, I think it would be nice to have a hint to the fullscreen api requestFullscreen where you could define a preferred orientation (which it would then lock to), something like requestFullscreen(HORIZONTAL). It would even be nice if the UA could tell whether it was possible to enter horizontal fullscreen mode or not, so that there can be some kind of fallback. Having it this way, it would be possible to click/tap on some element and animate the transition (scale + rotation) into the final state. I think that this makes sense. I guess that feedback should make its way to the HTML WG. I am new to how W3C etc works, so how do we bring the feedback there? Cheers, Kenneth -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆
Re: CfC Re: Charter addition proposal: screen orientation lock
I support, but I think it tied into the device adaptions spec, fullscreen and also splash screen support. Kenneth On Mon, Jan 30, 2012 at 2:26 PM, Charles McCathieNevile cha...@opera.comwrote: OK, since I was planning to have the charter up today, let's have a quick call for consensus on this. Please reply by end of business Wednesday if you support or object to this - silence will be taken as not explicitly supporting it, and without support it isn't going to get into the draft charter. If it does go there, there will still be opportunities to object but it will be harder to squeeze in. cheers Chaals On Mon, 30 Jan 2012 12:22:30 +0100, Robin Berjon ro...@berjon.com wrote: Hi all! Sorry for bringing this to the group this late, but it's a topic that's been discussed in other places and that I believe is both useful and mature enough to be ready for standardisation. Some applications are designed in such a way that they only make sense in one device orientation. The archetypical example would be a game that only works in landscape mode, but there are other examples. Right now native apps can support this rather easily, but web apps have been stuck with silly hacks such as detecting that the orientation is wrong and asking the user to rotate. This further leads to trouble when the device itself is used as a controller (e.g. in racing games) as this can sometimes trigger an undesired orientation change mid-game — hardly a user-friendly experience. Note that this is not about system-level orientation lock (which would be fodder for another group) but application-level orientation. Options to address this have been discussed (amongst other places) here: http://groups.google.com/**group/mozilla.dev.webapi/** browse_thread/thread/**f38bb05e66c01a77#http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/f38bb05e66c01a77# There is discussion as to whether this ought to be only an API or if it should use a meta element (which would also give it an API since it could be changed dynamically), with an overall leaning towards the latter. I am rather confident that we should be able to agree on the best approach relatively quickly. I will let implementers speak for themselves, but my understanding is that there is interest in this feature. It is certainly a regular request from developers. In previous discussions we haven't hashed out who would stand up as editor and test facilitator, but I'm confident that we can find people. If no one else steps up, I'll take the testing hat. WDYT? -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆
Re: Charter addition proposal: screen orientation lock
Hi, On Mon, Jan 30, 2012 at 6:32 PM, Mounir Lamouri mou...@lamouri.fr wrote: This is what I meant by not a MUST, so I guess we agree :) Perfect! :) We need this to be tied together in some way, so that it is possible to click on say, a video element and have to animate entering fullscreen and rotating at the same time. Doing these two transitions separately, would look pretty bad (at least animated). Sounds interesting. Maybe we could extend the fullscreen API later. However, we shouldn't force authors to use the fullscreen API to lock the screen. That is fine with me, but it would be great to cover as many use cases as possible early on, so that we don't end up patching things to work well together. Kenneth -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit. http://gmail.comorg http://codeposts.blogspot.com ﹆﹆﹆
Re: Rename XBL2 to something without X, B, or L?
I'm with you :-) I really dislike the current name, and it keeps reminding me of XBEL, the bookmark exchanging language. Kenneth On Tue, Dec 14, 2010 at 10:24 PM, Dimitri Glazkov dglaz...@google.com wrote: Dear all, Looking at the use cases and the problems the current XBL2 spec is trying address, I think it might be a good idea to rename it into something that is less legacy-bound? Hixie already cleverly disguised the X as [X]engamous in the latest draft, and if this spec is to become part of HTML, it probably should lose an 'L'. As for 'B', describing what XBL2 aims to do as 'bindings' ain't super-accurate. The way I look at it, the problems we're trying to solve are: a) templating -- for astoundingly fast creation of DOM chunks using declarative syntax; b) shadow DOM -- for maximum-pleasure encapsulation and leak-free component abstraction of DOM chunks; c) binding -- for joy-filled extension and decoration DOM elements. Describing all these as just Binding just feels wrong. Web Components perhaps or something along these lines? Who's with me? :) :DG -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆
Comments on View Modes
Hi there! Here you have some of my comments on the current view mode spec, which I have added support for in WebKit. With regard to the media feature http://dev.w3.org/2006/waf/widgets-vmmf/ http://www.w3.org/TR/widgets-vmmf/ I believe the 'all' is is not that useful as that is the same as not declaring anything. This comment has been given by others. With regard to the other modes, I find the 'mini' name very confusing as it refers to a docking state, and many people confuse 'floating' and 'mini' because of this. The 'application' mode doesn't sounds like a view mode but more like a state. Suggestions could be 'windowed' or maybe 'standalone'. But maybe instead we should go for something like: docked, floating, minimized, normal and maximized. Those really seem like view modes to me. The mode minimized might seem useless at first, but I added for completeness. As you can query the view mode from javascript, it might be possible to use it to purge resources from javascript when the app is minimized; but that requires having the dom events in place. I also think it would be good to define Chrome better in the spec, or maybe define Window Decorations, as I believe that a widget in 'application' mode should not have chrome but window decorations from the window manager. With regard to the VM Interface: http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html I beleive it should not be called ViewModeChanged but ViewModeChange, just like we have show, hide today and not shown, hidden. Same with MediaTypeChangedEvent. Opera also seem to use change and not changed in their original widget implementation. We also need an API for requesting view mode changes from JavaScript. It is important here that it is a request as not all widgets support all view modes. Cheers, -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org http://codeposts.blogspot.com ﹆﹆﹆
