Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
Hi, I know, I've mentioned this before - but why don't we just define one (hardware) direction as 0 degrees (e.g. portrait up), align all the orientation specs and keep things simple for everyone? ref http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0063.html br Lars On Fri, Aug 16, 2013 at 5:03 AM, Jonas Sicking jo...@sicking.cc wrote: On Aug 15, 2013 5:11 PM, Dhruv Chadha dhruv.cha...@microsoft.com wrote: Tab, We sympathize with the goal of creating a simple programming model for developers but we don’t believe that is what is currently specified on the device and screen orientation specs (as we stated in our earlier response to Jonas). Our proposal maps existing native implementations done by iOS, Android, and Windows. These native APIs provide capabilities to discover the native orientation of the device and to remap the coordinate system based on the user selected orientation. We believe that mapping the coordinates to the current screen orientation would generate the following issues: - Changes the design of the API as defined by current draft of the device orientation spec and will break interoperability with current implementations I agree this is a problem. - If the browser’s orientation is not locked, rotating the device would reset the coordinates back to 0 in the reference axis for each 90 degree rotation since the browser App UI would rotate as well Why is this bad? Maybe I'm not understanding the concern? - Does not provide flexibility. What happens if the developer is not interested in automatically re-mapping the coordinate system? They wouldn’t have an ability to change this behavior. What are the use cases for wanting to allow the screen to reorient while at the same time not adjusting the coordinate system? Are these use cases more common than the cases where you would want to adjust the coordinate system? A potential solution is to add a separate set of events exactly like the current DeviceOrientation events, but that are relative to the screen orientation rather than the device orientation. Sadly that might be the only way to keep compatibility with existing deployed implementations, while still keeping a decent API. - the alpha value (+Z) for device orientation should always be aligned to the input from the compass (i.e. hardware sensors) unless the developer requests a re-mapping I don't understand this. Could you provide an example or describe in more detail? / Jonas
CfC: publish LCWD of File API; deadline August 23
Arun proposed (see below) WebApps publish a Last Call Working Draft of File API and this is a Call for Consensus to do so, using the following ED as the basis: http://dev.w3.org/2006/webapi/FileAPI/ 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. ]] The proposed review period for this LC is 4 weeks. There are two open [Bugs] for this spec. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by August 23 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB [Bugs] http://tinyurl.com/Bugs-FileAPI Original Message Subject:File* Specifications | Status and some Promises Resent-Date:Thu, 15 Aug 2013 17:50:25 + Resent-From:public-webapps@w3.org Date: Thu, 15 Aug 2013 13:49:38 -0400 From: ext Arun Ranganathan a...@mozilla.com To: Web Applications Working Group WG public-webapps@w3.org Greetings WG, There are three moving proposals in the File* arena, and I thought I'd catpure what these are and what the status of these are. 1. The File API, currently updated as editor's draft at http://dev.w3.org/2006/webapi/FileAPI/ Review strongly encouraged :) Notable fixes are: i. A File constructor has been added, which has been a longstanding request. ii. A new static method on URL called URL.createAndRevoke has been added that gets defaults right, and does away with autoRevoke, which nobody implemented for URL.createObjectURL. iii. A Blob URL Store and a Revocation List, useful for URL Fetch (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765). This draft should be ready for LC and should be considered the File API v1. 2. Re-writing File APi to be Promises based, which should be considered a v2. The biggest departure from the current state of technology here would really be that we can have Promises right off the Blob itself, which is zeitgeist thinking about these things (and admittedly makes life easier than an XHR-inspired FileReader, which will be made legacy). The best stab at a strawperson was this one by Jonas: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html But Stream itself temporarily lives here without too much implementation backbone: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm I think we *should* have a Promises-based File API off of Blob, but I'm not totally sure about the Stream API as it is currently written; I'm amenable to editing the File API v2 portion, modulo our proposal for Stream. 3. Then there's the FileSystem API, currently discussed here: http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html This was the upshot of discussions on this listserv, as well as internally at Mozilla. I'm amenable to editing this, which is separate but related to 1. and 2. -- A*
Re: Updating Quota API: Promise, Events and some more
On Fri, Aug 16, 2013 at 3:25 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 15, 2013 at 9:44 AM, Kinuko Yasuda kin...@chromium.org
wrote:
requestQuota for temporary storage:
I'd like to better understand the use case for requestQuota for
temporary
storage. Are implementations allowed to bring up a prompt when an
increased
temporary storage quota is requested? I thought one of the big use
cases for
temporary storage was that it would never trigger prompts, though
obviously
an exception could be made for the explicit requestQuota function.
If the idea is for it not to bring up a prompt, why would we not simply
always allocate the largest value that could be requested?
Also, I think that we for temporary storage in Gecko would not want to
guarantee that the allocated quota (as reported by queryQuota) for
temporary
storage will remain allocated for longer than the running page. I.e.
once a
page is closed, we might want to release the quota allocated and give
it to
another website.
This is a very good feedback/question. In Chrome we actually don't
really
support requestQuota for temporary storage, we just silently ignore the
request but returns the current available quota to the requesting
webapp. I
also agree that it won't be desirable to preserve the quota allocated for
temporary storage.
Seems like having this method take a storage type just confuses
readers/implementors, we should probably just drop the storage type
parameter and rename it to something like 'requestPersistentQuota', or
only
add the method to 'navigator.persistentStorage' attribute?
I think adding storageQuota.requestPersistentQuota would be a good
solution. It seems cleaner than having a separate
navigator.persistentStorage object.
Agreed, sounds good to me too.
Based on the feedbacks (thanks all) I've dropped {get,set}StorageType and
storageok and storagechange events from the draft. (New events can be
added later whenever we find them useful with more concrete use cases)
Now the new draft looks like:
enum StorageType { temporary, persistent };
partial interface Navigator {
readonly attribute StorageQuota storageQuota;
};
[NoInterfaceObject] interface StorageInfo {
unsigned long long usageInBytes;
unsigned long long quotaInBytes;
};
[NoInterfaceObject] interface StorageQuota {
readonly attribute StorageType[] supportedTypes;
// Queries the current storage info.
PromiseStorageInfo queryStorageInfo(StorageType type);
// Requests a new quota for persistent storage.
PromiseStorageInfo requestPersistentQuota(unsigned long long
newQuotaInBytes);
// Creates a new StorageWatcher object to watch the storage changes.
StorageWatcher createStorageWatcher(StorageType type)
};
[NoInterfaceObject] interface createStorageWatcher {
// Fired when when the remaining storage space becomes lower
// than 10% of all available space for the type, or before the quota
backend
// triggers eviction (for temporary case), whichever happens first.
attribute EventHandler onstoragelow;
};
More feedback on this rough draft is always welcome. Also I'm going to
start updating the editor's draft based on this one and discussions we had
on this list.
/ Jonas
Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
On Fri, Aug 16, 2013 at 2:11 AM, Lars Knudsen lar...@gmail.com wrote: Hi, I know, I've mentioned this before - but why don't we just define one (hardware) direction as 0 degrees (e.g. portrait up), align all the orientation specs and keep things simple for everyone? ref http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0063.html Because that's nonsensical for landscape devices, or apps who are fine with being rotated to landscape. It's only simpler for spec authors - it requires extra work for web authors. ~TJ
[XHR] request error distinction: abort and error
Hi, I would like to bring this topic back in the list: [XHR] remove user cancels request [1]. It was quite a controversial topic and as far as I recall the discussion was not clearly concluded. We've had three different error cases to distinguish: (A) Network initiated errors (B) abort() call (C) End user cancellation in the spec [2][3]: clicking on a stop button in browser chrome, hitting escape, page navigation and window.stop() [4] (A) and (B) are apparent; the question is whether (C) should be classified as a network error or an abort error? Here's the implementation status reported by @Yaffle. [5] I support treating (C) as abort error. Semantically (B) and (C) are aligned as behaviors to abort the request while (A) occurs when the request fails by *error*. I believe, for authors, the request error handlers for (B) and (C) have better chance to have the same code logic than that of (A) and (C). (I suppose the ways to distinguish between (B) and (C) are beyond the scope of XHR.) Accordingly, it'd be necessary to change the wordings as: (before) - If the end user cancels the request This is an abort error. (after) - If abort() method is invoked - If window.stop() is invoked - If the request cancellation is trigger by the end user This is an abort error. Note: The request cancellations by the end user include clicking on a stop button in browser chrome, hitting escape, page navigation, etc. WDYT? [1] http://www.w3.org/Search/Mail/Public/advanced_search?keywords=hdr-1-name=subjecthdr-1-query=%5BXHR%5D+remove+%22user+cancels+request%22hdr-2-name=fromhdr-2-query=hdr-3-name=message-idhdr-3-query=period_month=period_year=index-type=gindex-grp=Public__FULLtype-index=resultsperpage=20sortby=date [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#infrastructure-for-the-send()-method [3] http://xhr.spec.whatwg.org/#infrastructure-for-the-send()-method [4] https://developer.mozilla.org/en-US/docs/Web/API/window.stop [5] https://github.com/w3c/web-platform-tests/issues/241#issuecomment-22750928 -- Jungkee Song
Re: [XHR] request error distinction: abort and error
- If the request cancellation is trigger by the end user
This is an abort error.
Note: The request cancellations by the end user include clicking
on a stop button in browser chrome, hitting escape, page navigation, etc.
WDYT?
I think the real reason for the disagreement is that the feature lacks a real,
solid use case - except, perhaps, if a script wanted to do alert('Hi, please
stop clicking the Stop button while we\'re processing your order') or
something. There simply isn't much a script can sensibly do in response to a
user interruption (certainly when one isn't quite sure if it is the user
interrupting or not..)
However, what one might want to do is to re-schedule some request and try again
later. In this respect, I think a user cancellation is much closer to a network
error than an abort() call. If the network fails, you can assume it's somewhat
erratic and it makes sense to try in a minute. If the user clicks stop, I guess
you can also assume that the user is somewhat erratic and it makes sense to try
again later ;-) (99% of users won't really understand that they interrupted
something, or what they interrupted, especially since I believe browsers do not
tend to have stop UI for XHR traffic).
By that logic I think having it classified as an 'error' event is better, but
IMO this is a minor detail and not really worth our time..
-Hallvord
Re: Updating Quota API: Promise, Events and some more
On Fri, Aug 16, 2013 at 6:56 AM, Kinuko Yasuda kin...@chromium.org wrote:
I had a few bike-sheddy comments as well.
Now the new draft looks like:
enum StorageType { temporary, persistent };
partial interface Navigator {
readonly attribute StorageQuota storageQuota;
};
[NoInterfaceObject] interface StorageInfo {
unsigned long long usageInBytes;
unsigned long long quotaInBytes;
};
I think these can be simplified to simply 'usage' and 'quota'. The
fact that it's in bytes doesn't really need to be spelled out in the
property name I think. Feedback that we've gotten from authors is that
they prefer short names.
[NoInterfaceObject] interface StorageQuota {
readonly attribute StorageType[] supportedTypes;
// Queries the current storage info.
PromiseStorageInfo queryStorageInfo(StorageType type);
I think simply 'getInfo' might be enough here. It should already be
obvious that it's storage-quota related.
// Requests a new quota for persistent storage.
PromiseStorageInfo requestPersistentQuota(unsigned long long
newQuotaInBytes);
// Creates a new StorageWatcher object to watch the storage changes.
StorageWatcher createStorageWatcher(StorageType type)
This could probably simply be done using a constructor. I.e.
new StorageWatcher(persistent);
[NoInterfaceObject] interface createStorageWatcher {
// Fired when when the remaining storage space becomes lower
// than 10% of all available space for the type, or before the quota
backend
// triggers eviction (for temporary case), whichever happens first.
attribute EventHandler onstoragelow;
};
Actually, the other two events made sense to me. Without onstorageok
the page has to poll queryStorageInfo to know when it's out of the
woods.
Actually, *only* having onstoragechange would solve both the use case
of detecting when you are running low on storage, as well as when you
are out of the woods. Especially if we provide both the quota and
the amount of used space in the event.
/ Jonas
Re: [webappsec + webapps] CORS to PR plans
Based on the feedback received during the Call for Consensus, I've updated the draft CORS PR at: http://webappsec-test.info/~bhill2/pub/CORS/index.html Language about an implementation report has been removed, and the only substantive modification from the previous proposed draft is that references to status codes 200 and 204 have been replaced with the 2xx range based on conformance testing that showed interoperability across the broad set of codes. A supplemental test report on the 2xx status codes as well as 308 redirect handling is available at: http://webappsec-test.info/~bhill2/pub/CORS/cors-test-supplement.htm 2xx handling is implemented consistently across Opera (Presto), IE, Firefox, Chrome and Mobile Safari. 308 handling is implemented consistently with 307 handling in Opera (Presto) and IE, and partially implemented in Firefox, satisfying the WG's criteria of two independent interoperating implementations. Additional test result submissions are welcome and encouraged. (I don't have a desktop Mac environment easily at hand.) This message resets the call for consensus by an additional seven days, to 23-Aug-2013. Please send feedback to public-webapp...@w3.org. Positive feedback is encouraged and silence will be considered assent. I have updated the target date for PR to 26-Sep-2013. Thank you, Brad Hill On Mon, Aug 5, 2013 at 4:48 PM, Brad Hill hillb...@gmail.com wrote: I'd like to issue this as a formal Call for Consensus at this point. If you have any objections to CORS advancing to Proposed Recommendation, please reply to public-webapp...@w3.org. Affirmative response are also encouraged, and silence will be taken as assent. The proposed draft is available at: http://webappsec-test.info/~bhill2/pub/CORS/index.html This CfC will end and be ratified by the WebAppSec WG on Tuesday, August 13, 2013. Thank you, Brad Hill On Tue, Jul 16, 2013 at 12:47 PM, Brad Hill hillb...@gmail.com wrote: WebAppSec and WebApps WGs, CORS advanced to Candidate Recommendation this January, and I believe it is time we consider advancing it to Proposed Recommendation. In the absence of an editor, I have been collecting bug reports sent to the public-webappsec list, and now have a proposed draft incorporating these fixes I would like to run by both WGs. The proposed draft can be found at: http://webappsec-test.info/~bhill2/pub/CORS/index.html A diff-marked version is available at: http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2Fdoc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html (pardon some spurious diffs indicated in pre-formatted text that has not actually changed) A list of changes is as follows: 1. Changed Fetch references. The CR document referenced the WHATWG Fetch spec in a number of places. This was problematic due to the maturity / stability requirements of the W3C for document advancement, and I feel also inappropriate, as the current Fetch spec positions itself as a successor to CORS, not a reference in terms of which CORS is defined. The proposal is to substitute these references for the Fetching Resources section of the HTML5 spec at: http://www.w3.org/TR/html5/infrastructure.html#fetching-resources I do not believe this produces substantive changes in the reading of CORS 2. In the Terminology section, added a comma after Concept in response to: http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html 3. Per discussion to clarify the interaction of HTTP Authorization headers with the user credentials flag, https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 and http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0366.html, I have inserted the following clarification: user credentials for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates !-- begin change -- that would be sent based on the user agent's previous interactions with the origin. !-- end change -- 4. In the defintion of the Access-Control-Allow-Methods header, in response to http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0046.html , clarified that The Allow header is not relevant for the purposes of the CORS protocol. 5. http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.htmland http://lists.w3.org/Archives/Public/public-webappsec/2013Mar/0096.htmlpoint out that header and method are not defined correctly in the response headers for preflight requests. It appears that the intent was to respond with the list provided as part of the preflight request, rather than the potentially unbounded list the resource may actually support The following clarifications were made: (for methods) Since the list of methods can be unbounded, simply returning the method indicated by Access-Control-Request-Method (if supported) can be enough. (for
[ime-api] Re: FYI: new WD of Input Method Editor API published
On Aug 16, 2013, at 5:44 AM, Arthur Barstow art.bars...@nokia.com wrote:
You may recall WebApps and PFWG discussed WebApps' Input Method Editor API
last April ([Mins]). As such, I wanted to let you know a new WD of that spec
was published on August 15: http://www.w3.org/TR/2013/WD-ime-api-20130815/
If you have any comments, please send them to the public-webapps @ w3.org
list.
-Regards, ArtB
[Mins] http://www.w3.org/2013/04/25-webapps-minutes.html#item12
This draft is much improved, but I still have one concern:
This code sample makes it clear you intend to do custom rendering of the
suggestions list…
// Render new suggeston list.
for (i = 0; i candidates.length; i++) {
suggest.appendChild(document.createElement('li'));
suggest.childNodes[i].textContent = candidates[i];
}
But it's not apparent to me how you're alerting the user agent to avoid
rendering the native candidate suggestions. It's also not clear to me how,
depending on user preference, the user agent would respond to let the web
application know that custom rendering is not allowed in this context or for
this user.
I'd expect something like this conditional to confirm with the UA that it's
okay for the web app to do custom rendering of the candidates.
// check with the UA to see if web app can render custom suggestions list
if (target.inputMethodContext.preventDefaultRendering()) {
// Render new suggeston list.
for (i = 0; i candidates.length; i++) {
suggest.appendChild(document.createElement('li'));
suggest.childNodes[i].textContent = candidates[i];
}
} // else custom rendering is disallowed by the UA
Re: [XHR] request error distinction: abort and error
On Sat, Aug 17, 2013 at 2:40 AM, Hallvord Steen hst...@mozilla.com wrote:
- If the request cancellation is trigger by the end user
This is an abort error.
Note: The request cancellations by the end user include clicking
on a stop button in browser chrome, hitting escape, page navigation, etc.
WDYT?
I think the real reason for the disagreement is that the feature lacks a
real, solid use case - except, perhaps, if a script wanted to do alert('Hi,
please stop clicking the Stop button while we\'re processing your order')
or something. There simply isn't much a script can sensibly do in response
to a user interruption (certainly when one isn't quite sure if it is the
user interrupting or not..)
However, what one might want to do is to re-schedule some request and try
again later. In this respect, I think a user cancellation is much closer to
a network error than an abort() call. If the network fails, you can assume
it's somewhat erratic and it makes sense to try in a minute. If the user
clicks stop, I guess you can also assume that the user is somewhat erratic
and it makes sense to try again later ;-)
In my understanding, here comes the difference. It seems network errors can
be considered erratic and it somehow makes sense to retry, but abort() call
and the user cancellations I referred to cannot simply be assured as
erratic situations. Users can explicitly abort the normal ongoing request
on purpose and in this case retry may not make sense. E.g. upon the request
abort made by clicking on browser stop button, the user rather expects to
explicitly reload or load the page again.
(99% of users won't really understand that they interrupted something, or
what they interrupted, especially since I believe browsers do not tend to
have stop UI for XHR traffic).
By that logic I think having it classified as an 'error' event is better,
but IMO this is a minor detail and not really worth our time..
-Hallvord
--
Jungkee Song
Re: [XHR] request error distinction: abort and error
On Fri, Aug 16, 2013 at 10:40 AM, Hallvord Steen hst...@mozilla.com wrote: However, what one might want to do is to re-schedule some request and try again later. In this respect, I think a user cancellation is much closer to a network error than an abort() call. If the network fails, you can assume it's somewhat erratic and it makes sense to try in a minute. If the user clicks stop, I guess you can also assume that the user is somewhat erratic and it makes sense to try again later ;-) I come to the opposite conclusion. If the user stops a request then we should assume that the user wanted to. We shouldn't assume that users are erratic and don't know what they are doing. Ideally we should separate all three types of errors. Though it's already possible for a page to know if it called abort since that can be handled through page-specific logic. So we need to be able to tell network errors from user aborts. (99% of users won't really understand that they interrupted something, or what they interrupted, especially since I believe browsers do not tend to have stop UI for XHR traffic). Gecko used to have UI for stopping XHR traffic, though this was more by accident than an intentional decision. I believe this has since been fixed. So based on the knowledge that browsers generally don't have UI for aborting XHRs, I would draw the conclusion that if the user did cause an abort, that that was *not* accidental but rather intentional. / Jonas
