- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 8 Sep 2009 13:41:24 +0200
- To: Mark Baker <distobj@acm.org>
- Cc: public-webapps <public-webapps@w3.org>
On Sep 8, 2009, at 00:21 , Mark Baker wrote: > On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjon<robin@berjon.com> wrote: >> On May 23, 2009, at 19:21 , Mark Baker wrote: >>> >>> Right. That's the same point Arve made. I don't see a problem with >>> it. Sure, a widget will be able to discover an implementation >>> detail >>> of its widget container - the base URI - but it's still up to the >>> container to permit or deny access to other resources from that >>> widget >>> when asked to dereference it, whether the widget discovered the URI >>> via a mechanism such as the one you describe, or even if it simply >>> guessed it. >> >> Calling it an implementation detail doesn't make it one. Say I have >> a script >> in which I need to identify resources that I'm currently using from >> within >> the widget. Since I don't want to have to care how the designers >> linked them >> in, I'll use their absolute URIs to compare them. If implementation A >> returns "http://magic-widget-host.local/dahut.svg", and >> implementation B >> "file:///special-widget-mount/dahut.svg", and C gives me "made-up:/ >> dahut.svg >> we don't exactly have interoperability. > > I don't understand. In what scenario would a script be comparing URIs > produced by different implementations? Know which section you're in to highlight a given button: function getSection () { return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/, "$1").toLowerCase(); } I won't say that it's necessarily the best-written code, but it's not daft enough to be shrugged off and it's not particularly contrived. It's easy to come up with a bunch of similar cases. If you get one implementation with more market-share than the others, then they'll have to copy its behaviour, and we'll then have to specify it. -- Robin Berjon - http://berjon.com/
Received on Tuesday, 8 September 2009 11:42:01 UTC