Re: [whatwg] New tag
On Fri, Apr 1, 2016 at 5:55 PM, Karl Dubost <k...@la-grange.net> wrote: > > Le 2 avr. 2016 à 04:04, Daniel Murphy <dmu...@google.com> a écrit : > > we wouldn't want to waste our expensive > > smell synthesis technology on the likes of webcrawlers and other robots > who > > wouldn't benefit. > > > Yup. User agent sniffing definitely stinks. > > -- > Karl Dubost > http://www.la-grange.net/karl/ > > I get a scents we should be worried about network congestion. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Wed, Apr 1, 2015 at 10:59 PM, Bobby Mozumder mozum...@futureclaw.com wrote: On Mar 31, 2015, at 12:43 PM, Joshua Cranmer pidgeo...@verizon.net wrote: On 3/30/2015 10:02 PM, Bobby Mozumder wrote: One thing I’m interested in is to see more technical discussions around this idea. Like, very specific issues that show a design or concept flaw. It’s only been about 10 days since I proposed this and I haven’t received much in that area. (I did change one thing to split MREF from HREF based on feedback about people wanting backwards compatibility.) Technical discussion is the last step of the process. The reason why people haven't provided technical feedback is because you have failed to motivate your proposal. I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. Most of the unnecessary arguments against it boil down to people just stuck in their comfort-zone, and those people aren’t the target audience for this proposal anyways. Javascript people are going to be happy with their existing selection of MVC frameworks, so why would they want anything new like this? The mistake Javascript developers are making is that they make the assumption that everybody else is a Javascript developer. That is just a fundamentally false portrayal and while I read between the lines and understand your intent, you're misunderstanding the goals and pressures of an explainable platform that gets partially figured out via experimental implementations. Literally all of the major players here are working on how to build increasingly high level abstractions and working to compete or collaborate where appropriate. Many of simple cases that I see that you could potentially do with your approach as described, at least my understanding of what I've seen so far, can in fact be done today with several frameworks declaratively.. There is competition in the space of how to express it and that is fundamentally no different than if we discussed it on a mailing list, there would be different ideas. The difference is that one involves speculation, no testing and is useless to people in the meantime (and the meantime means years) - very frequently only at the end of that do you find out that 'whoops, that isn't actually what developers need for 70% of real cases' and that scenario is a fundamental loss at almost every level. The issue is that that those simple cases are, in fact, not the norm, you exceed them very quickly and the question immediately becomes 'then what?'. There's a lot of competition and collaboration figuring out how you create a well reasoned system that allows users the proper balances of power and simplicity and ability to adapt. To answer the same sorts of questions that they answer every day, your solution will involve JavaScript too - as well as SQL and some server-side specifications which will require their own languages and probably frameworks. I'm honestly not trying to dissuade you here or perpetuate an argument, I'm just saying that your insistence on drawing this line to say 'it's so simple' is, surely you can appreciate, a 'big' statement and it doesn't seem unreasonable for people to ask you to actually show them. Believe it or not, participants in standards bodies have limits to the amount of time and monetary investment they can make into something and there's a lot to do. Getting something started often requires first-movers to show something, even browser makers usually don't just throw an idea out there, they work out a proof of concept with the proposal and show people what they are talking about. It's not unreasonable to think that people ask you to do a little more leg-work before they commit to ...well... even reading more if you see what I mean... we've all got limited time. I'm not trying to discourage you here, not at all. If you have an idea, I encourage you to try to develop it - find some people who are interested, make compromises, flesh it out and come back to the list with yourself in a better position. I mean, it's not my list, so you can do what you want - I just think that that's how you will see the best results. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
forward along the way (I think we are actually in a sense). Again, it's just my 2 cents. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Going to liberally snip the bits I'm responding to... On Fri, Mar 20, 2015 at 5:10 AM, Bobby Mozumder mozum...@futureclaw.com wrote: There’s a standard design pattern emerging via all the front-end javascript frameworks where content is loaded dynamically via JSON APIs. This is the single-page app web design pattern. [snip] Since this is so common now, can we implement this directly in the browsers via HTML so users can dynamically run single-page apps without Javascript? [snip] Anyways, what do you think about this? I think something like this could eliminate a lot of Javascript. These javascript frameworks are all trying to do this, but none of them do it easily and they’re always being redesigned. Something should be done to standardize on it at a higher level. There’s a tremendous speed advantage in this, and we shouldn’t have to program in Javascript for such a common design pattern. Web pages should be loadable with 60fps speeds and should be as responsive as native apps. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/ twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder A few things worth noting: First, we've actually tried a bunch of this before, and you're not using it now so I think we can say that at some level it was unsuccessful. Second, I am going to submit for comment that there are a couple of significant reasons why it failed and why I don't expect we'd have much more success with it if we were to take it up right now and you can kind of sum them up like this: There isn't something close enough to actually emerging that remotely looks ready and standards bodies are historically terrible at that class of problem. It's a really, really, really hard problem to abstract something at such a high level which meets all of the use cases people actually have which plays into why there are so many ever-changing solutions in the ecosystem - they're actually trying to figure it out and that's a good thing. It's rarely as simple as it appears at first blush and good ideas breed new possibilities of even better realizations. As the number of people using these tools increases, we gain additional input and data - Along the way they are helping to identify where there _are_ commonalities and suggest lower level additions that can be standardized as well as providing necessary failed experiments that go into finding a good solution. In general, see http://extensiblewebmanifesto.org or search for articles/posts related for the thoughts of a lot of us in the community on topics like this and, if you have an idea for what would be better - find some people to help you build it, give people an opportunity to try it and see... Where you can't, raise interesting questions about why and lets build up a platform where we can make reasonable explanations to build up higher-level proposals. Anyway, that's my 2 cents, as they say. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] Confusion about node1.replace(node2)
On Mon, Jan 12, 2015 at 7:15 AM, Glen Huang curvedm...@gmail.com wrote: Just realize that reversing the algorithm won’t work for node.replace(nodes), where nodes contains multiple nodes. So yeah, replaceWith looks pretty good. On Jan 12, 2015, at 8:07 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 12, 2015 at 12:03 PM, Glen Huang curvedm...@gmail.com wrote: Or, the current algorithm of replace could be reversed, which should eliminate such confusion. I think as James said that would leave the confusion. And given the precedent in libraries, replaceWith() seems good. -- https://annevankesteren.nl/ Yeah, libraries seem to have proven this out - unless there is a really compelling reason to violate this, replaceWith seems to be what it should be called. +1 to that. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] Notifications: making requestPermission() return a promise
On Oct 5, 2014 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola dome...@domenicdenicola.com wrote: So we should make a choice, as to whether we want developers to assume they will always get permission (in which case it should reject upon permission not being granted), or whether we want developers to ask the API whether they were granted permission (in which case it should give back a boolean fulfillment value or similar). How can they assume permission is always granted? It's up the user. It's a request from the developer and the user can say no. What's unclear about the name? I think Domenic is saying do we want to give the impression that you code the happy path only in the then(), or do we assume you are asking an async question for which an async answer is given with information for you to disambiguate in the then() regardless of whether this is happy or not. I originally expected denial to throw, I admit, but this is mainly because it was guessing on an unestablished pattern. If we establish something which can be applied widely, most of that is mitigated. I think the later (async question that always answers in .then()) makes much more sense especially given that https://notifications.spec.whatwg.org has 3 such values (accepted, denied, default) - if there is algebra to be done we can experiment with some good patterns inside .then() to make that easier. -- https://annevankesteren.nl/
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Aug 23, 2014 2:11 PM, James Graham ja...@hoppipolla.co.uk wrote: On 22/08/14 19:29, Brian Kardell wrote: On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell bkard...@gmail.com wrote: I still think that calling it bodyStream actually helps understanding all you need and it's short/portable... response.bodyStream.asJSON() seems to at least give the hint that it is a stream that is consumed without getting too crazy. Well 1), response.json() is short too, much shorter in fact. It is, but there was concern that is was too short to be clear/might actually be confusing before it was further shortened. Making it shorter doesn't help that objection - it doesn't make it clearer, does it? I'm not saying this is best I'm offering a proposal that tries to strike the balance with this fact - that's all there is to my comment. So my opinion is that there are two possible scenarios: 1) The API is consistent and friendly enough that, after an initial period of learning how it works, developers will internalize the semantics. In this case the short names are sufficient to describe the functionality and should be preferred because they increase the signal / noise ratio when reading and writing the code. 2) The API has semantics that are so liable to trip up developers that, without reminder of the behaviour, they will constantly make mistakes. In this case we should be working out how to design a less unfriendly API, not bikeshedding which function naming scheme will make the problem least bad. I am slightly concerned that the amount of discussion around naming here belies a belief that the underlying model is going to cause frustration for developers. Is that the case? Speculation on this is tough and has IMO really stymied standards efforts. The best way to know is to put something we think is a good effort out there for real use and get feedback. We're much better of when we can base decisions on data rather than guesswork. Ideally we could reasonably prolyfill the API surface, but for low level primitives, this is tricky. Is there any way we can, even if under the covers it didn't have quite the same implications? If so, let's try. If not, it seems next best would be to get in in a browser or two ASAP and leave it behind a flag until we can collect some. In not sure how negatively this would affect other things like service workers in terms of delays and frustrations though.
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 5:26 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald jaffathec...@gmail.com
wrote:
On 22 August 2014 07:20, Anne van Kesteren ann...@annevk.nl wrote:
That works for me too. I agree that developers will likely learn what
is going on here quickly enough. And that if anything should have long
names, it would be some new API that would use more memory. Jake?
Reading a url as some format is really common, so I'm in favour of shorter
method names.
var data = await (await fetch('/whatever')).asJSON();
The consuming behaviour may catch some developers out, once, in their
development environment.
I don't think Alex Domenic were as keen wanted something in the name to
represent consuming/taking.
James pointed out on IRC we could simply have this:
response.json()
response.text()
request.formData()
I did not like this at first. However, if we care about brevity, and
we often said we do and act in that manner (see e.g. querySelector -
query), he is right. as does not really add anything. bodyAsJSON
is a bit more descriptive and takeBodyAsJSON is even more, but in
the end everyone will know very quickly that response/request can only
have their body read once and will dislike us for having to type those
extra characters (and will then type another couple to complain about
it on Twitter).
I checked and none of the existing properties clash with data types we
might want to add in the future. I think those, combined with exposing
state through hasBody should be the way forward.
--
http://annevankesteren.nl/
I still think that calling it bodyStream actually helps understanding
all you need and it's short/portable...
response.bodyStream.asJSON()
seems to at least give the hint that it is a stream that is consumed
without getting too crazy.
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell bkard...@gmail.com wrote: I still think that calling it bodyStream actually helps understanding all you need and it's short/portable... response.bodyStream.asJSON() seems to at least give the hint that it is a stream that is consumed without getting too crazy. Well 1), response.json() is short too, much shorter in fact. It is, but there was concern that is was too short to be clear/might actually be confusing before it was further shortened. Making it shorter doesn't help that objection - it doesn't make it clearer, does it? I'm not saying this is best I'm offering a proposal that tries to strike the balance with this fact - that's all there is to my comment. 2) We have no idea what the design of what bodyStream's getter returns is or should be. There was a body property, I merely proposed renaming it to bodyStream. If you're saying that we've definitely decided to not directly expose the stream, merely means of consuming because of the open question of what streams look like, then yes, that's a good argument against what I'm saying... I might have missed that that decision was made, was it? 3) As already indicated, after you use this once, you realize how it works. Yes and no... It's moderately easier to learn if the API is clearer about what is is, and it's definitely easier to recognize in code without searching for context when 'response' could be several things. It's all a balancing act of cost and benefit (see next comment) 4) I don't see how yours is more portable than James' proposal. I didn't say it was, I just said it -was- portable... You could imagine carrying the lesson that stream based properties identify themselves as such across the platform - it's not overly long and they would be easily recognizable - maybe that's a good balance, maybe it's not You could definitely make the same argument with .json(), though it's different in the sense that there is no hint as to what you can .json() and what you can't. I'm definitely not saying bodyStream or it's wrong, but the API when I suggested it as an option at least was discussing methods like response.body.consumeAsJSON which is longer, less clear to me and offers no kind of hints or portability of the idea that I can really see. -- http://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
[whatwg] [Fetch] ambiguity problem?
Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. I'd like to suggest that this is less a problem with service workers and more with the (current at least) unfamiliarity with the idea that body is a stream, and maybe a lack of recognizable way to tell the difference from native apis. It seems like this is always going to be the case with code using fetch, not unique to ServiceWorkers. I think that commonly as developers we are used to response being a string or an already parsed object or something, and since both will persist in the platform. As such, I'd like to pose the idea of changing the IDL in 5.4 Response Class To add the word stream. I think in this case, the extra characters aren't bad and the clarity outweighs the cost. As in: readonly attribute FetchBodyStream http://fetch.spec.whatwg.org/#fetchbodystream body http://fetch.spec.whatwg.org/#dom-request-bodyStream;
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 9:07 AM, Brian Kardell bkard...@gmail.com wrote: Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. I'd like to suggest that this is less a problem with service workers and more with the (current at least) unfamiliarity with the idea that body is a stream, and maybe a lack of recognizable way to tell the difference from native apis. It seems like this is always going to be the case with code using fetch, not unique to ServiceWorkers. I think that commonly as developers we are used to response being a string or an already parsed object or something, and since both will persist in the platform. As such, I'd like to pose the idea of changing the IDL in 5.4 Response Class To add the word stream. I think in this case, the extra characters aren't bad and the clarity outweighs the cost. As in: readonly attribute FetchBodyStream bodyStream; Whoops, missing link http://jakearchibald.com/2014/reading-responses/
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 9:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 3:07 PM, Brian Kardell bkard...@gmail.com wrote: Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. Why? XMLHttpRequest does the same thing. -- http://annevankesteren.nl/ In what way? . response is a completely read DOMString or Object or whatever, not a Stream?
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 10:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 4:40 PM, Brian Kardell bkard...@gmail.com wrote: In what way? . response is a completely read DOMString or Object or whatever, not a Stream? In that you cannot get back to the original response. You can only get it in one chosen variant. If I do console. log(o.responseText); console. log(o.responseText); The second one will be what? The response text or nada? Isn't the later more analogous to what we're taking about here when it's a stream? It feels like it's reaching for consistency but could explain how it works either way.. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 1:38 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Brian Kardell bkard...@gmail.com console. log(o.responseText); console. log(o.responseText); This is why I've been advocating for asJSON() and friends to be verbs, not nouns, i.e. readAsJSON(). Showing how you take an action makes you think harder about whether the action will be repeatable or not. (To me, in the context of a stream or a response, read is not repeatable. But others have suggested consume as a verb that makes this clearer, for people who aren't as steeped in the semantics of those objects.) Unless I'm misunderstanding though, (you'd certainly know) from Jake's description it sounds like it's the body stream that gets used up/requires cloning, which is why I suggested, just call it that. If that's wrong then readAs makes more sense to me. I agree that it determines how you reason about things.
Re: [whatwg] Script preloading
On Aug 29, 2013 1:21 AM, Jonas Sicking jo...@sicking.cc wrote: Hi Ryosuke, Based on the feedback here, it doesn't sound like you are a huge fan of the original proposal in this thread. At this point, has any implementation come out in support of the proposal in this thread as a preferred solution over noexecute/execute()? The strongest support I've seen in this thread, though I very well could have missed some, is it's better than status quo. Is that the case? / Jonas On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 13, 2013, at 5:55 AM, Andy Davies dajdav...@gmail.com wrote: On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote: On browser preloading: There seems to an inherent conflict between 'indiscriminate' Pre-parsers/ PreloadScanner and responsive design for mobile. Responsive designs mostly implies that everything needed for a full screen desktop is provided in markup to all devices. The pre-loader is a tradeoff, it's aiming to increase network utilisation by speculatively downloading resources it can discover. Some of the resources downloaded may be not be used but with good design and mobile first approaches hopefully this number can be minimised. Even if some unused resources get downloaded how much it matter? It matters a lot when you only have GSM wireless connection, and barely loading anything at all. By starting the downloads earlier, connections will be opened sooner, and the TCP congestion window to grow sooner. Of course this has to be balanced against visitors who might be paying to download those unused bytes, and whether the unused resources are blocking something on the critical path from being downloaded (believe some preloaders can re-prioritise resources if they need them before the preloader has downloaded them) Exactly. I'd to make sure whatever API we come up gives enough flexibility for the UAs to decide whether a given resource needs to be loaded immediatley. On Jul 12, 2013, at 11:56 AM, Kyle Simpson get...@gmail.com wrote: My scope (as it always has been) put simply: I want (for all the reasons here and before) to have a silver bullet in script loading, which lets me load any number of scripts in parallel, and to the extent that is reasonable, be fully in control of what order they run in, if at all, responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might have existed at the time of initial request. I want such a facility because I want to continue to have LABjs be a best-in-class fully-capable script loader that sets the standard for best-practice on-demand script loading. Because of the different network conditions and constraints various devices have, I'm wary of any solution that gives the full control over when each script is loaded. While I'm sure large corporations with lots of resources will get this right, I don't want to provide a preloading API that's hard to use for ordinary Web developers. On Jul 15, 2013, at 7:55 AM, Kornel Lesiński kor...@geekhood.net wrote: There's a very high overlap between module dependencies and script dependencies proposal. I think at very least it would be useful to define script dependencies in terms of ES6 modules, or even abandon markup solution to avoid duplicating features. ES6 modules however do not solve the performance problem. In fact they would benefit from UA having a list of all dependencies up front (otherwise file's dependencies can only be discovered after that file is loaded, which costs as many RTTs as the height of the dependency tree). So I think that eventually ES6 modules + link[rel=subresource] could be the answer. The link would expose URLs to (pre)load for performance, but modules would handle actual loading/execution for flexibility and reliability. Yes, we should definitely consider how this preloading API works with ES6 modules. On Jul 22, 2013, at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: Having the load event anytime we are done with a network request also seems beneficial. Rather than having most APIs use load whereas this would use preload. Generally speaking load means loaded and processed. The 'noexecute' flag would change what the and processed piece includes. I don't think it'll be confusing if the script had noexecute. We can even call it noautoexecute if we wanted. But I'm fine either way here. The same question and risk of confusion seems to exist with the whenneeded attribute. In general whenneeded seems very similar to noexecute, but with a little bit more stuff done automatically, for better or worse. I like the simplicity of noexecute and excute(). However, I'm a little worried that it doesn't provide any information as to how important a given script is. So Web browsers have no choice but to request all scripts immediately. I'd like to eventually provide APIs that allow
Re: [whatwg] [html][webcomponents]: Link element in body?
On Wed, Mar 20, 2013 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/20/13 6:27 AM, Benjamin Stürmer wrote: I've been thinking about this exact thing for the last few weeks, because I have a use case in which it would be beneficial to use an in-body link to include CSS files, especially if link could be updated to support the scoped attribute with the same behavior as in style. I believe that's come up in the past; worth checking the archives. I _think_ people claimed at the time that style scoped with @import did the right thing, but I agree that link scoped seems cleaner... -Boris Yeah, I am almost positive that I've brought it up before though it might have been offlist to you or Tab... Also FWIW this is essentially the use case I cited when asking the questions that led to this thread... It's a really common case that pages are assembled with document fragments fetched from elsewhere... It would be difficult, implausible to manage web components for those use cases in a significant system/app by placing link references in head. It would be really nice if we had some advice at least for handling that if not a wholly spec'ed solution IMO. -- Brian Kardell :: @briankardell :: hitchjs.com
[whatwg] [html][webcomponents]: Link element in body?
Section 4.2.4 of the HTML Standard[1] contains a note: Note: If the rel attribute is used, the element is restricted to the head element. When used with the itemprop attribute, the element can be used both in the head element and in the body of the page, subject to the constraints of the microdata model. However, all modern browsers at least seem to respect/treat rel link elements in the body as most developers would expect (ie, they work just fine). Given that this would appear to be a de-facto standard and that is to some extent the goal of the spec (documenting what _is_ actually standard), I'm curious as to the discrepancy... Can someone (Hixie maybe) explain? Is it worth opening a bug or am I missing something important? 1. http://www.whatwg.org/specs/web-apps/current-work/#the-link-element -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] Mutation Observer arguments format
On Tue, Mar 12, 2013 at 6:22 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 03/12/2013 12:34 PM, Anne van Kesteren wrote: On Tue, Mar 12, 2013 at 12:41 AM, Alex Russell slightly...@google.com wrote: Thoughts? My main thought is that it's a pita to change the API at this time now it's unprefixed everywhere and we've been encouraging developers to use it in favor of mutation events. If Adam/Rafael/Olli/Jonas are willing to update WebKit/Gecko though I guess I don't really care. We could keep the old behavior and extend it to support types. I was going to mention this the other day - it works inter-operably today, so it seems like you probably don't want to break that. Simultaneously it does seem to me that the API is more sensible and less confusing - is there any reason not change the proposal such that the intent is to to deprecate the existing way and consider the new/proposed API as merely superceeding the old? Given that one is merely sugar on the other anyway - it should be possible to propose the change and augment/prollyfill the mapping I think and I see no reason you couldn't quickly roll that out natively given its simplicity. But since the change isn't backward compatible (scripts using types wouldn't work in older browsers), I'd like to understand the need for the change. -Olli -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] Mutation Observer arguments format
On Mar 12, 2013 12:06 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Mar 12, 2013 at 3:05 PM, Brian Kardell bkard...@gmail.com wrote: I was going to mention this the other day - it works inter-operably today, so it seems like you probably don't want to break that. Simultaneously it does seem to me that the API is more sensible and less confusing - is there any reason not change the proposal such that the intent is to to deprecate the existing way and consider the new/proposed API as merely superceeding the old? Given that one is merely sugar on the other anyway - it should be possible to propose the change and augment/prollyfill the mapping I think and I see no reason you couldn't quickly roll that out natively given its simplicity. Yes, that is the basic argument made time and again. It neglects the costs. It takes away time from people that should probably work on other stuff, it increases the API surface area and what needs to be tested, and thereby increases the chance for mismatching functionality across user agents. Making changes, even seemingly trivial ones, across multiple independent engines is not something that should be taken lightly. -- http://annevankesteren.nl/ Anne, I feel like you've misunderstood my comments/observations. Let me clarify and see: 1) I think this API is more sensible - I had the same problem with mutation observers api. 2) we should not be forever stuck with an unintuitive API 3) we have interop now and a mature spec, that sucks in retrospect that we didn't see this earlier, but it is what it is. 4) this adds nothing in the way of features, it is merely sugar/better API so it should be easily prollyfillable. As such, I am suggesting that we draft a proposal to do so, explain in detail how it would work (I gave a high-level suggestion), provide test cases, etc... That's what prollyfills are all about - a way to evolve outside the browser impl itself based on competition and data which makes that part easier and makes sure we don't take turns that users have problems with ... and ... 5) should we reach that point (it is entirely possible we dont) the actual implementation should be *comparatively *low cost. Does it make sense? Do you feel like I am hand-waving away any of your concerns? I hope not because the idea there is precisely to help address concerns like these (as well as many others). -Brian
Re: [whatwg] Mutation Observer arguments format
On Mar 11, 2013 8:41 PM, Alex Russell slightly...@google.com wrote:
Hi all,
I had a moment today while trying to use Mutation Observers where it
wasn't
clear to me what bits of the configuration passed to observe() are
required
and which are configuration about required values. In particular, the
names
subtree and childList feel like they should be peers, but it seems
they're not.
After a quick chat with Adam Klein, it seems like it might be easier to
understand if the childList, attributes, and characterData
attributes
of the configuration bag were rolled into a single value, e.g. type or
types. The observe() might then be written as:
observer.observe(node, { types: [attributes, childList], subtree:
true });
This breaks the types of observation into a separate bag from the
configuration for those observations.
Thoughts?
Yes, i really like it :)
Re: [whatwg] [Web-storage] subdomains / cooperation and limits
On Sep 17, 2012 8:22 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Sep 2012, Brian Kardell wrote: Ian, you hit the nail on the head with the text section that raised the issue but I still am not entirely sure that I understand... Doesn't this imply that in a case like *.wordpress.com would have a (suggested) limit of 5mb combined for all of its tons and tons of subdomains (at least without additional/constant prompting)? It wouldn't be constant prompting, but yes, the spec does suggest that if you visit a dozen WordPress-hosted blogs and they all try to load a bunch of content onto your machine, you should probably have to give consent or at least be aware of what's going on. I think I may be starting to fill in my mental gap here, thanks for your patience. I think you are saying that each subdomain does get a seperate area, but the spec encourages prompt or at least informative communication to the user to prevent at least obvious misuse and runaway scenarios. Specifically what degree to which they do that are left up to implementations...is that correct? There are a whole lot of what I would call common examples like where it seems (to me anyway) unintuitive given the regularity with which this kind of case would happen to think that that is what is actually proposed. What's the alternative? Allowing any site to overload your machine with infinite amounts of content isn't really a viable solution. Blindly, sure, that could be a problem. If a user can grant permission for more to a particular domain explicitly, that is mostly mitigated I think. If I understand, that is the idea with the subdomains limitations. I will have to do some more searching to find the conversations I might have missed as I expect this was all discussed a while back and in following so many lists I am just missing a few key points. I can understand blocking access to that data pretty easily, but with postMessage, being in the same top-level domain doesn't even matter so it seems that one could just as easily subvert the limit that way. The difference is that getting a new domain costs money, whereas getting a subdomain does not. So the cost of attacking someone with subdomains is much lower than with domains. I think it isn't really implemented that way anywhere though, is it? That is, do browsers really share the limit across subdomains like that... If they do not, they are likely vulnerable to this kind of griefing. It would be great if some ms, moz, opera and webkit variant folks could chime in with any helpful implementaion details so we could understand the emerging rationales about how this is being managed effectively, it might even flesh out additional notes that could be added to the doc. In the very least it would be in the archives for future searches. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] [Web-storage] subdomains / cooperation and limits
Cross posted from w3c list.. I have searched the archives and been unable to resolve this to a great answer and I just want to make sure that my understanding is correct lest I have to unwind things later as someone has recently made me second guess what I thought was a logical understanding of things. Essentially, x.wordpress.com and y.wordpress.com both allocate and use space - no problem, right? Access is subject to the browsers -general- sop, (leaving aside the ability to document.domain up one), right? If I have two affliate sites who communicate across an explicit trust via postMessage - is this problematic? I thought not, and it doesn't seem to be - further - I cannot imagine how it could work otherwise and still be useful for a host of common cases (like the wordpress one I mentioned above). I have been told that the draft contradicts my understanding, but I don't think so. Thought that some manufactures/maybe Hixie could set me straight...? Brian
Re: [whatwg] [Web-storage] subdomains / cooperation and limits
On Sep 17, 2012 5:22 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Sep 2012, Brian Kardell wrote: Essentially, x.wordpress.com and y.wordpress.com both allocate and use space - no problem, right? Access is subject to the browsers -general- [same-origin policy], (leaving aside the ability to document.domain up one), right? If I have two affliate sites who communicate across an explicit trust via postMessage - is this problematic? I thought not, and it doesn't seem to be - further - I cannot imagine how it could work otherwise and still be useful for a host of common cases (like the wordpress one I mentioned above). I have been told that the draft contradicts my understanding, but I don't think so. I don't really understand your question, but does this answer it?: http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#disk-space-0 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Ian, you hit the nail on the head with the text section that raised the issue but I still am not entirely sure that I understand... Doesn't this imply that in a case like *.wordpress.com would have a (suggested) limit of 5mb combined for all of its tons and tons of subdomains (at least without additional/constant prompting)? There are a whole lot of what I would call common examples like where it seems (to me anyway) unintuitive given the regularity with which this kind of case would happen to think that that is what is actually proposed. If so, I guess I am looking for some kind of explanation which I haven't really been able to find to help me understand how that came about. I can understand blocking access to that data pretty easily, but with postMessage, being in the same top-level domain doesn't even matter so it seems that one could just as easily subvert the limit that way. I think it isn't really implemented that way anywhere though, is it? That is, do browsers really share the limit across subdomains like that... am I just completely misunderstanding what that section is saying?
