[Bug 25088] New: 'orientationchange' should fire on Window so that there can be a event handler for it
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25088 Bug ID: 25088 Summary: 'orientationchange' should fire on Window so that there can be a event handler for it Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: i...@hixie.ch QA Contact: public-webapps-bugzi...@w3.org CC: ann...@annevk.nl, jo...@sicking.cc, m...@w3.org, public-webapps@w3.org, sim...@opera.com 'orientationchange' should fire on Window so that there can be a event handler for it. That would also mean we don't have to retroactively turn Screen into an EventTarget object. This would also make this API more consistent with the rest of the platform. -- 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 17, 2014, at 4:59 AM, Robin Berjon 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). > > I've been talking with some editor developers and have heard some interesting > ideas, notably from the Substance.io people. I think one big problem with contenteditable and execCommand is that it's a very high-level API and that there are two very distinct use cases: WYSIWYG editor - Some CMS, Mail clients, etc... Semantic editor - Some CMS, word processors, etc... And there are also two distinct desires as to what kind of markup UAs should generate: Minimal output - Mail clients want to minimize the size of emails Preserving all elements - CMS editors, etc... want to mark parts of documents via span with id, class, etc... I'm very pessimistic about the prospect of fixing execCommand. I think we have a much better chance of coming up with some lower-level API that JS libraries could use to build editors. > 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. Glad to hear that. > 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. That sounds more like a selection-mode API than contenteditable to me. > 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. The biggest piece we're missing on the web platform today is mapping of key events to intended editing actions. e.g. how do you know that Shift+Enter should insert line break as opposed to start a new paragraph, or that Shift+Control+Left should extend selection to the beginning of the line. Another big piece is undo. We currently don't have any ways to hook things up with browser's native UI for undo/redo, and as a result, most of websites implement their own undo manager which is incompatible with undo/redo menu items. I tried to solve this problem a few years ago with UndoManager API when I was still at Google but that turned into an incomprehensible monstrosity once we introduced undo scopes and other advanced APIs. We might need to introduce something simpler first like the one introduced in IE11 that uses execCommand to start and end an undo unit [1]. [1] http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx - R. Niwa
Re: On starting WebWorkers with blob: URLs...
On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren wrote: > On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson wrote: >> On Fri, 14 Mar 2014, Arun Ranganathan wrote: >>> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL >> >> LGTM. Assuming that UAs implement this, that makes Workers automatically >> support blob: URLs, too. > > I don't think this is the way we should go about this. I don't > understand why a blob URL would have an origin. Because URLs with origins are much simpler than what we do for data:. The main indicator of that is that we still haven't managed to get implementations to agree on how to do security boundaries for data:, whereas we're quite well aligned on security boundaries for http:. Inheriting origins the way data: does it is actually quite tricky from an security point of view. Internally in gecko we're moving towards adding a flag whenever we're doing a resource load that indiciates "Allow this load to inherit origin if it wants to". The default for that flag would be *false*. This is because we have been bit several times by having code from security context A (in our case code from chrome://) receive a URL from code from security context B. A would then load that URL. This way B can trick A into creating content that B controls, but that runs with As privileges. I'd love it if the web also had such an opt-in flag, but I don't know how possible that is to create. > Trying to couple origins with strings seems like a bad idea. Isn't that what http does? I'd actually love it if data: encoded an origin too in a way that prevented the above attack. But that doesn't seem possible. / Jonas
Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
On Mon, Mar 17, 2014 at 9:08 AM, Anne van Kesteren wrote: > On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky wrote: >> On 2/13/14 5:35 AM, Anne van Kesteren wrote: >>> >>> Also, Type 2 can be used for built-in elements >> >> Built-in elements need Type 4. > > Well, Chrome does not have Type 4, yet is implementing parts of the > their elements using shadow DOM constructs. So clearly something is > possible with the current design. We enforce that through C++ magic right now. There's a lot of details to figure out before it's something that can be exposed to JS. ~TJ
Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
On 3/17/14 12:08 PM, Anne van Kesteren wrote: Well, Chrome does not have Type 4, yet is implementing parts of the their elements using shadow DOM constructs. What makes you say Chrome doesn't have Type 4? They do in fact have it for the case in question, as far as I can tell (inaccessible .shadowRoot, separate worlds for the JS objects, etc). They just don't expose a way to do Type 4 to web pages. -Boris
Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky wrote: > On 2/13/14 5:35 AM, Anne van Kesteren wrote: >> >> Also, Type 2 can be used for built-in elements > > Built-in elements need Type 4. Well, Chrome does not have Type 4, yet is implementing parts of the their elements using shadow DOM constructs. So clearly something is possible with the current design. -- http://annevankesteren.nl/
[Bug 23346] Use TypeError for argument validation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23346 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Anne --- Hallvord, I guess we should just not do this and avoid churn. However, given how IDL might change around ByteString and such we might have some exception changes down the road. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25081] New: Make read operation really async
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081 Bug ID: 25081 Summary: Make read operation really async Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org It seems if the blob is closed read should not return failure synchronously if you expect to use it asynchronously. A task would be better. Also, what happens if a blob is closed while you're reading it? -- You are receiving this mail because: You are on the CC list for the bug.
Re: On starting WebWorkers with blob: URLs...
On Mon, Mar 17, 2014 at 6:59 AM, Anne van Kesteren wrote: > On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson wrote: > > On Fri, 14 Mar 2014, Arun Ranganathan wrote: > >> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL > > > > LGTM. Assuming that UAs implement this, that makes Workers automatically > > support blob: URLs, too. > > I don't think this is the way we should go about this. I don't > understand why a blob URL would have an origin. Simply fetching a blob > URL will work and the response won't be tainted and therefore it > should work. Trying to couple origins with strings seems like a bad > idea. > If you can load a blob URL as a worker, then it would become the origin of the worker, right? (That could matter more if blobs weren't same-origin only and after cross-origin workers are supported.) (I don't understand why blobs are only accessible by the same origin. They contain an unguessable random string anyway.) -- Glenn Maynard
Re: On starting WebWorkers with blob: URLs...
* Anne van Kesteren wrote: >On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson wrote: >> On Fri, 14 Mar 2014, Arun Ranganathan wrote: >>> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL >> >> LGTM. Assuming that UAs implement this, that makes Workers automatically >> support blob: URLs, too. > >I don't think this is the way we should go about this. I don't >understand why a blob URL would have an origin. Simply fetching a blob >URL will work and the response won't be tainted and therefore it >should work. Trying to couple origins with strings seems like a bad >idea. The way RFC 6454 defines the concept, an origin is a string derived from a resource identifier and one would expect 'blob' identifiers to have a "globally unique identifier" as their origin, so having one is fine. But it seems as proposed here, it would not be possible to derive the origin based only on the 'blob' identifier, you rather need specific knowledge about individual identifiers so that `blob:A` and `blob:B` end up as two same-origin blobs. I think that is incompatible with the concept as it's defined in RFC 6454, but then again, given the other problems with that, https://mailarchive.ietf.org/arch/msg/websec/ln55YxWM-uRNdxRLu9-7YH9mN2k the idea that "URLs" have "origins" may be the actual problem and we may have to make some bigger conceptual changes to explain the rules. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?
On Tue, Feb 18, 2014 at 1:12 PM, Hallvord R. M. Steen wrote: > So, the story so far is that the spec has added something it labels > "semi-trusted events" - that is an event triggered from a trusted event of a > whitelisted type. The precedence here is popup blocking - browsers already > have rules for which events are "more trusted than others" in terms of likely > expressing user intent. (An example makes this clearer: scripts are typically > allowed to call window.open() from a click event listener, but are typically > not allowed to call window.open() from an load or mouseover listener.) Those rules are part of a standard these days: http://www.whatwg.org/specs/web-apps/current-work/#allowed-to-show-a-popup You might want to file a bug to extend the list of trusted event types there. -- http://annevankesteren.nl/
[Bug 24998] What is the origin of a blob: URL?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 Anne changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Anne --- Right, I mean blob URLs should have a unique identifier as origin so we don't mix strings with origin data. The way blob URLs should work is that they don't return a tainted response when fetched and therefore workers should automatically work. -- You are receiving this mail because: You are on the CC list for the bug.
Re: On starting WebWorkers with blob: URLs...
On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson wrote: > On Fri, 14 Mar 2014, Arun Ranganathan wrote: >> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL > > LGTM. Assuming that UAs implement this, that makes Workers automatically > support blob: URLs, too. I don't think this is the way we should go about this. I don't understand why a blob URL would have an origin. Simply fetching a blob URL will work and the response won't be tainted and therefore it should work. Trying to couple origins with strings seems like a bad idea. -- http://annevankesteren.nl/
Re: [Editing] Splitting Selection API Into a Separate Specification
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). I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. 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. 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. -- Robin Berjon - http://berjon.com/ - @robinberjon
