Know your stuff: (Was: [uf-discuss] hCard-o-matic topleveldiv
mikeschinkel at gmail.com
Thu Oct 19 01:15:04 PDT 2006
Sorry for the late reply...
>> Mike, do you see any advantage to using a "/" instead of a "-" ?
Let me start by saying it definitely wasn't a conscious decision to use "/"
in an attempt to implicitly bypass your convention. I merely chose "/"
because it was what I am most commonly used to and I had only tangentially
noticed your convention but hadn't realized it was an explicit convention.
That said, I've been studying URLs a lot lately (if you haven't noticed :)
and generally speaking I think what I was proposing was explicitly a
heirarchy with the microformat being the "parent" of all things related to
that specific microformat (i.e. FAQs, Tutorials, Examples, Specification,
etc. etc.) So it seemed only natural to use the known heirarchy mechanism
built into URLs.
Further, people used to peeling/hacking URLs would know they could probably
get rid of the text past the last "/" to be able to get to the index page
for a microformat. With the "-", that's not as obvious.
BTW, if it were not Mediawiki the heirarchy would be grouping all things
related to a given microformat into it's own related area, but in
Mediawiki it's all a façade so that reason wouldn't hold water.
As for readability, it depends on the use-cases but I can see you still
being able to say "hcard-faq" as a convenience, and "hCard/FAQ" (with the
quotes) would probably work too.
Question: Will search engines not index "hcard/faq" as two words? (I dont
know for sure.)
Personally I think in this case the slashes is a tad stronger than the case
for dashes (for microformat subpages, not necessarily for other things on
HOWEVER, all that said I will loose ABSOLUTELY ZERO SLEEP if you consider my
comments here and decide they are irrelevant and choose to ignore them all!
Related to the web on a grand scale I'm passionate about URL design, but
I've got no similar strong feelings about the microcosm of how you choose to
design the URLs for the Microformat.org wiki. It's your baby after all, so
you get to decide. We're just thankfully along for the ride. :)
P.S. And I definitely agree with the Underscores. Too bad Mediawiki uses
them (wonder if you can change that in LocalSettings.php?)
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Tantek Ç
Sent: Tuesday, October 17, 2006 8:33 AM
Subject: Re: Know your stuff: (Was: [uf-discuss] hCard-o-matic topleveldiv
On 10/17/06 1:51 AM, "Mike Schinkel" <mikeschinkel at gmail.com> wrote:
> I think the reorganization to create mini-home pages for each
> microformat will make it easy to find and remember those
I think this is a good suggestion and perhaps we can do with a naming
convention for such "mini-home" overview pages, like *-index, e.g.
Mike, do you see any advantage to using a "/" instead of a "-" ?
The current page is at:
When we established this convention of using "-" separated words, we did so
for a few reasons.
1. Findability. It is significantly better for ambient findability. Search
engines will index "hcard-faq" both as a phrase and as separate words. This
is in stark comparison with both "hcard_faq" (which search engines will only
index as a phrase), and the wiki-traditional initialism "HcardFaq" which is
also only indexed as a phrase.
2. Readability/usability. Use of hyphens to denote compound phrases/words
is common in English, whereas "_" is programmer convention, and "/"
typically means "and/or" or "divided by" rather than a phrase when used to
3. Avoiding hierarchy. Hierarchical structures/taxonomies tend to be more
limiting (and confusing) for most folks, in comparison to flat
sets/taxonomies. Thus we have avoided (with only *two* exceptions), the use
of any hierarchy ("/") in wiki page URLs. The two exceptions are static
uses, that is two *specific* sub-directories inside which the contents
remain flat: /wiki/rest/ and /wiki/events/ . /rest/ is essentially for a
whole separate space of wiki pages having to do with a very different topic.
/events/ acts purely as a container for event specific pages. I for one
would like to avoid any additional sub-directories.
microformats-discuss mailing list
microformats-discuss at microformats.org
More information about the microformats-discuss