Re: Normative references to Workers.
On Tue, 15 Sep 2015, Mike West wrote: > > It seems appropriate, then, to bring the question to this group: does > WebApps intend to update the Workers draft in TR? FWIW, I think the W3C should get out of the business of republishing WHATWG specifications. It's just adding confusion, especially since the W3C drafts are invariably out of date. IMHO the "Upgrade Insecure Requests" specification should just reference the WHATWG spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Clarification of CSP sandbox and workers
On Wed, 12 Nov 2014, Mike West wrote: The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. I'd agree, for example, that it does appear that sandboxing a worker into a unique origin could be interesting. It's not clear to me whether any of the other flags would be useful, though. Ian, WDYT? Happy to add features if browsers are going to implement them. Just file a bug describing what the feature is. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: innerText spec
On Tue, 16 Sep 2014, Ryosuke Niwa wrote: Is either one of you working on innerText specification? (http://lists.w3.org/Archives/Public/www-archive/2014Mar/0008.html) I think we need it for the selection API specification because the concept of being “visually equivalent” and selection.toString need to be defined in terms of it. Last I checked, none of the browser vendors were interested in converging on a single definition, so I haven't look at it in a while. It appears that it depends on the current style sheets, at a minimum. Seems we've filed at least two bugs on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25159 As you say, Selection.toString() depends on this; the relevant bug is in a similar state: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10583 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: {Spam?} Re: [xhr]
On Tue, 2 Sep 2014, Brendan Eich wrote: Also (I am a WHATWG cofounder) it is overreach to promise obsolescence on any timeline on the Web. Robert should not worry about real browser implementors breaking content by removing sync XHR -- to do so would be to lose market share. In this light, WHATWG should avoid making indefinite-timescale, over-ambitious assertions. Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: {Spam?} Re: [xhr]
On Wed, 3 Sep 2014, Anne van Kesteren wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. See http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 for why we added a warning to the specification. It was thought that if we made a collective effort we can steer people away from depending on this. The text of the warning seems fine to me. It doesn't make any assertions about the future as far as I can tell; it just discourages use of a feature and says that we hope to remove it. If we are ever to remove something as widely used as sync XHR, this kind of advocacy seems like a prerequisite. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Blocking message passing for Workers
On Sat, 9 Aug 2014, Alan deLespinasse wrote: Thanks. Apparently I did a lousy job of searching for previous discussions. I just found this later, longer thread: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html (same thread, different year, so they're not linked) Has anything changed since that thread? It seems like the discussion stalled in early 2012. But I'm glad to find that other people want the same thing. I just noticed this thread. For what it's worth, I don't follow this list very closely. If you would like to request a new API for Workers, the best place to do it is the WHATWG mailing list or in the W3C Bug database: https://www.w3.org/Bugs/Public/enter_bug.cgi?assigned_to=ian%40hixie.chblocked=bug_file_loc=bug_severity=normalbug_status=NEWcomment=component=HTMLcontenttypeentry=contenttypemethod=autodetectcontenttypeselection=text%2Fplaindata=dependson=description=form_name=enter_bugkeywords=maketemplate=Remember%20values%20as%20bookmarkable%20templateop_sys=otherpriority=P3product=WHATWGqa_contact=contributor%40whatwg.orgrep_platform=Othershort_desc=target_milestone=---version=unspecified HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: First Draft of W3C version of URL Spec
On Wed, 27 Aug 2014, Daniel Appelquist wrote: As you might know, the new charter for webapps includes a new version of the URL spec. I am acting as editor of this spec. What's the purpose of the W3C republishing this spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: First Draft of W3C version of URL Spec
On Thu, 28 Aug 2014, Glenn Adams wrote: On Thu, Aug 28, 2014 at 10:04 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 27 Aug 2014, Daniel Appelquist wrote: As you might know, the new charter for webapps includes a new version of the URL spec. I am acting as editor of this spec. What's the purpose of the W3C republishing this spec? quite obviously, to have a reference to a stable document that follows the W3C REC process, while WhatWG documents satisfy neither condition Actually, the WHATWG URL standard does have a stable snapshot: http://www.whatwg.org/specs/url/2014-07-30/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Wed, 2 Jul 2014, Ryosuke Niwa wrote: On Jul 2, 2014, at 9:26 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ryosuke Niwa rn...@apple.com Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person committed a given code change was following. Yeah, it can be useful to look at old revisions for historical reasons. That's nothing like the W3C REC process (or even WD process) though. It applies just as much to individual revisions between WDs (let alone RECs). Off the top of my head, a good solution would be to produce URLs for every changeset, so that you can reference how the spec looked at a point in time. For the WHATWG HTML spec (and maybe other WHATWG specs, I'm not sure), there is a copy of the generated spec in source control, which we could expose. I've been reluctant to do so to avoid people ending up on obsolete versions (e.g. by following links from old source code) and not realising what's going on. Just as an example, a hyperlink I got in Feb 2013 [1] to the WHATWG HTML spec no longer works today. [1] http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality That specific one worked fine for me just now, FWIW. To me, Feb 2013 is not a long time ago and the fact I don't have an easy way of figuring out what the specification looked like at the time, or how it has changed since then is a serious problem since I don't have the luxury of following every spec. change due to the time restraints. If you need anything like this don't hesitate to reach out to me. I'm happy to provide old revisions, diffs, or whatever. If you're looking for when something changed in HTML, this can be useful; it's a cached set of blame files for some interesting revisions: http://www.whatwg.org/specs/web-apps/current-work/blames-list.cgi You can also use anonymous SVN at svn.whatwg.org if you want to grab specific things directly yourself. There are other ways to mitigate these issues in addition to publishing every revision of a given specification. For example, spec authors could list support every historical terminology and fragmentation ever introduced. We could even create some service/database to map such historical names to the new ones, explaining the difference. That's a lot of work, and we already have more work than people. But as Tab said, we can probably do a better job of keeping old IDs around. I've definitely tried to do that more in recent years (though not perfectly), but there's a lot more that we could do. If you have any specific ideas, don't hesitate to let me know. (In particular, right now I'm working on a new publication pipeline for HTML and so I'm in a good position to add new features for this kind of thing.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: WebIDL Spec Status
On Wed, 2 Jul 2014, Domenic Denicola wrote: From: Ian Hickson i...@hixie.ch I've been reluctant to do so to avoid people ending up on obsolete versions (e.g. by following links from old source code) and not realising what's going on. This is the danger, but I think an appropriately-annoying danger sign mitigates it significantly. I was going to link to the picture spec as my favorite example, but they seem to have made it less annoying (by moving it to the bottom instead of the middle), which is sad. So I made this example instead: http://jsbin.com/mutefami/1/ Yeah, that's an interesting idea. I've filed a bug to track this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Fri, 27 Jun 2014, Glenn Adams wrote: For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Whatever you ship should be regularly kept up to date with changes to the spec as they occur. (It's not an option to not be able to ship fixes, since otherwise you'd be unable to fix security vulnerabilities either, which is obviously a non-starter.) What you ship, and subsequent revisions thereto, is what you should be spending any serious amount of time testing. And for that, you shouldn't use a snapshot, you should use the latest revision of the spec. For the pointless certification, just as for the patent coverage, we should publish whatever revision we have and just stamp it as a REC. It doesn't matter what bugs it has. We know it'll have bugs -- the day after it's published, maybe even earlier, we'll find new bugs that will need fixing. It doesn't really matter, since it's not for use by implementors, just by lawyers and pointless certification teams. I would respond, but it would be ... pointless. I'm guessing you misinterpreted what I said, specifically, that you interpreted the pointless in pointless certification as an insult of some sort. To clarify, I did not mean it that way; I meant it literally, as in, specifically the kinds of certifications that you may be required to pursue for political or bureaucratic reasons but which have no practical purpose, as opposed to the kind of certification that serves an important purpose, like certifying that some software that's going to run a rocket passes all its tests. Certifying that software passes tests for an obsolete version of a standard, when the standard's purpose is interoperability and achieving that interoperability requires converging on a target that we're only slowly reaching over many years, is at best pointless, and at worst harmful, which is why I stand by the advice above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Fri, 27 Jun 2014, Glenn Adams wrote: Clearly we operate in different business regimes. If we both operate on the same Web content, then I don't think that matters, the interoperability issue is the same either way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Wed, 25 Jun 2014, Glenn Adams wrote: On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson i...@hixie.ch wrote: Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. That sounds reasonable, but its not always true (an exception to every rule, eh). For example, in order to ship a device that must satisfy compliance testing to be certified, e.g., to be granted a branding label, to satisfy a government mandate, etc., it may be necessary to implement and ship support for an earlier version. For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Whatever you ship should be regularly kept up to date with changes to the spec as they occur. (It's not an option to not be able to ship fixes, since otherwise you'd be unable to fix security vulnerabilities either, which is obviously a non-starter.) What you ship, and subsequent revisions thereto, is what you should be spending any serious amount of time testing. And for that, you shouldn't use a snapshot, you should use the latest revision of the spec. For the pointless certification, just as for the patent coverage, we should publish whatever revision we have and just stamp it as a REC. It doesn't matter what bugs it has. We know it'll have bugs -- the day after it's published, maybe even earlier, we'll find new bugs that will need fixing. It doesn't really matter, since it's not for use by implementors, just by lawyers and pointless certification teams. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Tue, 24 Jun 2014, Boris Zbarsky wrote: On 6/24/14, 1:05 PM, Glenn Adams wrote: Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. I see. So this is not about actual spec implementations or spec authors but effectively about a QA cycle that compares the implementations to the specs, and which needs to know which spec to compare the implementations to. Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Indexed DB Transactions vs. Microtasks
On Thu, 5 Jun 2014, Joshua Bell wrote:
For case 2, it looks like implementations differ on whether microtasks
are run as part of the event dispatch. This seems to be outside the
domain of the IDB spec itself, somewhere between DOM and ES. Anyone want
to offer an interpretation?
Event dispatch (specifically, the handling of onsuccess, as opposed to
addEventListener('success') which is similar but defined in other specs)
is something that HTML tries to define. Assuming IndexDB defers to HTML's
definition of event handler IDL attribute, then you go through the
event handler processing algorithm, which calls jump to a code
entry-point which calls clean up after running a callback which calls
perform a microtask checkpoint which, once ES and HTML have been made to
play nice, invokes the promise callbacks, all before the task that fired
the event handler has returned to the event loop. And once it does return
to the event loop, the next major thing _it_ does is perform a microtask
checkpoint anyway.
HTH.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
On Thu, 8 May 2014, Bruce Lawson wrote: On 7 May 2014 20:03, Ian Hickson i...@hixie.ch wrote: Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I think the ship HMS Ugly has already sailed, given a dash is compulsory for the names of custom elements. Also, requiring a dash in the names of custom attributes would establish an easily-memorable convention for authors, and safeguard new global attributes. I disagree. With element names, you really should be putting a uniquish prefix on your element names to avoid clashes with other custom vocabs. So the dash is just the way we encourage that. google-button yahoo-button ...etc. But the attributes are _already_ scoped, since they're on the element. android-patterngrid width=3 height=3 ...vs android-patterngrid data-width=3 data-height=3 The data- bits don't add anything useful. Anne's point about the DOM interface also being an issue is very important also. Unless we're also going to be forcing everyone to prefix their APIs, which would also be really ugly, the namespace wouldn't be protected anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
On Wed, 7 May 2014, Anne van Kesteren wrote: On Tue, May 6, 2014 at 7:19 PM, Wilson Page wilsonp...@me.com wrote: I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes? Yeah, we should figure something out here. From one perspective you've already namespaced your element by using a dash. However, given the existence of an ever growing set of global attributes you probably do not want to clash with those. Maybe we should allow any attribute as long as it contains a dash (and does not match a set of existing names)? Still seems somewhat suboptimal. Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. We only introduce them at the rate of ~one per year if you treat namespaced groups of attributes like event handlers, microdata, or ARIA as single units (which they more or less are, for this problem, I think). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom Elements: 'data-' attributes
On Wed, 7 May 2014, Ryosuke Niwa wrote: How are you going to quantify the risk of adding a new global attribute in the future? Same we we do today. Look to see how many pages use the attribute, find a name that's not used much, and then try to deploy it and see what breaks. I don't want us to depend on some random search engines to make a guess as to which names are safe to use. That's basically how we've been doing it so far. I mean, it's not like disallowing people from making up attributes has stopped everyone from making up attributes. This is already a problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Should events be preferably sent to the Window or the nearest object?
On Mon, 7 Apr 2014, Marcos Caceres wrote: On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote: Agreed. The exact target isn't very important here, and so being consistent with legacy event firing for the same system is probably a good idea. Agree. Let's go with consistency, even though it feels a bit weird. Ian, would it be possible to have some kind of hook in HTML to give us this behaviour for free? That is, given an event handler IDL attribute on some interface, we get the HTML attribute equivalent on body element (all wired up and ready to be used). That would be useful in that we wouldn't need to define the HTML onorientationchange attribute in the Orientation Lock spec (and all future specs). This could really help with consistency. I'm very happy to add any such attributes to the HTML spec, just file a bug once you're confident that it won't change. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest Level 1- specification history
On Sun, 30 Mar 2014, Jungkee Song wrote: I presume the author originally put the part rather informatively. I made it a single sentence as clarified here: https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html#specification-history Oh, man, please don't fork this further! The canonical spec for XHR is Anne's, at http://xhr.spec.whatwg.org/. I really would rather the W3C stopped causing all this confusion with all these forks of WHATWG specs. It's harming the Web. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest Level 1- specification history
On Mon, 31 Mar 2014, Jungkee Song wrote: I really would rather the W3C stopped causing all this confusion with all these forks of WHATWG specs. It's harming the Web. This snapshot is not to develop the features in its own way but to provide the work for the implementors to test and achieve the compatibility with. That's the goal of the WHATWG version. The W3C process actually makes it harder to achieve this, since it involves multiple copies of the specification (e.g. editor's drafts, outdated copies on the TR/ page, etc). Either way, though, the change you said you would make here is to non-normative content, so it is a fork that in no way impacts the purpose for which you say you are editing the spec. I think the related testing efforts [1] (the current status [2]) from many industry players (of course Anne contributed enormous part of the test too) are improving the Web in a way. [1] http://w3c-test.org/XMLHttpRequest/ [2] http://jungkees.github.io/XMLHttpRequest-test/ Those tests, if they are going to be useful, will track the WHATWG version. That is, if the WHATWG version changes to fix a bug and the W3C version doesn't (because it's a REC, say, and thus can't change), then the WHATWG one is the one that the tests will match. And thus, the W3C one is not going to do anything to provide the work for the implementors to test and achieve the compatibility with. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest Level 1- specification history
On Sat, 29 Mar 2014, David Dailey wrote: The XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest object was initially defined as part of the WHATWG's HTML effort. (Long after Microsoft shipped an implementation.) To me this is ambiguous: It could either mean 1. Long after Microsoft had shipped a related implementation, the XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest object was defined as part of the WHATWG's HTML effort This is correct. 2.The XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest object was initially defined as part of the WHATWG's HTML effort. (Much later, Microsoft shipped an implementation.) If this was the meaning, you would need a comma after Long after. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Should events be preferably sent to the Window or the nearest object?
On Fri, 21 Mar 2014, Mounir Lamouri wrote: I would love to gather the opinion of public-webapps on a discussion Hixie and I had for two different APIs recently: if an array |foo| can change, should the change event be fired on its parent or the window (its grandparent)? The two cases we discussed with Hixie were navigator.languages and screen.orientation for which Hixie thinks the change events should be fired on the window so developers can do body onlanguagechange=... onorientationchange=... but I feel that having the change event sent on the parent would make things more self-contained. I would love to hear people's opinion on this. (Note: sending an orientationchange event to the window object would have other implications because there is a proprietary API that does that but this is entirely orthogonal.) To be clear, my opinion is just that we should be consistent. If the event is related to the Document, then we should fire it at the Document. If it's related to the html, we should fire on the html. Some objects are already EventTargets, including many new objects. I'm just saying that for existing objects that aren't EventTargets, and for which events have historically been sent to the Window, we should continue to send events to the Window, so that we don't end up sending some events to the object and some to the Window. In the case of Navigation, online and offline events go to the Window. In the case of Screen, resize and scroll events go to the Window. So it makes sense to put new events there too. IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: On starting WebWorkers with blob: URLs...
On Fri, 14 Mar 2014, Arun Ranganathan wrote: On Mar 12, 2014, at 6:54 PM, Ian Hickson wrote: For blob: URLs we agreed to make this pretty explicit: http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL Unfortunately, scripts don't have origins these days, so this definition doesn't really work. It didn't work since it wasn't formally specific about effective script origin according to the script setting object, but I've fixed that so hopefully this definition should work: http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL LGTM. Assuming that UAs implement this, that makes Workers automatically support blob: URLs, too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: On starting WebWorkers with blob: URLs...
On Wed, 12 Mar 2014, Arun Ranganathan wrote: On Feb 19, 2014, at 7:09 PM, Jonas Sicking wrote: On Wed, Feb 19, 2014 at 3:51 PM, Travis Leithead wrote: Agreed! It's a bit tricky since the concept of origins and thus same origin for data: and blob: is a bit unclear still. I.e. browsers don't behave consistently. Definitely not between each other, and sometimes not internally within a browser IIRC. Well, for data: URLs what's normative might be: http://tools.ietf.org/html/rfc6454#section-4 but sadly that's not really clear (what's host here?). data: does not use a hierarchical element as a naming authority and thus its origin is a fresh globally unique identifier. For blob: URLs we agreed to make this pretty explicit: http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL Unfortunately, scripts don't have origins these days, so this definition doesn't really work. However, something along these lines would be fine by me, and would mean that blob:s work fine in Workers without any changes to the Workers spec. 2. In the W3C where would we spec this? (Workers V2?) I care less strongly about this. There's also the synchronous message passing API which I'd still like to see added to the workers spec. IMHO it makes sense in Workers V2. Workers are currently at v8541, for the record. :-) The canonical spec for workers is not a W3C spec, it's the WHATWG one: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Assuming things are still working, this should be the same prose but with the W3C letterhead (and some subtly broken cross-references since it doesn't include the rest of the spec): http://dev.w3.org/html5/workers/ As is normal, the TR/ spec for workers is woefully out of date at this point. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Thu, 20 Feb 2014, Jonas Sicking wrote:
On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor eocon...@apple.com wrote:
Yeah, I think we just say that [form.elements] is the legacy feature
that only exposes built-in controls. form.getParticipants() works for
me.
Agreed. [form.elements] is pretty crappy anyway in that it's live and
that it doesn't include input type=image elements for webcompat
reasons (stemming from an old Netscape bug :))
I actually think form.elements is more important than form submission, as
far as custom form controls go.
Pages with custom form controls are highly likely, I would guess, to be
interactive apps that don't have any unscripted form submission. I would
expect lots of XHR, WebSockets, and the like. However, scripts are hugely
simplified by form.elements. Instead of having to grab things by ID, you
can just name them, for example. This is even more true for event handlers
on form controls, which have the form in the scope chain. For example, one
of the big reasons for adding output was that it makes it easier to
update text -- instead of:
oninput=document.getElementById('a').textContent = process(value)
...you can write:
oninput=a.value = process(value)
More concretely:
poutput name=o100:00/output – output name=o224:00/output/p
input type=range min=0 max=24 value=0,24 step=1.0
oninput=o1.value = valueLow + ':00'; o2.value = valueHigh + ':00'
...or:
form onsubmit=return false oninput=o.value = a.valueAsNumber +
b.valueAsNumber
input name=a type=number step=any +
input name=b type=number step=any =
output name=o for=a b/output
/form
Similarly, in a script block you can get form controls by name from forms
gotten by name:
document.forms.main.elements.result.value = 'Hello World';
document.forms.npc.elements.char.value = getRandomName();
This gives you a much more intuitive way of figuring out what's going on.
You can tell what form the controls are from, and the name just fits into
the code without appearing to involve string manipulation, the way that
getElementById() or querySelector() would.
(The last four examples above are all from the HTML spec.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Fri, 21 Feb 2014, Maciej Stachowiak wrote: I'd guess most sophisticated webapps do not use attribute-based event handlers (as opposed to addEventListener), so they would not get this convenient scoping benefit. That's not clear to me. I mean, certainly today, with div soup, they don't. But that's at least partly because there's no sane way to do it when your markup isn't really declarative in any useful sense. When you have Web components that let you get the effect you want while sticking to a terse markup language, it becomes much more feasible to return to using inline event handlers. If you're looking at an out-of-line function, then your comparison is: this.a.value = process(value) this.querySelector(#a).value = process(value) which is a less dramatic difference. It's a pretty compelling difference, IMHO. Also, the short version gives you the risk of namespace conflicts with the built-in methods and properties of form. You can do this instead if that feels like a real risk: this.elements.a.value = process(value) ...but in practice I think it's a pretty minimal risk. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Passsword managers and autocomplete='off'
On Tue, 17 Dec 2013, Joel Weinberger wrote: Thanks for the feedback, everyone. A few people at this point have suggested emailing the wha...@whatwg.org list since this is really an HTML feature; I'll do that in a few. In response to Ian's question, I'm referring to the W3 WebForms standard: http://www.w3.org/Submission/web-forms2/#the-autocomplete That is actually the WHATWG spec from 2005. It's absurdly out of date. :-) This evolved into what is now this: http://whatwg.org/html#attr-fe-autocomplete Please, as an implementor, never look at a document that is more than a week or so old. If the date isn't really recent, then you're almost certainly looking at something obsolete, and implementing it will just mean you're implementing known-buggy text. (Or, you're looking at something that's fallen into decay with no active maintenance, which is almost as bad.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Passsword managers and autocomplete='off'
On Thu, 12 Dec 2013, Joel Weinberger wrote: This is a feature (or anti-feature, depending on your perspective :-) that has been touted as good security for quite some time (in fact, the W3C spec specifically calls it out in that regard). Which spec are we talking about here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Workers v2 (Was: Refactoring SharedWorkers out of Web Workers W3C spec)
On Tue, 10 Dec 2013, Jonas Sicking wrote: 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. There's seven features I'm aware of that people have asked for that aren't in Workers currently, or are specced in a way people don't want: - Synchronous message channels This has been proposed several times on this list, but so far I've only seen interest from Mozilla. This is currently not on my radar, since there's no outstanding e-mail on this topic that was sent to the WHATWG list, and no bug is assigned to me on this topic as far as I can tell. The last proposal that I am aware of is: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0686.html http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0142.html - Inline workers (inline as in specified by script in HTML) Waiting for implementation interest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22700 - Canvas in Workers There's been various proposals, including one in the spec that hasn't met with implementor approval; I'm waiting for something to get traction amongst the competing proposals. - Being clearer about what features are visible in workers Blocked on: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22646 - Cross-origin workers Waiting for implementations to implement the other features first: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0617.html - Real-time support Waiting for implementation interest: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0272.html - A worker to intercept the fetch logic Alex is working on this; I haven't been following it: https://github.com/slightlyoff/ServiceWorker/blob/master/README.md If any of them have multiple vendors on board, let me know, and I'll spec them. I try to keep the spec not too far ahead of the browsers. Incidentally, I found this interesting: https://gist.github.com/tobeytailor/2693804 ...especially in the context of: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0695.html If this kind of thing is indeed feasible (I haven't studied it closely), it might make the need for sync APIs more moot. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Workers v2
On Wed, 11 Dec 2013, pira...@gmail.com wrote: - Canvas in Workers There's been various proposals, including one in the spec that hasn't met with implementor approval; I'm waiting for something to get traction amongst the competing proposals. - Being clearer about what features are visible in workers Blocked on: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22646 I have proposed several times about allowing to create PeerConnection and DataChannel objects from inside a Worker, don't know if that request falls into the what features are visible topic or if it's a special case like the canvas... https://groups.google.com/forum/m/#!topic/discuss-webrtc/-bOW_hhs28E It's in the what features are visible topic, unless there's anything specific about the API that needs changing in workers. As far as the WebRTC stuff goes, though, I'll let the WebRTC group decide what should happen. The issue of being clearer about what features are visible in workers is mostly about getting some IDL-level keyword that we can use to make it easier to specify (right now it can be done but has to be done in prose, and I haven't been consistent about it in my specs). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Styling form control elements
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
Let me understand the problem of styling/replacing builtin form controls.
As I understand it, people want to do:
select name=cities is=map
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
or
input is=switch type=checkbox ...
to have a nice fallback when is / shadow DOM is not supported.
Why can't we just do:
map
select name=cities
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
/map
and
switchinput type=checkbox .../switch
instead?
I suppose you _could_ do that, but it would mean that author-defined
widgets would be second class citizens.
Personally what I'd like is:
select name=cities
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
...with:
select[name=cities] { binding: url(map); }
...in the CSS, since this is just presentation.
What is so special about form controls or custom elements that warrant a
completely different mechanism?
Different than what? I'd love the markup to not be different whether or
not we're using custom widget presentations.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Styling form control elements
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
Let me understand the problem of styling/replacing builtin form
controls.
As I understand it, people want to do:
select name=cities is=map
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
or
input is=switch type=checkbox ...
to have a nice fallback when is / shadow DOM is not supported.
Why can't we just do:
map
select name=cities
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
/map
and
switchinput type=checkbox .../switch
instead?
I suppose you _could_ do that, but it would mean that author-defined
widgets would be second class citizens.
Could you elaborate on what you mean by this?
Well for example they wouldn't participate in form.elements, the
submission model would presumably defer to the select, etc. That is to
say, the map in the example above is just for style, whereas the
select in the example above is where all the logic lies.
Personally what I'd like is:
select name=cities
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
...with:
select[name=cities] { binding: url(map); }
...in the CSS, since this is just presentation.
This approach is better than using custom element in that author can't
expose a new JS API or override existing ones so that UA can safely NOT
apply the binding if wanted.
Right.
On the other hand, this still doesn't tell UA whether it should be
ignoring the binding on a given platform or not (i.e. it doesn't address
the device-specific UI control use case).
Yeah. I don't know of a way to fix that.
The problem you're worried about is one that we _do_ have today on mobile
devices with sites that aren't designed with mobile devices in mind, just
not particularly for form control styling. For example, page widths, input
events, all kinds of things like that, make Web pages break on mobile, or
look bad on mobile.
Any solution we come up with for the general problem should, in theory, be
able to solve the problem for this specific subcase too.
On the other hand, using CSS for binding shadow DOM has a culprit that
instantiation life-cycle of such shadow DOM becomes a tricky issue.
i.e. spec'ing exactly when those shadow DOM bind unbind would be
tricky.
Yes. But we shouldn't shy away from hard problems. ;-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Styling form control elements
On Thu, 5 Dec 2013, Jonas Sicking wrote: I think both are issues. I.e. I think we have two separate use cases: 1. Enable using the built-in rendering of form controls, but style them using author-supplied CSS. 2. Enable completely replacing the rendering of form controls I think 1 is *really* hard. Maybe hard enough that we can't do it. But I think it would help the web a lot if we could pull it off, so I think we should try. And I think is=... is the wrong solution for 2. As is wrapping the control with custom elements. You should be able to attach a replacement style using CSS. This is what decorators is, which so far no one is working on afaict. Agreed. I think #1 is easier than it looks, though. My vision for doing this would be to define some pseudo-elements we say a browser can provide, explained as the browser using some default binding that declares those pseudo- elements (thought obviously behind the hood it doesn't need to be done that way). Obviously there's a limit to how much you can do with just this, but I think if we provide sufficient hooks, there needn't be that much of a limit. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: LINK only in HEAD?
On Wed, 27 Nov 2013, Dimitri Glazkov wrote: On Wed, Nov 27, 2013 at 12:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: http://www.whatwg.org/specs/web-apps/current-work/ multipage/sections.html#the-body-element says its content model (this part is normative!) is http://www.whatwg.org/specs/web-apps/current-work/ multipage/elements.html#flow-content which is a whitelist of things that are allowed in body and contains: link (if the itemprop attribute is present) So link without @itemprop is not allowed as flow content. I see. Do you know why? It seems that all browsers support it anywhere, and this looks like just validator hoop-jumping. The spec has a detailed section that talks about why we have authoring conformance criteria like this: http://whatwg.org/html#conformance-requirements-for-authors The basic idea is to try to help authors by catching things that they probably didn't intend. In the case of link in body, the main problem is late loading of style sheets leading to poor performance and flicker. If there are use cases where best practice would involve a link rel in the body, we can always change the rules here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Allow javascript: URIs for registerProtocolHandler
to be used inside img tags, but also I don't think too much people will be creating their own file formats that would require registerContentHandler() in the same way they would create their own custom protocols, so maybe loose the symmetry here makes sense... [...] By cool feature I means that it wide open the usage posibilities, for example someone would create a 'wiki:' protocol to add links to Wikipedia and when when used on a img tag like 'wiki:images/dog.png' 'would insert images directly, or a 'youtube:' protocol to insert videos on a video tag. This would require to have registered the protocol, obviously, but the same happens if they are set on a link that people can click and surf... This is primarily useful for site-agnostic solutions, e.g. dictionary:depreciate for embedding a dictionary definition of depreciate from whatever the user's preferred dictionary is, rather than oxford:depreciate which might as well be written as a URL to the Oxford Dictionary site directly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebSocket API - server initiated close
On Thu, 14 Mar 2013, Zhong Yu wrote: If a client app connects to a server through WebSocket API, and server sends a close frame, how is the client app notified? You get a 'close' event on the WebSocket object. Does the client stack automatically respond with a close frame, then raise a close event? Whether a close frame is sent or not depends on various things, e.g. whether one was received from the server. Meanwhile, if the client app is invoking send() while the server close frame arrives, what happens? The paragraph about bufferedAmount implies that send() won't fail, is that correct? Since the processing of an incoming close frame is handled in a task, it cannot be synchronous with a send() call. For specific details, see the exact algorithm described here: http://www.whatwg.org/html/#dom-websocket-send HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Bringing other Web Components specs into HTML
On Sun, 16 Jun 2013, Dimitri Glazkov wrote: On Fri, Jun 14, 2013 at 10:26 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Jun 2013, Dirk Schulze wrote: On Jun 14, 2013, at 6:41 AM, Robin Berjon ro...@w3.org wrote: now that template is in HTML, I was wondering if some of the other specs needed the same treatment. Some of the specs can be relevant for other specifications as well. Unless you don't want to integrate the whole web stack (SVG, MathML, ...) into the HTML spec, some things should be separated from HTML. I think the main deciding factor should be who is going to maintain the text once in the future. With template, presumably that's now us (HTML spec editors). For most Web component stuff, I assume it's still Dimitri and company. Thus they should probably stay in separate specs. I think this is a nice rule of thumb. We could then refactor respective specs to better integrate with each other by adding extension points and removing monkeypatches. Absolutely. There's a rich history of us adding hooks for each other in specs in this exact manner (e.g. see how the URL and DOM specs interact with the HTML spec, and vice versa). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Bringing other Web Components specs into HTML
On Fri, 14 Jun 2013, Dirk Schulze wrote: On Jun 14, 2013, at 6:41 AM, Robin Berjon ro...@w3.org wrote: now that template is in HTML, I was wondering if some of the other specs needed the same treatment. Some of the specs can be relevant for other specifications as well. Unless you don't want to integrate the whole web stack (SVG, MathML, ...) into the HTML spec, some things should be separated from HTML. I think the main deciding factor should be who is going to maintain the text once in the future. With template, presumably that's now us (HTML spec editors). For most Web component stuff, I assume it's still Dimitri and company. Thus they should probably stay in separate specs. If it wasn't for that, I would indeed be arguing for merging the entire Web stack into a single document (called The Web). That's certainly how it's implemented, and it would fix a lot of problems with have with things falling between the cracks. (See, e.g., how much of an improvement we made to that kind of thing when we merged DOM HTML and HTML.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web Storage's Normative References and PR / REC
On Thu, 7 Mar 2013, Philippe Le Hegaret wrote: The goal is to demonstrate that the materials referenced are stable and any change to those references won't have an impact on the recommendations. What do you mean by stable? If we find something wrong with a REC, we still need to change it, since otherwise browsers are going to implement things that are wrong... (e.g. anyone implementing HTML4 now is going to be in a world of trouble because HTML4 has all kinds of mistakes in it, despite being a REC -- HTML4 is not stable at all.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Allow ... centralized dialog up front
On Thu, 31 Jan 2013, Florian B�sch wrote: There is a problem confronting applications desiring to use a variety of APIs such as pointerlock, fullscreen, WebRTC, local storage and so on. The problem is that each instance of attempting to use such an API leads to a new Allow ... popup the user has to click away. Yes, that is a problem. The solution isn't another dialog, though, the solution is to design the APIs such that they don't need to prompt, or that their prompt doesn't look like a security prompt. For example, this has a security prompt, but you don't see it: input type=file So does drag-and-drop, so did my design for WebRTC, so does the feature that allows the author to start a print job. In all these cases, the user is asked for information that looks like a request for data but is really a request for permission. What file should the page have access to? What printer should we print to, with what settings? What camera and microphone should we use? Etc. Fullscreen doesn't need a security dialog -- just have an animation zoom the element up to full screen, and the option to force the page back to just being zoomed in the tab rather than in the whole screen. Notifications don't need a permission UI, just pop the permision up within the tab the first time and offer a UI to move the notification to the whole screen if the user wants it. localStorage and other storage mechanisms can all be handled with one asynchronous popup which just says: ++ | example.org is using 4.5/5.0MB. Increase quota? |--+| 5GB X| ++ Geolocation can use a similar asynchronous UI: ++ | (+) example.org wants to know your location. [ San Jose (IP) |V] X| +---| Mountain View |---+ | 1600 Plymouth | | Use GPS| ++ And so on. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [fullscreen-api] Allowing AJAX requests when in fullscreen mode
On Thu, 24 Jan 2013, Anne van Kesteren wrote: On Wed, Jan 23, 2013 at 2:50 PM, Adam Sobaniec sobani...@gmail.com wrote: I have made a more detailed test. It's not AJAX itself that breaks the fullscreen mode, but it's History API that is the main cause of problem. In my case, I have a web app that goes fullscreen and when I click on a link there is being pushed new state to history and an url is being modified. When it happens, Chrome is exiting fullscreen mode, while FF behaves as I'm expecting it to behave. I will try to file a ticket for Chrome. Ah, there is a requirement to the effect that when navigating, you exit fullscreen. Maybe we should restrict that to cross-origin navigation. Ian, other Adam, thoughts? The history API doesn't involve navigation, unless I misunderstood the question. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: exposing CANVAS or something like it to Web Workers
On Wed, 2 Jan 2013, Gregg Tavares (社�~T�) wrote: Another issue as come up and that is one of being able to synchronize updates of a canvas in worker with changes in the main page. For 2D, the intended solution is to just ship the ImageBitamp from the worker canvas to the main thread via a MessagePort and then render it on the canvas at the appropriate time. I don't know how you would do it for WebGL. Similarly, let's say you have 2 canvases and are rendering to both in a worker. Does context1.commit(); context2.commit(); guarantee you'll see both commits together? No, unfortunately not. There's no synchronisation between workers and the main thread (by design, to prevent any possibility of deadlocks), and there's not currently a batching API. However, if this becomes a common problem (which we can determine by seeing if we get bugs complaining about different parts of apps/games seeming to slide around or generally be slightly out of sync, or if we see a lot of authors shunting multiple ImageBitmap objects across MessagePort channels) we can always add an explicit batching API to make this kind of thing easy. Note that in theory, for 2D at least, shunting ImageBitmaps across threads can be as efficient as commit(). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Server-Sent Events contradiction
On Sun, 30 Dec 2012, Bill Thiede wrote: The Server-Sent Events at http://www.w3.org/TR/2012/CR-eventsource-20121211/ states under the IANA considerations / Security considerations section: Servers can be overwhelmed if a situation develops in which the server is causing clients to reconnect rapidly. Servers should use a 5xx status code to indicate capacity problems, as this will prevent conforming clients from reconnecting automatically. However, under section 5 Processing model it is stated: HTTP 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout responses, and any network error that prevents the connection from being established in the first place (e.g. DNS errors), must cause the user agent to asynchronously reestablish the connection. My guess is section 5 was updated more recently and the IANA section was overlooked. I know there are 5xx errors not listed explicitly, which would then trigger the Any other HTTP response code not listed here must cause the user agent to fail the connection, but I doubt that a 501 or 505 are the suggested solution here. Good catch. Since none of the browsers I could test reconnect for 500s currently as far as I can tell, I've changed the spec to not make 5xxs reconnect. The server load issue seems like a pretty big deal. It still says to reconnect in the case of an interrupted connection though, or if the connection couldn't be established in the first place, so going through a tunnel should still work fine. Updated text is at: http://whatwg.org/html#event-source-network-errors-reconnect PS I'm emailing, because the 'Feedback Comments' form on the web page returned 'ERROR' on my attempt to submit. Not sure who to notify of that problem. The error reporting widget on the WHATWG spec above should work, FWIW. E-mail is fine too though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Server-Sent Events contradiction
On Wed, 2 Jan 2013, Glenn Maynard wrote: On Wed, Jan 2, 2013 at 4:23 PM, Ian Hickson i...@hixie.ch wrote: Since none of the browsers I could test reconnect for 500s currently as far as I can tell, I've changed the spec to not make 5xxs reconnect. The server load issue seems like a pretty big deal. Ordinary exponential backoff deals with the server load issue. Exponential backoff is a pretty horrible user experience. It basically doesn't work in UI, especially for transient problems. It doesn't make sense for a transient error to cause the connection to permanently fail. We're not really talking about a transient error, though. We're talking about a situation where you connect and immediately have a problem, or the connection drops, you try to reconnect, and _then_ you immediately have a problem. All this does is make web developers do it themselves, which we shouldn't need to deal with. I would rather make Web devs who want this to reconnect have their error case for the EventSource URL a 200 OK with the right type that then drops the connection right away, than hammer the server so hard that the Web dev can't log in to fix the problem in the first place. (Or, even better, they can simply not open the incoming connection until the problem is resolved -- that will also cause attempts to reconnect.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Tue, 4 Dec 2012, Charles McCathie Nevile wrote: This is a formal warning. I do not support the chairs in this. I stand by Ms2ger. He has not acted inappropriately and his complaints are valid. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Sat, 1 Dec 2012, Ms2ger wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 I agree. That change is offensive. It gives credit to dozens of people who have done basically nothing productive at all, for work that a few of us have spent years doing. I find the W3C's behaviour here to be increasingly out of control, as someone I spoke to recently put it. It's discourteous and uncivil. If the W3C wants to write their own specs then that's fine, but stop forking work done by other people who have no interest in working with the W3C at this time. This is just plagiarism. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [admin] XHR ED Boilerplate
On Mon, 26 Nov 2012, Anne van Kesteren wrote: I agree with Ian's other observations/comments. On Fri, Nov 23, 2012 at 10:22 PM, Ian Hickson i...@hixie.ch wrote: What I don't really understand, though, is why any of this is needed at all. What value is the W3C adding by creating these forks? In the end (dunno when that will be), patent commitments from the Members of the WebApps WG. That seems worthwhile to me. It is unfortunate I could not reach an agreement with the W3C where I could publish my work under CC0 and still achieve that. I'm all in favour of that, but if that's the goal, there's no point the WG doing anything until there's something that could actually go to REC, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Sun, 25 Nov 2012, David Bruant wrote: The intent is clear: the WHATWG publishes documents in the public domain for very good reason. Anyone (W3C included!) can reuse them under close to no condition, not even credit. I can speak pretty authoritatively to the intent, if that's what you are interested in. The relevant philosophy in the WHATWG context is multi-pronged: 1: Specs should be reusable in software, documentation, tutorials, and the like, without any barrier, whether free software or proprietary software, whether in books printed for money or FAQs that are themselves free to copy, whether in online courses with $10,000 entry fees or demos on street corners that are organised by marketing departments. 2: A spec author can go bad without realising it, so it should be possible to fork a specification if that happens, without the author having any control over this. 3: Forking specifications, publishing multiple copies of specifications, and publishing easy-to-find-with-a-search-engine snapshots of specifications, are all things that hurt interoperability by making implementors reference different requirements. The only time that forking a specification is justified is #2 above. We use open licenses on our specifications because of #1 and #2. We can't legally prevent #3 while allowing #1 and #2, so we rely on common sense and good faith to achieve #3. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Sun, 25 Nov 2012, Jonas Sicking wrote: On Sun, Nov 25, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 25 Nov 2012, David Bruant wrote: The intent is clear: the WHATWG publishes documents in the public domain for very good reason. Anyone (W3C included!) can reuse them under close to no condition, not even credit. I can speak pretty authoritatively to the intent, if that's what you are interested in. The relevant philosophy in the WHATWG context is multi-pronged: 1: Specs should be reusable in software, documentation, tutorials, and the like, without any barrier, whether free software or proprietary software, whether in books printed for money or FAQs that are themselves free to copy, whether in online courses with $10,000 entry fees or demos on street corners that are organised by marketing departments. 2: A spec author can go bad without realising it, so it should be possible to fork a specification if that happens, without the author having any control over this. 3: Forking specifications, publishing multiple copies of specifications, and publishing easy-to-find-with-a-search-engine snapshots of specifications, are all things that hurt interoperability by making implementors reference different requirements. The only time that forking a specification is justified is #2 above. We use open licenses on our specifications because of #1 and #2. We can't legally prevent #3 while allowing #1 and #2, so we rely on common sense and good faith to achieve #3. I'm not sure in what capacity you are writing this. [...] I forget exactly what policies govern WHATWG, but I don't know if the above can be considered an official WHATWG policy. I don't know what official would mean here. I just meant the intent that is behind my (and Anne's, I believe) advocacy of open licensing for specifications. However I'll note that not everyone at least at Mozilla agree with #3. #3 is actually the most empirically testable one, at least the first sentence of it. Given the number of e-mails I get from implementors asking me questions with links to outdated snapshots of specs they found via search engines, where their question was already answered by the editor's draft of that spec, I don't really see how it can be controversial. :-) What do you think justifies having multiple copies of a spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [admin] XHR ED Boilerplate
On Fri, 23 Nov 2012, Arthur Barstow wrote: Here's what I did for the URL spec re the boilerplate to help address the attribution issue re Anne and WHATWG: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html [...] That's pretty good, though the Status of this Document boilerplate other than the green note seems kinda contradictory. For example: This is the 8 November 2012 draft of the URL standard. ...should probably say something more like: This is a copy of the WHATWG URL standard as of 8 November 2012. Similarly, it says: This document is maintained by the Web Applications (WebApps) Working Group. ...which should probably say something more like: This document is maintained by the WHATWG and copied by the Web Applications (WebApps) Working Group. ...or some such. The next paragraph starts in a similarly misleading way: This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. A more accurate statement would be: This document was produced by the WHATWG and then republished by a group operating under the 5 February 2004 W3C Patent Policy. Also, the document asks for feedback on the public-webapps list, but that fragments feedback on the spec; the WHATWG copy instead suggests feedback go to the WHATWG list. The change to the heading, moving Anne from Author to Editor, makes some of the text in the spec, e.g. the note saying As the editor learns more about the subject matter the goals might increase in scope somewhat, somewhat confusing. What I don't really understand, though, is why any of this is needed at all. What value is the W3C adding by creating these forks? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [admin] XHR ED Boilerplate
On Fri, 23 Nov 2012, Glenn Adams wrote: On Fri, Nov 23, 2012 at 2:22 PM, Ian Hickson i...@hixie.ch wrote: What I don't really understand, though, is why any of this is needed at all. What value is the W3C adding by creating these forks? The problem as I see it is that the WHATWG documents are living documents and never final per se. A WD isn't final either. If the WHATWG documents were published (by WHATWG) as fixed snapshots during their lifecycle, then perhaps it wouldn't be necessary for the W3C to create snapshots. For business and legal purposes, it is often a requirement to have such snapshots that are known to never change. Every time a change is made, there is a snapshot made as well. For example, here's the XHR snapshot from October 11th: https://raw.github.com/whatwg/xhr/f4652f2a07b5614236b5be53f9769082bfb86070/Overview.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: exposing CANVAS or something like it to Web Workers
On Mon, 14 May 2012, Gregg Tavares (�~K�) wrote: I'd like to work on exposing something like CANVAS to web workers. Ideally how over it works I'd like to be able to *) get a 2d context in a web worker *) get a WebGL context in a web worker *) download images in a web worker and the images with both 2d contexts and WebGL contexts I've now specced something like this; for details, see: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: exposing CANVAS or something like it to Web Workers
On Fri, 16 Nov 2012, Charles Pritchard wrote: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html Seems like we might use requestAnimationFrame in the main thread to postMessage to the worker as an alternative to using setInterval in workers for repaints. The idea in due course is to just expose rAF in workers. Please do read the e-mail above, which actually mentions that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Making offline apps easier?
On Mon, 12 Nov 2012, Charles McCathie Nevile wrote: 1. Appcache. Yeah, we know. But if nobody makes a proposal, nothing will get better. (There is also a fixing-appcache community group taht might come here with proposals). There are already several proposals, and they are already making their way through to the spec. If anyone has any use cases that they haven't filed as bugs on the WHATWG spec or e-mailed the WHATWG list, please don't hesitate to do so, so that they can be considered. It's use cases that are needed, not proposals, to make additional progress here beyond what will happen already given the currently-filed bugs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Call for Editor: URL spec
On Tue, 6 Nov 2012, Paul Libbrecht wrote: Could be slightly more formal? You are speaking of hypocrisy but this seems like a matter of politeness, right? I am just saying that the W3C claims to have certain values, but only applies those values to other people, not to itself. Specifically, the W3C says forking specifications is bad (and even goes out of its way to disallow it for its own), but then turns around and does it to other people's specifications. hypocrysy (noun): The practice of claiming to have moral standards or beliefs to which one's own behavior does not conform; pretense. I'm also claiming that when doing so, the W3C does not generally give credit where credit is due. For example, this document is basically written by Ms2ger: http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html Here's the version maintained by Ms2ger, for comparison (the only differences I could find were editorial style issues, not even text -- basically just that the doc has been converted from the anolis style to the respec style): http://domparsing.spec.whatwg.org/ The most Ms2ger gets is a brief mention in the acknowledgements almost at the very end of the document. The WebApps working group gets a whole sentence above the fold: This document was published by the Web Applications Working Group. The W3C has their logo right at the top and calls the draft a W3C Editor's Draft. plagiarism (noun): The practice of taking someone else's work or ideas and passing them off as one's own. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Call for Editor: URL spec
On Mon, 5 Nov 2012, Arthur Barstow wrote: On 11/5/12 5:47 PM, ext Tab Atkins Jr. wrote: In the meantime, W3C is copying Anne's work in several specs, to It seems like W3C groups copying WHATWG's work has been ongoing for several years (so I think this is old news, especially since, AFAIU, it is permissiable, perhaps even encouraged? via the WHATWG copyright) ;-). In the past (and for some specs still today), it was done by the editor (e.g. me), as dual-publication. What's new news now is that the W3C does this without the editor's participation, and more importantly, while simultaneously decrying the evils of forking specifications, and with virtually no credit to the person doing the actual work. It's this hypocrisy that is new and notable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Thu, 30 Aug 2012, Olli Pettay wrote: The spec used to say DOM mutation events must not fire for changes caused by the UA parsing the document. I've updated this to also mention mutation observers. Why? Getting MutationObserver notifications during parsing is what I'd expect the API to provide (and that is implemented in Gecko). My original change was motivated just by inertia and conservatism, wanting to keep the intent of the spec unchanged. On Thu, 30 Aug 2012, Jonas Sicking wrote: Indeed. I have the same questions. The API doesn't have same performance and re-entrancy problems that caused us to disable mutation events. If we don't fire mutation observers during parsing it means that you basically can't rely on mutation observers at all until after the DOMContentLoaded event has fired. In fact, you can't rely on them even past then since if another page is loaded in an iframe and nodes are moved from that iframe to your document, you won't be notified about changes done by the parser to those nodes. So this change removes the ability to guarantee that you can track mutations done to a document, which was one of the big advantages that MutationObservers had over mutation events. I.e. mutation events only let you track mutations to your document as long as those mutations behaved well, i.e. weren't done from inside mutation observers. With this we add a similar requirement to mutation observers that they are only reliable as long as pages behave well and don't move nodes from a document which is being parsed. Just like mutation events solved the use cases of many authors, mutation observers will solve the use cases of many authors even with this change. However it will miss edge cases which I think is really unfortunate. This seems pretty convincing. I've changed the spec accordingly. On Thu, 6 Sep 2012, Adam Klein wrote: The spec actually does require that the UA provide a stable state before processing scripts, which invokes the relevant part of the event loop. If mutation observers were to fire during parse, it would require those to fire too (it currently does not). In my testing, Gecko doesn't behave this way: MutationRecords are delivered at the end of any encountered script tags (at the end-of-microtask, essentially), rather than before they run. If delivery-during-parse is how we end up going, spec-wise, I think it's important for the use-cases that we deliver before each script runs. Fixed this also. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Server-Sent Events] Infinite reconnection clarification
FYI, I've updated the EventSource spec to do reconnection in the case of certain 5xx errors, DNS errors, and connection failures, as per a thread earlier this year. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Sync API for workers
On Mon, 3 Sep 2012, Glenn Maynard wrote: - Add an internal flag to MessagePort, blocking permitted, which is initially set. - When a MessagePort port is transferred from source to dest, - If source is an ancestor of dest, the blocking permitted flag of port is cleared. (This is a down transfer.) You basically can't do this, because by the time you've received the message saying that the port is in a permitted scope, the other side of the port could have been shunted three times and now be who knows where. Basically as soon as a port leaves the scope in which it was created, you can no longer make any stable statements about where the other side is. This is why the ports used in dedicated Workers are hidden (so you can't send them anywhere). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Sync API for workers
On Sun, 2 Sep 2012, Andrew Wilson wrote: Just wanted to point out that all of the arguments for a wait-for-reply API in workers also apply to SharedWorkers. It's trickier for SharedWorkers since they use MessagePorts Dedicated Workers use MessagePorts too, they're just embedded in the WorkerGlobalScope and the API exposed through that interface, so that you can't send the port's endpoint around. But it's literally defined in terms of a MessagePort. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Editor's draft created of DOM Parsing and Serialization Spec
On Wed, 29 Aug 2012, Travis Leithead wrote: Folks, following up on my action item from TPAC 2011 (yeah, I know...), the DOM Parsing and Serialization Editor's Draft specification has been created! http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html I assume this means Microsoft, or at least you, are now a supporter of making it possible for specs to be forked? Previously you had indicated that you were not: https://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results A list of active bugs against the spec are being maintained against this component in the Bug tracking system: https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=DOM%20Parsing%20and%20Serializationresolution=--- Please do not close bugs unless they are fixed in the canonical version of the spec as well (the one Ms2ger maintains). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Drag Drop Web Apps
On Fri, 10 Aug 2012, Joran Greef wrote: Given the advance of HTML 5, and in the interest of developing web apps with average functionality, would it now be possible to: 1. Drag files and folders into a web app? Files is specced and implemented. Folders is implemented in Chrome experimentally, and there's a ton of feedback about it pending in the WHATWG feedback buckets, but I'm not aware of interest from other browser vendors so I've left it languishing for now. If it's something other vendors want, it could probably be added without too much trouble (especially if we just matched Chrome, so I don't have to come up with anything ;-) ). 2. Drag files and folders out of a web app? Dragging files out is specced. Not sure about implementation status. Dragging folders would be added as soon as we added dragging folders in (the API is ready for for it, I just need an interface to represent folders which I would plug into it). 3. Drag a spreadsheet out of a web app onto the icon of Excel in the dock and have it open in Excel? That's possible today, in theory, assuming you can describe the data in a form Excel supports. 4. Monitor that same spreadsheet's content (originally provided by the web app) for changes when the user edits it and presses CTRL+S? I'm not aware of any work on this front. It's something we could support if there's interest, but I expect most of the interest on this front will be superseded with something like Web Intents. Or is it only possible to drag things into a browser window but not back out and nothing else? The API is entirely symmetric, so both are possible. Can a user drag a piece of data into a browser window… and then drag it back out? Yes. For example, a user may want to use a Contacts web app, and drag a contact out the browser window as a piece of vcard data and land this onto the Contacts app in the dock, which would then import the contact, all in a single mouse gesture? Assuming the Contacts app in the dock is a _Web_ app, I'm not sure we'd support dropping onto the icon itself. But in principle this is possible. Or is it not possible to provide that kind of user experience? It should be possible. For example, a user may want to use a PDF web app, and transfer a piece of PDF data to the Preview app, but be forced to click a link to download the PDF, click the very small Keep button next to the This type of file can harm your computer. Do you want to keep anyway? warning, and then drag the PDF onto the Preview app, and then go to the Downloads folder to delete the download. At least 5 mouse clicks and then a CMD+backspace to accomplish what (from the user's point of view at least) should have only taken one drag and drop? That sounds like an issue with the specific browser. And then this may be vendor specific, but if a user created a piece of PDF data and dragged it into the browser window in the first place, does it still make sense to warn them that this type of file can harm your computer? This is vendor-specific. The browser takes on too much responsibility for things it can't possibly reason about, and seeks not enough advice from the user where it could. It often seems that the browser is built to lecture the user, rather than the other way round. I use the browser everyday at work, and sometimes you have to ask yourself: who's serving who. Does the user serve the browser, or does the browser serve the user? The browser serves the user, but many of the users it serves are not as educated about security risks. (And many of those who incorrectly think they are educated are the most at risk.) HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wed, 8 Aug 2012, Kyle Huey wrote: PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. Not prefixing, and instead having spec authors make sure that what they spec is compatible with what has shipped (at the very least by changing names when they change semantics), is of course the right solution here. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Lazy Blob
On Mon, 6 Aug 2012, Glenn Adams wrote: I did share a couple of use cases in my response to Ian: I will let Robin and Jungkee reply to the more general use case requirements. As far as WS is concerned, I don't see any impact of this thread on the WS API or WSP specs, its really simply an application of WS/WSP to remote/lazy blobs. Clearly, there are many high level use cases that involve a repetitive send/response message paradigm, which can certainly be implemented with XHR, but some application authors would prefer using WS for various efficiency reasons. My suggestion is essentially: if we are going to define a remote blob bound to an XHR source for a one-shot send-response, then perhaps we should define a remote blob bound to a WS source for multiple send-response pairs. For example, a symmetric presence protocol or IM protocol would typically fall into this usage category. Using remote blobs for either the send or response data (or both) would be useful for certain architectures and provide more deployment flexibility and perhaps greater efficiencies. Those are still not use cases, for the record. I tried explaining what a use case was here: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0302.html http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0288.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Lazy Blob
On Thu, 2 Aug 2012, Glenn Adams wrote: I don't really care about the XHR side of this (happy to let Anne figure that out), but since WebSockets was mentioned: what's the use case that involves Web Socket? I don't really understand what problem we're trying to solve here. i would like to support two use cases: (1) simple - single blob send, single blob response (2) multiple - multiple instances of simple, i.e., send/response pairs Sorry, I was vague. What I mean is what user-facing problem is it that we're trying to solve? For example, I have a real-time game that needs to send commands to the server from the client and needs to receive updates from the server to the client, where latency is not a big issue (it's turn-based or tick-based with widely-spaced ticks) but where reliability is paramount (dropping a message would mean the state was inconsistent) would be a use case for Web Sockets. That use case could be more simply described as I want to write a chess game as a Web app. Another use case for Web Sockets could be I want to write an instant messaging application in my Web page, or I want the view of the data that my application shows to update in place when the server notices that it has changed. Notice the lack of any mention of specific solutions in the use case descriptions -- it's just a high-level problem statement, typically one that even an end-user could actually understand (or at least that a programmer could understand, even if they were not familiar with the Web). What's the use case that is driving the ideas discussed in this thread in the context of Web Sockets? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Lazy Blob
On Thu, 2 Aug 2012, Glenn Adams wrote: Sorry, I was vague. What I mean is what user-facing problem is it that we're trying to solve? see DAR's initial message in this thread; bringing WS into scope doesn't change the problem statement, it merely enlarges the solution space, or keeps it from being unnecessarily narrow Do you have a link to a specific message? I went through the archives and couldn't find any e-mails in this thread that came close to describing a use case for anything, let alone anything that would be related to persistent bi-directional full-duplex communication with a remote server. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Lazy Blob
On Thu, 2 Aug 2012, Glenn Adams wrote: I was referring to http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html While that message does not specifically refer to a full-duplex comm path, it states the general problem in terms of It is increasingly common that data may flow from a server to an in-browser page, that may then pass that data on to another in-browser page (typically running at a different origin). In a many cases, such data will be captured as Blobs. Ah, sorry, I probably still haven't explained the term use case properly. :-( The above isn't a use case, it's a description of an architectural design, the first step towards the description of a solution. What I'm trying to understand is the underlying _problem_ that the technology is trying to solve. Something like I want to be able to sell plane tickets for people to go on holiday, say. Or I want to provide a service to users that lets them merge data from a medical drugs database and a patient database, without giving me their credentials to those databases. Or some such. I don't know exactly what the use case here would be, hence my questions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Lazy Blob
On Thu, 2 Aug 2012, Glenn Adams wrote: Are you asking for use cases for a remote/lazy blob in general? i.e., as would apply to the proposed XHR usage and any other underlying supported data source? or are you asking about high level use cases that are particular to a WS binding but not an XHR binding? Both would be useful, but my primary concern is Web Sockets, since I edit that spec. Before I can consider proposals that affect Web Sockets, I need to know what use case it is we're trying to address. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Lazy Blob
On Wed, 1 Aug 2012, Glenn Adams wrote: Of course, implementers are free to ignore whatever they want, but last time I checked, the W3C was a consensus based standards organization which means agreement needs to be reached on what specs go out the door and what are in those specs. Doesn't really matter what's in the specs going out the door if it's not what's implemented... I don't really care about the XHR side of this (happy to let Anne figure that out), but since WebSockets was mentioned: what's the use case that involves Web Socket? I don't really understand what problem we're trying to solve here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web Activities: counter-proposal to Web Intents
On Tue, 12 Jun 2012, Mounir Lamouri wrote: With some people at Mozilla, we've been working on an API similar to Web Intents in some points but distant enough to be a counter-proposal. We believe that the API is now in a good enough shape to be officially sent in those mailing lists and discussed. You can have an overview of the API here: https://wiki.mozilla.org/WebAPI/WebActivities I've taken this proposal and the Web Intents proposal (amongst others) and written up a proposal that attempts to merge them here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036719.html If anyone has any feedback on that, please e-mail the WHATWG list. (For background: The editors of the Web Intents draft suggested a few months back that I spec such a thing in the HTML spec, superceding their work and integrating it with the register*Handler() methods.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Why the restriction on unauthenticated GET in CORS?
On Fri, 20 Jul 2012, Henry Story wrote: How many of those would use ip addresses that are not standard private ip addresses? (Because if they do, then they would not be affected). Of those that do not, would IPV6 offer them a scheme where they could easily use standard private ip addresses? I think you're missing the point, which is that Web browser implementors are not willing to risk breaking any such deployments, however convoluted that makes the resulting technology. If you want a technology to be implemented, you have to consider implementators' constraints as hard constraints on your designs. In this case, the constraint is that they will not implement anything that increases the potential attack surface area, whether or not the potentially vulnerable deployed services are designed sanely or not. Once you realise that this is a hard constraint, questions such as yours above are obviously moot. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Making template play nice with XML and tags-and-text
On Wed, 18 Jul 2012, Adam Barth wrote: Inspired by a conversation with hsivonen in #whatwg, I spend some time thinking about how we would design template for an XML world. One idea I had was to put the elements inside the template into a namespace other than http://www.w3.org/1999/xhtml. Interesting idea. To handle multiple namespaces (specifically SVG and MathML), we could say that inert namespaces are namespaces that start with or end with a particular prefix, e.g. that are in the inert: scheme or that end with #inert. Then to de-inert nodes, you just strip the relevant part of the namespace string when cloning. To make this work in HTML with nested namespaces might be interesting: template div svg foreignObject math mi var I guess what we do in the HTML parser is have it use all the same codepaths as now, except the create an element operations check if there's a template on the stack, and if there is, then they add the inert marker to the namespace, but everything else in the parser acts as if the marker is not there? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On Tue, 6 Dec 2011, Jonas Sicking wrote: On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead travis.leith...@microsoft.com wrote: A new scenario just came to my attention that I thought I might pose to the list. Given the current same-origin restrictions on new Worker(), it is problematic for Worker usage by any JS libraries on a CDN. A site using a CDN simply provides an absolute URL reference to the library, and it is subsequently downloaded and executed in the context of the current page's domain. Relative URLs to a worker script will resolve according to the domain of the hosting page: // http://cdn.net/dowork.js which was included from http://test.com/home.htm var w = new Worker(lib/workers/w1.js); // Tries to open http://test.com/lib/workers/w1.js and absolute URLs will fail due to the cross-origin restrictions on the new Worker constructor: // same setup as before var w = new Worker(http://cdn.net/lib/workers/w1.js;); // Cross-origin failure from http://test.com/home.htm I looked back through the list and at the original worker proposals to try and discover why the same-origin restrictions is in place. The root of the issue seems to be the expectation that WorkerGlobalScope runs and executes everything according to its own location.URL. Thus, allowing http://cdn.net/lib/workers/w1.js to load in the previous example, would allow http://test.com/home.htm to potentially modify any data associated with cdn.net's domain (like through Indexed DB, or XHR, etc). One way to allow the CDN scenario to work would be to provide an explicit way to tell a worker to run in the host context, rather than the context that the Worker is loaded from (which is what script inclusion and importScripts does today). Since Workers _can't_ be loaded cross-origin [currently], the Workers are already running in the host context by virtue of this limitation. Codifying that a WorkerGlobalScope's execution environment is always that of the document that created it, and then allowing workers to be constructed from any URL would effectively solve the CDN problem IMHO. Later, when/if we open up cross-origin workers, we can provide a special way to instruct the workers to set their execution context to that of the URL they are loaded from. Thoughts from the group? It's not an entirely bad idea. We've solve the solution in a somewhat less elegant way. Since firefox generally considers data:-uris to be same-origin with whatever page loaded them, you can create a worker using a data:-uri which then importScripts the cross-origin script. (This is relatively newly implemented so I forget if it's in released versions of firefox). I've specced this. But I can't really come up with any arguments against your proposal... My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On Wed, 18 Jul 2012, Bronislav Klu�~Mka wrote:
Since script is loaded using HTTP, why not use already defined CORS headers on
server side while serving those scripts?
CORS is the wrong semantic. It's not origin A is allowed to read content
from origin B, it's origin A is allowed to cause origin B to run code,
which is a very different threat model. It would be quite bad for us to
say that any file that you can read from another origin, you can cause to
be executed as script in that origin.
And if you want it to be defined in JS file itself, I'll suggest use
strict approach:
file ---
Access-Control-Allow-Origin: *;
(function(){
use strict;
var x = 5;
})();
---file
Whether it's a string or a comment seems like a detail. If we do do this,
I expect we'll find something that's somewhat language-agnostic (e.g.
allowing any leading and trailing punctuation on the first line, or
something to that effect).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Why the restriction on unauthenticated GET in CORS?
On Wed, 18 Jul 2012, Henry Story wrote: So my argument is that this restriction could be lifted since 1. GET is indempotent - and should not affect the resource fetched 2. If there is no authentication, then the JS Agent could make the request via a CORS praxy of its choosing, and so get the content of the resource anyhow. No, such a proxy can't get to intranet pages. Authentication on the Internet can include many things, e.g. IP addresses or mere connectivity, that are not actually included in the body of an HTTP GET request. It's more than just cookies and HTTP auth headers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Thu, 12 Jul 2012, Julian Reschke wrote: It almost seems to me that nobody cares over here what the W3C document actually says, as there is that other more helpful version. In which case I wonder why it's published at all? Patent policy. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Wed, 11 Jul 2012, Julian Reschke wrote: OK; the amount of work is ~45 minutes (and probably can be automated for future publication cycles). See attachments; an edited version of the current editor's draft, and the diffs. ... ..and the diff was reversed; new version attached. Applying that diff to the spec on dev.w3.org is dumb, as it will just get blown away the next time I update the spec. If you actually want to help please e-mail me (as I suggested on the bug) and I can provide you with the relevant files against which to write the diff so that it will be maintained in future versions of the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Server-Sent Events] Network connection clarification
On Sun, 29 Apr 2012, Neil Jenkins wrote: In response to the request for comments on server-sent events, I believe the definition of when to fail a connection needs clarification and/or adjustment. Specifically, in Section 5 Processing Model, the line: Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection. Combined with the definition of fail the connection... When a user agent is to fail the connection, the user agent must queue a task which, if the readyState attribute is set to a value other than CLOSED, sets the readyState attribute to CLOSED and fires a simple event named error at the EventSource object. Once the user agent has failed the connection, it does not attempt to reconnect! this seems to imply that if there is no internet connection currently present, the EventSource connection will fail and not attempt to reconnect. Correct. EventSource is intended to not ever reconnect except in the case of the server being fine. This obviously reduces its usefulness. For example: - A user is connected to the internet via 3G on a train and passes through a tunnel. The connection is lost, so the EventSource object tries to reconnect after x (say 30) seconds. Right, though that's more of a side-effect of the design than intended. The reconnection logic is intended for the case of a server wanting the user agent to reconnect because it's shifting its load (e.g. when you have a cluster of machines behind a load balancer and one of the machines is being taken down so needs to offload its connections to others on the cluster) or because it knows no events will be coming any time soon. That it happens to also mean that a network break will result in a reconnection (once) is an unfortunate side-effect. If, when this first reconnection attempt happens, the user has still not regained a network connection, it will fail permanently and never reconnect again. Right. The script is supposed to be the one doing the reconnecting. - When a computer wakes from sleep, there is often a delay before the network connection is re-established; this creates a race condition - if the EventSource attempts to reconnect before the network is reestablished it again fails permanently. Right. Again, it's only because it's hard to distinguish this case from the server closing the connection that there's any attempt to reconnect at all. In my opinion, the failure due to the absence of an internet connection should be a temporary failure, and should ideally schedule a reconnection attempt when the computer next finds a network. The current spec seems to explicitly disallow this, although some browsers are attempting to reconnect anyway. The idea is to let the script handle network troubles, so that authors are in full control of how much load their servers get when they are having trouble. The alternative is that UAs will DOS networks without the networks having a way to gracefully reduce it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Server-Sent Events] Network connection clarification
On Tue, 10 Jul 2012, Kornel Lesi�~Dski wrote: However, I'm afraid that the most common implementation (aside from complete lack of error recovery) will be a simple as 30-second retry interval and that won't be very DoS-safe. UAs can do better than that. That's not entirely clear. For example the spec could require UAs to have randomized retry interval and exponential backoff on failure. Is there anything more that authors could do client-side to avoid DoSing? Exponential back-off isn't at all necessarily the right solution. In particular, consider mobile devices, where network connectivity goes in and out as the user moves. Most of the time, you want to be trying to connect as soon as you have connectivity. Similarly with laptops on wifi where the connection is only briefly hurt by an obstacle -- you want to keep trying every few seconds until the obstacle is gone. Exponential backoff if a terrible thing in those kinds of situations. You can distinguish local network difficulties from server load difficulties in a variety of ways, e.g. having a dedicated ping server on the same network as the real server, which doesn't suffer from the same load concerns, and which you try to contact and only switch to exponential backoff if it responds but the main server isn't. And so on. UAs can do that kind of thing. SSE is mostly a convenience API (advanced authors can use streaming XHR or WebSockets to achieve the same result the hard way), so lack of convenience in error recovery feels like an omission in this API. If it's something we do want to eventually support, I think it's be something to consider for v2. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
On Mon, 4 Jun 2012, Ian Hickson wrote: On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok [...] Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't have a good handle on how much commitment there is from non-Chrome parties here. I don't want to add this to the spec only to find that people think it's a good idea but only one vendor has plans to implement it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Server-Sent Events] Infinite reconnection clarification
On Tue, 17 Apr 2012, Odin Hørthe Omdal wrote: If I understand correcly, the spec expects the implementation to keep reconnecting indefinitely, when the network cable is yanked. No. The spec says Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection. and Once the user agent has failed the connection, it does not attempt to reconnect. (In particular, note that reestablish the connection only ever occurs if the remote resource is actually obtained with the right MIME type.) I tried yanking the network for 10+ minutes, and when I put the cable in again, both Firefox and Chromium used 25 seconds to reconnect. When only yanking it for one minute, the reconnection was much faster (2-5 seconds). This with *reconnection time* set to 500ms. As far as I can tell, none of that is conforming. If you yank the cable, they should retry once, then give up, per the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Thu, 7 Jun 2012, Henri Sivonen wrote: I believe in this case not changing the way SVG script content tokenizes would be best for authors. For what it's worth, I agree with Henri here. In my experience, spec churn is the number two way of making a spec fail. I think it's better to have something that works consistently everywhere than to have things work different across different browsers and even different versions of the same browser. That's the effect of spec churn. It also has the effect of putting test suites in unclear states, which is especially bad for test suites that have been copied into browser vendors' development environments (especially if they don't realise the spec has changed), and more subtly it has the effect of making developers more reluctant to be first adopters, since they start feeling first adopters have to pay a higher cost, and it makes authors feel like the specs aren't really worth anything because they keep changing. Plus, of course, there's the opportunity cost: making a minor improvement means we're spending lots of resources (speccing, implementating, testing, documenting, advocating) that we could instead be spending on making something else a _lot_ better. (The number one way of making a spec fail is to ignore backwards compatibility, of course. Which in a way is the same thing, just on a larger scale.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal: Document.parse() [AKA: Implied Context Parsing]
On Mon, 4 Jun 2012, Adam Barth wrote: � http://www.hixie.ch/specs/e4h/strawman Who wants to be first to implement it? Doesn't e4h have the same security problems as e4x? As written it did, yes (specifically, if you can inject content into an XML file you can cause it to run JS under your control in your origin with content from the other origin). However, as Anne and you have said, it's easy to fix, either by using an XML-incompatible syntax or using CORS to disable it. Since we have to disable it in Workers anyway, I'd go with disabling it when there's no CORS. Strawman has been updated accordingly. On Tue, 5 Jun 2012, Anne van Kesteren wrote: A (bigger?) problem with E4H/H4E is that TC39 does not like it: http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg33 What matters is what implementors want to do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok, but it has the problem that it doesn't give a way to reset the insertion mode again while inside a template. Consider the difference in how these would parse: template tbody /tbodytr /template template tbody /tbody template /template tr /template We need a way to stay in the 'in table' mode. We could do this by having the parser insert a fake node into the stack of open elements just for this purpose, I think. That is, when switching insertion mode in response to the first start tag inside the template insertion mode, also insert something into the stack so that the next time we reset, we reset correctly. We need to do that in a way that doesn't match end tags, though... Maybe we have to introduce a new kind of thing we push on the stack, which doesn't get matched by anything but the reset algorithm? The proposal here doesn't support SVG (or MathML, but SVG seems more important for template). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on template, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before (in table body, etc). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal: Document.parse() [AKA: Implied Context Parsing]
On Fri, 25 May 2012, Rafael Weinstein wrote:
Now's the time to raise objections to UA's adding support for this
feature.
For the record, I very much object to Document.parse(). I think it's a
terrible API. We should IMHO resolve the use case of generate a DOM tree
from script using a much more robust solution that has compile-time
syntax checking and so forth, rather than relying on the super-hacky
concatenate a bunch of strings and then parse them solution that authors
are forced to use today.
innerHTML and document.write() are abominations unto computer science, and
we are doing nobody any favours by continuing the platform down this road.
They lead to programming styles that are rife with injection bugs (XSS),
they are extremely difficult to debug and maintain, and they are terribly
complicated to implement compared to more structured alternatives. The
core reasons for these problems, IMHO, are two-fold:
1. Lack of compile-time syntax checking, which leads to typos not being
caught and thus programmer intent not being faithfully represented,
and
2. Putting markup syntax and data at the same level, instead of having
separating them as with other features in JS.
For example, this kind of bug is easy to introduce and hard to spot or
debug:
var heading = 'h1Hello/h1';
// ...
div.innerHTML = 'h1' + heading + '/h1';
Even worse are things like typos:
tr.innerHTML = 'td' + c1 + '/tdtd' + c2 + '/tddt' + c3 + '/td;
Compile-time syntax checking makes this a non-issue. Making data variables
be qualitatively different than the syntax also solves problems, e.g.:
var title = I hate /p tags.;
// ...
div.innerHTML = 'pToday's topic is: ' + title + '/p'; // oops, not
escaped
There have been several alternative proposals; my personal favourite is
Anne's E4H solution, basically E4X but simplified just for HTML, which
I've written a strawman spec for here:
http://www.hixie.ch/specs/e4h/strawman
I'm happy to write a more serious spec for this if this is something
anyone is interested in implementing. The above examples become much
easier to debug. The first one results in very ugly markup visible in the
output of the page rather than in the weird spacing:
var heading = 'h1Hello/h1';
// ...
div.appendChild(h1{heading}/h1);
The second results in a compile-time syntax error so would be caught even
before the code is reviewed:
tr.appendChild(td{c1}/tdtd{c2}/tddt{c3}/td/);
The third becomes a non-issue because you don't need to escape text to
avoid it from being mistaken for markup [1]:
var title = I hate /p tags.;
// ...
div.innerHTML = pToday's topic is: {title}/p;
Other proposed solutions include Element.create(), which is less verbose
than the DOM but still more verbose than innerHTML or E4H; and
quasistrings, which still suffer from lack of compile-time checking and
mix markup with data, but at least would be more structured than raw
strings and could offer better injection protection.
[1] (This is not the same as auto-escaping strings in other contexts. For
example, E4H doesn't propose to have CSS literals, so a string embedded in
a style= attribute wouldn't be automagically safe.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
On Mon, 4 Jun 2012, Tab Atkins Jr. wrote: [...] We could do this by having the parser insert a fake node into the stack of open elements just for this purpose, I think. That is, when switching insertion mode in response to the first start tag inside the template insertion mode, also insert something into the stack so that the next time we reset, we reset correctly. We need to do that in a way that doesn't match end tags, though... Maybe we have to introduce a new kind of thing we push on the stack, which doesn't get matched by anything but the reset algorithm? A template context? Sets the context for the rest of parsing, and gets popped by a /template returning to its matching template. Yeah, something like that could work. We'd have to make sure we defined it as happening when /template was popped, but if we force that to only ever happen when we see a literal /template (which the proposal seems to, though I haven't verified that) that might work ok. The proposal here doesn't support SVG (or MathML, but SVG seems more important for template). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on template, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before (in table body, etc). It doesn't require any more hard-coding than HTML needs in order to create proper elements instead of HTMLUnknownElements. You have to know the list of valid HTML elements to produce a proper DOM, and update that as you add more, even if the rest of parser is unchanged. This is the same thing, except it needs the list of valid SVG and MathML elements. I agree that it's the same. I don't think having a hard-coded list of HTML elements is a good thing either, it's got the same forward-compatibility problems. Unfortunately in the case of the existing lists we had no choice because UAs already had them. Here, we have a choice. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal: Document.parse() [AKA: Implied Context Parsing]
On Mon, 4 Jun 2012, Rafael Weinstein wrote: Just to be clear: what you are objecting to is the addition of formal API for this. You're generally supportive of adding a template element whose contents would parse the way we're discussing here -- and given that, a webdev could trivially polyfil Document.parse(). Sure. I.e. you're ok with the approach of the parser picking a context element based on the contents of markup, but against giving webdevs the impression that innerHTML is good practice, by adding more API in that direction? Right. Put another way, though you're not happy with adding the API, you willing to set that aside and help spec the parser changes required for both this and template element (assuming the remaining issues with template can be agreed upon)? I think template is important. If implementing that happens to make it easier for a script to implement a bad practice, so be it. (See my e-mail on the template thread for comments on that subject.) FWIW, I agree with Hixie in principle, but disagree in practice. I think innerHTML is generally to be avoided, but I feel that adding Document.parse() improves the situation by making some current uses (which aren't likely to go away) less hacky. If we want to make things less hacky, let's actually make them less hacky, not introduce more APIs that suck. Also, I'm not as worried with webdevs taking the wrong message from us adding API. My feeling is that they just do what works best for them and don't think much about what we are or are not encouraging. I strongly disagree on that. Whether consciously or not, we set the standard for what is good practice. I've defintely seen authors look at the standards community for leadership. Just look at how authors adopted XHTML's syntax, even in the absence of actually using XHTML. It was such a tidal wave that we ended up actually changing HTML's conformance criteria to ignore the extra characters rather than say they were invalid. Why? Because XHTML was what the W3C was working on, so it must have been good, even though objectively it really added no semantics (literally nothing, the language was defined by deferring to HTML4) and the syntax changes were a net negative. Also, I'm highly supportive of the goal of allowing HTML literals in script. I fully agree that better load (compile) time feedback would be beneficial to authors here. Let's do it! As far as I can tell, the impact on a JS parser would be pretty minimal. http://www.hixie.ch/specs/e4h/strawman Who wants to be first to implement it? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Fri, 1 Jun 2012, Anne van Kesteren wrote: On Wed, May 30, 2012 at 5:59 PM, Øyvind Stenhaug oyvi...@opera.com wrote: 4. layer and layer 10 in section 6.1 are unclear. Layer is used nowhere in CSS references used in this spec. This must be clarified. This section also seems to assume that the list in CSS 2.1's appendix E is for the entire document (e.g. saying Each browsing context has one associated viewport and therefore also one top layer), but it's actually the painting order of a stacking context, of which there can be several. Tab, Ian, Robert, so the problem is that even if we create a new stacking context layer, it will still be relative. R is root. R1 and R2 are its children, both creating their own stacking context. R1 has z-index 0 and R2 has z-index 1. Now R1 has a child F. F gets displayed fullscreen in the new top layer, but will still be behind R2. So we need something else. I'm not entirely sure what would be a good solution though. I assumed we were talking about the stacking context of the root element, not just the one that the dialog's parent is in. Otherwise there wouldn't need to be anything about how the parent's stacking context has no effect, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Shared workers - use .source instead of .ports[0] ?
On Wed, 11 Apr 2012, Ian Hickson wrote: I'm fine with making changes here. The following proposals seem to make the most sense, though I'm sure others could work too: 2. Make the .source attribute be of type (MessagePort or WindowProxy)? and add the port to .source, also leaving it in .ports[0]. I've now done this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: App Manifest API Proposal
On Sat, 12 May 2012, Anant Narayanan wrote: Q. Apps are just web pages, why bother installing them? A. This has been previously discussed on the list [4]. [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html This has already received a reply: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0465.html There are clear differences in perception between an app and a website for most users. Most web content is expected to be free, but the same content wrapped in an app is something people seem to be willing to pay for. Monetization is important to encourage a thriving web developer community. I don't think it makes sense to use a technical solution to a non-technical problem. Additionally, treating certain installed websites as apps gives us a context separate from loading pages in a browser, which allows us to provide privileged APIs to such trusted apps, APIs we would normally not give to untrusted web content. Desktop operating systems have demonstrated over a period of many years that this approach simply doesn't work. Users find it very difficult to understand what it means to trust an app. The Web's security model is IMHO significantly superior than any of the app security models we have seen in native operating systems, as demonstrated by the way that when malware is written to the app model it has to be dealt with by curating the application market space, whereas when malware is written to the Web model it is almost always because of errors in the design or implementation of the Web platform that, once fixed, preclude any similar attack from being performed again. The installation security model of asking the user up-front to grant trust just doesn't work because users don't understand the question, and the installation security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn't scale. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Tab Atkins Jr. wrote: On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? That's pretty much exactly the description of the jQuery $([markup goes here]) functionality, which has been cited multiple times as the justification for this functionality. A previous thread about this functionality was started by Yehuda Katz from jQuery about that exact function, asking for this functionality. Yes, I understand that. But what's the use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Erik Arvidsson wrote:
On Thu, May 10, 2012 at 3:18 PM, Ian Hickson i...@hixie.ch wrote:
Yes, I understand that. But what's the use case?
http://code.google.com/p/dart/source/search?q=new%5CsElement%5C.html%5C%28origq=new%5CsElement%5C.html%5C%28btnG=Search+Trunk
I'm sure you can find a bunch of jQuery usages too.
None of the examples I see there seem to be cases where the parsing code
doesn't know what's going on ahead of time. As far as I can tell, they
could all easily just take an argument saying what parse mode to use, and
avoid all the problems of magically determining the parse mode; e.g. it
would allow the examples inserting style blocks to insert the contents
into existing style blocks instead of creating new ones, and it would
not run the risk of the parse mode changing unexpectedly due to unescaped
content in the various places that seem to be prone to injection attacks
(though maybe the \${} syntax is some sort of magically autoescaping
syntax? Though I don't see how it could be, it doesn't seem to have enough
context either).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Jonas Sicking wrote: Yes, I understand that. But what's the use case? The use-case is to provide a more convenient API for developers. The whole purpose of this thread is to provide a convenience API which provides context-free parsing. If we don't care about providing such convenience for authors we should just tell them to use the already-defined .innerHTML or a custom HTML parser and this whole thread is just moot. My understanding is that the context for this thread is how to support template. Neither innerHTML nor a custom HTML parser will help for that. On Thu, 10 May 2012, Scott Gonz�lez wrote: Why is simplicity not enough of an answer? It's a fine answer. But I don't think magical APIs are simple. Simplicity in this case IMHO argues for explicitly selected context. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Jonas Sicking wrote: The jQuery API shows that at least jQuery developers don't agree with you regarding what is simpler here. That wouldn't be the first time. :-) jQuery doesn't really match the Web platform's design aesthetic, with method names consisting purely of punctuation, methods that can be used both to register a callback and invoke a callback (click(f) vs click()), the style of using return values to enable chained invocations of methods on a specific object, etc. I have great respect for jQuery as a library, but I'm not sure it's necessarily a given that just because jQuery does something one way, it makes sense for the Web platform to do it that way as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
The innerHTML API is convenient. It lets you set the entire descendant
tree of an element, creating elements and giving them attributes, in a
single call, using the same syntax you'd use if you were writing it in
HTML (module some extra quote-escaping maybe).
[...]
I'll go ahead and anticipate your response of they should just use the
Element.create() API
That would indeed be my response.
while Element.create() is great, it solves a different use-case. Being
able to construct DOM from raw HTML is easy to read and write and
understand, particularly when it's a static fragment (or a concatenation
of mostly static fragments), while Element.create() requires a
translation into a JS API with a much different syntax. Element.create()
is much more readable and writable when you're making some DOM out of a
*lot* of dynamic information.
In other words, this:
$(div class=fooimg src=+foosrc+/div)
is a lot easier than:
Element.create(div, {class: foo}, [ Element.create(img, {src: foosrc})
]);
So, that's the use-case for this API.
The idea of building elements using string concatenation is a security
disaster. What if foosrc above contains ' onclick=...' ?
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery, and security by damned.
If we're going to do that, then we don't need any lookahead at all. We
should support literally that: parsing one element and its descendants. We
determine what element is being generatd by looking at the top of the
string (div ... - it's a div, tr ... - it's a tr, etc), and we
parse until that element is popped from the stack or the end of the string
is reached. This avoids all the problems with doing magical lookahead.
But I'm very skeptical about creating new APIs to encourage authors to use
injection-prone, non-type-checked, direct string manipulation in script to
generate DOM trees.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Scott Gonz�lez wrote: On Thu, May 10, 2012 at 7:01 PM, Ian Hickson i...@hixie.ch wrote: But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. Do you realize that a very large percentage of developers are already doing this and will continue to do it regardless of whether UAs provide this functionality? Sure. Lots of sites have XSS vulnerabilities, too. Back in the day, font was used everywhere, as were tables for layout. Over time, Web authors have moved away from such practices. Today, many Web authors use innerHTML. I see no reason to believe that they wouldn't move away from doing so, if we provide them with better tools. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, 11 May 2012, Tab Atkins Jr. wrote: This solves exactly the jQuery use-case of parse a document fragment from a string. Fantastic! Let's use it then. It doesn't solve the *almost* identical case of parse the contents of a template, because there you don't have a root element. That's fine. We don't have to have the same solution for every problem. But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. As others have said, you've lost this race. People said the same about font. I chose to be more optimistic. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
