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
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
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
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
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:
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
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
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
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
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
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
[ 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
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:
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
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
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
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
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
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
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
20 matches
Mail list logo
