Re: do not deprecate synchronous XMLHttpRequest
You either block the JS event loop or you don't. If you do, I'm not sure how a long running synchronous call to the server won't result in this script is taking too long alert and basically hold up all execution till it's done. What am I missing? If you want to synchronize tasks you can promises or callbacks or (in ES6/7) I'm sure other ways too On Fri, Feb 6, 2015 at 10:38 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well yeah. But the manufacturer of your audio equipment doesn't come into your home to yank the player out of your setup. But that's not really the issue here. We're talking about technology that is being developed so that people like me can build good content. As long as there are a lot of people out there using synchronous calls, it would be the job of the browser development community to find a way to make such calls less harmful. Michaela On 02/06/2015 12:28 PM, Marc Fawzi wrote: I have several 8-track tapes from the early-to-mid 70s that I'm really fond of. They are bigger than my iPod. Maybe I can build an adapter with mechanical parts, magnetic reader and A/D convertor etc. But that's my job, not Apple's job. The point is, old technologies die all the time, and people who want to hold on to old content and have it play on the latest player (browser) need to either recode the content or build adapters/hosts/wrappers such that the old content will think it's running in the old player. As far as stuff we build today, we have several options for waiting until ajax response comes back, and I'm not why we'd want to block everything until it does. It sounds unreasonable. There are legitimate scenarios for blocking the event loop but not when it comes to fetching data from a server. On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspective. Would it have been the end of the world to stick with some kind of database language most coders already are familiar with? Same with (sand boxed) file system access. Google went the right way with functions trying to give us what we already knew: files, dirs, read, write, append. But that's water under the bridge. I have learned to code my stuff in a way that I have to invest time and work so that my users don't have to. This is IMHO a good approach. Unfortunately - some people up the chain have a different approach. Synchronous calls are bad. Get rid of them. Don't care if developers have a need for it. Why bother. Our way or highway. Frankly - I find that offensive. If you believe that synchronous calls are too much of a problem for the browser, find a way for the browser to deal with it. Building browsers and adding functionality is not and end in itself. The purpose is not to make cool stuff. We don't need people telling us what we are allowed to do. Don't get me wrong: I really appreciate your work and I am exited about what we can do in script nowadays. But please give more thought to the folks coding web sites. We are already dealing with a wide variety of problems: From browser incompatibilities, to responsive designs, server side development, sql, memcached, php, script - you name it. Try to make our life easier by keeping stuff simple and understandable even for those, who don't have the appreciation or the understanding what's going on under the hood of a browser. Thanks. Michaela On 02/06/2015 09:54 AM, Florian Bösch wrote: I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot: http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience. Via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending a synchronous request whenxhr.responseType is set. The idea behind the change is to help mitigate further usage of synchronous xhrs wherever possible. Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
Re: do not deprecate synchronous XMLHttpRequest
On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz michaela.m...@hermetos.com wrote: it would be the job of the browser development community to find a way to make such calls less harmful. If there was a way to make synchronous calls less harmful, it'd have been implemented a long time ago. There isn't. You could service synchronous semantics with co-routine based schedulers. It wouldn't block the main thread, but there'd still be nothing going on while your single-threaded code waits for the XHR to complete, and so it's still bad UX. Solving the bad UX would require you to deal with the scheduler (spawn microthreads that do other things so it's not bad UX). Regardless, ES-discuss isn't fond of co-routines, so that's not gonna happen.
Re: Are web components *seriously* not namespaced?
I'm inclined to agree with Glen here on a couple of points. 1) The exact form of the namespacing mechanism isn't so important as the fact that there is a mechanism in place. While not everyone will use namespaces (and to be honest that should be seen as a requirement, that any namespace proposal should account for that 90% case that Tab laid out earlier where namespaces are an encumbrance) I think that the sooner such a namespacing mechanism be put into place, the sooner that it can be adopted by the 10% who do in fact have significant need for namespaces (semantic web being the biggest use case I can think of at the top of my head). 2) I tend to distrust public registries - they add a layer of complexity and often are underutilized when finally implemented. I'm more inclined to see something like a namespace bundle or package that can be written in JSON in some kind of standardized format. Node's *npm* might be a good model there. This creates a set of bound key prefixes for a given site that can in turn be associated with corresponding namespaced globals and extended HTML elements. I'd have to think about this a bit, but I could see this both as a way to allow for large organizations to manage its widget usage within web apps. Kurt Cagle Principle Evangelist, Semantic Technologies Avalon Consulting, LLC kurt.ca...@gmail.com, personal cag...@avalonconsult.com, business 443-837-8725 On Fri, Feb 6, 2015 at 9:01 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow art.bars...@gmail.com wrote: Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? Yep. That's a good place. :DG
Re: do not deprecate synchronous XMLHttpRequest
Ryosuke: I understand the reasoning behind the thought. But it is IMHO not the job of browser implementations to educated web developers or to tell them, how things should (not) be done. All I am asking is to keep in mind that it is us who actually makes the content - the very reason for browsers to be developed and improved. And - seeing the e-mail address and hoping that you have some influence on the development of Safari: Please make the necessary improvements so that Safari can be used in a highly complex script environment. That includes indexeddb/file handle and the possibilities to export and store arbitrary blobs of data into the file system (eg. createObjectURL for any kind of data). Thanks. m. On 02/06/2015 12:30 PM, Ryosuke Niwa wrote: On Feb 6, 2015, at 9:27 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspective. Would it have been the end of the world to stick with some kind of database language most coders already are familiar with? Same with (sand boxed) file system access. Google went the right way with functions trying to give us what we already knew: files, dirs, read, write, append. But that's water under the bridge. I have learned to code my stuff in a way that I have to invest time and work so that my users don't have to. This is IMHO a good approach. In that regard, I'm on the same boat. I still write simple web apps in PHP with PostgreSQL instead of Scala/Ruby and a non-schema database today. So I totally understand your sentiment. However, Unfortunately - some people up the chain have a different approach. Synchronous calls are bad. Get rid of them. Don't care if developers have a need for it. Why bother. Our way or highway. Frankly - I find that offensive. If you believe that synchronous calls are too much of a problem for the browser, find a way for the browser to deal with it. The problem isn't so much that it causes a problem for browser implementors but rather it results in poor user experience. While a synchronous XHR is on the fly, user cannot interact with the page at all. With some spinner, etc... UI indicating that the user has to wait, the user can at least still click on hyperlinks and so forth. Since browser vendors (and I hope so are other participants of the working group) are interested in providing better user experience, we would like websites to use asynchronous XHR. Having said that, don't worry. Synchronous XHR isn't going away anytime soon. As long as real websites are using synchronous XHR, browser vendors aren't going to remove/unsupport it. - R. Niwa
[webcomponents]: Let's reach consensus on Shadow DOM
Folks, I wrote a long email, replying to each point where I agreed/differed with Ryosuke, and then deleted it, realizing I wasn't being productive. So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits We are at a point where there are hard choices to be made. But with the 4+ history of the adventure, it's nearly impossible for everyone to recall or catch up on discussions and relevant insight. With this doc, I am hoping we'll get on the same page and make way. :DG
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: * Domain names don't mean much. For example, Dublin Core's namespace starts with http://purl.org/;, which is effectively meaningless. It means that the owner of purl.org decided to allocate the namespace, as opposed to someone else. So while it's not arbitrary, for our purposes it's entirely opaque. * Similarly, path components often exist which are worthless and just lengthen the namespace for no uniquifying gain, such as the SVG namespace http://www.w3.org/2000/svg which contains /2000/ for some historical reason (it was minted in 2000, and at the time the W3C put the year in most urls for some reason). (Note the use of www in this url, compared to no www in the DC namespace. Inconsistency!) URIs are opaque, it's not really worth it to argue about how they're designed, because their design is meaningless to everyone except the authority that minted them. Every once in a while in the RDF/Semantic Web community, there's a complaint that http://www.w3.org/1999/02/22-rdf-syntax-ns# is too long to remember. Eventually the discussion realizes that it's a non issue because, again, URIs are opaque. If you have to look up a URI, http://prefix.cc/xsd (for example) works pretty well. If you type, auto-complete, copy/paste, or otherwise enter the wrong namespace, it'll be pretty clear right off the bat that your program isn't working. Even if that weren't the case, we have spell-checkers, why not namespace-checkers? (snip) I'll stop there, though I could name a few more. All a namespace needs is to be of reasonable length so that it's probably unique. There are any number of non-insane ways to do that, but XML namespaces chose many of the worst options possible. I would call the namespace issue largely /resolved/ by XML. All of the features you named exist because it adds a definite feature; e.g. the ability to paste an SVG document directly into a document without having to copy-paste a bunch of headers (Turtle, SPARQL has this problem; nested namespaces are a definite *feature*!). XML namespaces are greatly preferable to the tag-soup problem we have with text/html and application/json, where there's *no* namespaces whatsoever, with *no* way to mix vocabularies, and *no* forward compatibility. Nothing against JSON; I maintain numerous utilities around JSON including JSON Schema, JSON Hyper-schema, JSON-LD, and more. JSON documents are great for what they do; XML (and other DOM serializations) documents are great for the different task that they do, and they do namespaces. If nothing else, we need to support namespaces because HTML isn't the only DOM-based hypertext technology out there. Limiting our sights to HTML would be unfortunate. I'm not even sure how namespaces are unsupported; namespaces exist in the DOM, even if they don't exist in the text/html syntax. It's not terribly hard to use: var svgns = 'http://www.w3.org/2000/svg'; // functionally same as xmlns=, @prefix, etc document.getElementsByTagNameNS(svgns, 'svg'); var e = document.createElementNS(svgns, 'rect'); ... this is not fundamentally different than all the DOM stuff we do for HTML. We're dealing with Web Scale here. Works for 90% of us isn't good enough. Austin Wright.
Re: do not deprecate synchronous XMLHttpRequest
Florian: I ain't got a problem with synchronous calls. Its just that I had the need to rant because the rift between you guys and simple developer folks is getting deeper every day. If somebody fucks up his web site because he doesn't get the differences between asynchronous and synchronous calls, that's his prerogative. m. On 02/06/2015 12:50 PM, Florian Bösch wrote: On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote: it would be the job of the browser development community to find a way to make such calls less harmful. If there was a way to make synchronous calls less harmful, it'd have been implemented a long time ago. There isn't. You could service synchronous semantics with co-routine based schedulers. It wouldn't block the main thread, but there'd still be nothing going on while your single-threaded code waits for the XHR to complete, and so it's still bad UX. Solving the bad UX would require you to deal with the scheduler (spawn microthreads that do other things so it's not bad UX). Regardless, ES-discuss isn't fond of co-routines, so that's not gonna happen.
do not deprecate synchronous XMLHttpRequest
I disagree with deprecating synchronous XMLHttpRequest: 1) it is not upward compatible so can break numerous sites. Many websites do not have active development, and framework updates that fix this are even slower to roll out to web apps. Many web app clients would much prefer a sub-optimal experience than a broken website. 2) A better way to approach this might be to respect the async=false setting but have the browser move the script thread to another thread which is blocked until the jax (not ajax anymore) completes. Make the browser do the heavy lifting so scripts remain simple. 3) Loading long chains of on-demand content becomes unnecessarily complex. Example: a config file that specifies URLs for column headers which specify URLs for content requires 3 nested .success handlers. With async=false, one can simple write those sequentially. 4) Have it been considered if jQuery can create a work-around to simulate async=false? If not, do not deprecate, as there will be even more browser-specific code splintering. 5) When data loads slowly, many sites will show a please wait view anyway, which disables useful interactions, so how much value does this deprecation add to usability? 6) Do you really want script writers to deal with scroll events while an ajax is outstanding? That seems to be beyond the ability of a plug-in to handle in the general case. async=false really simplifies some tasks. --Gregg Tracton, Chapel Hill, NC, USA
Re: Are web components *seriously* not namespaced?
Web Components are also JS. Any renaming you do in JS, you can do just as easily in HTML. + No functionality is enabled by namespaces that can't be done without them just as easily but with a little more verbosity. So I can import a custom element and rename it even after it has been registered? Also, how do I get information about a custom element in my IDE of choice? You don't need to fear future conflicts. Googling for a name is often sufficient. You can change later if there is a conflict. Seriously? And then I break all the code of users who depend on my element? So they rename it to the new name, and for them it conflicts with yet another element? Most people who mention namespaces on the web are referring to XML Namespaces, so I assumed you were as well. The only thing that was similar was the use of a URL, and I made it clear that this was just an example. Regarding the use of URLs: - You can just as easily misspell (or screw up a copy/paste) if you were using a URN or arbitrary string. Since the NS wouldn't match the one defined with the element, the element would fail to run. - You can't actually fetch namespace urls -- It would be made clear that the URLs should return certain metadata, if they don't then it's just a poorly maintained element. - URLs contain a bunch of extra typing baggage -- Who types namespaces? Copy/paste. - Domain names don't mean much -- that's why you can open the URL in a browser and find information about the element(s). - The ability to redefine namespaces at various points in the tree make generic processing far more complicated than it should be -- This is an implementation detail that I cannot comment on, but it may be sufficient to just support declarations in the head. I just thought that this would be useful in cases where you have less control of certain areas within your page (AJAX-loaded content, etc.). - The ns prefix is actually significant ... -- Same as above. All a namespace needs is to be of reasonable length so that it's probably unique I agree, but reasonable length will be too long in the case of HTML elements. Go to http://customelements.io; and search for x-. For example, x-gif has no identity. We can Google x-gif and get 5 x-gif elements, so now I have to search through my code to find the definition, and hope that there are comments etc. pointing to more information about the element. There are any number of non-insane ways to do that ... Good. So: 1. Are you thinking of using something like a URN? If so, will there be an endpoint that allows you to register your element and provide metadata that IDEs can query? It's a single point of failure, but it's better than nothing at all. (I think that arbitrary strings would probably be a bad idea) 2. Can you, or anyone else, agree with me that namespaces should be implemented sooner rather than later? Has this already been put to a vote? If so, have any of the vendors changed their minds? I really think that this is important. G. On 2015/02/05 21:55, Tab Atkins Jr. wrote: On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@gmail.com wrote: So in other words it *is* a case of it's good enough. Web components are quite possibly the future of the web, and yet we're implementing them to be good enough in 90% of use cases? jQuery is JavaScript which means that it's different for various reasons: 1. It's less important to keep the names short. 2. It's possible to rename a plug-in if there is a conflict (e.g. @ http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name) 3. It's a library, not something built into the browser, which means that if jQuery decides to add some form of namespacing, it doesn't require a major specification and implementation by 5+ major browsers, etc. Web Components are also JS. Any renaming you do in JS, you can do just as easily in HTML. Complicating things further simply isn't all that necessary. Complicating it for the developer, or the implementers? I can't speak for the latter, but for developers, this would be an *optional* feature. If you don't have conflicts you don't *have* to alter an element's NS prefix, but specifying the prefix in your HTML would provide rich IDE functionality, so I don't see why anyone would *not* want to do this. Again, namespaces are nothing more than an indirection mechanism for prefixes, so you can write a long and more-likely-unique prefix as a shorter prefix that you know is unique for your page. No functionality is enabled by namespaces that can't be done without them just as easily but with a little more verbosity. It's something that can be added organically as necessary. Anne has already made a point about this, but also consider the fact that without real namespacing, we're forced to name based on *potential* conflicts. For example, in the ms- case, ms- may either already exist, or *potentially* exist and be useful, so I name
Re: Allow custom headers (Websocket API)
Usually, - IETF HyBi ML http://www.ietf.org/mail-archive/web/hybi/current/maillist.html for protocol stuff - Here or WHATWG ML https://lists.w3.org/Archives/Public/public-whatwg-archive/ for API stuff On Thu, Feb 5, 2015 at 11:07 PM, Michiel De Mey de.mey.mich...@gmail.com wrote: Standardizing the approach would definitely help developers, however where will we communicate this?
Re: Are web components *seriously* not namespaced?
On 2/4/15 4:41 PM, Dimitri Glazkov wrote The proposed solution is using registries: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578 Thanks Dimitri. Glen - FYI, I added a link to the thread you started to the above bug (and embellished the bug's title a bit to reflect this thread). The registry API hasn't been spec'd yet. Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? -ArtB
Mail list Etiquette [Was: Re: Shadow tree style isolation primitive]
[ Apologies for cross-posting ] On 2/4/15 6:56 PM, Ryosuke Niwa wrote: That sounds rather demeaning and insulting [1]. public-webapps, or a mailing list of any W3C working group, isn't an appropriate forum to rant. Given this thread resulted in some heated replies, I'd like to remind everyone of WebApps' e-mail list etiquette policy: [[ https://www.w3.org/2008/webapps/wiki/WorkMode#Mail_List_Policy.2C_Usage.2C_Etiquette.2C_etc. *WebApps' members appreciate and encourage frank technical discussions on our mail lists but all discussions must be done in a respectful manner. Please note this respect requirement is codified in the Process Document via the following participation criteria Social competence in one's role http://www.w3.org/2005/10/Process-20051014/policies.html#ParticipationCriteria. Additionally, seeCode of Ethics and Professional Conduct http://www.w3.org/Consortium/cepc/and if you did not attend/Kindergarten/, we expect our list participants to adhere to the basic principles inAll I Really Need To Know I Learned In Kindergarten http://www.peace.ca/kindergarten.htm. *]] Please focus on technical comments and always be respectful. -Thanks, ArtB [1] http://www.w3.org/Consortium/cepc/ - R. Niwa
Re: do not deprecate synchronous XMLHttpRequest
I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot: http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience. Via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending a synchronous request whenxhr.responseType is set. The idea behind the change is to help mitigate further usage of synchronous xhrs wherever possible. Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
Re: do not deprecate synchronous XMLHttpRequest
I second Gregg's suggestion. It should be up to the developer to decide whether he wants to block or not. On 02/05/2015 08:58 PM, Gregg Tracton wrote: I disagree with deprecating synchronous XMLHttpRequest: 1) it is not upward compatible so can break numerous sites. Many websites do not have active development, and framework updates that fix this are even slower to roll out to web apps. Many web app clients would much prefer a sub-optimal experience than a broken website. 2) A better way to approach this might be to respect the async=false setting but have the browser move the script thread to another thread which is blocked until the jax (not ajax anymore) completes. Make the browser do the heavy lifting so scripts remain simple. 3) Loading long chains of on-demand content becomes unnecessarily complex. Example: a config file that specifies URLs for column headers which specify URLs for content requires 3 nested .success handlers. With async=false, one can simple write those sequentially. 4) Have it been considered if jQuery can create a work-around to simulate async=false? If not, do not deprecate, as there will be even more browser-specific code splintering. 5) When data loads slowly, many sites will show a please wait view anyway, which disables useful interactions, so how much value does this deprecation add to usability? 6) Do you really want script writers to deal with scroll events while an ajax is outstanding? That seems to be beyond the ability of a plug-in to handle in the general case. async=false really simplifies some tasks. --Gregg Tracton, Chapel Hill, NC, USA
Re: do not deprecate synchronous XMLHttpRequest
Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspective. Would it have been the end of the world to stick with some kind of database language most coders already are familiar with? Same with (sand boxed) file system access. Google went the right way with functions trying to give us what we already knew: files, dirs, read, write, append. But that's water under the bridge. I have learned to code my stuff in a way that I have to invest time and work so that my users don't have to. This is IMHO a good approach. Unfortunately - some people up the chain have a different approach. Synchronous calls are bad. Get rid of them. Don't care if developers have a need for it. Why bother. Our way or highway. Frankly - I find that offensive. If you believe that synchronous calls are too much of a problem for the browser, find a way for the browser to deal with it. Building browsers and adding functionality is not and end in itself. The purpose is not to make cool stuff. We don't need people telling us what we are allowed to do. Don't get me wrong: I really appreciate your work and I am exited about what we can do in script nowadays. But please give more thought to the folks coding web sites. We are already dealing with a wide variety of problems: From browser incompatibilities, to responsive designs, server side development, sql, memcached, php, script - you name it. Try to make our life easier by keeping stuff simple and understandable even for those, who don't have the appreciation or the understanding what's going on under the hood of a browser. Thanks. Michaela On 02/06/2015 09:54 AM, Florian Bösch wrote: I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot: http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience. Via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending a synchronous request whenxhr.responseType is set. The idea behind the change is to help mitigate further usage of synchronous xhrs wherever possible. Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
Re: do not deprecate synchronous XMLHttpRequest
Here is an additional past discussion of this topic: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0232.html Sincerely, James Greene On Fri, Feb 6, 2015 at 9:54 AM, Florian Bösch pya...@gmail.com wrote: I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot: http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience. Via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending a synchronous request whenxhr.responseType is set. The idea behind the change is to help mitigate further usage of synchronous xhrs wherever possible. Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
Re: Are web components *seriously* not namespaced?
On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow art.bars...@gmail.com wrote: Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? Yep. That's a good place. :DG
Re: do not deprecate synchronous XMLHttpRequest
On Feb 6, 2015, at 9:27 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspective. Would it have been the end of the world to stick with some kind of database language most coders already are familiar with? Same with (sand boxed) file system access. Google went the right way with functions trying to give us what we already knew: files, dirs, read, write, append. But that's water under the bridge. I have learned to code my stuff in a way that I have to invest time and work so that my users don't have to. This is IMHO a good approach. In that regard, I'm on the same boat. I still write simple web apps in PHP with PostgreSQL instead of Scala/Ruby and a non-schema database today. So I totally understand your sentiment. However, Unfortunately - some people up the chain have a different approach. Synchronous calls are bad. Get rid of them. Don't care if developers have a need for it. Why bother. Our way or highway. Frankly - I find that offensive. If you believe that synchronous calls are too much of a problem for the browser, find a way for the browser to deal with it. The problem isn't so much that it causes a problem for browser implementors but rather it results in poor user experience. While a synchronous XHR is on the fly, user cannot interact with the page at all. With some spinner, etc... UI indicating that the user has to wait, the user can at least still click on hyperlinks and so forth. Since browser vendors (and I hope so are other participants of the working group) are interested in providing better user experience, we would like websites to use asynchronous XHR. Having said that, don't worry. Synchronous XHR isn't going away anytime soon. As long as real websites are using synchronous XHR, browser vendors aren't going to remove/unsupport it. - R. Niwa
Re: do not deprecate synchronous XMLHttpRequest
I have several 8-track tapes from the early-to-mid 70s that I'm really fond of. They are bigger than my iPod. Maybe I can build an adapter with mechanical parts, magnetic reader and A/D convertor etc. But that's my job, not Apple's job. The point is, old technologies die all the time, and people who want to hold on to old content and have it play on the latest player (browser) need to either recode the content or build adapters/hosts/wrappers such that the old content will think it's running in the old player. As far as stuff we build today, we have several options for waiting until ajax response comes back, and I'm not why we'd want to block everything until it does. It sounds unreasonable. There are legitimate scenarios for blocking the event loop but not when it comes to fetching data from a server. On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspective. Would it have been the end of the world to stick with some kind of database language most coders already are familiar with? Same with (sand boxed) file system access. Google went the right way with functions trying to give us what we already knew: files, dirs, read, write, append. But that's water under the bridge. I have learned to code my stuff in a way that I have to invest time and work so that my users don't have to. This is IMHO a good approach. Unfortunately - some people up the chain have a different approach. Synchronous calls are bad. Get rid of them. Don't care if developers have a need for it. Why bother. Our way or highway. Frankly - I find that offensive. If you believe that synchronous calls are too much of a problem for the browser, find a way for the browser to deal with it. Building browsers and adding functionality is not and end in itself. The purpose is not to make cool stuff. We don't need people telling us what we are allowed to do. Don't get me wrong: I really appreciate your work and I am exited about what we can do in script nowadays. But please give more thought to the folks coding web sites. We are already dealing with a wide variety of problems: From browser incompatibilities, to responsive designs, server side development, sql, memcached, php, script - you name it. Try to make our life easier by keeping stuff simple and understandable even for those, who don't have the appreciation or the understanding what's going on under the hood of a browser. Thanks. Michaela On 02/06/2015 09:54 AM, Florian Bösch wrote: I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot: http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience. Via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending a synchronous request whenxhr.responseType is set. The idea behind the change is to help mitigate further usage of synchronous xhrs wherever possible. Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
Re: do not deprecate synchronous XMLHttpRequest
Well yeah. But the manufacturer of your audio equipment doesn't come into your home to yank the player out of your setup. But that's not really the issue here. We're talking about technology that is being developed so that people like me can build good content. As long as there are a lot of people out there using synchronous calls, it would be the job of the browser development community to find a way to make such calls less harmful. Michaela On 02/06/2015 12:28 PM, Marc Fawzi wrote: I have several 8-track tapes from the early-to-mid 70s that I'm really fond of. They are bigger than my iPod. Maybe I can build an adapter with mechanical parts, magnetic reader and A/D convertor etc. But that's my job, not Apple's job. The point is, old technologies die all the time, and people who want to hold on to old content and have it play on the latest player (browser) need to either recode the content or build adapters/hosts/wrappers such that the old content will think it's running in the old player. As far as stuff we build today, we have several options for waiting until ajax response comes back, and I'm not why we'd want to block everything until it does. It sounds unreasonable. There are legitimate scenarios for blocking the event loop but not when it comes to fetching data from a server. On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote: Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspective. Would it have been the end of the world to stick with some kind of database language most coders already are familiar with? Same with (sand boxed) file system access. Google went the right way with functions trying to give us what we already knew: files, dirs, read, write, append. But that's water under the bridge. I have learned to code my stuff in a way that I have to invest time and work so that my users don't have to. This is IMHO a good approach. Unfortunately - some people up the chain have a different approach. Synchronous calls are bad. Get rid of them. Don't care if developers have a need for it. Why bother. Our way or highway. Frankly - I find that offensive. If you believe that synchronous calls are too much of a problem for the browser, find a way for the browser to deal with it. Building browsers and adding functionality is not and end in itself. The purpose is not to make cool stuff. We don't need people telling us what we are allowed to do. Don't get me wrong: I really appreciate your work and I am exited about what we can do in script nowadays. But please give more thought to the folks coding web sites. We are already dealing with a wide variety of problems: From browser incompatibilities, to responsive designs, server side development, sql, memcached, php, script - you name it. Try to make our life easier by keeping stuff simple and understandable even for those, who don't have the appreciation or the understanding what's going on under the hood of a browser. Thanks. Michaela On 02/06/2015 09:54 AM, Florian Bösch wrote: I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot: http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience. Via https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending a synchronous request whenxhr.responseType is set. The idea behind the change is to help mitigate further usage of synchronous xhrs wherever possible. Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
