Re: HTML5 proposes introduction of new family of URI schemes

Robin Berjon wrote:
>
> Eric J. Bowman wrote:
> > Robin Berjon wrote:
> >> 
> >> How is the web platform expected to be viable if it cannot perform
> >> some tasks that are trivial for installed applications? In what way
> >> is this API a protocol-layer solution?
> > 
> > More correctly, then, it's a wholesale change to the Web
> > architecture for no reason other than "because webmail" when a
> > browser config hasn't even been tried.
> 
> I think that there's some confusion and conflation going on in this
> thread. To help alleviate it, I've created the following trivial demo:
> 

OK, thanks for that, yes I was confused a bit, but not enough to change
my point.

> 
> >  If there were some empirical evidence to point to
> > showing that everyone's a numbnut who can't figure this out,
> > different story, but assuming that will fail before it's been tried
> > is putting the cart before the horse (greenfield solutions are the
> > opposite of what standardization is about).
> 
> Just because you haven't heard of this before doesn't make it a
> greenfield solution. It's been around a while, has been discussed a
> fair bit, is implemented in multiple major browsers, and it's an
> important piece of architecture.
> 

I'm not talking about registerProtocolHandler(), I'm talking about web+
schemes.  I always lurk, and sometimes participate in, the relevant
groups where web+ was never discussed (except for Mark's blog which I
missed).  If web+ wasn't a greenfield solution, I'd have heard of it
before it was shipping in browsers, even without following HTML 5.
Because fundamentally altering URI schemes would seem to be beyond the
scope of that work to spawn, without outside review.  Reassuring me
that Apple, Google, Microsoft and/or AOL agreed to ship it, doesn't
assuage my concerns.

>
> And frankly, if you told me I'd have to muck with some bits of
> configuration in my browser in order to use your site I a) wouldn't
> trust you and b) probably wouldn't find it (on my mobile, I
> definitely would not find it). If I did, I'd probably be lazy. And
> I'd forget how it's done when I switch browsers.
> 

Huh.  I've been explaining how to configure browsers to use e-mail
clients to handle mailto: for 18 years now.  I see what you're saying,
this allows Gmail to easily direct users to set it up as their default
e-mail client.  But, do you see what I'm saying, which is a browser
configuration option allowing webmail URIs to be entered, is either
broken for everyone, or fixed for everyone?  What about my clients who
insist on using CPanel webmail?

When they don't get the same functionality as colleagues using Gmail,
guess who they're going to call expecting to fix that?  I'd pass on
their concerns to CPanel, but I wouldn't expect them to refactor into
HTML 5 anytime soon.  It's a clever way to drive more webmail users to
Gmail, I'll grant that, but don't expect me not to have a problem with
it.

>
> > All developers need is markup to declare the intent "this is an
> > e-mail address" which is solved by mailto: URIs.  Why on Earth
> > would I want to go back and change every static Web page I've ever
> > put a mailto: on to make it some sort of interactive API which
> > expresses "this is the same damn e-mail address for Gmail, this is
> > the same damn e-mail address for Yahoo, this is the same damn
> > e-mail address for standalone clients" etc. when all I need is to
> > declare "this is an e-mail address" which is STILL the only real
> > intent -- declaring an e-mail addy to be an e- mail addy.
> 
> Indeed, why on Earth would you do that, and which specification on
> Earth did you read to come away with the impression that you'd need
> to do any of the above?
> 

I'm not getting that from any spec, I'm getting it from using my brain.
Opening the door to willy-nilly ad-hoc URI scheme proliferation could
result in webmail systems defining alternatives to the mailto: scheme.
Then, guess who gets to deal with all the bug reports filed against
legacy websites that stop working with their chosen providers?  My only
recourse would be to go back and add to the mailto: links, by popping up
some sort of selection box or something.

Maybe I'm worrying over nothing, but this is the sort of concern I'd
have brought up, had there been anything resembling an open process
rather than an end-run around that process by a WG exceeding its
charter.  You know, before it had already shipped as a fait accompli.
Anyone with concerns now has the only recourse of crossing their
fingers and hoping Pandora's Box hasn't been opened, or tilting at the
browser-vendor windmill.

>
> > Handwaving won't get past the fact that this "fixes" something
> > that's never been broken, without any regard for the ramifications,
> > in a way that's exactly the opposite of what made the Web work in
> > the first place.  Which was the simplicity of just marking up an
> > e-mail addy to be recognizable as one, and leaving it at that for
> > decades on end no maintenance required.  I don't want all my prior
> > work appearing "broken" to visitors and domain owners because the
> > browser vendors never even tried addressing the webmail problem
> > with a configuration.
> 
> I really, really wonder where you're getting these ideas from. Have
> you considered reading the specification on this topic?
> 

Yes, I eventually found the time, but the point of my participation
here was originally just to give a +1 to an objection to the end-run
around AWWW and any RFCs the WHATWG didn't like.  If you're going to
prod me into speaking my mind, I will, and might even start using words
like "collusion".  What haven't the vendors been telling us about their
plans for web+?

-Eric

Received on Thursday, 26 January 2012 22:58:50 UTC