Re: URL structure sanity check

Oops. My example is not correct. I'll fix that. Instead, see
http://docs.webplatform.org/wiki/apis/file/events/onabort.
+SCott



On Fri, Nov 16, 2012 at 11:30 AM, Scott Rowe <scottrowe@google.com> wrote:

> Hi Mike,
>
> Perhaps I'm not gettin' it, but why would you strip out the "on"? We
> usually document them as event handlers (properties). Here's an old MDN
> doc: https://developer.mozilla.org/en-US/docs/DOM/FileReader, and here's
> my treatment of
> http://docs.webplatform.org/wiki/apis/webrtc/objects/MediaStreamTrack/properties/onmute
> .
>
> +Scott
>
>
>
>
>
> On Fri, Nov 16, 2012 at 4:49 AM, Jonathan Garbee <jonathan@garbee.me>wrote:
>
>>  I'm inclined to agree with Paul here.  Using his example of
>> PerformanceTiming there are about *twenty* subpages.  That seems pretty
>> excessive to me.  I think his idea of using one comprehensive page is good,
>> but making sure headings are setup properly so if people want to point to a
>> specific thing or know where they are going they can easily use a fragment
>> to do it.  I'm also seeing some with only two or three subpages; having
>> those seems almost wasted for so little content when one page could do just
>> fine with the information.
>>
>> I am not sure what was said during the telcon for this though.  If there
>> was a technical reason for wanting to use sub-pages then please let me
>> know.  I think we could get the forms/templates setup pretty well for
>> having one page handle all that is needed though.
>>
>> -Garbee
>>
>>
>> On 11/15/2012 6:33 PM, Paul Irish wrote:
>>
>> I've long proposed shorter URLs and still think they are a better match
>> for our audience than over-specifying and using spec vocabulary.
>>
>>  However,
>>
>>  Given this list, I feel like the larger issue is one of granularity.
>> There simply isn't a good reason all  the PerformanceTiming events (for
>> example) should get their own page. performance.timing deserves ONE page
>> that's comprehensive.
>>
>>  Our imported content defined these conventions, though, as far as I
>> know, no one considered them. In nearly every page in the linked file<https://github.com/mike-sierra/webplatform/blob/master/urls.txt>,
>> I would probably collapse it into its parent.
>>
>>  I don't think we'll find an URL structure that is consistent,
>> technically accurate, using precise terminology, using developer
>> terminology, and simultaneously user-friendly. And that's okay. The
>> important thing is having high-value documentation. Pages that developers
>> read and are hugely impressed so much valuable content is there.
>>
>>
>> On Thu, Nov 15, 2012 at 10:51 PM, Michael Sierra <msierra@adobe.com>wrote:
>>
>>> Turns out there are quite a few collisions in these examples once you
>>> strip out the 'on' prefixes from the event names:
>>>
>>> /apis/file/FileReader/abort
>>> /apis/file/FileReader/error
>>> /apis/push/PushService/error
>>> /apis/webcrypto/CryptoOperation/abort
>>> /apis/webcrypto/CryptoOperation/complete
>>> /apis/webcrypto/CryptoOperation/init
>>> /apis/webrtc/DataChannel/close
>>> /apis/websocket/WebSocket/close
>>>
>>> --Mike Sierra
>>>
>>>
>>>
>>> ________________________________________
>>> From: PhistucK [phistuck@gmail.com]
>>> Sent: Thursday, November 15, 2012 5:33 PM
>>> To: Michael Sierra
>>> Cc: public-webplatform@w3.org
>>> Subject: Re: URL structure sanity check
>>>
>>> In some cases (WebSocket, for example, if I am not mistaken), you cannot
>>> use addEventListener for listening to an event, like ws.onopen. Adding it
>>> as "open" might cause some confusion.
>>> It might be an implementation issue, because I think WebSocket is
>>> specified to subclass EventTarget as well, which means addEventListener
>>> should apply to it, but in Chrome, as far as I remember, it does not work.
>>> I have not tried other browsers.
>>> Anyway, in cases like these (assuming no browser implements
>>> addEventListener for that object), events should begin with the "on"
>>> prefix, I believe (but still have the regular Event template, I guess).
>>>
>>> What does everyone think?
>>>
>>> Also, does anyone have any information regarding other browsers (or
>>> current Chrome?) in this regard?
>>>
>>>
>>> ☆PhistucK
>>>
>>>
>>>
>>>  On Thu, Nov 15, 2012 at 11:18 PM, Michael Sierra <msierra@adobe.com
>>> <mailto:msierra@adobe.com>> wrote:
>>> Re the recent conf-call clarifying the apis/ URL space, here are a few
>>> random APIs generated from some test W3C specs:
>>>
>>> https://github.com/mike-sierra/webplatform/blob/master/urls.txt
>>>
>>> Of all the comments are marked "#",
>>>
>>> * I think of "deviceorientation" as belonging under apis/, but it seems
>>> to simply modify the window object.  Can/should it be represented here?
>>>
>>> * The File API defines a new URL scheme, and I wonder where that gets
>>> doc'ed
>>>
>>> * I noticed one instance of a namespace collision, where an abort()
>>> method collides with an "abort" event.  In this URL list, I kept it as it
>>> appears in the spec, "onabort," but current practice in the wiki is to
>>> strip the "on" prefix, which would cause a problem.
>>>
>>> --Mike Sierra
>>>
>>>
>>>
>>>
>>
>>
>