Austin,
Second on the problem with namespaces and Sparql. I spend a significant
amount of code in my sem apps getting the application to manage these,
rather than the querant. It's also at least one reason why I think that
many ontologists tend to go to a single namespace, even where there are
usu
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:
On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr.
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
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 s
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
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,
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
On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz
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 servic
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
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 w
> On Feb 6, 2015, at 9:27 AM, Michaela Merz 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 m
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 perspecti
On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow
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<
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 wrote:
> I had an Android device, but now I have an iPhone. In addition to the
>> popup pro
>
> 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
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 no
[ 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
everyo
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
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
registere
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
wrote:
> Standardizing the approach would defi
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 exp
21 matches
Mail list logo