Re: IndexedDB: ambiguity around IDBTransaction.error
On Fri, May 25, 2012 at 1:16 PM, Alec Flett alecfl...@google.com wrote:
I have found what feels like an ambiguity in the spec around
IDBTransaction..error and when it is available.
In particular, the spec says:
When the done flag is true, getting this property must return the error of
the request that caused the transaction to be aborted. [...] When
the done flag is false, getting this property must throw a DOMException of
type InvalidStateError.
The ambiguity here is that the 'done flag' is technically something that
resides on the request, not the transaction. After the transaction itself is
complete, the 'error' attribute should be the error that caused the
transaction to abort, if any. So the question is, which 'done' flag does
this correspond to - the done flag on the current request, the done flag on
the request that caused the abort, or some other 'done' state about the
transaction itself.
An example:
transaction = ...
transaction.objectStores(foo).put(badValue).onerror = function(event) {
// can I access transaction.error here?
// the request has its own error though.
requestError = event.target.error;
transaction.objectStores(foo).put(goodValue).onsuccess =function(event)
{
// can I access transaction.error here? If so, is it requestError, or is
it null?
}
}
transaction.objectStores(foo).put(goodValue).onsuccess =
As a consumer of this interface, I'd expect the transaction's error property
to be set early - i.e. available as soon as the error handler fires, above,
and then I'd expect it to remain unchanged for the duration of the rest of
the transaction. But I can see arguments against that. For instance, what
happens if preventDefault() is called? we need to avoid setting the error in
that case.. I think. So that would argue for some kind of 'done' flag /
state for the transaction itself.
Thoughts?
We have the 'finished' flag already, which I think is what we should
use here. Unfortunately it's somewhat ambigious when a transaction
becomes finished.
Would you mind filing a bug on this?
/ Jonas
Re: Push API draft uploaded
On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote: * As far as I understand it, |requestRemotePermission| and |checkRemotePermission| could be one single method which could be named something like |getPushServiceUrl|. The only difference between those two methods is the permission asking part but that should stay as a UA decision. Given that the method is anyway asynchronous, the UA can do whatever wanted before sending a result. Showing a permission prompt could be one of those. bryan I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse the two methods into one. I wouldn't name the proposal on the wiki page as Mozilla's proposal. This wiki is public and what is described is far from being a finished work. In addition, the wiki page is quite explicit about the existence of those two methods and the given reasons are quite invalid. * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). I don't how this could be related to Web Intents? Picking the service provider should be up to the UA (using whichever method the UA feels appropriate). If a website *needs* a specific service provider that means this API has been a failure so I wouldn't add a parameter that would help this happen. * I'm not sure why you have a |requestUrl| attribute in PushService. Do you have any use case for that? bryan The use case is that an app can have multiple Push service requests active at a time, with different URLs. In order to be able to associate each PushService object with a specific set of options or services for example, it needs to know what URL was used when the PushService object was created. The intent is similar to that of EventSource, which has the url attribute for a similar purpose (at least that is how I have used it). And since the checkRemotePermission() method needs to verify the permission for the same URL, it is better to have the resolved form of the URL available as an attribute, so that it's easy to call the checkRemotePermission() method for the right URL (as the absolute URL may have changed since the original resolution). The resolving part seems quite useless because contrary to EventSource, it might be pretty uncommon to use a relative path to the push service. Anyhow, I think this should disappear with the parameter in the methods. The client shouldn't know which server is used: this is part of the user's privacy. * |readyState| should be a DOMString. bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. I was following their lead. I don't know for XHR but the new way is DOMString for multiple reasons. I believe Ms2ger pointed you to a link which likely explains those. * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a
Re: CfC: publish WD of DOM 3 Events; deadline June 4
On Mon, 28 May 2012 13:49:01 +0200, Arthur Barstow art.bars...@nokia.com wrote: Travis would like to publish a new Working Draft of the DOM 3 Events spec and this is a Call for Consensus to do so, using http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html as the basis. Please do. cheers Note this is Not a Last Call WD and the comment tracking document for the last LCWD (published 31-May-2011) is http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by June 4 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, ArtB -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
RE: Push API draft uploaded
No, the proposal at https://wiki.mozilla.org/Services/Notifications/Push/API. This was mentioned by Jonas at the Webapps meeting as the way that Mozilla is looking at this API. In that API there are two methods: requestRemotePermission() and checkRemotePermission(); But also separately, I am considering how Web Intents can be used for API service provider discovery, and use. Thanks, Bryan Sullivan -Original Message- From: Mounir Lamouri [mailto:mou...@lamouri.fr] Sent: Tuesday, May 29, 2012 2:48 AM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 05/25/2012 04:00 PM, SULLIVAN, BRYAN L wrote: [...] I am following the Mozilla lead on registering the intent to receive messages, [...]. I'm not sure I understand. Do you mean the proposal on the wiki page is proposing to use intents? -- Mounir
Is Quota Management API ready for First Public Working Draft?
Hi Kinuko, All - what are people's thoughts on whether or not the Quota Management API spec is ready for First Public Working Draft? A rule of thumb for FPWD is that the ED's scope should cover most of the expected functionality although the depth of some functionality may be very shallow, and it is OK if there are open bugs/issues. -Thanks, Art On 5/29/12 12:30 AM, ext Kinuko Yasuda wrote: On Wed, May 23, 2012 at 9:32 PM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Wed, May 23, 2012 at 2:05 PM, Kinuko Yasuda kin...@chromium.org mailto:kin...@chromium.org wrote: https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html I noticed something else. StorageInfo is marked as Supplemental and NoInterfaceObject, but I do not think either is meant to be used here. Supplemental has been replaced by partial interface (rather than [Supplemental] interface), but is only supposed to be used if this is not the original definition (and I do not think StorageInfo is defined elsewhere). NoInterfaceObject is used prevent certain interfaces from being prototyped, but I do not think we want that here either. Oops.. thanks very much for pointing out those mistakes. You're right, neither Supplemental nor NoInterfaceObject look appropriate here. I dropped them from the draft. https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html Thanks!
Re: Feedback on Quota Management API
On 5/17/12 11:02 AM, Kinuko Yasuda kin...@chromium.org wrote: Thanks for the feedback! For context for others, I assume they are comments for the draft pushed at: https://dvcs.w3.org/hg/quota/Overview.html I'm super excited to see an API for this is in the works. It's been a much wanted feature by developers. Couple of thoughts/questions (sorry for the late feedback, I was on parental leave): 1. My experience with measuring maximum storage quota in existing implementations shows that while some implementations share a common quota across different data stores (e.g. 10 MB for both localStorage and AppCache on iOS last time I looked), not all do. What's the reasoning behind enforcing this (is it easier for implementors? Better for developers?) and is there agreement across implementors that this is the way forward? 2. If the case is that we're going for a binary choice (i.e. persistent vs. temp data stores) why not create specific methods for each rather than pass a constant (or string) as first argument: e.g.: navigator.storageInfo.queryTemporaryUsageAndQuota and navigator.storageInfo.queryPersistentUsageAndQuota That'll avoid having to deal with typos in the first arg, error handling in that case, etc. Best, --tobie
[admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
A recent manifest spec thread lead to a discussion about the group's top-posting policy which is a good segue to remind everyone we do have some expectations on the usage of the group's mail lists and I'll quote it here ... [[ http://www.w3.org/2008/webapps/wiki/WorkMode#Mail_List_Policy.2C_Usage.2C_Etiquette.2C_etc. *WebApps' members appreciate and encourage frank technical discussions on our mail lists but all discussions must be done in a respectful manner. Please note this respect requirement is codified in the Process Document via the following participation criteria Social competence in one's role http://www.w3.org/2005/10/Process-20051014/policies.html#ParticipationCriteria. Additionally, seePositive Work Environment Task Force http://www.w3.org/2007/06/PWET-statement-of-principles.htmland if you did not attend/Kindergarten/, we expect our list participants to adhere to the basic principles inAll I Really Need To Know I Learned In Kindergarten http://www.peace.ca/kindergarten.htm.* We also expect our mail list participants to adhere to the following: * Follow basic/Netiquette/ http://en.wikipedia.org/wiki/Netiquettesuch as avoiding typing in ALL CAPS * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text * Messages should not usetop-posting http://en.wikipedia.org/wiki/Posting_style#Top-posting. See theWHATWG's top-posting guidelines http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3Ffor more information. * Subjects should be prefaced with the name of the spec (for example:/[DOM4] Blah, Blah, Blah/) * Attachments must follow theW3C Guidelines for Email Attachment Formats http://www.w3.org/2002/03/email_attachment_formats.html, in particular: o Avoid unnecessary email attachments. o Use an attachment only when it is likely to benefit to recipients. Otherwise, place the information (in plain text format) in the body of your message. o If an attachment is necessary, avoid formats that are virus prone, proprietary or platform dependent. For example, whenever possible you should use HTML instead of MS Word, PowerPoint or PDF. o FollowWeb Content Accessibility Guidelines http://www.w3.org/TR/WAI-WEBCONTENT/(WCAG) ]] -Thanks, AB
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.comwrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. * Messages should not usetop-posting http://en.wikipedia.org/wiki/Posting_style#Top-posting. It's good to avoid top-posting, but unfortunately in the real world it's often just not possible: editing quotes for inline posting on a mobile device is more or less impossible. o FollowWeb Content Accessibility Guidelines http://www.w3.org/TR/WAI-**WEBCONTENT/http://www.w3.org/TR/WAI-WEBCONTENT/ (WCAG) (I hope nobody honestly expects people to read a this before posting an attachment to a mailing list.) -- Glenn Maynard
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On 2012-05-29 16:53, Glenn Maynard wrote: On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. Emails should only be in plain text. ... It's good to avoid top-posting, but unfortunately in the real world it's often just not possible: editing quotes for inline posting on a mobile device is more or less impossible. ... Then maybe one should wait with replying until a proper mail client is available :-)- ... Best regards, Julian
[Bug 17236] New: Ambiguity in IDBTransaction.error around 'done' state
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17236
Summary: Ambiguity in IDBTransaction.error around 'done' state
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: alecfl...@chromium.org
QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
The spec says:
When the done flag is true, getting this property must return the error of the
request that caused the transaction to be aborted. [...] When the done flag is
false, getting this property must throw a DOMException of type
InvalidStateError.
The ambiguity here is that the 'done flag' is technically something that
resides on the request, not the transaction. After the transaction itself is
complete, the 'error' attribute should be the error that caused the transaction
to abort, if any. So the question is, which 'done' flag does this correspond to
- the done flag on the current request, the done flag on the request that
caused the abort, or some other 'done' state about the transaction itself.
An example:
transaction = ...
transaction.objectStores(foo).put(badValue).onerror = function(event) {
// can I access transaction.error here?
// the request has its own error though.
requestError = event.target.error;
transaction.objectStores(foo).put(goodValue).onsuccess =function(event) {
// can I access transaction.error here? If so, is it requestError, or is it
null?
}
}
transaction.objectStores(foo).put(goodValue).onsuccess =
As a consumer of this interface, I'd expect the transaction's error property to
be set early - i.e. available as soon as the error handler fires, above, and
then I'd expect it to remain unchanged for the duration of the rest of the
transaction. But I can see arguments against that. For instance, what happens
if preventDefault() is called? we need to avoid setting the error in that
case.. I think. So that would argue for some kind of 'done' flag / state for
the transaction itself.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
RE: Push API draft uploaded
Responses inline. Thanks, Bryan Sullivan -Original Message- From: Mounir Lamouri [mailto:mou...@lamouri.fr] Sent: Tuesday, May 29, 2012 3:06 AM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote: * As far as I understand it, |requestRemotePermission| and |checkRemotePermission| could be one single method which could be named something like |getPushServiceUrl|. The only difference between those two methods is the permission asking part but that should stay as a UA decision. Given that the method is anyway asynchronous, the UA can do whatever wanted before sending a result. Showing a permission prompt could be one of those. bryan I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse the two methods into one. I wouldn't name the proposal on the wiki page as Mozilla's proposal. This wiki is public and what is described is far from being a finished work. In addition, the wiki page is quite explicit about the existence of those two methods and the given reasons are quite invalid. bryan OK, I am open to collapsing these two methods into one, and will update the draft with a proposal for that. * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). I don't how this could be related to Web Intents? Picking the service provider should be up to the UA (using whichever method the UA feels appropriate). If a website *needs* a specific service provider that means this API has been a failure so I wouldn't add a parameter that would help this happen. bryan The concept of service provider selection by the user (in essence the provider of some functionality distributed as Web pages/applications/workers etc) is fundamental to the Web Intents concept, so it seemed natural to me to consider that for this API. I don't think UA's should be exclusively responsible for service provider selection, for this purpose or others. If service providers can be more flexibly integrated through APIs such as Web Intents IMO that is good for the Web. * I'm not sure why you have a |requestUrl| attribute in PushService. Do you have any use case for that? bryan The use case is that an app can have multiple Push service requests active at a time, with different URLs. In order to be able to associate each PushService object with a specific set of options or services for example, it needs to know what URL was used when the PushService object was created. The intent is similar to that of EventSource, which has the url attribute for a similar purpose (at least that is how I have used it). And since the checkRemotePermission() method needs to verify the permission for the same URL, it is better to have the resolved form of the URL available as an attribute, so that it's easy to call the checkRemotePermission() method for the right URL (as the absolute URL may have changed since the original resolution). The resolving part seems quite useless because contrary to EventSource, it might be pretty uncommon to use a relative path to the push service. Anyhow, I think this should disappear with the parameter in the methods. The client shouldn't know which server is used: this is part of the user's privacy. bryan But as with EventSource, we won't know if the service URL will be commonly relative, or not. EventSource itself is quite young in terms of adoption, and with CORS there are good reasons why the path *won't* be
Re: IndexedDB: ambiguity around IDBTransaction.error
Done. https://www.w3.org/Bugs/Public/show_bug.cgi?id=17236
On Tue, May 29, 2012 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, May 25, 2012 at 1:16 PM, Alec Flett alecfl...@google.com wrote:
I have found what feels like an ambiguity in the spec around
IDBTransaction..error and when it is available.
In particular, the spec says:
When the done flag is true, getting this property must return the error
of
the request that caused the transaction to be aborted. [...] When
the done flag is false, getting this property must throw a DOMException
of
type InvalidStateError.
The ambiguity here is that the 'done flag' is technically something that
resides on the request, not the transaction. After the transaction
itself is
complete, the 'error' attribute should be the error that caused the
transaction to abort, if any. So the question is, which 'done' flag does
this correspond to - the done flag on the current request, the done flag
on
the request that caused the abort, or some other 'done' state about the
transaction itself.
An example:
transaction = ...
transaction.objectStores(foo).put(badValue).onerror = function(event) {
// can I access transaction.error here?
// the request has its own error though.
requestError = event.target.error;
transaction.objectStores(foo).put(goodValue).onsuccess
=function(event)
{
// can I access transaction.error here? If so, is it requestError, or
is
it null?
}
}
transaction.objectStores(foo).put(goodValue).onsuccess =
As a consumer of this interface, I'd expect the transaction's error
property
to be set early - i.e. available as soon as the error handler fires,
above,
and then I'd expect it to remain unchanged for the duration of the rest
of
the transaction. But I can see arguments against that. For instance, what
happens if preventDefault() is called? we need to avoid setting the
error in
that case.. I think. So that would argue for some kind of 'done' flag /
state for the transaction itself.
Thoughts?
We have the 'finished' flag already, which I think is what we should
use here. Unfortunately it's somewhat ambigious when a transaction
becomes finished.
Would you mind filing a bug on this?
/ Jonas
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On 29/5/12 17:56 , Julian Reschke wrote: On 2012-05-29 16:53, Glenn Maynard wrote: On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. Emails should only be in plain text. JCD: It would be easier for me to comply with this rule if I understood the rationale. My perception is that this rule is not relevant any more. Against this rule, I claim that the readability of replies in text-only threads is much worse, unless the replier spends ages paying attention to text formatting by hand which is not acceptable. At least, that was the case the last time I tried. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
IndexedDB: use of TypeError
So I didn't start working on/implementing indexedDB until after this message went out: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0958.html So I haven't had to face the full implications of using TypeError until this week. I'd like to (hopefully not too late) voice my opposition to TypeError for the following scenarios: - invalid value for the 'direction' parameter to open*Cursor (must be 'next', 'prev', 'nextunique', or 'prevunique') - advance(count) where count 1 - open(version) where version 1 The problem here is that these are not easily enforceable by the WebIDL spec, which means implementations have an extra burden of customizing their WebIDL implementation to custom-annotate the IDL extend things like [EnforceRange=Positive] or introducing JS semantics into their otherwise JS-free code. Now this certainly could just be an implementors complaint, but I feel like I can retroactively justify it: The rationale behind the current spec is that these are very similar to a range error where the API has a very narrow range of values, that precede any higher level semantic parameter constraints. But the problem is that they still have some semantic value within IndexedDB - i.e. even though '0' is a valid numeric value to JavaScript, it is invalid because of specific consistencies within the IndexedDB spec. Even though foo is a valid string to JavaScript, strings like next and prev are the only valid strings because they have specific meaning in the context of IndexedDB. So I'd argue that these errors should be indexeddb-specific errors, and/or reused DOMExceptions. What I miss is the NotAllowedError that I believe in an earlier version of the spec, but I could also believe that DOMException's InvalidAccessError could also be used (The object does not support the operation or argument) Alec
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On Tue, May 29, 2012 at 9:28 AM, Jean-Claude Dufourd jean-claude.dufo...@telecom-paristech.fr wrote: On 29/5/12 17:56 , Julian Reschke wrote: On 2012-05-29 16:53, Glenn Maynard wrote: On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. Emails should only be in plain text. JCD: It would be easier for me to comply with this rule if I understood the rationale. My perception is that this rule is not relevant any more. Against this rule, I claim that the readability of replies in text-only threads is much worse, unless the replier spends ages paying attention to text formatting by hand which is not acceptable. At least, that was the case the last time I tried. There are several fairly simple reasons supporting Glenn's point (Julian's is simple excessive): 1. Many HTML-producing mail clients still produce very bad HTML, which doesn't translate well to all clients. 2. In the same vein, the WYSIWYG nature often means that people end up producing something that looks good enough, particular with quote towers. Many of the rich-text editors I've seen have really bad usability around quote towers. 3. I've seen a *lot* of abuse of color as a way of distinguishing between quote and reply. This is confusing because, first, it's a second way of doing the same thing, and second, I'm color-blind. Basically, in plain text there's more-or-less only way to do most things. It's really easy to format, especially if you follow a format like Markdown so you don't have to think about things much. I happen to read and write all my messages in plain text, and I can assure you that it does not take ages. Most of the time, all I have to do is trim the whitespace that Gmail inserts at the top, and trim off signatures from the bottom. If I feel like it, I'll take a few seconds to clean up the quote tower too to add or remove blank lines at the correct quote depth as necessary. Responding to your email, for example, took less than 5 seconds of formatting time. ~TJ
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On Tue, May 29, 2012 at 9:52 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, May 29, 2012 at 9:28 AM, Jean-Claude Dufourd jean-claude.dufo...@telecom-paristech.fr wrote: On 29/5/12 17:56 , Julian Reschke wrote: On 2012-05-29 16:53, Glenn Maynard wrote: On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. Emails should only be in plain text. JCD: It would be easier for me to comply with this rule if I understood the rationale. My perception is that this rule is not relevant any more. Against this rule, I claim that the readability of replies in text-only threads is much worse, unless the replier spends ages paying attention to text formatting by hand which is not acceptable. At least, that was the case the last time I tried. There are several fairly simple reasons supporting Glenn's point (Julian's is simple excessive): 1. Many HTML-producing mail clients still produce very bad HTML, which doesn't translate well to all clients. 2. In the same vein, the WYSIWYG nature often means that people end up producing something that looks good enough, particular with quote towers. Many of the rich-text editors I've seen have really bad usability around quote towers. 3. I've seen a *lot* of abuse of color as a way of distinguishing between quote and reply. This is confusing because, first, it's a second way of doing the same thing, and second, I'm color-blind. Basically, in plain text there's more-or-less only way to do most things. It's really easy to format, especially if you follow a format like Markdown so you don't have to think about things much. I happen to read and write all my messages in plain text, and I can assure you that it does not take ages. Most of the time, all I have to do is trim the whitespace that Gmail inserts at the top, and trim off signatures from the bottom. If I feel like it, I'll take a few seconds to clean up the quote tower too to add or remove blank lines at the correct quote depth as necessary. Responding to your email, for example, took less than 5 seconds of formatting time. ~TJ And your modified reply causes GMail not to collapse the replied-to text, meaning that when I want to scan through a thread I have to spend a lot more effort finding where the previous email ended and your reply beings. There's a lot of benefits to formatted conversations. I don't understand what benefits people are claiming from plain text that aren't resolved by using an up-to-date MUA.
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
Le 29 mai 2012 à 12:59, Ian Fette (イアンフェッティ) a écrit : And your modified reply causes GMail not to collapse the replied-to text seems to be a GMail issue. […] resolved by using an up-to-date MUA. Dare putting a list somewhere? -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On Tue, May 29, 2012 at 10:32 AM, Karl Dubost ka...@opera.com wrote: Le 29 mai 2012 à 12:59, Ian Fette (イアンフェッティ) a écrit : And your modified reply causes GMail not to collapse the replied-to text seems to be a GMail issue. […] resolved by using an up-to-date MUA. Dare putting a list somewhere? Sure, how about: - Thunderbird 12 - GMail - Mail.app - Opera Mail 11.64
CfC: Publish FPWD of Web Intents spec; deadline June 12
Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a first public working draft, and this is a Call for Consensus to do so, using the following document as the basis: dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html I included public-webapps and public-device-apis on this CfC since Web Intents is a joint-deliverable [2][3] between these two groups. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is June 12. Please send all comments to: public-web-inte...@w3.org Thanks, James Hawkins [1] http://lists.w3.org/Archives/Public/public-web-intents/2012Apr/0016.html [2] http://www.w3.org/2012/webapps/charter/ [3] http://www.w3.org/2011/07/DeviceAPICharter
RE: DOM3 Events - additional editing help to move the spec forward
-Original Message- From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es] Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). It would be great to discuss this feature in future versions of the drafts mentioned before. I discussed this briefly with Jatinder Mann (who works on the High resolution timing spec--you might know him?). Based on that discussion it sounds like the high-resolution timestamp provides three features: 1. The timestamp is relative to the loaded page (not the Unix epoch) 2. The timestamp can be in microsecond resolution (a best effort-approach) 3. The timestamp is garuanteed to be monotonically increasing. Based on #1, we can't simply replace the current timestamp property on DOM events with a high-resolution time stamp--this would be a change (though perhaps not very impactful) to backward compatibility. Therefore, the only plausible action could be a new property (e.g., highResolutionTimeStamp or similar). However, I wonder what real value this would have. Typically events only fire within the scope of the current window and do not bleed out into other windows (Message and Storage events are notable exceptions)--so new Date() should be self-consistent (coming from the same script engine) even if other script engines are suffering from clock-skew. One issue that is present in IE, is Date objects that get serialized over from Web Workers--they can have a pretty big clock skew pretty quickly, but hypothetically performance.now() can cover those scenarios. Are there other specific use cases that you're finding where the timestamp property doesn't meet your needs?
Re: IndexedDB: use of TypeError
On Tue, May 29, 2012 at 9:49 AM, Alec Flett alecfl...@google.com wrote: So I didn't start working on/implementing indexedDB until after this message went out: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0958.html So I haven't had to face the full implications of using TypeError until this week. I'd like to (hopefully not too late) voice my opposition to TypeError for the following scenarios: invalid value for the 'direction' parameter to open*Cursor (must be 'next', 'prev', 'nextunique', or 'prevunique') advance(count) where count 1 open(version) where version 1 The problem here is that these are not easily enforceable by the WebIDL spec, which means implementations have an extra burden of customizing their WebIDL implementation to custom-annotate the IDL extend things like [EnforceRange=Positive] or introducing JS semantics into their otherwise JS-free code. Now this certainly could just be an implementors complaint, but I feel like I can retroactively justify it: The rationale behind the current spec is that these are very similar to a range error where the API has a very narrow range of values, that precede any higher level semantic parameter constraints. But the problem is that they still have some semantic value within IndexedDB - i.e. even though '0' is a valid numeric value to JavaScript, it is invalid because of specific consistencies within the IndexedDB spec. Even though foo is a valid string to JavaScript, strings like next and prev are the only valid strings because they have specific meaning in the context of IndexedDB. So I'd argue that these errors should be indexeddb-specific errors, and/or reused DOMExceptions. What I miss is the NotAllowedError that I believe in an earlier version of the spec, but I could also believe that DOMException's InvalidAccessError could also be used (The object does not support the operation or argument) The open*Cursor exception should be enforcable using WebIDL by using an enum. The only reason we don't have it that way in the spec is because ReSpec doesn't support that. For the other exception, I would say that it seems weird if -1 threw one error and 0 threw another one, so I'd like to stick to the current spec. There is of course also the fact that the requested change doesn't obviously make it better for web developers and that it's late in the game to make this change. What we've done in Gecko is to create a special C++ error code which turn into a TypeError by the JS-glue layer. That way we don't have to add new WebIDL annotations but we also don't have to introduce JS-isms into the C++ code. I suspect more specs will end up throwing TypeError so that solution seems good for future proofing. / Jonas
Re: DOM3 Events - additional editing help to move the spec forward
On Tue, May 29, 2012 at 12:03 PM, Travis Leithead travis.leith...@microsoft.com wrote: -Original Message- From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es] Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). It would be great to discuss this feature in future versions of the drafts mentioned before. I discussed this briefly with Jatinder Mann (who works on the High resolution timing spec--you might know him?). Based on that discussion it sounds like the high-resolution timestamp provides three features: 1. The timestamp is relative to the loaded page (not the Unix epoch) 2. The timestamp can be in microsecond resolution (a best effort-approach) 3. The timestamp is garuanteed to be monotonically increasing. Based on #1, we can't simply replace the current timestamp property on DOM events with a high-resolution time stamp--this would be a change (though perhaps not very impactful) to backward compatibility. Therefore, the only plausible action could be a new property (e.g., highResolutionTimeStamp or similar). However, I wonder what real value this would have. Typically events only fire within the scope of the current window and do not bleed out into other windows (Message and Storage events are notable exceptions)--so new Date() should be self-consistent (coming from the same script engine) even if other script engines are suffering from clock-skew. One issue that is present in IE, is Date objects that get serialized over from Web Workers--they can have a pretty big clock skew pretty quickly, but hypothetically performance.now() can cover those scenarios. Are there other specific use cases that you're finding where the timestamp property doesn't meet your needs? The main value is that it makes it much easier to synchronize the event with various animations going on. The requestAnimationFrame API uses high resolution timers relative to the page load time, as does the performance.now() function. By putting time stamps of the same unit on events, it's much easier to do things like start animations when an event occurred, but do all rendering in requestAnimationFrame. I.e. it makes it easier to account for moving the animated item between the event occurs and when the rendering happens. Likewise it makes it easier to do things like hit detection to figure out where various objects on the screen were when an event occurs, accounting for partial movement between two rendered frames. / Jonas
Re: DOM3 Events - additional editing help to move the spec forward
On Fri, May 25, 2012 at 11:30 PM, Pablo Garaizar Sagarminaga garai...@deusto.es wrote: Hello, on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc wrote: This is not yet an official last call, but if you'd like to re-read the spec and provide additional feedback--this is a good time to do it. Disclaimer: I don't know how and where to do this proposal. I hope you'll help me to find the proper place to send it. During High Resolution Time working draft final call for public comments I wrote a suggestion about DOM events' timestamps and the use of monotonically increasing values provided by High Resolution Time API: I would love to have the chance to get a DOMHighResTimeStamp as a property of an DOM event, like event.timeStamp. Events' timestamps are also subject to system clock skew and other problems mentioned in High Resolution Time working draft, and providing access to HRT when triggering events will be very helpful to program accurate interactions. I'm not sure if this could be done adding a new property to the event interface (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp property (i.e., DOMHighResTimeStamp). Please come up with a list of cases where this timestamp would be useful and start a new thread on www-...@w3.org explaining your use cases and how you think this proposal would help. I agree that this could be quite useful. It would probably be handled as part of DOM4 events. - James It would be great to discuss this feature in future versions of the drafts mentioned before. Best regards, -- Pablo Garaizar Sagarminaga Universidad de Deusto Avda. de las Universidades 24 48007 Bilbao - Spain Phone: +34-94-4139000 Ext 2512 Fax: +34-94-4139101
[Bug 17241] New: Editing API spec needs to be aware of PRE contents
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17241 Summary: Editing API spec needs to be aware of PRE contents Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: rn...@webkit.org QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org It appears that the current specification doesn't do anything special for PRE elements. It needs to be fully aware of PRE elements, and treat each line in PRE as a separate paragraph. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: Publish FPWD of Web Intents spec; deadline June 12
Please refer to the email thread below http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html Where a consensus was reached to delete the following statement from the Suggestions related text. The User Agent should ignore the suggested services from the intent invocation if the user already has a handler selected. I would like that statement to be delete before FPWD. Regards Deepanshu Gautam Senior Engineer, Service Standards, Huawei O: +86 25 56620008 M: +8613585147627 -Original Message- From: James Hawkins [mailto:jhawk...@google.com] Sent: Wednesday, May 30, 2012 2:45 AM To: WebIntents; public-webapps@w3.org; public-device-a...@w3.org Subject: CfC: Publish FPWD of Web Intents spec; deadline June 12 Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a first public working draft, and this is a Call for Consensus to do so, using the following document as the basis: dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html I included public-webapps and public-device-apis on this CfC since Web Intents is a joint-deliverable [2][3] between these two groups. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is June 12. Please send all comments to: public-web-inte...@w3.org Thanks, James Hawkins [1] http://lists.w3.org/Archives/Public/public-web-intents/2012Apr/0016.html [2] http://www.w3.org/2012/webapps/charter/ [3] http://www.w3.org/2011/07/DeviceAPICharter
