ACTION-234

Hello,

I took an action to review the draft finding 'Usage Patterns for 
Client-side URL parameters' [1]. I consider this email sufficient to 
mark the action 'pending review' and will updated the action with a link 
to this email.

I had various editorial comments, some of which related to use of 
terminology (such as 'web parts') and would like to know whether we are 
talking about URIs or URLs here (the document, however, seems quite 
clear that these are URLs).

I noted also that the 'recommended best practices' section [2] of [1] is 
empty. I felt, however, that there were some potential best practices 
trying to reveal themselves from within the text:

i) Web applications should use the fragment identifier to refer to 
client state-related information, as this helps links to remain 
"bookmarkable" and to make the browser back-button work reasonably.
ii) Conversely, it sounds from the text as if the "naked hash-ref" is a 
potential anti-pattern.

If we wish to publish this document in any form, we should certainly 
either fill in the empty sections or remove them.

My raw comments are listed below.

Regards,

- johnk

[1] http://www.w3.org/2001/tag/doc/hash-in-url
[2] http://www.w3.org/2001/tag/doc/hash-in-url#id2261987

Full comments below
-------------------

1. s/URL/URI/g
2. What is a "Web part"? (Abstract)
3. Are # parameters the only (TAG-approved) way to pass parameters to
the client?

4. Note: the abstract specifically mentions this as a *finding*. I
would suggest that if we wish to publish this sooner rather than wait
for Raman to make it a finding, we should make this text vaguer about
the final output of the work.

5. 2.1.1 would like to see 'things to note' bulleted, or otherwise
distinguished from one another.

6. 2.1.2 s/extrapollating/extrapolating/

7. what, actually, is the common architectural model here? What is the
difference between a JS app running inside HTML, vs. a video,
vs. multiple iFrame proxies?

8. 2.3, 2.4 - 2.6 all seem rather similar.

9. 2.2 is not fully described - what exactly is the iFrame proxy doing
to ensure the back button works? Is there a suggestion that everyone
should do things this way? What situations does this work better in
than some other method (simply updating the URL in the address bar
with a # to maintain client state?

10. Is there actually a recommendation to be made here in using #
parameters to carry client state for 'bookmarkability' - it felt like
it from the text....

11. Conversely, is "naked-hashref" an anti-pattern?

12. Remove or fill empty sections (ie. conclusions etc.)

13. Some references mentioned in text are missing, and at least one
reference (to JSONP) is not referenced in the text (and in fact, what
does JSONP have to do with #?)

14. In general, do we want to advise AGAINST breaking the same-domain
policy by doing JSONP and/or iFrame proxy? Tough question (use-cases
vs. security).... Should at least mention interaction here of such
things allowing cross-site scripting or request forgery ("breaking"
the browser same-domain policy), which is surely a security
consideration.

Received on Monday, 23 March 2009 22:00:50 UTC