Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I had a number of revelations through rereading this classic article:

First, holy crap, I hadn't been to http://www.w3.org/ in a long time, and it looks like they've actually made it to the 21st century!

Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html is kind of an unfortunate URI. What's "Provider"? Why are "Provider" and "Style" uppercase? And what's wrong with 301 redirecting (don't break old URIs, but still restructure them as your website matures and you realize a better organizational hierarchy)?

Third and perhaps most importantly, this all seems like a pretty awesome problem to have! How many websites survive more than a few years? (Geocities doesn't count.)



> Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html is kind of an unfortunate URI. What's "Provider"? Why are "Provider" and "Style" uppercase?

They're uppercase because they're uppercase. Asking why is like asking why Rubyists like_using_method_names_like_this and .NET devs LikeUsingMethodNamesLikeThis.


Convention is for URLs to be all lowercase, which IMO aids in readability and certainly makes them easier to type (imagine giving a URL to a friend over the phone -- remember this is 1999).


Well luckily for you, the URI is case-insensitive and redirects (301) to the canonical version.


The standard is that hostnames are case-insensitive, but non-FQDN paths should allow both uppercase (especially for systems which don't include lower-case elements, yes, Virginia, they exist) and lowercase elements.


I agree that method_names_like_this is more readable, even (or, especially) after many years of .NET programming. I used the_style_like_this back in C++ days and, honestly, miss it. Perhaps, the renaissance of C++ in the form of C++11 will bring it back :)


like_using_method_names_like_this is more readable. White space has been in use to separate words since the time of Alciun, and that's the closest way to do it. Call me conservative but I prefer to stick to the insights of the last 1400 years rather than mangle them horribly ;-)

Oh, and I am not a Ruby developer ;-)


Whitespace is nice but underscores aren't whitespace. They also leave a zigzag effect that isn't wonderful.


They are the closest thing you can have to whitespace. That's the point. Actually come to think of it, they are underlined whitespace ;-)

As for a zigzag effect I think CamelCasing is at least that bad, maybe moreso.

Wondering if I get points for bringing early Medieval history into a discussion on coding conventions ;-)


What do you mean by zigzag effect?


The it isn't actually

word+empty-space+word

but

word+line-down-below+word

so your eyes go zig-zag from the taller glyphs of the word to the low glyph of the underscore (vertical zig zag motion), instead of jumping to the next world (horizontal).


funny, I was just checking because I have never noticed my eyes doing that and afaics my eyes still scan horizontally. I don't need to look down to see the underscore. I guess YMMV?


Actually I read somewhere that the decision for Ruby using underscored names as a naming convention was because of the very large number of non-native English speakers in the early days of the language. Something along the lines of it was easier to read for non-native speakers because it more closely mimicked spaced English.

Searching for the source now.


> Second, perhaps cool URIs don't change, but it seems like http://www.w3.org/Provider/Style/URI.html is kind of an unfortunate URI. What's "Provider"? Why are "Provider" and "Style" uppercase?

Take a look at w3.org/Provider and w3.org/Provider/Style. It's actually a well-constructed URL. It appears to be a "Style guide" for "web content Providers."


> What's "Provider"?

It's because it is a part of a collection of numerous pages named "Putting Information onto the Web". Its audience is obviously (content) providers, which the URI reflects.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: