RE: Push API - use parameterized Promise types
+1 On 20 mar 2014 at 18:13:34, Luke Hoban wrote: I agree that there is significant readability value to the consumer of a WebIDL- based API spec if the return types of Promise-returning APIs are captured in the IDL. For the same reason that documenting return types is valuable to readability even though not enforced in the JavaScript projection of WebIDL. The IDL serves a useful documentation purpose even beyond the explicit semantics it conveys. Luke From: Michael van Ouwerkerk Sent: 3/20/2014 11:46 To: Domenic Denicola Cc: public-webapps Subject: Re: Push API - use parameterized Promise types So it is not normative? It seems it would be very informative though, so still worth adding to the spec. But it seems it would be even better if it was changed to be normative. Thanks, Michael On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Michael van Ouwerkerk mvanouwerk...@google.com Ah I didn't know it has no effect on return values. Why not? Well, I believe it's the same with all WebIDL method return values. If you return something that doesn't match the declared return value, that's a spec bug, but it has no impact on anything. (This is unlike argument values, where if the user passes in something that doesn't match the declared parameter type then conversion is performed.) Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Re: On starting WebWorkers with blob: URLs...
On Fri, Mar 21, 2014 at 1:34 AM, Jonas Sicking jo...@sicking.cc wrote: We could. Would love to see proposals for that. Right now the specification for origin handling is fiction and as far as I know there is no proposal that all involved parties agree to. An important question is if we can fix data:'s origin handling, without making it complicated enough that we don't want to use it for anything else. I wish I was more familiar with the problems you are alluding too. I can definitely see how you do not want to simply load data URLs you did not create yourself in any context. But e.g. loading a (random) data URL in img and then drawing it on canvas and analyzing the data is fine. Putting a (random) data URL in iframe is asking for trouble, but putting a trusted one there is fine and not different from iframe srcdoc. Adam, Paul, is Chrome not interested in aligning its data URL handling with other browsers? In particular, inheriting the parent's origin. Is there more information somewhere on what Chrome would like the eventual status quo to be and why? -- http://annevankesteren.nl/
Re: On starting WebWorkers with blob: URLs...
On Fri, Mar 21, 2014 at 6:57 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 21, 2014 at 1:34 AM, Jonas Sicking jo...@sicking.cc wrote: We could. Would love to see proposals for that. Right now the specification for origin handling is fiction and as far as I know there is no proposal that all involved parties agree to. An important question is if we can fix data:'s origin handling, without making it complicated enough that we don't want to use it for anything else. I wish I was more familiar with the problems you are alluding too. I can definitely see how you do not want to simply load data URLs you did not create yourself in any context. But e.g. loading a (random) data URL in img and then drawing it on canvas and analyzing the data is fine. Putting a (random) data URL in iframe is asking for trouble, Exactly. Same thing with `new Worker(dataurl)` but putting a trusted one there is fine and not different from iframe srcdoc. srcdoc is more similar to eval(). I.e. it would always be foolish to take an unchecked string from an untrusted 3rd party and stick it in srcdoc. The contents of the iframe srcdoc/eval() always executes in your security context so it shouldn't be a surprise when it happens. On the other hand, iframe sandbox srcdoc is always safe and never executes in your security context. The situation with iframe src=... is much more complex, which is why it's easier to make mistakes. / Jonas
[Bug 24872] [Shadow]: Consider adding back at least :first-of-type to valid matching criteria
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24872 Dimitri Glazkov dglaz...@chromium.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Dimitri Glazkov dglaz...@chromium.org --- For the moment, let's concentrate on enabling first-of-type use case with imperative API. I reverted the original change in https://github.com/w3c/webcomponents/commit/a9583c299c4a30d9a462efd6e05438ded9926b25 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mar 18, 2014, at 2:22 PM, Johannes Wilm johan...@fiduswriter.com wrote: On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon ro...@w3.org wrote: On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). That is interesting. I had not heard that before, but it certainly makes sense in many cases. Some other issues, such as when joining two paragraphs by hitting backspace at the beginning of the second one leading to the two paragraphs not being merged the way one would assume by joining the contents of the two paragraphs, but instead by a number of font elements and similar being inserted, don't seem like they would be used by any current editor. It is my understanding that the reasoning behind this is just that A. there is no full and good spec on doing this, so B. everybody waits until there is one with fixing this. I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. They are also some of those I have spoken to. We share a lot of the same problems as they have, but it is my understanding that they have not yet had to deal with noneditable islands or noneditable islands with editable lakes and similar items. The CKEditor on the other hand does have to deal with this, as do we. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would certainly be an improvement. As it is now, we for example do not use contenteditable for anything else than the caret movement, so if that could be done right in all cases, that would mean a lot. Creating a javascript/contenteditable editor is not that hard, if one only has to deal with the various text formatting and adding functions. The problems starts if one has to get around bugs related to the cursor not moving correctly or not moving at all to certain places (for example between two inline non-editable objects in Firefox). Then one needs to create a fake-cursor, etc. which is a much bigger task and only has been achieved by a very few projects so far. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. If it would help, I could help organize a meeting with the various editor creators (Aloha, TinyMCE, CKEditor, Substance.io, Fidus writer, HalloJS, etc.) to discuss this. In my experience, these developers are very interested in getting in contact with the browser makers about this, and haven't always been successful in this. Understanding the real needs of editor developers would be great. Would it be possible to have this meeting at this year's TPAC? - R. Niwa
