Re: Are web components *seriously* not namespaced?

[Kurt Cagle]

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
usually fairly strong type correlations and inheritance that can be
signaled in Sparql. Manage those namespaces and prefix as type signifier
usually becomes much more useful.

> We're dealing with Web Scale here. "Works for 90% of us" isn't good
enough.

Yup. This is my problem with HTML5 in general - while there are some
benefits to creating "simplified" HTML (the biggest being partial
rendering, which XML is still struggling with via the streaming APIs) the
most highly touted benefit - the Aunt Gladys dictum (HTML should be
simplest enough that your Aunt Gladys should be able to write it)  - has
always seemed specious to me. HTML5 is the only programming language I'm
aware of that doesn't specifically require syntactical integrity. Not
surprising, that tends to add considerably to both the browser's overhead
and the likelihood of misrendering. I think this is even more true for 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 2:30 PM, Austin William Wright  wrote:

>
>
> 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. 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  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,  (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.
>

[webcomponents]: Let's reach consensus on Shadow DOM

[Dimitri Glazkov]

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?

[Austin William Wright]

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. 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  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,  (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: Are web components *seriously* not namespaced?

[Kurt Cagle]

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  wrote:

>
> 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<
>

Re: do not deprecate synchronous XMLHttpRequest

[Marc Fawzi]

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 
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 
> 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

[Michaela Merz]

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 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.

Re: do not deprecate synchronous XMLHttpRequest

[Michaela Merz]

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
 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

[Florian Bösch]

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 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: do not deprecate synchronous XMLHttpRequest

[Michaela Merz]

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
> 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
> >
> > 
>
>
>

Re: do not deprecate synchronous XMLHttpRequest

[Marc Fawzi]

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 
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

[Ryosuke Niwa]

> 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 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

[Michaela Merz]

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: Are web components *seriously* not namespaced?

[Dimitri Glazkov]

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<

Re: do not deprecate synchronous XMLHttpRequest

[James M. Greene]

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 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

[Florian Bösch]

>
> 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

[Michaela Merz]

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
>
>
>
>

Mail list Etiquette [Was: Re: Shadow tree style isolation primitive]

[Arthur Barstow]

[ 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:


[[


*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 
". 
Additionally, seeCode of Ethics and Professional Conduct 
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 
.

*]]

Please focus on technical comments and always be respectful.

-Thanks, ArtB

[1] http://www.w3.org/Consortium/cepc/ - R. Niwa 

Re: Are web components *seriously* not namespaced?

[Arthur Barstow]

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

Re: Are web components *seriously* not namespaced?

[Glen]

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 . 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  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 na

Re: Allow custom headers (Websocket API)

[Takeshi Yoshino]

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 definitely help developers,
> however where will we communicate this?
>

do not deprecate synchronous XMLHttpRequest

[Gregg Tracton]

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