Re: [WebIDL] T[] migration
On Thu, 07 Jan 2016 20:12:44 +0100, Boris Zbarsky <bzbar...@mit.edu> wrote: On 12/18/15 3:53 AM, Simon Pieters wrote: Note that it requires liveness. Does that work for a frozen array? No. You'd have to create a new array object at the point when you want to update the set of values in the array. OK... Maybe this particular API should be a method instead that returns a sequence? Will that cause anyone to implement it? Because if no one is planning to ever implement it, it should probably be removed, not twiddled. Yes, you're right. Removed. https://github.com/w3c/csswg-drafts/commit/e5353d078e686136fdb28c7de37ffd375cd6d79f https://www.w3.org/Bugs/Public/show_bug.cgi?id=29471 -- Simon Pieters Opera Software
Re: Can we land heycam's WebIDL tests as-is and address review comments following?
On Mon, 21 Dec 2015 07:34:12 +0100, Zhang, Zhiqiang <zhiqiang.zh...@intel.com> wrote: Hi, 2+ years ago, heycam submitted WebIDL tests at https://github.com/w3c/web-platform-tests/pull/271 These tests have been reviewed by several guys but get no update ever since. I wonder if we could land the tests as-is and address the review comments in further pull requests? Then we can make a test suite to advance the specification and for people to understand the specification. Thoughts? Thanks, Zhiqiang Personally I don't object to that plan, but an alternative is to create a new branch in w3c/web-platform-tests with these changes, and anyone with push access to w3c/web-platform-tests can make changes to that branch, and then we can merge to master when it's ready. git fetch origin refs/pull/271/head:refs/remotes/origin/pr/271 --force git checkout -b webidl-tests origin/pr/271 git push -u origin webidl-tests -- Simon Pieters Opera Software
Re: [WebIDL] T[] migration
On Fri, 18 Dec 2015 18:04:27 +0100, Olli Pettay <o...@pettay.fi> wrote: On 12/18/2015 06:20 PM, Domenic Denicola wrote: From: Simon Pieters [mailto:sim...@opera.com] Note that it requires liveness. Does that work for a frozen array? Frozen array instances are frozen and cannot change. However, you can have the property that returns them start returning a new frozen array. The spec needs to track when these new instances are created. Changing the array object wouldn't be backwards compatible. (The attribute used to be DOMStringList) Maybe this particular API should be a method instead that returns a sequence? Also not backwards compatible. But I'd assume the first option (changing the array) would be less backwards incompatible, so I'd prefer that one. OK, but... Document#styleSheetSets is not widely implemented, and appears to not be widely used. On github I see 80 code matches in javascript, where most are just listing stuff, some are browser sniffing, and some might be actual usage (maybe with a fallback for other browsers?). Although it has been implemented in Gecko for a long time, I think it is possible to make incompatible changes (or maybe drop altogether). -- Simon Pieters Opera Software
Re: [WebIDL] T[] migration
On Thu, 16 Jul 2015 18:16:04 +0200, Boris Zbarsky <bzbar...@mit.edu> wrote: Other references: ·CSS OM Presumably this is Document.styleSheetSets? In practice, I believe no one except Gecko implements this and I therefore don't expect it to make it to REC... Updating this draft to use FrozenArray<> would be possible, of course. Fixed in https://github.com/w3c/csswg-drafts/commit/e8a91deb46b670d6c2d8d302492a64222928d08a Note that it requires liveness. Does that work for a frozen array? Maybe this particular API should be a method instead that returns a sequence? -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 02 Apr 2015 14:15:10 +0200, Simon Pieters sim...@opera.com wrote: http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- the test is wrong. Passing undefined means the argument is not present per Web IDL, so this should not throw. I assume you mean some other test since that test doesn't use undefined. (I'll have a look and fix ones that use undefined.) https://github.com/w3c/web-platform-tests/pull/1702 -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 18:24:22 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 3/26/15 10:51 AM, Arthur Barstow wrote: If anyone is willing to help with the failure analysis, that would be very much appreciated. Taking a brief look at some of the failures in Firefox, in addition to the ones Olli already posted about: http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- the test is wrong. Passing undefined means the argument is not present per Web IDL, so this should not throw. I assume you mean some other test since that test doesn't use undefined. (I'll have a look and fix ones that use undefined.) http://www.w3c-test.org/websockets/cookies/001.html seems racy to me: it kicks off an async test and then immediately removes the cookie, so it's not obvious to me why it expects that cookie to be present in the websocket connection; the cookie may well be removed before the connection is set up. I agree. The spec says to return from the constructor and establish the connection in parallel, so it is not guaranteed which cookies to include. Fix: https://github.com/w3c/web-platform-tests/pull/1701 But arguably that is a spec bug. It would be nice if it was deterministic. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28393 http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html looks wrong to me: the value it should get is in fact undefined, since the property got deleted from the prototype. (Will have a look.) -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 02 Apr 2015 14:15:10 +0200, Simon Pieters sim...@opera.com wrote: http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html looks wrong to me: the value it should get is in fact undefined, since the property got deleted from the prototype. (Will have a look.) http://heycam.github.io/webidl/#es-attributes [[ configurable is false if the attribute was declared with the [Unforgeable] extended attribute and true otherwise; ]] Fix: https://github.com/w3c/web-platform-tests/pull/1703 -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 18:06:15 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 3/26/15 1:02 PM, Boris Zbarsky wrote: It looks like the tests that are failed with an Error as opposed to a Fail are not being counted in the 2 passes list? And the for http://www.w3c-test.org/websockets/keeping-connection-open/001.html which is all-Timeout. This test passes for me in Blink and Gecko. It has a meta indicating it needs a long timeout. Is it a bug in the test runner being used here? -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 16:37:28 +0100, Olli Pettay o...@pettay.fi wrote: websockets/interfaces.html the test itself has bugs (uses old idlharness.js?). https://github.com/w3c/web-platform-tests/pull/1714 -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 16:37:28 +0100, Olli Pettay o...@pettay.fi wrote: Also websockets/interfaces/WebSocket/events/013.html is buggy. Seems to rely on blink/presto's EventHandler behavior, which is not what the specs says should happen. It probably matched the spec at the time the test was written. Spec now says [TreatNonObjectAsNull] so this should return the object, not null. https://html.spec.whatwg.org/multipage/webappapis.html#eventhandlernonnull Fix: https://github.com/w3c/web-platform-tests/pull/1704 -- Simon Pieters Opera Software
Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28
On Sat, 21 Mar 2015 13:52:25 +0100, Arthur Barstow art.bars...@gmail.com wrote: As previously mentioned on [p-w], the test results for Web Messaging [All] indicate significant interoperability with only two tests that have less than two passes [2]. The two tests, including a short analysis of the failure, are: 1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test failure (which passes on Firefox) can be considered more of a Web IDL implementation issue and thus not a significant interop issue. 2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this test failure (which passes on IE) is considered an implementation bug (MessageChannel and MessagePort are supposed to be exposed to Worker) that is expected to be fixed. Cindy created a Draft PR [PR] that includes Hixie's updates since the [CR] was published (but not the PortCollection interface [PC] which is not broadly implemented). Overall, we consider the changes since the CR as non-substantive bug fixes and clarifications that align the spec with current implementations, and that the test suite tests the updated spec. See [Diff] for all of changes between the CR and the draft PR and note the draft PR's status section includes a short summary of the changes. As such, this is a Call for Consensus to publish a Proposed Recommendation of Web Messaging using the [PR] as the basis. Agreement with this CfC means you consider the test results shows interoperability and the changes since CR are not substantive. If you have any comments or concerns about this CfC, please reply to this e-mail by March 28 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. If there are no non-resolvable objections to this proposal, the motion will carry and we will request the PR be published. Opera supports publishing. -Thanks, ArtB [p-w] https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html [All] http://w3c.github.io/test-results/webmessaging/all.html [2] http://w3c.github.io/test-results/webmessaging/less-than-2.html [PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/ [CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/ [PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports [Diff] https://www.diffchecker.com/qswiibb5 -- Simon Pieters Opera Software
Re: [XHR] UTF-16 - do content sniffing or not?
On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Hi, I've just added a test loading UTF-16 data with XHR, and it exposes an implementation difference that should probably be discussed: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding, or just assume UTF-8 and return mojibake-ish data? Per my test, Chrome detects the UTF-16 encoding while Gecko doesn't. I think the spec currently says one should assume UTF-8 encoding in this scenario. Are WebKit/Blink - developers OK with changing their implementation? (The test currently asserts detecting UTF-16 is correct, pending discussion and clarification.) What is your test doing? From what I understand of the spec, the result is different between e.g. responseText (honors utf-16 BOM) and JSON response (always decodes as utf-8). -- Simon Pieters Opera Software
Re: [XHR] UTF-16 - do content sniffing or not?
On Mon, 23 Mar 2015 14:32:27 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding, or just assume UTF-8 and return mojibake-ish data? What is your test doing? From what I understand of the spec, the result is different between e.g. responseText (honors utf-16 BOM) and JSON response (always decodes as utf-8). It tests responseText. OK. I think the spec currently says one should assume UTF-8 encoding in this scenario. My understanding of the spec is different from yours. Let's step through the spec. https://xhr.spec.whatwg.org/#text-response [[ Let bytes be response's body. If bytes is null, return the empty string. Let charset be the final charset. ]] final charset is null. [[ If responseType is the empty string, charset is null, and final MIME type is either null, text/xml, application/xml or ends in +xml, use the rules set forth in the XML specifications to determine the encoding. Let charset be the determined encoding. [XML] [XMLNS] ]] Which MIME type did you use in the response? BOM sniffing in XML is non-normative IIRC. For other types, see below. [[ If charset is null, set charset to utf-8. Return the result of running decode on byte stream bytes using fallback encoding charset. ]] - https://encoding.spec.whatwg.org/#decode [[ For each of the rows in the table below, starting with the first one and going down, if the first bytes of buffer match all the bytes given in the first column, then set encoding to the encoding given in the cell in the second column of that row and set BOM seen flag. ]] This step honors the BOM. The fallback encoding is ignored. -- Simon Pieters Opera Software
Is clearUndo() in UndoManager the wrong way round?
I'm implementing a partial version of UndoManager myself, as I see it to be rather useful. I'm interpreting clearUndo as clearing any undo actions, so Ctrl+z will not do anything anymore. The spec states that clearUndo resets the position to 0, but is this the wrong way round? Since position increments whenever we undo, I would think that position should be set to the undo stack's length - 1. Simon
Re: oldNode.replaceWith(...collection) edge case
On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com wrote: Ah, thank you for letting me know. I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? (I remember myself wondering why bowsers couldn’t optimize that back then.) Many people still suggest it though, including google (https://developers.google.com/speed/articles/javascript-dom https://developers.google.com/speed/articles/javascript-dom the DocumentFragment DOM Generation” section), and you can find more by googling “why use document fragment. I think that article is a bit misguided. Changing a class does trigger a reflow, but it doesn't force a reflow while the script is running (maybe it does in old browsers). Asking for layout information does force a reflow. I think documentfragment has been faster in several browsers and maybe still is, but in Blink at least it appears that the different methods are getting about equally fast. It probably depends on how you do it, though. This jsperf might be interesting: http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 So to recap, when you have the need to pass the context node as an argument along with other nodes, just use before() and after() to insert these other nodes? And even insert them one by one is fine? Yeah. -- Simon Pieters Opera Software
Re: oldNode.replaceWith(...collection) edge case
On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang curvedm...@gmail.com wrote: I wonder what the correct method should be? For the example I gave in the previous mail, it looks like I have to either create two fragments (and compute which nodes go to which fragment) and insert them before or after the node (two reflows), or implement the transient node algorithm myself (but with no suppressing observer ability, also three reflows (insert fake node, pull out context node, insert fragment), i guess if browsers implement it natively, they can reduce it to just one reflow?). Both doesn’t sound very optimal. In all cases it would be just one reflow after the script has finished, unless you force a reflow by asking for layout information (e.g. offsetTop) between the mutations. -- Simon Pieters Opera Software
Re: Defining a constructor for Element and friends
On Fri, 16 Jan 2015 20:08:30 +0100, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
How can that work if the custom element constructor needs to look in
the registry to find its name? Pick a name at random?
Nah, it just automatically starts acting like HTMLQuoteElement: the
localName option becomes required. See
https://github.com/domenic/element-constructors/blob/5e6e00bb2bb525f04c8c796e467f103c8aa0bcf7/element-constructors.js#L229-L233
https://github.com/domenic/element-constructors/blob/5e6e00bb2bb525f04c8c796e467f103c8aa0bcf7/element-constructors.js#L51-L54
Consider if HTML adds a new element that uses the same interface as
another element, let's say foobar, so that both foobar and data use
HTMLDataElement. When this happens, new HTMLDataElement() starts throwing?
Similarly, if HTML is changed such that an element changes to use a more
specific interface, e.g. ruby changes from HTMLElement to
HTMLRubyElement, then new HTMLElement('ruby') will start throwing?
If so, it seems it removes some flexibility with how HTML uses interfaces.
In particular many elements use HTMLElement and it should be possible to
change them to use a more specific interface. How do you envision to solve
this? Should we assign element-specific interfaces to all post-HTML4
elements now, just in case? Or make new HTMLElement('ruby') create an
HTMLRubyElement? Something else?
--
Simon Pieters
Opera Software
Re: [editing] Responsive Input Terminology
On Fri, 12 Dec 2014 13:39:47 +0100, Tobie Langel tobie.lan...@gmail.com wrote: On Fri, Dec 12, 2014 at 1:00 PM, Arthur Barstow art.bars...@gmail.com wrote: What is your counter-proposal? Heh. Fair enough, I guess. :) These seem related to what Java calls semantic events [JAVADOC], so I'd give that a try to see if it fits the model. If not, would abstract events or simply high-level events work? Sorry if these have already been discussed and dismissed (haven't had much time to look through the archives, tbh). How about device-independent events? -- Simon Pieters Opera Software
Re: [editing] Responsive Input Terminology
On Fri, 12 Dec 2014 17:02:25 +0100, Frederico Knabben f.knab...@cksource.com wrote: On Friday, 12 December 2014 at 14:40, Simon Pieters wrote: How about device-independent events? Aren’t we missing what kinds of events we’re talking about? We would just know that those events are device-independent. So far we’ve been talking about “input” events. If this is still the case, this should be clear. Option 1: You agree that because we’re talking about “device”, “input” is an implicit information. I’m unsure. I think this is generally understood. You wouldn't refer to e.g. the 'load' event as a device-independent event even though it technically is. Option 2: Device-Independent Input Events (dii-events then). Option 3: We’re talking about a totally new group of events, which don’t include only input, but everything that is “device-independent”. Then use cases should be listed. -- Simon Pieters Opera Software
Re: [eventsource] ACTION-742: Re sse test results, followup on the timeouts with the 2 test facilitators (Web Applications Working Group)
On Thu, 13 Nov 2014 10:14:38 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Nov 13, 2014 at 9:20 AM, Zhang, Zhiqiang zhiqiang.zh...@intel.com wrote: We may need to re-evaluate the tests, however, because the latest editor draft has removed this statement in the CR: [[ This constructor must be visible when the script's global object is either a Window object or an object implementing the WorkerUtils interface. ]] Thoughts, Simon Odin? Redundant with [Exposed]. Please use https://html.spec.whatwg.org/multipage/comms.html#server-sent-events when implementing. What Anne said. :-) -- Simon Pieters Opera Software
Re: [Custom] Custom elements and ARIA
On Thu, 28 Aug 2014 16:57:00 +0200, Domenic Denicola dome...@domenicdenicola.com wrote: Hi Steve, thanks greatly for your help. It's clear now that I should have reached out to you for your expertise directly before being very wrong on a public mailing list :) From: Steve Faulkner faulkner.st...@gmail.com It appears (please correct me) you have made the assumption that 'strong native semantics' for roles is a UA requirement? This is not the case (in the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has gone in defining ARIA in HTML), they are author conformance requirements. Yes, I was misled about that pretty badly. That changes things, as it means there are no non-overridable roles or stoperties (as you show with hr role=menuitem). States and properties can be non-overridable, though, as I understand it. [[ When a host language declares a WAI-ARIA [state/property] attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic. ]] http://www.w3.org/TR/wai-aria/host_languages#host_general_conflict_header From my reading though, the default implicit ARIA semantics are still UA requirements, right? Yes. [...] -- Simon Pieters Opera Software
Re: HTML imports: new XSS hole?
On Mon, 02 Jun 2014 11:32:45 +0200, Anne van Kesteren ann...@annevk.nl wrote: How big of a problem is it that we're making link as dangerous as script? HTML imports can point to any origin which then will be able to execute scripts with the authority of same-origin. I still think it is a problem. http://www.w3.org/mid/op.ww3ecpo5idj3kv@simons-macbook-pro.local -- Simon Pieters Opera Software
Re: where do tests for window.opener go?
On Wed, 21 May 2014 17:54:44 +0900, Zhang, Zhiqiang zhiqiang.zh...@intel.com wrote: From: Hallvord R. M. Steen [mailto:hst...@mozilla.com] Sent: Wednesday, May 21, 2014 4:22 AM To: public-webapps Subject: [web-platform-tests] where do tests for window.opener go? Hi, we have a window.opener issue and would like to have some tests for it. I'm planning to write some and thought I might as well add them to the web- platform-tests suite. Where? Would this be a suitable location: https://github.com/w3c/web-platform- tests/tree/master/html/browsers/the-window-object/security-window ? -HR For security, yes. For navigating auxiliary browsing contests in the DOM, better to https://github.com/w3c/web-platform-tests/tree/master/html/browsers/windows/auxiliary-browsing-contexts Alternatively, if there are multiple plausible places, and you want some related tests to be in the same place but still annotate some of them as being a test for another section, you can do that with link rel=help. -- Simon Pieters Opera Software
Re: Custom Elements: 'data-' attributes
On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa rn...@apple.com wrote: On the other hand, if the same element had exposed contentEditable property, then UA's native contentEditable property would simply be overridden since it would appear higher up in the prototype chain. It's true that this custom element's contentEditable would have completely different semantics from that on other elements but that wouldn't break websites that use this custom element as long as authors are only accessing contentEditable property on instances of the custom element for semantics C. I forgot the exact details, but we had some amount of trouble when we introduced min and max attributes due to sites using expandos with the same names. I think we need something better than encouraging certain conventions if we want this to work. Bare names in event handler content attributes are troublesome. For instance, sites doing: button onclick=action() made us have to rename button action to button formaction (the new .action reflecting action= was closer in the scope chain than the intended function). Global attributes have the same issue. So when we research if it's safe to add a new global attribute, it's not enough to measure how often such an attribute is used in the wild. We need to research bare names in event handlers also. -- Simon Pieters Opera Software
Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?
On Wed, 18 Dec 2013 11:58:07 +0100, Simon Pieters sim...@opera.com wrote: On Tue, 17 Dec 2013 17:06:57 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 12/17/13 3:29 AM, Jonas Sicking wrote: This is a good point. Would this have performance implications for down-level browsers? I don't know if prescanners etc in contemporary browsers are smart enough to ignore script tags that use a non-JS type attribute. Gecko's is not. Not least because as far as I can tell scripts with unknown type are in fact always loaded, In my testing this appears to not be the case. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2697 This gives nothing in the Network tab in Firefox or in my TCP inspector. I think this is the same as what the spec requires and what at least WebKit/Blink/Presto also do. Sorry, not Presto. See step 7 in http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#prepare-a-script (the fetch happen in step 14). But it seems you are correct about the behavior of the speculative parser in Gecko: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2698 Same in WebKit/Blink. -- Simon Pieters Opera Software
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On Wed, 11 Dec 2013 14:42:15 +0100, Arthur Barstow art.bars...@nokia.com wrote: One of the issues here is `missing data`. Indeed. The first Call for workers Test Results was sent over a half-year ago and another one a few weeks before WebApps' Shenzhen meeting. Despite those requests, the workers implementation report [IR] remains empty. Simon - would you please add results for Presto? Done. First I ran the tests using https://bitbucket.org/ms2ger/test-runner/src on a local server, but then I couldn't think of a straight-forward way to put the results in the wiki so I just ran the tests manually, too. :-( Since most tests are automated it's silly to run them manually and edit a wiki page. Is there a better way? I also found a bug in a test https://www.w3.org/Bugs/Public/show_bug.cgi?id=24074 (Actually there were several tests with bugs but I didn't investigate further.) Kinuko - would you please add results for Chrome (as you said you would do in Shenzhen [Mins])? Travis - would you please add results for IE? Another issue is that during the related discussion in Shenzhen, I don't think this new info from Jonas was available. Jonas - can someone please run the tests on FF Nightly (see [IR] or the test suite [Tests])? Depending on the test results, it might make sense to (re)consider if it still makes sense to create a spec of without shared workers. -Thanks, ArtB [IR] http://www.w3.org/wiki/Webapps/Interop/WebWorkers [Tests] http://w3c-test.org/web-platform-tests/master/workers/ [Mins] http://www.w3.org/2013/11/12-webapps-minutes.html#item08 -- Simon Pieters Opera Software
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On Tue, 10 Dec 2013 20:14:35 +0100, Travis Leithead travis.leith...@microsoft.com wrote: During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. I'm afraid that won't be enough; if you two implementations passing all approved tests you need to remove the spec for dedicated workers also. Safest is probably to remove the whole spec and all the tests, then we'll have 100% pass rate. Seriously though, I really don't understand the motivation here. I'd rather we remove the first exit criteria than try to punch conformance holes in the spec for failing tests. -- Simon Pieters Opera Software
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On Tue, 10 Dec 2013 22:09:38 +0100, Jonas Sicking jo...@sicking.cc wrote: We at Mozilla just finished our implementation of Shared Workers. It will be turned on in the nightly releases starting tomorrow (or maybe thursday) and will hit release on April 29th. Excellent. So if we are only reason we're doing anything here is lack of a 2nd implementation, then we might already be good. The premise here appears to be that Presto doesn't count. Why? Presto has been shipping shared workers for 3,5 years now (introduced in Opera 10.60). As far as I can tell Presto-based Opera products match the definition of implementation in the CR exit criteria. That said, I don't know what the test suite status is etc, so I'm totally fine with punting Shared Workers for now. The test suite coverage is about the same between dedicated workers and shared workers, I believe. However I'd really like to see us start a level 2 of the spec. The synchronous messaging channels is something else I'd like to see done there. / Jonas -- Simon Pieters Opera Software
Re: Sync IO APIs in Shared Workers
On Fri, 22 Nov 2013 03:33:51 +0100, Jonas Sicking jo...@sicking.cc wrote: The only browser shipping SharedWorkers is Chrome (not sure if Opera does too?), Yes, both Presto-based (since Opera 10.60) and Chromium-based. -- Simon Pieters Opera Software
Re: Define window.orientation
On Wed, 06 Nov 2013 01:17:31 +0100, Jonas Sicking jo...@sicking.cc wrote: window.screen.orientation seems like a better way forward. Why would window.screen.orientation be any more correctly implemented than window.orientation? -- Simon Pieters Opera Software
Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time
On Tue, 29 Oct 2013 00:54:05 +0100, Anne van Kesteren ann...@annevk.nl wrote: We are considering not throwing in XML. Only on getting innerHTML, though, right? -- Simon Pieters Opera Software
Re: [clipboard] typo in WebIDL
On Tue, 08 Oct 2013 12:32:22 +0200, Hallvord R. M. Steen hst...@mozilla.com wrote: Better now, right? http://dev.w3.org/2006/webapi/clipops/clipops.html#dictionary-clipboardeventinit-members Not quite, you removed the attribute keyword from the interface declaration too, where it is needed. Guilty, and fixed - I obviously need to study that WebIDL spec in some detail.. :-/ Pro tip: use http://www.w3.org/2009/07/webidl-check (I invoke it in my Makefile for CSSOM). -- Simon Pieters Opera Software
Re: [clipboard] typo in WebIDL
On Tue, 08 Oct 2013 17:19:51 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/8/13 7:47 AM, Simon Pieters wrote:
Pro tip: use http://www.w3.org/2009/07/webidl-check (I invoke it in my
Makefile for CSSOM).
Hmm. What makes sure this is updated when the spec is updated? I just
tried this:
interface Foo {
void x(optional long y, long z);
};
and the checker reports an error...
See the footer. Please report bugs on github.
https://github.com/dontcallmedom/webidl-checker/issues
--
Simon Pieters
Opera Software
Re: [XHR] Content-Length header for data: URLs
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg j...@ubourg.net wrote: Sure, what I actually meant is that you'd need to somehow pre-parse the data URL to extract the exact length before storage. Dunno how desirable/desired/common this is. I would hardly call taking the length subtracting any characters before the , and applying a multiplier parsing. You don't have to look at any characters after the , at all. Just applying a multiplying doesn't take percent-escaping into account, though. -- Simon Pieters Opera Software
Re: [XHR] xhr.responseXML.cookie ?
On Fri, 20 Sep 2013 12:53:23 +0200, Hallvord Steen hst...@mozilla.com wrote: Hi, per this test: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm some implementations define responseXML.cookie and some don't. This probably isn't really XML-related, but I guess it should be raised and possibly defined somewhere (is it already?)? It's defined here: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-cookie Since that document has no browsing context, getting returns empty string and setting does nothing, per spec. -- Simon Pieters Opera Software
Re: [XHR] responseXML.referrer
On Fri, 20 Sep 2013 12:58:42 +0200, Hallvord Steen hst...@mozilla.com wrote: Another issue exposed by http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm Gecko sets responseXML.referrer to the requesting URL. Most other implementations set it to an empty string. Where is / should this be spec'ed? http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-referrer The XHR spec doesn't seem to set the document's referrer, so the value is the empty string per spec. -- Simon Pieters Opera Software
Re: [XHR] statusText, status and network errors
On Fri, 20 Sep 2013 13:20:44 +0200, Hallvord Steen hst...@mozilla.com wrote: Test case http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-redirect-bogus.htm has an interesting behaviour in Gecko. Last test fails with output: assert_equals: expected but got WEBSRT MARKETING Test returns a bogus redirect like HTTP/1.1 303 WEBSRT MARKETING Location: foobar:some...@example.org Per spec, this is a network error. Now, the spec does *not* explicitly say that exposing .statusText for network errors is wrong, although the test asserts that it is. Maybe some spec clarification is required? Or maybe it makes sense to pass status and statusText on to the script even if redirects fail, and we should spec that? -Hallvord http://xhr.spec.whatwg.org/#network-error - http://xhr.spec.whatwg.org/#request-error - http://xhr.spec.whatwg.org/#terminate-the-request - Set the error flag. http://xhr.spec.whatwg.org/#dom-xmlhttprequest-statustext - If the error flag is set, return the empty string. (I'm not sure where the spec says that the above case is a network error, though.) -- Simon Pieters Opera Software
Re: when will serializing a document throw?
On Fri, 20 Sep 2013 14:01:36 +0200, Hallvord Steen hst...@mozilla.com wrote: If a document is passed to send(), the spec says re-throw any exception the serializing throws. There is a test that attempts to test this statement: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-entity-body-document-bogus.htm It passes a completely empty document without even a document element to send(). No implementation throws. Is the incomplete spec attemt on http://domparsing.spec.whatwg.org/#concept-serialize-xml the best reference we have at the moment? Even the statement I found there about serializing comments that do not match the comment syntax seems not to match reality - Gecko serialized a document containing 'html!-- invalid comment ---/html just fine. I think the reason here is that what the spec says is the right thing, and there probably isn't a Web compat reason not to do the right thing, but browsers haven't considered this to be high priority to fix. Maybe we could remove the throwing from the spec, but it seems kind of sad to not catch this in the serializer. Does anyone have examples of documents that should and actually DO throw when serialized? Or should we just drop that test and leave that spec statement untested? Why would you drop the test? -- Simon Pieters Opera Software
Re: when will serializing a document throw?
On Fri, 20 Sep 2013 14:34:55 +0200, Hallvord Steen hst...@mozilla.com wrote: I think the reason here is that what the spec says is the right thing, and there probably isn't a Web compat reason not to do the right thing, but browsers haven't considered this to be high priority to fix. Well, that may be the reason - and I'm not aware of any compat issues anyone has had in the past because of exceptions here. It still seems a bit suspect that all implementors have aligned perfectly on the spec-wise wrong behaviour. It also carries a bit of a risk to push for introducing new exceptions and make code that didn't throw historically change behaviour. Sure. Not throwing gives the impression that it will round-trip, but actually it won't. That's bad. Catching the error early is better. (Another solution to this problem would be to make the XML parser error tolerant, but that hasn't been a great success so far.) Maybe we could remove the throwing from the spec, but it seems kind of sad to not catch this in the serializer. Sort of.. but then again, I guess a completely empty string could be considered a valid representation of a completely empty document..? :-) XML can't represent an empty document. -- Simon Pieters Opera Software
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Wed, 24 Apr 2013 13:00:48 +0200, Kenneth Rohde Christiansen kenneth.r.christian...@intel.com wrote: I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. There's currently http://dev.w3.org/csswg/css-device-adapt/#dom-interfaces Is that sufficient? -- Simon Pieters Opera Software
Re: webcomponents: import instead of link
On Wed, 15 May 2013 20:26:36 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, May 14, 2013 at 2:21 PM, Simon Pieters sim...@opera.com wrote: That seems to be an argument based on aesthetics. That's worth considering, of course, but I think is a relatively weak argument. In particular I care about the first bullet point above. link is not capable of executing script from an external resource today. What are the implications if it suddenly gains that ability? Given that WebAppSec peeps suggested that CSP treats link rel=import as script-src, I am pretty sure we're okay here. Are there any other things that we should worry about? That by itself doesn't make me confident that there are no security problems. If this has been reviewed by the security team at one or several browser vendors, that would inspire more confidence. Has it? I don't have a specific attack scenario to present right now. I'm just presenting my knee-jerk reaction to making an existing element capable of executing script from an external file. Case study: img was historically not capable of executing script from an external file. This lead to sites expecting img to be safe (e.g. allow untrusted comments to use img). When browsers wanted to support SVG in img, scripting had to be disabled in order to not break the assumption that img is safe. There's one more ditty that seems valuable: HTML Imports scripts-blocking behavior is much closer to how link rel=stylesheet works (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html#dfn-import-ready-flag and thereabouts) I'm not familiar with the code for this in browsers, but it seems to me that it shouldn't be much harder to reuse the mechanism for this if we use script import rather than link rel=import. -- Simon Pieters Opera Software
Re: webcomponents: import instead of link
On Tue, 14 May 2013 09:45:01 +0200, Hajime Morrita morr...@google.com wrote: Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? The good old link has its own semantics which allows users to change the attributes dynamically. For example, you can change @href to load other stylesheets. @type can be dynamically changed as well. In contrast, importing HTML document is one-shot action. We don't allow updating @href to load another HTML. (We cannot do that anyway since there is no de-register of custom elements.) This difference will puzzle page authors. And an implementer (me) is also having troubles... Current link implementation is all about dynamic attribute changes. disabling its dynamic nature only with @rel=import seems tricky. Well, yes. I can just refactor the code. But this complication implies that making it interoperable will be a headache. There will be many hidden assumptions which come from underlying link implementation. For example, what happens if we update @rel from import to style after the element imported document or vice versa? We need to clarify all these cases if we choose link as our vehicle. It seems burden for me. Using new element like import doesn't have such issues. We can just define what we need. Also, we'll be able to introduce import-specific attributes like @defer, @async or even something like @sandbox without polluting link vocabulary. One downside is that we'll lose the familiarity of link. But having indirection like the Import interface smells like we're just abusing it. What do you think? Is this reasonable change or am I just restarting something discussed before? I have proposed script import=url/script instead of link rel=import href=url before. http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0009.html http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0024.html Benefits: * Components can execute script from an external resource, which script src can do as well, so that seems like a good fit in terms of security policy and expectations in Web sites and browsers. * script src is not dynamic, so making script import also not dynamic seems like a good fit. * script can appear in head without making changes to the HTML parser (in contrast with a new element). To pre-empt confusion shown last time I suggested this: * This is not script src. * This is not changing anything of the component itself. -- Simon Pieters Opera Software
Re: URL comparison
Le 25/04/2013 20:41, s...@cateches.is a écrit : Requests I've heard before I looked at :local-link(): * Simple equality * Ignore fragment * Ignore fragment and query * Further normalization (browsers don't normalize as much as they could during parsing, but maybe this should be an operation to modify the URL object rather than a comparison option) What about links that point to a null URL with a hash? ie a href=#back-to-top Obviously this is a local link, but it doesn't really fit into the host/path/query segmentation that's defined with the :local-link([0|1|2...]) definition[1]. Perhaps a :local-link(hash) keyword would be appropriate so that we could select links within the page? [1]http://dev.w3.org/csswg/selectors/#local-pseudo Selectors 4 says an element that is the source anchor of a hyperlink whose target's absolute URL matches the element's own document URL. So the href attribute value would be parsed as an URL and made absolute per the usual rules before being matched by :link-local. In an HTML document, without a base element, the base URL would be the document URL and so :link-local would match. However, :local-link() also ignores port/scheme which is not typical. Isn't it perfectly reasonable to expect that a different scheme/port is running an entirely different application? I agree that Selectors 4 should be changed here. URLs that differ only by the scheme or port number should not be considered local. -- Simon Sapin
Re: Fixing appcache: a proposal to get us started
On Wed, 03 Apr 2013 14:50:53 +0200, Robin Berjon ro...@w3.org wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content negotiation headers for images vs media files. I'm not sure
that this is worth it though given how few websites use content
negotiation headers.
* Use script to detect which formats are supported by the UA and then
use cacheURL to add the appropriate URL to the cache.
* Use the NavigationController feature.
* Use UA-string detection. You can either send different manifests
that point to different URLs for the media, or use a single manifest
but do the UA detection and serve different media files from the same
media URL. This is a pretty crappy solution though.
Another option: in your list of URLs to cache, instead of just strings
you can also have objects of the form { video/webm: kittens.webm,
video/evil: dead-kittens.mv4 } that would operate in a manner
modelled on source, caching only what's needed.
Is this intended only for video resources, or arbitrary resources?
Non-media elements (and hence, non-media resources) don't have the
source mechanism, so maybe the syntax should make it clear that it's
media-specific.
e.g.:
MEDIA
kittens.webm video/webm; codecs=...
kittens.mp4 video/mp4; codecs=...
# one MEDIA block per resource?
This doesn't include the media= attribute of source, but I think that
should be dropped from the element anyway.
Something similar could be done for img srcset, maybe, which is a
different beast than source.
It's a bit verbose, but it's a lot less verbose than loading the content
twice.
--
Simon Pieters
Opera Software
Re: [editing] defaultParagraphSeparator
On Tue, 05 Feb 2013 01:41:14 +0100, Alex Mogilevsky alex...@microsoft.com wrote: ± From: Pablo Flouret [mailto:pab...@motorola.com] ± Sent: Monday, February 4, 2013 12:47 PM ± ± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky alex...@microsoft.com ± wrote: ± ± There was a discussion here a while ago on desired default behavior ± for Enter in contenteditable and options for ± execCommand(defaultParagraphSeparator): ± http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/thre ± ad.html#msg171 ± ± Did it ever get to consensus? Or is there new thinking on how that ± should work? ± ± I implemented this in Opera and WebKit[1], can't really tell from the ± bugzilla bug if it's in firefox too[2], but i think they were on board as ± well. ± ± [1] https://bugs.webkit.org/show_bug.cgi?id=59961 ± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303 The Editing API document flags defaultParagraphSeparator as having issues, some are mentioned in the document and more raised in the discussion. Such as * default value (currently 'p', but not consistent in implementations) Opera used p for compat with IE, though I don't have a strong opinion about what the default should be, so long as we all do the same thing. * default styles (if 'p' is default, it adds default 1em margin before first line, which most people consider undesirable) The undesirable style is basically the reason we implemented this in Opera. We didn't want to just use div by default because it was considered risky compat-wise. * when should Enter insert a line break instead of block (e.g. when inside pre)? Isn't this defined in the spec? https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command * can/should the default block be set per editable area and how? This is not specific to defaultparagraphseparator but applies to many commands, and there has been a proposal to expose execCommand on elements. * why only 'p' and 'div'? Only p and div addresses the use case of p having undesirable style. If there is a chance to settle on what's right for any of these, it would be awesome. Alex [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-defaultparagraphseparator-command -- Simon Pieters Opera Software
Re: [editing] defaultParagraphSeparator
On Sat, 09 Feb 2013 02:11:41 +0100, Alex Mogilevsky alex...@microsoft.com wrote: ± From: Pablo Flouret [mailto:pab...@motorola.com] ± Sent: Monday, February 4, 2013 12:47 PM ± ± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky alex...@microsoft.com ± wrote: ± ± There was a discussion here a while ago on desired default behavior ± for Enter in contenteditable and options for ± execCommand(defaultParagraphSeparator): ± http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/thre ± ad.html#msg171 ± ± Did it ever get to consensus? Or is there new thinking on how that ± should work? ± ± I implemented this in Opera and WebKit[1], can't really tell from the ± bugzilla bug if it's in firefox too[2], but i think they were on board as ± well. ± ± [1] https://bugs.webkit.org/show_bug.cgi?id=59961 ± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303 I can't find any documentation for any of the implementations, perhaps you could answer if the following is true: * The command name is defaultParagraphSeparator, unprefixed In Presto, it's opera-defaultblock (we implemented it before it was in the spec). * Argument is case insensitive * The only available options are P and DIV * Default is P In Presto, yes. Is that correct? Thanks Alex -- Simon Pieters Opera Software
Re: Monkeypatching document.createElement() is wrong
On Tue, 12 Feb 2013 12:24:59 +0100, Anne van Kesteren ann...@annevk.nl wrote: If the goal of custom elements is to expose the guts of what happens https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element is the wrong solution. Currently new Image() and createElement(img) are equivalent and no additional magic is required. Same for new Audio() and createElement(audio). Not quite, actually. new Audio() sets the content attribute preload=auto. -- Simon Pieters Opera Software
Re: RfR: Web Workers Test Cases; deadline March 28
On Thu, 14 Mar 2013 20:34:52 +0100, Arthur Barstow art.bars...@nokia.com wrote: This is a WG-wide Request for Review [RfR] for the tests Microsoft and Opera submitted for the Web Workers CR [CR]: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ http://w3c-test.org/webapps/Workers/tests/submissions/Opera/ Simon (Web Workers' `Test Facilitator`) proposed in [1] the tests are sufficient to test the CR's exit criteria. If you have any comments, please send them to public-webapps-testsu...@w3.org by March 28. I've looked at all the files in http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ , below are my comments. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_ErrorEvent_message.htm assert_not_equals(err.message, undefined); assert_not_equals(err.message.indexOf(ErrorMessage), -1); I think this assertion should be removed. The spec doesn't require any particular text in the message argument of onerror, so it doesn't make sense to check the value in a test, beyond checking that it is a string. I'd suggest the following assertion instead of the two above: assert_equals(typeof err.message, 'string'); (Same thing in Worker_ErrorEvent_message.htm.) The WorkerGlobalScope_ErrorEvent tests are not testing ErrorEvent at all, but are testing WorkerGlobalScope#onerror and its arguments. I suggest renaming these tests and their description to be less confusing as to what they are testing. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_EventTarget.htm title WorkerGlobalScope implements EventTarget /title var t = async_test(Test Description: WorkerGlobalScope implements EventTarget); This doesn't affect what the test does, but in the spec the interface inherits from EventTarget, rather than implements it. assert_regexp_match(target, /\[object (.*?)Worker(.+?)\]/); This should be instead: assert_equals(target, '[object WorkerGlobalScope]'); http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_removeEventListener.htm This has trailing junk that should be removed. This test also appears to be brittle as to whether it produces a result (I often get Not Run result). It appears to have to do with timing -- it sets a setTimeout that may or may not be longer than the timeout set in setup(). Other tests use the same pattern. I would recommend having a fixed number in setTimeout of, say, 100ms, and do this for all tests that contain `time * 2`. (Some tests do this already.) setTimeout(t.step_func(VerifyResult), time * 2); change to setTimeout(t.step_func(VerifyResult), 100); That appears to give more stable results for me. I also recommend changing the timeout in setup() in all tests to 2000ms since it might take some time to load the worker file, and I seem to get Not Run sometimes (when loading a test the first time) for some tests even if they're just waiting for a message event. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerLocation_hash_nonexist.htm var t = async_test(Test Description: WorkerLocation hash attribute returns an empty string when there is no lt;querygt; component in input URL.); change to var t = async_test(Test Description: WorkerLocation hash attribute returns an empty string when there is no query component in input URL.); (Similarly in other files, search for `lt;`.) worker.postMessage(EvalScript); EvalScript is not defined. I think the whole line can be removed. (Same error in some other files.) http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerNavigator_appName.htm var description = WorkerNavigator appName: Returns the name of the browser: + window.navigator.appName; Remove window.navigator.appName from the description since it complicates comparing results of tests between browsers if the names of the tests differ between browsers. (Similarly for the other WorkerNavigator tests.) Test names should be fixed strings. The spec now has a 'language' member for WorkerNavigator but there's no test for it. There are some tests (e.g. the ErrorEvent tests) that are almost identical, connect to the same worker, get the same data, and only differ in what they check. This seems to be an inefficient way of doing things and makes the test suite take longer than necessary to run. I would recommend folding such tests together into one file and have separate test_async() objects for each thing that is to be tested. http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/Worker_ErrorEvent_type.htm All the Worker_ErrorEvent tests are wrong in that the ErrorEvent.js file catches the runtime error in onerror and then returns true, which means that the error is handled, and no error event should be fired on the worker object
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky bzbar...@mit.edu wrote: And if so, which objects should they be on? Window? Documents? Elements? Currently event handlers are available on all of Window, Document and HTMLElement even if the relevant event just fires on one of them, so I suggest we do that. -- Simon Pieters Opera Software
Re: Review of the template spec
On Fri, 14 Dec 2012 00:04:20 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 11, 2012 at 5:00 AM, Henri Sivonen hsivo...@iki.fi wrote: 1. If DOCUMENT does not have a browsing context, Let TEMPLATE CONTENTS OWNER be DOCUMENT and abort these steps. 2. Otherwise, Let TEMPLATE CONTENTS OWNER be a new Document node that does not have a browsing context. Is there a big win from this inconsistency? Why not always have a separate doc as the template contents owner? Or why not always use the owner document of the template element? I think that would cause things like img elements to load. Documents are fairly heavy-weight and introducing several documents into the mix means that we have to deal with issues like making sure that those documents have the same behavior (for example, if HTML elements in those documents uppercase the nodeName or not) / Jonas -- Simon Pieters Opera Software
Re: [webcomponents] More backward-compatible templates
On Fri, 02 Nov 2012 22:41:22 +0200, Adam Barth w...@adambarth.com wrote: I'm not sure offhand of the parsing behavior of xmp. Will it prevent the contents from being parsed as tags? Yes. xmp is basically ![CDATA[...]] for HTML. There are differences, though: * it closes p * default style is display: block; margin-top: 1em; margin-bottom: 1em; font-family: monospace; white-space: pre; unicode-bidi: isolate; -- Simon Pieters Opera Software
Re: Scrolling when document.documentElement requests fullscreen
On Fri, 07 Sep 2012 01:32:07 +0200, Chris Pearce cpea...@mozilla.com
wrote:
We've had a couple of bugs filed against Gecko recently about scrolling
fullscreen content.
Currently behaviour differs between Chrome and Gecko when fullscreen is
requested on document.documentElement. When this happens Chrome still
shows the viewport/browser scrollbars, but Gecko does not show viewport
scrollbars.
For example, compare the behaviour of
http://robnyman.github.com/fullscreen/index-high-content.html in Chrome
and Firefox.
Our developer evangelists tells us that authors intuitively expect
scrollbars when requesting fullscreen on document.documentElement.
Authors expect that since the document is scrollable (via the viewport
scrollbars) before entering fullscreen it should remain scrollable after
entering fullscreen.
Gecko does not show viewport scrollbars when requesting fullscreen on
document.documentElement since the :fullscreen psuedoclass's
position:fixed positioning styles cause it to be unscrollable. I don't
know why Chrome shows scrollbars in this case.
We're proposing in the relevant Mozilla bug [1] to change our
implementation so that the :fullscreen pseudoclass rule is :not(:root).
This would mean that document.documentElement would still be scrollable
after entering fullscreen, which would then match authors' expectations.
i.e.:
*|*:not(:root):fullscreen {
position: fixed;
top:0; right:0; bottom:0; left:0;
/* etc... */
}
Before I make this change in Gecko I'd like to get consensus from other
implementers that we want this behaviour, and get the spec changed to
reflect that.
Sounds good to me.
Regards,
Chris Pearce.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=779286#c18
--
Simon Pieters
Opera Software
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. -- Simon Pieters Opera Software
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: 1. Explicitly undefine this case. That would not be my preference. 2. Spec IE9, Firefox13 and Opera12alpha's behavior Roughly speaking, the choice is an invalid token or '|' whichever comes first, but I'd note that in the corner case These are valid: |a *|a My proposed spec change: # If the group of selectors include namespace prefixes that need to # be resolved, the implementation must raise a NAMESPACE_ERR # exception. s/NAMESPACE_ERR/SYNTAX_ERR/ -- Simon Pieters Opera Software
[selectors-api] Consider backporting find() behavior to querySelector()
So http://dev.w3.org/2006/webapi/selectors-api2/ introduces the methods find() and findAll() in addition to querySelector() and querySelectorAll() and changes the scoping behavior for the former methods to match what people expect them to do. I'm not convinced that doubling the API surface is a good idea. If we were to do that every time we find that a shipped API has suboptimal behavior, the API surface on the Web would grow exponentially and we wouldn't make the overall situation any better. What if we find a new problem with find() after it has shipped? Do we introduce yet another method? I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. -- Simon Pieters Opera Software
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Fri, 01 Jun 2012 11:02:43 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
| If its specified 'position' is 'static', it computes to 'absolute'.
What if position is not specified?
Everything's specified.
http://www.w3.org/TR/CSS21/cascade.html#specified-value
Other comments:
# *|*:fullscreen {
# position:fixed;
# top:0; right:0; bottom:0; left:0;
# margin:0;
Shouldn't that be margin: auto? I'd've assumed you'd want replaced
elements
centered by default.
No because width/height are set as well. We should maybe set another
property for replaced elements. content-fit or some such.
Do you mean object-fit? I guess it would be nice for images to be
object-fit:contain in fullscreen. (Videos already are.)
--
Simon Pieters
Opera Software
Re: Proposal: add websocket close codes for server not found and/or too many websockets open
On Fri, 01 Jun 2012 21:33:47 +0200, Jason Duell jduell.mcb...@gmail.com wrote: On 05/28/2012 04:03 AM, Takeshi Yoshino wrote: The protocol spec has defined 1015, but I think we should not pass through it to the WebSocket API. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0437.html I think 1006 is the right code for all of WebSocket handshake failure, TLS failure and TCP connection failure. If the language in http://tools.ietf.org/html/rfc6455#section-7.4.1 is not good, we can add cannot be opened or before closed abnormally for clarification. I could certainly live with this. It would be nice to have it clarified in the W3C websocket spec that we won't be delivering 1015 (I assume it's too late to take it out of RFC 6455). You can submit errata, but should probably raise it on hybi first. And to have the additional language you suggest for 1006 (connection could not be opened or something like that) added somewhere (again I assume RFC 6455 isn't possible, but the IANA database and/or the W3C spec). As above. best, Jason Mozilla -- Simon Pieters Opera Software
Re: Proposal: Document.parse() [AKA: Implied Context Parsing]
On Fri, 25 May 2012 09:01:43 +0200, Rafael Weinstein rafa...@google.com
wrote:
Ok, so from consensus on earlier threads, here's the full API
semantics.
Now's the time to raise objections to UA's adding support for this
feature.
-
1) The Document interface is extended to include a new method:
DocumentFragment parse (DOMString markup);
which:
-Invokes the fragment parsing algorithm with markup and an empty
context element,
-Unmarks all scripts in the returned fragment node as already started
-Returns the fragment node
2) The fragment parsing algorithm's context element is now optional.
It's behavior is similar to the case of a known context element, but
the tokenizer is simply set to the data state
3) Resetting the insertion appropriately now sets the mode to Implied
Context if parsing a fragment and no context element is set, and
aborts.
4) A new Implied Context insertion mode is defined which
-Ignores doctype, end tag tokens
-Handles comment character tokens as if in body
-Handles the following start tags as if in body (which is as if in
head): style, script, link, meta
-Handles any other start tag by selecting a context element, resetting
the insertion mode appropriately and reprocessing the token.
5) A new selecting a context element algorithm is defined which
takes a start tag as input and outputs an element. The element's
identity is as follows:
-If start tag is tbody, thead, tfoot, caption or colgroup
return table
-if start tag is tr,
return tbody
-if start tag is col
return colgroup
-if start tag is td or td
return tr
-if start tag is head or body
return html
-if start tag is rp or rt
return ruby
I think ruby is better handled by always making rp and rt generate
implied end tags in the fragment case (maybe even when parsing normally,
too). Making the context element ruby still doesn't make rt parse
right, because the spec currently looks for ruby on the *stack* (and the
context element isn't on the stack).
Also, the ruby base is allowed to include markup, so this would fail:
ruby.appendChild(document.parse('spanfoo/spanrtbarrtbaz'));
-if start tag is a defined SVG localName (case insensitive)
return svg
Except those that conflict with HTML?
-if start tag is a defined MathML localName (case insensitive)
return math
(Making the context element svg or math doesn't do anything currently:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 )
-otherwise, return body
--
Simon Pieters
Opera Software
Re: Proposal: add websocket close codes for server not found and/or too many websockets open
On Wed, 23 May 2012 06:21:21 +0200, Jason Duell jduell.mcb...@gmail.com wrote: On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters sim...@opera.com wrote: 4. If the connection could not be opened, either because a direct connection failed or because any proxy used returned an error, then the client MUST _Fail the WebSocket Connection_ and abort the connection attempt. I'm also wondering if it would be useful to have a dedicated error code for this case (server not available'). I believe it would be a security problem to expose to scripts detailed reasons about how it failed to connect. Could you say more about why a simple connection not available would be a security problem, Simon? Earlier drafts of the WebSocket Protocol had the following requirement (I don't know why it was removed; I stopped following hybi): User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations: o A server whose host name could not be resolved. o A server to which packets could not successfully be routed. o A server that refused the connection on the specified port. o A server that did not complete the opening handshake (e.g. because it was not a WebSocket server). o A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified an origin that differed from the script's). o A WebSocket server that abruptly closed the connection after successfully completing the opening handshake. I believe the problem is related to wanting to not expose information about stuff behind the user's firewall, more than can be exposed with other Web features already. Pre-WebSocket features don't expose connection not available vs other reasons for failure, if I'm not mistaken, so WebSocket shouldn't either to be on the safe side. We already have a code for the special case of TLS handshake failing: Maybe we shouldn't. (Same argument as above.) a code that encompasses every other reason why the connection wasn't made doesn't seem obviously risky to me (but I'm no security expert).. Also: I expect every browser that implements web sockets will have some limit on the number of websockets it allows to be open at once (to prevent DoS attacks if nothing else). The spec has a simple measure against DoS -- only allowing one socket in the connecting state at a time per host (or some such). But there can be platform-specific limitations. True, but this doesn't protect against running out of file descriptors for sockets, etc. Indeed. So while it's not an easy DoS vector, it's still a possible scenario. For now, Firefox is calling onerror and onclose with 1011 in this case (internal error, though it's a loose application of the code, since its intended to be sent by the remote endpoint rather than used for internal errors in the client). I could probably be persuaded to throw an exception instead--in fact, I'm almost convincing myself of it as I type :)(We made the decision not to queue the connection, because WS's are long-lived and there's thus no obvious wait time bounds). OK. Exception works for me. It would be good if the WebSocket API spec said to throw (and what to throw) for this scenario. Thanks for the feedback. Jason Duell Mozilla -- Simon Pieters Opera Software
Re: Proposal: add websocket close codes for server not found and/or too many websockets open
On Wed, 16 May 2012 02:17:45 +0200, Jason Duell jduell.mcb...@gmail.com wrote: So the Web Socket spec is a little vague on how JS is notified when the targeted web socket server is down/nonexistent/etc. Firefox is firing an 'error' event when this happens, based on the language here in the W3C spec: if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection Chrome is not calling onerror for this, so we have a difference here. The language in the spec isn't really clear if this covers the connection-never-happened case. Both Chrome and Firefox (haven't tested other browsers/clients) are then calling close with code=1006, which seems the best code available in RFC 6455, but the language there isn't great either: to indicate that the connection was closed abnormally, e.g., without sending or receiving a Close control frame. There's essentially no mention in either spec of what happens when there never was any connection to the server.. It would be useful to be clear about whether onerror should be called here. I'm also wondering if it would be useful to have a dedicated error code for this case (server not available'). I believe it would be a security problem to expose to scripts detailed reasons about how it failed to connect. Also: I expect every browser that implements web sockets will have some limit on the number of websockets it allows to be open at once (to prevent DoS attacks if nothing else). The spec has a simple measure against DoS -- only allowing one socket in the connecting state at a time per host (or some such). But there can be platform-specific limitations. I'm not sure of what the right close code for this is. Ideas? Perhaps we could also use a dedicated code for this case too. Or throw an exception? Or queue the connection? I've touched on this subject before, but we didn't reach any conclusion as to what the right thing to do is. Jason Duell Mozilla -- Simon Pieters Opera Software
Re: Proposal: add websocket close codes for server not found and/or too many websockets open
On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters sim...@opera.com wrote: On Wed, 16 May 2012 02:17:45 +0200, Jason Duell jduell.mcb...@gmail.com wrote: So the Web Socket spec is a little vague on how JS is notified when the targeted web socket server is down/nonexistent/etc. Firefox is firing an 'error' event when this happens, based on the language here in the W3C spec: if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection Chrome is not calling onerror for this, so we have a difference here. The language in the spec isn't really clear if this covers the connection-never-happened case. Both Chrome and Firefox (haven't tested other browsers/clients) are then calling close with code=1006, which seems the best code available in RFC 6455, but the language there isn't great either: to indicate that the connection was closed abnormally, e.g., without sending or receiving a Close control frame. There's essentially no mention in either spec of what happens when there never was any connection to the server.. 4. If the connection could not be opened, either because a direct connection failed or because any proxy used returned an error, then the client MUST _Fail the WebSocket Connection_ and abort the connection attempt. _Establish a WebSocket Connection_ in rfc6455 It would be useful to be clear about whether onerror should be called here. I'm also wondering if it would be useful to have a dedicated error code for this case (server not available'). I believe it would be a security problem to expose to scripts detailed reasons about how it failed to connect. Also: I expect every browser that implements web sockets will have some limit on the number of websockets it allows to be open at once (to prevent DoS attacks if nothing else). The spec has a simple measure against DoS -- only allowing one socket in the connecting state at a time per host (or some such). But there can be platform-specific limitations. I'm not sure of what the right close code for this is. Ideas? Perhaps we could also use a dedicated code for this case too. Or throw an exception? Or queue the connection? I've touched on this subject before, but we didn't reach any conclusion as to what the right thing to do is. Jason Duell Mozilla -- Simon Pieters Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 09 May 2012 22:32:08 +0200, Scott González scott.gonza...@gmail.com wrote: Perhaps I'm missing something, but isn't foocaptionbar/caption an invalid use case? Any top-level element that needs a context can't be mixed with a text node. Are there cases where this isn't true? foo tspanbar/tspan baz -- Simon Pieters Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 09 May 2012 19:01:42 +0200, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing
and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Or just string with the tag name, so it works the same as template
context?
Have innerHTML use that as the context element to the fragment parsing
algorithm.
df.innerHTML = 'p::before { content: 'hello world'; }';
Have template take an argument that's the element tag name for it to
use to create its context element. Defaults to body.
template context=tr td /template
template context=svg g/ /template
Parse template by creating a new Document object that's like the
ones
you get from createDocument() (i.e. dead), and then creating a
DocumentFragment owned by that Document, and then pushing that
DocumentFragment onto the stack instead of the template element, but
set up to act like the template element for the purposes of being
popped off. (Except when parsing without a browsing context, then you
just parse normally.)
Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)
--
Simon Pieters
Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 09 May 2012 19:29:42 +0200, Ryosuke Niwa rn...@webkit.org wrote:
On May 9, 2012 10:26 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 09 May 2012 19:01:42 +0200, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing
and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null
means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Or just string with the tag name, so it works the same as template
context?
What happens when I pass a?
I think that should get in body. Do we need to support anything more
than svg and math to get foreign content parsing here?
--
Simon Pieters
Opera Software
Re: [IndexedDB] Checked in fix for ReSpec issue
On Thu, 03 May 2012 07:56:49 +0200, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 2, 2012 at 2:07 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 02 May 2012 13:46:27 -0700, Jonas Sicking jo...@sicking.cc wrote: I certainly agree that it would be better to move the definition of when to throw exceptions into the prose for each function and attribute, but that's a big change that I don't think we should block on. (In fact, it might be big enough that we don't want to take it on at all, but that's something we shouldn't decide on here). Is the order of exceptions defined? E.g. if a method can throw two different exceptions and you violate both requirements, which exception throws? That's one of the minor problems this legacy DOM-style gives. I suspect that's not always defined no. It doesn't seem like a huge deal, but it's definitely another argument for moving away from depending on the current style. Yes, I would much prefer if specs currently using ReSpec moved towards using algorithms like the HTML spec. It's much clearer and is less likely to have gaping holes for edge cases. -- Simon Pieters Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein rafa...@google.com wrote: Here's the approach for picking the implied context element: Let the first start tag token imply the context element. The start tag = implied context element is as follows: caption, colgroup, thead, tbody, tfoot = HTMLTableElement tr = HTMLTableBodyElement col = HTMLColGroupElement td, th = HTMLTableRowElement head, body = HTMLHTMLElement rp, rt = HTMLRubyElement Any other HTML tagName = HTMLBodyElement Isn't this one redundant with the last step? Any other SVG tagName = SVGElement Any other MathML tagName = MathElement What are these two, exactly? The parser currently doesn't have a list of SVG/MathML tag names, and the SVG WG didn't like it when it was proposed to use a fixed list of SVG tag names for parsing SVG in text/html, IIRC. Also note that innerHTML on non-HTML elements currently always parses in the in body insertion mode. I'd like to see that fixed before we try to support foreign content in contextless innerHTML. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 Any other tagName = HTMLBodyElement -- Simon Pieters Opera Software
Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer
On Thu, 12 Apr 2012 22:11:38 +0200, Eric U er...@google.com wrote: On Thu, Apr 12, 2012 at 12:54 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 12 Apr 2012 21:48:12 +0200, Boris Zbarsky bzbar...@mit.edu wrote: Because it's still in the current editor's draft and it's still in the Gecko code and I was just reviewing a patch to it and saw the API? ;) Eric, the plan is to remove that from File Writer, no? Yes. The next draft I publish will mark it deprecated, and it will eventually go away. Please just remove it from the spec directly. If implementors feel they want to keep it around for a while longer, that's up to them, but the spec should describe the end goal. As for implementations, it's usually simpler to remove features earlier than to wait a while and hope it will be possible to remove it later. The longer a feature is exposed on the Web, the more content will end up relying on it. However, currently at least Gecko and WebKit support BlobBuilder, and WebKit doesn't yet have the Blob constructor, so it'll be a little while before it actually fades away. That being said, we should be talking about making this addition to Blob, not to BlobBuilder. I thought we discussed long ago it should be removed in favor of a constructable(sp?) Blob? Could be. Like I said, it's still in the editor's draft. Blob with constructor is in http://dev.w3.org/2006/webapi/FileAPI/ Also, should it not accept just ArrayBufferView then as per XMLHttpRequest? Is there existing content depending on BlobBuilder and its ArrayBufferView stuff? I thought the idea was to not have BlobBuilder at all. -- Anne van Kesteren http://annevankesteren.nl/ -- Simon Pieters Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Wed, 11 Apr 2012 07:56:48 +0200, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 10:44 PM, David Levin le...@google.com wrote: What is the backwards compatibility story for websites already using SharedWorkers with the interface that has been in the spec for over a year now? There are sites using them. For example, Google Docs uses them and Google Web Toolkit exposes them. Either we get them updated to the new API or we keep ports[0] around for compat. If we can't get rid of ports[0], I see less value in making the change at all since some scripts will use .source and other will use .ports[0], which seems pretty confusing. Google Docs can hopefully be updated before implementations ship with this, but GWT might be more problematic since there may be legacy apps around with unknown update shedule... As far as I can see there are no backwards compat breaking changes proposed. Are there any particular parts you are worried about? I proposed setting ports to null. -- Simon Pieters Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking jo...@sicking.cc wrote: I would prefer to expose the port through .source even if we can't get rid of .ports[0] right now. I think the longer we wait with removing it, the more legacy will be created that relies on its existence. The ports property is basically useless right now except for this one instance and so while I agree that there might be some confusion in the short term, it doesn't seem like it would be a compatibility problem, and long term it seems like a win that authors wouldn't have to worry about the property at all. It might continue to work if we decide that it's needed for back compat, but it seems like we eventually would be able to get rid of it given how new the property still is. / Jonas -- Simon Pieters Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this
proposal.
Can someone comment or cc relevant people, please?
FWIW this to me seems like a good improvement to the intuitiveness.
OK. To make things clear, are you OK with making this change in WebKit?
Since
a MessageEvent interface is being used, qualifying that *source*
WindowProxy
is populated is all that's needed?
It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
IDL for MessageEvent's source member would need to change type from
WindowProxy? to object?.
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers.
One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 20:26:04 +0200, Travis Leithead travis.leith...@microsoft.com wrote: IE10 does not implement SharedWorkers at the present time. We also don’t yet implement the updated Transferrable notion for MessagePorts in the structured clone algorithm. Ah, OK. We do ship Workers now, and so my primary concern is that the spec doesn't remove the ports property of the MessageEvent. Yep, I'm not suggesting to remove it. I don't mind the proposal to re-use .source of MessageEvent for a connect event on a SharedWorker. I think it's a bit ugly to swap the WindowProxy type of .source to any just for this case. Anne said the type could be (WindowProxy or MessagePort)?. I am curious to see where this latest discussion on perhaps using a different Event interface for connect events will lead... -- Simon Pieters Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 19:33:55 +0200, Andrew Wilson atwil...@google.com
wrote:
I'll agree that having to use ports[0] to access the MessagePort in a
connect event has always felt a bit like an API wart. However, I don't
entirely recall why we wanted to have the connect event use the
MessageEvent interface. So I'd be uncomfortable with changing connect
event
to not match that interface without understanding why we made those
interfaces match in the first place (perhaps Ian can chime in here).
I don't see the problem with using MessageEvent for connect.
I'll also note that the MessageEvent for cross-document messaging has a
|ports| attribute, so I'm not certain why removing this attribute on the
connect event makes it closer to the [cross-document messaging] API -
can
you clarify your reasoning here?
The code you write looks more like in cross-document messaging:
// cross-document messaging:
// I can get a message event from several places
onmessage = function(e) {
// post a pong message back
e.source.postMessage('pong', '*');
}
// shared workers:
// I can get a connect event from several places
onconnect = function(e) {
// post a pong message back
e.source.postMessage('pong');
}
The author doesn't need to care that e.source are different objects in the
two cases, they only need to care that it exposes a postMessage method
that they can use to communicate back.
Also, since MessagePort is not a
WindowProxy, I'm not sure we want to encourage developers to treat them
as
the same by putting them both as the |source| attribute in MessageEvents
in
different contexts, especially since the postMessage() APIs don't
precisely
match.
Hey, we use MessageEvent in lots of different contexts with different
semantics -- cross-document messaging, workers, shared workers,
EventSource, WebSocket... I don't think making this change to shared
workers is going to invalidate the usage of MessageEvent.
On Tue, 10 Apr 2012 19:47:12 +0200, Andrew Wilson atwil...@google.com
wrote:
To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
changed to support object transfers after we defined the connect event
structure, so it's not unreasonable that we should take another look at
the
connect event to try to make it match the current definition of
postMessage().
I think the model of connect event we've used in the past
(pre-structure-clone-transfer) is as if the creator of the SharedWorker
were sending a message like so:
postMessage(, [newPort]);
The recipient then receives a MessageEvent with data= and
ports=[newPort].
In the new world where postMessage() supports a transfer object, I think
the appropriate analogous connect event would be to result in a
MessageEvent with both the |data| and |ports| attributes pointing at an
array containing a single MessagePort. I don't think putting the
MessagePort as the source attribute is the right model.
I don't think authors think of it in this way.
--
Simon Pieters
Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this proposal.
Can someone comment or cc relevant people, please?
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers. One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
Shared workers - use .source instead of .ports[0] ?
Hi,
In Opera Extensions we use something that resembles shared workers. One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
Re: [XHR] Constructor behavior seems to be underdefined
On Mon, 02 Apr 2012 07:50:21 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 4/2/12 1:33 AM, Simon Pieters wrote: Yes, but what do they use for the origin of the Worker object itself? Run a worker for the resulting absolute URL, with the script's browsing context of the script that invoked the method as the owner browsing context, with the script's document of the script that invoked the method as the owner document, with the origin of the entry script as the owner origin, and with worker global scope as the global scope. http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-worker Well, that's origin for the worker *script*. Yes, that's not the same thing. The Worker *object* doesn't have an origin, I think. Well, what controls which scripts can touch the Worker object? That should be controlled by the origin of the window or document it's associated with, but the spec doesn't define what that is. I.e. if you create one and then one of the documents involved has .domain set on it, what happens? The document's effective script origin changes. The origin doesn't. Sure. Workers use origin, not effective script origin, so setting document.domain should have no effect on workers even if you set it before creating the worker. I think you're missing my point. Say I have two documents d1 and d2, in windows w1 and w2 respectively. These are same-effective-origin (whether because they started that way or because both set document.origin to the same thing doesn't matter). Assume script in w1 has a reference to w2 (e.g. w2 is in a subframe). Script running in w1 does: var worker = new w2.Worker(some_url); Then script in w2 changes d2.origin, which changes the effective origin of w2 and d2. What happens to script that runs later on in w1 and tries to call a method on |worker|? For comparison, if Worker is replaced with Image in the above scenario, the correct answer is a security exception is thrown because for purposes of touching the image object itself what matters is whether the effective origin of the script that's running matches the effective origin of the image's ownerDocument. Not that the spec actually says this anywhere that I can tell... http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0 has rules for specific things. Yes, that's talking about a different thing entirely (e.g. for images this defines an origin for the image _data_, not for the image object itself; the two can obviously differ when the image load is not same-origin with the page the img tag is in). Perhaps the spec terminology for the thing I'm after here is effective script origin? That seems to be what it uses for Document. But maybe it only does that so it can define it for scripts by reference to the document that loaded them? In any case, the concept I'm after is the thing that determines whether script at a particular effective script origin can touch your properties. The spec (_some_ spec, at least) needs to define the value of this concept for all objects. The simplest thing is to piggyback on the existing all objects are associated with some global bit in WebIDL and say that for a given object this concept has the same value as the global it's associated with (which is what Gecko, say, does in practice). But then you have to define what the value of this concept is for globals (for Windows it would be the effective script origin of the .document, I believe) and which global each object is associated with (the point of this thread). -Boris -Boris Ah, I see what you're saying. I can find: User agents must throw a SecurityError exception whenever any properties of a Document object are accessed by scripts whose effective script origin is not the same as the Document's effective script origin. http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents and window has some rules involving effective script origin. http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object I don't know how well this matches reality though. It seems the spec forbids access to iframe.contentWindow.document but allows iframe.contentDocument. -- Simon Pieters Opera Software
Re: [XHR] Constructor behavior seems to be underdefined
On Sat, 31 Mar 2012 13:09:40 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 3/31/12 2:15 AM, Cameron McCormack wrote: Boris Zbarsky: What's the document associated with xhr? Is it w1.document, w2.document, or window.document? The concept the Window object for which the XMLHttpRequest interface object was created doesn't seem to be defined anywhere I don't have a dfn for it, but http://dev.w3.org/2006/webapi/WebIDL/#dfn-initial-object says that each global environment has a set of interface objects, and in http://dev.w3.org/2006/webapi/WebIDL/#es-platform-objects I use the term associated with, but again not wrapped in a dfn. Sure. And the latter section says: It is the responsibility of specifications using Web IDL to state which global environment (or, by proxy, which global object) each platform object is associated with. And my point is that the XHR spec doesn't state that. Stating that the return value is associated with the same global environment as the constructor that was used to create it would do the trick. On the other hand, maybe that should just be in WebIDL? Are there use cases for constructors which create platform objects associated with a different global than the constructor itself? I believe some things in the HTML spec uses the entry script, at least for the purpose of choosing origin or base URL. For instance: WebSocket, Worker. -- Simon Pieters Opera Software
Re: [XHR] Constructor behavior seems to be underdefined
On Mon, 02 Apr 2012 07:20:27 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 4/2/12 12:58 AM, Simon Pieters wrote: I believe some things in the HTML spec uses the entry script, at least for the purpose of choosing origin or base URL. For instance: WebSocket, Worker. Yes, but what do they use for the origin of the Worker object itself? Run a worker for the resulting absolute URL, with the script's browsing context of the script that invoked the method as the owner browsing context, with the script's document of the script that invoked the method as the owner document, with the origin of the entry script as the owner origin, and with worker global scope as the global scope. http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-worker Well, that's origin for the worker *script*. The Worker *object* doesn't have an origin, I think. (SharedWorker also uses entry script.) I.e. if you create one and then one of the documents involved has .domain set on it, what happens? The document's effective script origin changes. The origin doesn't. Workers use origin, not effective script origin, so setting document.domain should have no effect on workers even if you set it before creating the worker. As far as I can tell, the HTML spec doesn't actually define this behavior (and for that matter it doesn't seem to define the origin of most objects, unless I'm missing something...) -Boris http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0 has rules for specific things. -- Simon Pieters Opera Software
Re: WebSockets -- only TCP?
On Thu, 15 Mar 2012 12:28:54 +0100, Rick van Rein r...@openfortress.nl wrote: Hello, I would like to comment on the current (20120313) WebSockets specification. The text sounds to me like it implicitly assumes that all protocols are run over TCP. It could be said that the choice of URL makes it sufficiently general to include UDP (and possibly SCTP), but the usage of terms like connecting sends a hint to implementers that support of TCP would suffice. If the intention is to create a TCP-only WebSocket, then I think this should be made explicit. And if UDP would also be supported, then a remark around connection states that some apply only to connection-oriented URL protocols would send a clearer message to implementers. I do think UDP is too important to discard from WebSockets; among the things we can do with current technology (Flash or Java) is a softphone running in a browser; in a TCP-only HTML5 environment with deprecated support for these technologies such options would have no standing ground. See PeerConnection in http://dev.w3.org/2011/webrtc/editor/webrtc.html I hope this is helpful feedback. Best wishes, Rick van Rein OpenFortress -- Simon Pieters Opera Software
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, 28 Feb 2012 13:05:37 +0100, Jonas Sicking jo...@sicking.cc wrote: If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to U+FFFD them in APIs. If the only way to get them is a JS escape, then an exception seems OK. People use JS strings to handle binary data. This is something that has worked since the dawn of JS and is something that I believe is defined to work in recent ECMAScript specs. I don't think that we can start restricting that and try to enforce that JS-strings always contain valid UTF16. Right. So I think our only option is to make all APIs which does UTF16-UTF8 conversion explicitly define how to deal with invalid surrogates. Sure, I don't suggest we leave it undefined. My preference would be to deal with them by encoding them to U+FFFD for the same reason that we let the HTML parser do error recovery rather than XML-style draconian error handling. I'm not really opposed to making APIs use U+FFFD instead of exception, but I'm not entirely convinced, either. If people use binary data in strings and want to use them in these APIs, U+FFFDing lone surrogates is going to silently scramble their data. Why is this better than throwing an exception? -- Simon Pieters Opera Software
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote: On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan aranganat...@mozilla.comwrote: Simon, Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 I was thinking of If the data argument has any unpaired surrogates, then throw a SyntaxError exception.. http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#dom-websocket-send That defines decoding UTF-8 to Unicode strings. You need the reverse. Using a replacement scheme like UTF-8 decoding, instead of a hard exception, seems more consistent with how encodings in general are handled. Otherwise, you'll end up with bugs in code if, for example, people paste in unpaired surrogates (Firefox allows this, last I checked), Maybe unpaired surrogates should be converted to U+FFFD on paste. Are there other cases? causing unexpected exceptions in code. Instead, just convert them to U+FFFD, which gives much more graceful error handling for such a rare case that most people will never handle explicitly. If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to U+FFFD them in APIs. If the only way to get them is a JS escape, then an exception seems OK. I think WebSocket should do the same, for the same reason. Have you filed a bug? -- Simon Pieters Opera Software
Re: [IndexedDB] Numeric constants vs enumerated strings
On Thu, 23 Feb 2012 10:47:56 +0100, Odin Hørthe Omdal odi...@opera.com wrote: On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking jo...@sicking.cc wrote: Yes! I would love to make this change. This is my main peeve with the API as it stands. Cool! :D I even think that implementations could remove support for the numbers by keeping the constants but have them defined to return string values. I.e. db.transaction([store], IDBTransaction.READ_WRITE); would continue to work and is the usage pattern that I've seen in all code that I've looked at. Ah, that is a very smart idea. We just had the break of open() with upgradeneeded instead of setVersion. That's a much bigger break, and if most of us get this in with the same change - it can just slip nicely in. The code would have to change anyway. So I think it's not too hard to remove the constants as well. It's obviously a bit different for Mozilla, since they've shipped their setVersion killer already, but generally Mozilla is not afraid of changing stuff if they want to (and it doesn't hurt too much, which IMHO it won't in this case, sync XHR + CORS is much more painful :P). The few people who code directly to nightly versions will be used to changing their code anyway. Keep supporting the numbers is OK, but a bit strange, given the above reasons. As long as it's not possible to rely on the numbers, I hope that developers won't use it anyway, and it'll slowly become obsolete. Then it can be very easily removed again. Although skipping that dance is of course even better ;-) To be honest, I think authors will use the enumerated strings - so if some implementations do some backwards compat stuff, it'll hopefully become obsolete. I think if we want the end result to be strings only, the best way to get there is for everyone to remove support for constants and numbers at the same time as they implement support for strings. -- Simon Pieters Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, 11 Jan 2012 16:39:48 +0100, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa rn...@webkit.org wrote: p has default margins. That alone is enough for us not to adopt p as the default paragraph separator. On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters sim...@opera.com wrote: Sure, but some apps like to send their stuff in HTML email to clients that don't support styling, or some such. I used to think that this was a strong argument, but then I realized blockquote and ol and ul have default margins too. So if you want it to look right, you'll have to use a stylesheet. Also, it's worth pointing out that recent versions of Word have margins by default when you hit Enter. But Simon makes a good point: for the e-mail use-case, styling might not be available. So this is a decent reason to support div. Also, unfortunately, there are many legacy contents that rely on the fact webkit uses div as the paragraph separator so we need a global or per editing-host switch regardless. This is also a good reason -- it lets preexisting apps that expect div opt into that behavior in new browsers, instead of being rewritten to support p. Okay, so what API should we use? I'd really prefer this be per-editing host. In which case, how about we make it a content attribute on the editing host? It can be a DOMSettableTokenList. Maybe something like div editoptions=tab-indent where the attribute is a whitespace-separated list of tokens. To start with, we can maybe have tab-indent (hitting Tab indents) and div-separator (hitting Enter produces div). Does this sound like a good approach? If so, what should we call the attribute? Currently the editing options available, other than enabling and disabling contenteditable, use the execCommand API. I don't see why we should switch to attributes for new editing options. To make editing options per editing host, I prefer this proposal: [[ Ojan suggested in the other thread that we instead allow calling execCommand() on Element, and have the result restricted to that Element. That solves the global-flags problem too, and doesn't require new attributes. So you'd do div.execCommand(tabindent, false, true); or whatever. Someone could still call document.execCommand(tabindent, false, false), but that would be overridden if it was called on the editing host. I filed a bug on it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522 Does that sound good too? ]] And should it imply contenteditable=true, or should the author have to specify that separately? The latter IMHO. Also: are there any good use-cases for br? I still haven't seen any. Allowing div instead of p adds basically no extra complexity, but allowing br would make things significantly more complicated. On Wed, 11 Jan 2012 21:15:18 +0100, Ryosuke Niwa rn...@webkit.org wrote: Should enter behave like shift+enter when br is the default paragraph separator? Default paragraph separators are used in a couple of other places too, so it would be a little more work than that. Indeed, e.g. shift+enter doesn't break out of lists, so it's not equivalent. Making it equivalent would be adding some complexity. But I just looked, and it wouldn't be as bad as I thought. So this is doable if people have any good use-cases. Great. So what's the use case? :-) If none are presented, I object to adding it based on the Avoid Needless Complexity and Solve Real Problems design principles. -- Simon Pieters Opera Software
Re: Selection of a document that doesn't have a window
On Thu, 12 Jan 2012 16:58:58 +0100, Aryeh Gregor a...@aryeh.name wrote: What does document.implementation.createHTMLDocument().getSelection() return? * IE9 returns a Selection object unique to that document. * Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as document.getSelection(). * Chrome 17 dev returns null. I prefer IE's behavior just for the sake of simplicity. If we go with Gecko/WebKit/Opera, we have to decide how to identify which documents get their own selections and which don't. The definition should probably be something like documents that are returned by the .document property of some window, but I have no idea if that's a sane way to phrase it. HTML uses this concept in lots of places, e.g. http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object A Document that has no browsing context. So should the spec follow IE? If not, what definition should we use to determine which documents get selections? -- Simon Pieters Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. This is why we implemented opera-defaultblock. Apps were manually converting our output to use divs because they didn't want margins, which is non-trivial to do and often leaves bugs in edge cases. That alone is enough for us not to adopt p as the default paragraph separator. Also, unfortunately, there are many legacy contents that rely on the fact webkit uses div as the paragraph separator so we need a global or per editing-host switch regardless. Do you suggest that all browsers adopt div as default separator by default? Or that it will be impossible to reach interop? Or something else? :-) I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. That would rather miss the point of having the spec IMHO. If we all implement a global switch to opt in to a different behavior, let's design a new, sane editing API instead. But I think the editing spec should try to reach interop for the legacy feature first. - Ryosuke -- Simon Pieters Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, 11 Jan 2012 10:43:24 +0100, Markus Ernst derer...@gmx.ch wrote:
p has default margins.
This is why we implemented opera-defaultblock. Apps were manually
converting our output to use divs because they didn't want margins,
which is non-trivial to do and often leaves bugs in edge cases.
Actually, applying p {margin:0} looks quite trivial.
Sure, but some apps like to send their stuff in HTML email to clients that
don't support styling, or some such.
That would rather miss the point of having the spec IMHO. If we all
implement a global switch to opt in to a different behavior, let's
design a new, sane editing API instead. But I think the editing spec
should try to reach interop for the legacy feature first.
IMO the ability to create clean, state-of-the-art HTML code should be
one of the main goals of a new spec. That means: Editor implementations
should be able to get p on Enter, and br on Shift-Enter (as people
are used to from commonly used word processors) without additional
scripting.
That's nice but it's not clear how to go from here to there. There is web
content that relies on quirks of each browser and might stop working
completely if we change things. I value interop higher than clean code,
so if, for instance, we can converge on div but not on p, then that's
what we should spec, IMHO. (However I'm not convinced yet that it's easier
to converge on div rather than p, which is why Opera still uses p by
default. We have generally aimed for matching IE for contenteditable.)
I don't know the use cases Ryosuke mentions, where apps rely on
webkit-specific behavior (or other ua-specific behaviors), and I don't
know how harmful a change could be for them (paragraph margins appearing
in a forum I would not consider very harmful).
It's more that a subtle change can break functionality completely in
some apps. Even if it's just margins appearing where they didn't before,
it might still not be accepted by many users and web developers.
On the long term, from a developer's and client supporter's POV I'd
prefer to have a standard behavior that works the same in all UAs, and
all common editor applications, by default.
I agree.
Offering a default paragraph separator setting means, that editor
behaviors will remain different across applications,
It already is different across applications, because they implement the
default paragraph separator setting themselves.
which is confusing for many users.
It might be less a hassle to have maintainers of existing applications
insert a line of code that triggers legacy behavior, if this is crucial
for their application.
--
Simon Pieters
Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote: BCC: whatwg, CC:public-webapps since discussion of the editing spec has moved I'm OK with this conclusion, but I still strongly prefer div to be the default single-line container name. Why? Also, I'd really like the default single-line container name to be configurable in some way. I agree. Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. Something like document.execCommand(DefaultBlock, false, tagName). What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. What is the use case for br that div doesn't cover? As one proof that this is valuable, the Closure editor supports these three with custom code and they are all used in different apps. Which apps use br? Could they switch to div without losing some functionality? I'm tempted to say that any block type should be allowed, I strongly disagree. Supporting any block type opens up for lots of bugs and weird cases. We should only support the types necessary to cover presented use cases. but I'd be OK with starting with the tree above. For example, I could see a use-case for li if you wanted an editable widget that only contained a single list. Just use ul contenteditableli|/li/ul. li as defaultblock would result in invalid markup if there's no list (and when breaking out of a list, etc). Ojan On Mon, May 30, 2011 at 1:16 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Behavior for Enter in contenteditable in current browsers seems to be as follows: * IE9 wraps all lines in p (including if you start typing in an empty text box). If you hit Enter multiple times, it inserts empty ps. Shift-Enter inserts br. * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) * Chrome 12 dev doesn't wrap a line when you start typing, but when you hit Enter it wraps the new line in a div. Hitting Enter multiple times outputs divbr/div, and Shift-Enter always inserts br. * Opera 11.10 wraps in p like IE, but for blank lines it uses pbr/p instead of just p/p (they render the same). What behavior do we want? I ended up going with the general approach of IE/Opera: http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements It turns out WebKit and Opera make the insertParagraph command behave essentially like hitting Enter, so I actually wrote all the requirements there (IE's and Firefox's behavior for insertParagraph was very different and didn't seem useful): http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command The basic idea is that if the cursor isn't wrapped in a single-line container (address, dd, div, dt, h*, li, p, pre) then the current line gets wrapped in a p. Then the current single-line container is split in two, mostly. Exceptions are roughly: * For pre and address, insert a br instead of splitting the element. (This matches Firefox for pre and address, and Opera for pre but not address. IE/Chrome make multiple pres/addresses.) * For an empty li/dt/dd, destroy it and break out of its container, so hitting Enter twice in a list breaks out of the list. (Everyone does this for li, only Firefox does for dt/dd.) * If the cursor is at the end of an h* element, make the new element a p instead of a header. (Everyone does this.) * If the cursor is at the end of a dd/dt element, it switches to dt/dd respectively. (Only Firefox does this, but it makes sense.) Like the rest of the spec, this is still a rough draft and I haven't tried to pin corner cases down yet, so it's probably not advisable to try implementing it yet as written. As always, you can see how the spec implementation behaves for various input by looking at autoimplementation.html: http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph -- Simon Pieters Opera Software
Re: Barewords in on* attributes, redux (also, find() and company)
On Wed, 14 Dec 2011 08:36:44 +0100, Boris Zbarsky bzbar...@mit.edu wrote: John Jensen here at Mozilla has been doing some web crawling trying to find what barewords are used in on* attributes. Awesome! What I have so far as a result is a list of about 1.7 million barewords used across several tens of thousands of pages. Do you have a more accurate figure for the number of pages? If people are interested in the exact methodology, I can probably get a description. I'm interested. It's hard to make conclusions from data without knowing what the data is, how it is biased, what false positives it might have, etc. I'm working on making sure that it's ok for me to post the data in its entirety so you can all look as well. Assuming it is (very likely), where's a good place to stick a 7MB compressed file? In any case, for this particular data set there are no hits on findAll or matches (good!), but there are two hits on find as a bareword in an on* attribute. Specifically: 1) http://otc-pif.rbc.ru/pif_calculator/calculator.jsp has onclick=find(document.getElementById(current + 'List').children, searchString.value) 2) http://bookmark.people.com.cn/index.html has onclick=find() These would both obviously get broken by the proposed find() API, unless we actually do some sort of workaround for this problem... -Boris -- Simon Pieters Opera Software
Re: Barewords in on* attributes, redux (also, find() and company)
On Wed, 14 Dec 2011 09:15:12 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/11 3:01 AM, Simon Pieters wrote: What I have so far as a result is a list of about 1.7 million barewords used across several tens of thousands of pages. Do you have a more accurate figure for the number of pages? 57,444 unique urls, all taken from the top 21,000 domains is all the information I have there so far. Thanks! If people are interested in the exact methodology, I can probably get a description. I'm interested. It's hard to make conclusions from data without knowing what the data is, how it is biased, what false positives it might have, etc. Yeah, understood. Working on getting that description. -Boris cheers -- Simon Pieters Opera Software
Re: [FileAPI] createObjectURL isReusable proposal
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then the first dereference of the URL revokes it. Could the argument have inverted semantics? Optional arguments that default to true are a bit confusing. Usually omitted boolean arguments default to false. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf -- Simon Pieters Opera Software
Re: XPath and find/findAll methods
On Mon, 21 Nov 2011 20:34:14 +0100, Martin Kadlec bs-ha...@myopera.com wrote: Hello everyone, I've noticed that the find/findAll methods are currently being discussed and there is one thing that might be a good idea to consider. Currently, it's quite uncomfortable to use XPath in javascript. The document.evalute method has lots of arguments and we have to remember plenty of constants to make it work. IE and Opera support selectNodes method on NodePrototype, which is really useful, but what's the point in using it when it doesn't work in FF/Chrome/Safari. Maybe FF/Chrome/Safari should add support for selectNodes? -- Simon Pieters Opera Software
window.find already exists
There's discussion about introducing find and findAll as an alternative to querySelector[All]. However, window.find exists already in Firefox and WebKit, and is for in-page text search. There's a placeholder for it in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-find Are Firefox and WebKit going to drop the old find()? Is there legacy content that feature detects for find() and would break if it changed semantics? -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 12:52:36 +0100, Julian Reschke julian.resc...@gmx.de wrote: If Gecko does that for Workers, that would be a bug. Workers are UTF-8 only. If you are saying that Content-Type: application/javascript;charset=iso-8859-1 ... 0xC3 0xB6 ... should have U+00C3 U+00B6 when used viascript and an U+00F6 when used via `new Worker` then I will stand ready to roll over the floor laughing when Firefox and Chrome are changed so they conform to this bizarre idea instead of doing the right thing and treating the two cases the same. +1 The only alternative would be to *reject* the script. ... But it seems that this is what http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says. Please consider this a bug report. UTF-8-only for workers is deliberate. I don't see any reason to reject scripts that have other charset. Rejecting the script would mean that some authors can't use workers at all because their server uses charset and they can't change it. -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 13:03:03 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/19/11 12:52 AM, Julian Reschke wrote: http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says. For what it's worth, Gecko's worker loading code runs the same algorithm to determine the charset as the algorithm used for script src (except of course it does not have access to any charset attributes on an element). And by same algorithm I mean they call the same function in our code which takes the HTTP headers, document object, value of @charset, and bytes and returns a Unicode string. If we have UA compat on that behavior, it makes more sense to standardize it than to standardize the UTF-8-only thing, perhaps Opera conforms to the spec and always decodes worker scripts as UTF-8. -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-18 13:03, Simon Pieters wrote: UTF-8-only for workers is deliberate. I don't see any reason to reject scripts that have other charset. Rejecting the script would mean that some authors can't use workers at all because their server uses charset and they can't change it. What kind of server sets a charset on JS *and* cannot be configured not to? I don't know. I know we changed appcache to not do MIME type checking of the cache manifest because authors had trouble changing it. I know we sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and text/plain; charset=UTF-8 because it's the default in some servers. And, if this is the case, isn't this a good reason to actually require that the charset is handled correctly? For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT, workers). I really believe that piling up workarounds and inconsistencies like these makes the whole platform much harder to use than necessary. Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and character escapes. AFAIK there's have been no requests to support legacy encodings in workers in Opera. -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 13:46:16 +0100, Julian Reschke julian.resc...@gmx.de wrote: That's fine if you use a new type, or profile an existing one. But claiming that charset=... means something else before depending on the context it's used in is asking for trouble. What kind of trouble? Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and character escapes. AFAIK there's have been no requests to support legacy encodings in workers in Opera. I'm ok with that. I'm not ok with treating something that has a charset of ISO-8859-1 silently as UTF-8, in particular when other parts of the platform disagree. Why not? We have context-dependent treatment of MIME types already (e.g. a text/html resource can be treated as a script). -- Simon Pieters Opera Software
Re: Firefox bug: Worker load ignores Content-Type version parameter
On Fri, 18 Nov 2011 14:10:36 +0100, Julian Reschke julian.resc...@gmx.de wrote: Why not? We have context-dependent treatment of MIME types already (e.g. a text/html resource can be treated as a script). These are workarounds because of legacy, I assume. Workers are a new feature. Workers ignore the MIME type. -- Simon Pieters Opera Software
Re: innerHTML in DocumentFragment
On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking jo...@sicking.cc wrote: And yes, this does create a lot of edge cases which needs to be defined. But the goal should be to make sane calls sane, that seems imminently possible. So frag.innerHTML = g/g; someSVGElement.appendChild(frag); seems very possible to make work. How? -- Simon Pieters Opera Software
Re: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein tobias.oberst...@tavendo.de wrote: Is executing step 2 above (fire error) meant to cancel execution of step 3 (fire close)? No, it would say ...and abort these steps if it did. Just to be sure I get that right: If step 2 is executed, that is error is fired, then abort and do not continue with step 3, that is do not fire close If step 2 is not executed, continue and execute step 3, that is fire close ? No. Specifically, which events should be fired when WS(S) connection establishment fails due to: a) host unreachable (TCP could not even be established) b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also) c) TLS handshake failed due to invalid server certificate d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..) All of these should be handled identically (for security reasons -- if we treat them differently you could use it to probe non-WebSocket servers on an intranet, for instance). Ok, I see. Thats a good reason. Practically, I am mostly interested in: How can I detect TLS failed due to invalid server cert from JavaScript in the context of WSS. You cannot, by design. If we allowed JS to detect this it would enable attackers to do network topology scans of restricted networks. Ok. Would the following then be appropriate behavior for browsers? User loads https://somehost.com:9000/index.html UA presents cert for somehost:9000 not trusted .. accept .. continue? dialog. = That dialog is builtin, no JS involved. As today. If user continues, then index.html loads, contains JS. The JS then opens wss://somehost.com:9090 UA present cert for somehost:9090 not trusted .. accept .. continue? [*] = Builtin dialog, no JS involved. Not available in browsers today. I believe Opera does this (if you enable websockets). We might change this to reject untrusted certs for websocket, though. If user continues, then the WSS connection succeeds. WS onopen() handler fires. If user does not continue, then WSS connection fails. WS onerror() handler fires - the latter does not give reason for failure. The JS will get onerror() fired for all reasons a) - d) above. Thus, there would be not only needed new dialog [*] for invalid server cert, but also for the other reasons a) - d). In no case JS involved .. dialogs are browser builtin. Does above make sense? No, both error and close fire. -- Simon Pieters Opera Software
Re: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 15:54:17 +0200, Tobias Oberstein tobias.oberst...@tavendo.de wrote: Would the following then be appropriate behavior for browsers? User loads https://somehost.com:9000/index.html UA presents cert for somehost:9000 not trusted .. accept .. continue? dialog. = That dialog is builtin, no JS involved. As today. If user continues, then index.html loads, contains JS. The JS then opens wss://somehost.com:9090 UA present cert for somehost:9090 not trusted .. accept .. continue? [*] = Builtin dialog, no JS involved. Not available in browsers today. I believe Opera does this (if you enable websockets). We might change this to reject untrusted certs for websocket, though. Does that mean Opera might just _silently_ reject untrusted certs without giving the user a dialog to accept the cert? Right. That would be unfortunate IMHO. Since then there is no way to get an acceptable user experience any longer. I can't present a JS created notification and act accordingly, since JS won't be allowed to detect invalid cert. I can't rely on the browser rendering a builtin dialog for the user to accept the cert. WSS just fails silently. How is a JS app using WSS supposed to create an acceptable user experience? By using a cert that isn't rejected. btw: does Opera support =Hybi-10, No. -00. and if so, how do I activate it? Enable WebSockets in opera:config. If user continues, then the WSS connection succeeds. WS onopen() handler fires. If user does not continue, then WSS connection fails. WS onerror() handler fires - the latter does not give reason for failure. The JS will get onerror() fired for all reasons a) - d) above. Thus, there would be not only needed new dialog [*] for invalid server cert, but also for the other reasons a) - d). In no case JS involved .. dialogs are browser builtin. Does above make sense? No, both error and close fire. Ok. There are different views on that I guess http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html Seems Richard is misreading the spec. but I - given the comment by Ian, that JS should in no case get detailed error feedback on invalid cert, whether onclose fires or not - honestly do not care any longer .. it won't solve my problem anyway. OK. On the other hand, I think it should be decided which is the desired behavior: fire onerror only, or fire both. The spec clearly requires both. -- Simon Pieters Opera Software
Re: [DOM3 Events] Some comments on Basic Event Interfaces
On Thu, 13 Oct 2011 03:19:26 +0200, Jacob Rossi jacob.ro...@microsoft.com wrote: Note: For programming languages which do not allow optional method parameters, such as Java, the implementation may provide two EventTarget.addEventListener methods, one with 2 parameters, and one with 3 parameters. Is this a note or is it normative? You can't have both. This is a note that suggests a workaround for implementations in languages that don't support optional arguments. It's not normative. An implementation may do this, or it may not-up to the implementer (since optional useCapture isn't required). 'may' is an RFC2119 term. Don't use it in notes. If a listener was registered twice, once for the capture and target phases and once for the target and bubbling phases, each must be removed separately. It's not clear if this is a UA requirement. This is intended for authors: target.addEventListener(foo,bar,false); target.addEventListener(foo,bar,true); target.removeEventListener(foo,bar,false); This only removes the first of the two listeners. It doesn't look like a note to me. It looks like a conformance requirement (since it contains the word 'must'). If it's targeting authors, it means they're being non-conforming if they don't remove their event listeners any time they register a listener twice (one capture and one bubbling). If you intend it to be a note, clearly mark it as a note and don't use RFC2119 terms. The content authors should also remove their EventListener from its EventTarget after they have completed using the listener. I wonder why this is a should. It's a coding best practices suggestion towards authors. 'should' is not a suggestion, it's a conformance requirement. ... It seems to me you need to be more careful in your usage of RFC2119 keywords. Also see http://ln.hixie.ch/?start=1140242962count=1 -- Simon Pieters Opera Software
