Minifootnotes

[active_apathy]

So, I'm at a bit of an interesting step in developing my layout XHTML. In case it's not immediately obvious, the two things I want to take care of with the generated XHTML are that it's easy to style without ever needing to change more than one or two things, and that the code degrades gracefully.

The flexibility is easy enough to build in; you use neat, tidy, minimalist XHTML, with some places built in for fun effects. Then, you write out the S2 so that all the functions that generate the page display are happily decoupled. If people want to change, say, the order of the metadata, they shouldn't need to change the whole function that writes the entries. Further to this, the whole thing is designed as a liquid layout, because it's far easier to make a liquid layout static than it is to go the other way.

With regards to degrading gracefully, I'm not entirely certain how best to linearise the entries (ie, arrange the code so that old/broken/portable/spoken word/other browsers can read the text in a sensible order, and then pushing things back into place with styles for users with modern desktop browsers). Which is why I'm posting this, because that gives me access to the minds of over a hundred users of the Webbernets (plus anyone else who swaggers on over to read the entry).

My current thinking for entry code runs along the lines of...

<div class="entry">1
    <div class="user_data">2
        <img />
        <a class="username"></a>
    </div>
    <div class="datesubject">3
        <h2 class="subject">Entry title</h2>4
        <p class="date">Date and time</p>5
    </div>
    <div class="body_text">
        Whee, the actual text.
        Which is mostly not my problem, yey.
    </div>6
    <ul class="metadata">7
        <li class="tags">Tags</li>
        <li class="mood">Mood</li>
        <li class="music">Music</li>
        <li class="location">Location</li>
    </ul>
    <ul class="links">8
        <li><a>Link</a></li>
        <li><a>Track</a></li>
        <li><a>xyz comments</a></li>
        <li><a>Reply</a></li>
    </ul>
</div>

1. This class is instrumental to how I want classes to work in styling the finished layout. Respecting the DOM and using it to my advantage should save on writing pages of CSS that all do the same thing. But more on that where appropriate.
2. I'm unhappy with this entire <div>, but I'm uncertain how else it could work. Unless, perhaps, the userpic/name and the date and subject were combined into a single unit of post data.
   
3. The entry class looks so much more stylish... now. Many other items will have dates and subjects, so common styles can go in here, and then the CSS can specify something like div.entry div.datesubject {} or div.comment div.datesubject {}, and the classes stay semantically meaningful.
4. The recommendation in the spec is that heading tags - that's <h1> to <h6> for those who don't commonly fixate on this kind of thing - be used to indicate degree of importance. My scheme for that is, at the moment, looking a little like h1 for the journal and page titles, h2 for entry titles (or other appropriate item for that view), h3 for comment headings and h4 for sidebar headings.
5. I'm not sure I like this one being a <p>, but I'm uncertain what else could sensibly be done with it. Most people write CSS selectors without rederencing the tags anyway, which makes it easy to override them later with specificity, and makes the actual tag mostly irrelevant; they're both block-level nonreplaced elements.
6. This one's the easiest to deal with. Again, other things like comments will have body text. A different class name might be sensible, but I'm mostly satisfied with that one.
7. These ones mightn't strictly need classes, but it's easier to have them in there to help describe the structure and content.
8. I'm not happy with that class name. Also, I'm undecided as to whether the individual links need their own classes. It's probably helpful for implementing, say, sprite-based rollover imagemaps or such. And then I need to make up class names that'd be sensible for other people.

So, yes. fun all over. I'd monospace the code snippets in the minifootnote box, but that's more effort than it's worth. Also, you can see an interesting behaviour from the minifootnotes: IE will render the numbers inside the lines, and Firefox will render the numbers outside. I'm not sure how IE7 does it, but footnotes-inside comes from a valid-but-different reading of the spec, so it's not as evil as it could be. With my current layout (itself a fork of Flexible Squares), apparently they both render the same.

Comments

[bending-sickle.livejournal.com]

I have no idea what you're talking about...but love you anyway. Good luck with the layout.

[matgb]

Personally, I like haveing a few more options within markup now I'm making my own. The Wordpress theme I'm adapting has nowhere near enough internal divs and spans for me to move stuff to where I want it, very annoying, means I'm going back into the PHP source and adding bits constantly, and sometimes I miss an implementation for a different display.

What I really like about Expressive/Mixit is that it's got so many wrappers and divs; inners, outers, etc. I can move anything, put a border around an element, a whole column or just one type of bit in one column, very nice. Of course, the borders look ugly in IE, but is it my fault IE still only parses CSS2 when they're doing CSS4 now? I think not.

But I think the order you're putting stuff in is about right. I'd not put the journal subhead at h1 though, h2 or 3. Journal name sjhould be h1 (Mat Bowles) but (Insert Hunour Here) is just an aside reference, a descriptor, and shouldn't have the same prominence. Nice to see the specs are similar to SEO guidance though.

[active-apathy.livejournal.com]

Sprinkling on some extra divs is wondrously simple later, which means I'm not too bothered about it now. At the very least, I want to have separator divs between entries and sidebar elements, somewhere to insert things at the top and bottom of a container, things like that.

I wasn't planning on using a header tag for the journal subheading (or, if I did, it'd be about an h3). The current view, on the other hand, is a high-level description of the page content - whether it's recent entries, the friends page, or whatever else.