[uf-discuss] hResume Check Please
steve at ganz.name
Sun Jul 16 14:28:47 PDT 2006
> First up, the best-practice method of containing hCard within
> an ADDRESS element appears hard to implement,
This is a known issue. Hence the recent adjustment to the draft that states
it is recommended but not required to use the <address> element for the
> given the
> inline nature of ADDRESS. In my case, I tried to have
> [div#benmichaelward] (line 100) as an ADDRESS, but the
> block-level children triggers quirks mode in browsers and
Using the <address> element to contain block-level child elements shouldn't
trigger quirks mode by itself, but it surely (and sadly) isn't valid HTML
4.01 or XHTML 1.0. The good news is that both XHTML 2.0 and WHATWG both plan
on turning the <address> into a structural element so in the future this
will be much easier to use as originally intended.
> causes the block level content (h1, ul, dl) to become
> siblings in the DOM, not children, which in turn breaks stlyling.
Among other things.
> Second, I find the mark-up required for skills - using
> rel=tag - to be rather laborious to author. I appreciate the
> value of using tags, pointing multiple skill sets to the same
> place, but there is a lot of typing involved, not to mention
> the effort of hunting out the URLs. I honestly don't know if
> there's a better way though, since everything I keep
> half-thinking of as I type this doesn't actually help very
> much (briefly the idea of a base URL for tags, but that
> doesn't actually get around much of the labour problem).
I agree with you on the level effort. It's not entirely clear from the spec,
so perhaps Ryan can clarify, but if an author could choose to use only
class="skill" on the parent element, without using the rel="tag" it would
definitely cut down on the amount of work involved.
Aside from the rel="tag" issue, I feel we could simplify "skills" a bit by
using a hierarchical taxonomy that looks like this:
The idea, which I got from the old "XML Resume Library"
[http://xmlresume.sourceforge.net/], would be to use nested lists and
eliminate the need to mark up each individual skill with class="skill" and
assume that each child <li> of <ul class="skills"> and/or <ul
class="skillset"> are, in fact, an indvidual skill when either of those is a
You can see an example of this in my resume
Using this schema, the markup would end up looking something like (ommitting
rel="tag" for clarity):
Or we could further simplify by just using one level:
> The last thing regards experience/education hevents that are
> still ongoing ("2002-present"). Is it safe to assume, or
> should it perhaps be specified in hResume itself, that
> 'present' is implied by the absence of a dtend field?
I'm not sure about this. I've wondered the same thing. I am sure someone
knows the answer to this definitively, but AFAIK, "dtend" is not required as
a part of iCalendar specification. I don't see any notes to the effect that
it's any different in hCalendar
More information about the microformats-discuss