

How many ways can you slice a URL and name the pieces? - remi
http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces

======
forgotusername
I have no idea why some think it's a good idea to 'supplement' the browser's
built in navigation by overriding yet more of its standard keys. On pressing
left arrow, I expect it to behave uniformly, not navigate to some other page.
If you insist on doing this, then at least use accesskeys= attribute. Instead
I'm left reeling, hands off, staring at my keyboard as if it is an unknown
enemy preparing to attack.

Really don't care about presentation (serve your blog in text/plain all I
care), but some things are unforgivable. Didn't get reading past the first few
lines.

Is it really unfair to assume someone who makes this mistake could not hold
any kind of useful, complex, technically valid opinion that would teach me
something new?

~~~
Luyt
_"I have no idea why some think it's a good idea to 'supplement' the browser's
built in navigation by overriding yet more of its standard keys."_

Because they can. I have yet to meet a 'web designer' or an 'user interface
designer' who doesn't redesign all buttons, scrollbars and text fields for
every design they do: as if the standard built-in ones aren't good enough. Or
perhaps they're afraid they won't be judged as having done a good enough job
on the design?

Jakob Nielsen writes about this phenomenon, and I agree with him:

 _"Many Flash designers introduce their own nonstandard GUI controls. How many
scrollbar designs do we need? [...] The specification of a new GUI widget is a
major human-factors exercise. The current Macintosh and Windows scrollbars
emerged after the world's best interaction designers worked for years testing
numerous design alternatives. A new scrollbar designed over the weekend is
likely to get many details wrong. And, even if the new design was workable, it
would still reduce a site's overall usability because users would have to
figure out how it worked. They know how to operate the standard widget. When
you use standards, users can focus on content and their reasons for visiting
your site. Deviate, and you reduce their feeling of environmental mastery."_

The disadvantage of this approach is that my apps use only the standard GUI
components, which makes some people say that "they're not of this time" and
that I should give the app a "fresh new look with a contemporary skin". Maybe
their taste and expectations are already numbed beyond repair by the chaos in
designs and visual overkill we encounter each day on the web.

------
pragmatic
Surely there is a name for this phenomena.

Just like human languages have more than one word for the same thing (words
for sex, genitals, alcohol, people you like/love/hate).

When something is popular (like the things I mentioned above) words to
describe it flourish.

Also, the url is a close to a universal thing as we have in programming.
Almost every framework evolves to eventually deal with a URL (Greenspun's
Tenth Rule).

So maybe this is asking why the word for (sex|drugs|etc) are different in
English than Russian.

</wild speculation>

~~~
lmkg
I think the word "Balkanization" is pretty accurate. "Divergent Evolution" if
you're into the whole PC thing.

~~~
digikata
Or "Babelization"

------
mildweed
Yet another lovely cheatsheet to print off and hang on the wall by my desk.
Thank you remi. Perhaps I should put up a blog post with all my cheat sheets
some day.

------
saurik
I was somewhat disappointed that the author of this article left out URI "path
parameters": semicolon-delimited name/value pairs that can be attached to each
component of the slash-delimited path.

~~~
pyre
The newer RFC (RFC 3986[1] from 2005, which I assume is being used here) for
URIs doesn't specifically mention them in the spec. You have to go back to
1998 and rfc 2396[2].

RFC 3986 (circa 2005):

    
    
          path          = path-abempty    ; begins with "/" or is empty
                        / path-absolute   ; begins with "/" but not "//"
                        / path-noscheme   ; begins with a non-colon segment
                        / path-rootless   ; begins with a segment
                        / path-empty      ; zero characters
    
          path-abempty  = *( "/" segment )
          path-absolute = "/" [ segment-nz *( "/" segment ) ]
          path-noscheme = segment-nz-nc *( "/" segment )
          path-rootless = segment-nz *( "/" segment )
          path-empty    = 0<pchar>
    
          segment       = *pchar
          segment-nz    = 1*pchar
          segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                        ; non-zero-length segment without any colon ":"
    
          pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
    

RFC 2396 (circa 1998):

    
    
          path          = [ abs_path | opaque_part ]
    
          path_segments = segment *( "/" segment )
          segment       = *pchar *( ";" param )
          param         = *pchar
    
          pchar         = unreserved | escaped |
                          ":" | "@" | "&" | "=" | "+" | "$" | ","
    

IIRC, somewhere in RFC 3986 it alludes to the fact that you could still do
something like that, but it would be scheme-specific, and not part of the URI
spec.

Also of note is that pipes ("|") are no longer even _mentioned_ in RFC 3986,
but they were characterized as 'unwise' in 1998.

RFC 2396:

    
    
       unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
    

[1] <http://www.apps.ietf.org/rfc/rfc3986.html#sec-3.3>

[2] <http://www.apps.ietf.org/rfc/rfc2396.html#sec-3.3>

------
jisaacstone
I see the block at the end as "

A few conclusions: "/* is more prevalent than "/ _. Yet anecdotally developers
use "/_ more, and in practice most schemes are protocols. "/* is used
consistently (to mean the same thing) as are "/* and "/ _. "/_ has been used
consistently for the past 10+ years and in a way consistent with its operating
system roots. "/* is used inconsistently as to whether or not it includes the
leading "#" hash/pound symbol. However, notably absent from any specification
or platform was the alternative phrase "/*.

"

I feel there is something wrong

------
adnam
And absolutely any combination gets named "baseUrl".

------
tantalor
I've seen people confuse "http" with "http:", as in "the 'http:' URI scheme".

The name of the scheme is "http"; "http:" is meaningless.

~~~
franksalim
That's probably because the DOM's window.location.protocol returns "http:" for
URLs with http schemes. That is reflected in the diagram included in the
article where protocol extends to cover the colon in the DOM row. Overall,
it's a pretty unfortunate mish mash of terminology.

