In article <Xns97568535ABCC9jkorpelacstutfi@193.229.4.246>,
"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:
[color=blue]
> Eric Lindsay <NOSPAmar2005@ericlindsay.com> wrote:[color=green]
> > <html lang="en"> (not styled as I use HTML 4.01 Strict)[/color]
>
> I'm not sure I see what you mean by styling here. But the tag is OK, for
> dominantly English-language pages, assuming that you do not wish to
> distinguish between "en-GB", "en-US", "en-AU" (which is quite understandable
> since among the few programs that recognize lang attributes, some don't
> recognize anything but a value with a simple primary code like "en").[/color]
On styling, I was meaning avoiding any classes applied to <html> and any
CSS like * html { ... } and applying any of these via the <body> tag.
This was purely because of using HTML 4.01 Strict instead of XHTML.
I was tempted by "en-AU" since some of my text deliberately contains
Australian vernacular, however an earlier discussion in this group
convinced me it was better to stick with just the primary code.
[color=blue][color=green]
> > <body id="css-signature" class="thisfolder thisfile">[/color]
>
> I can see the points behind this, but I don't think they are very relevant.
> And instead of a class like "thisfile", I would you a file-specific style
> sheet, referred to via a <link> element, or (to be honest) even a <style>
> element.[/color]
I was (and still am) uncertain that I want to include a class like
"thisfile". However I was mindful that since any CMS I write will be
aware of the folder name and the file name, both seemed a convenient
"hook" for styling. I already use folder specific CSS files, which do
all the styling. What I was hoping to do during my rewrite was to
abstract much of the site CSS to a site specific style sheet. As my
site grew rather organically, it is still too disorganised to do so
until I rewrite.
Interesting that you suggest the pragmatic approach of just using a
<style> element instead of a "thisfile" hook. I somehow picked up the
idea that using a style element like this was not the approved method.
Since almost the only thing I can see wanting to do with the "thisfile"
hook for every file is to identify the current location in the
navigation, using a <style> element would probably be just as easy.
[color=blue][color=green]
> > <div id="maintext">
> > <h1></h1>
> > <p class="first"></p> (special treatment)
> > rest of main text, with appropriate h2 h3 etc.
> > </div><!-- maintext closed -->
> >
> > <ul class="nav"> ... </ul>
> > <ul id="header"> ... </ul>
> > <ul id="footer"> ... </ul>
> > </body></html>[/color]
>
> Looks fine, assuming that the header is really meant to be there in a non-CSS
> presentation.[/color]
I am anxious to have my h1 and other headings, and my main content first
in the page, right after the <body> tag, since this seems to help make
search engines happy. Hence the "header" is fairly low in the written
page. I put the "header" back where it should appear with
position="fixed".
[color=blue]
> Logically, class="first" is not needed, since you can use contextual
> selectors instead. But since IE does not support such fancy selectors as
> h1 + p or p + p, there's a good practical reason for using the class,
> if you intend to do some paragraph styling like "literary paragraphs".[/color]
"Literary paragraphs" were indeed why I wanted to target the first
paragraph. While I had read of contextual selectors like h1 + p, I
didn't have any experience of using them. Thank you for pointing out
that they are a valid way of replacing "first" (except for IE).
[color=blue]
> On similar grounds, you would not need id="maintext" if you used the pattern
> consistently on all pages. You could use e.g. body > div (or, to guard
> against some modifications to your pattern, body > div:first-child) to refer
> to a div element that is a child of body (or the first child of body).
> But we have IE, and we could also argue that the logically redundant id and
> class attributes may serve as comment-like notes about the markup structure.[/color]
I was actually (unconsciously I guess) using div id="meaningful" as a
way of commenting the markup structure. I also used </div><!--
meaningful closed --> to indicate the end of specific divs, although if
a </div> was ever missed or done twice, the comment no longer had any
meaning.
I must admit I also have a bit of an eye on the development of my CMS,
which is only a series of Bash scripts at the moment. Having particular
content between meaningful tags would make it much easier for me to use
sed to edit files. I am particularly thinking of the scripting
potential for incorporating comments and emails into a static site, in a
similar manner to the way blogs work (except I want human oversight
before comments get passed along to the script).
Thank you for your thoughtful comments Jukka. I have an experimental
page up at
http://www.ericlindsay.com/palmtop/palmnote.htm
While the CSS is still very rough, I think I am gradually finding how I
want the HTML to go (while still keeping it sufficiently simple for me
to mostly generate with scripts). The page works fine with HTML only
browsers (a significant part of my PDA using audience), and with modern
CSS browsers. It breaks in IE, but that is an entirely separate problem
which I will try to address with a conditional comment. Also there are
several (PDA, and Apple specific) parts of my site where I don't care if
IE breaks.
--
http://www.ericlindsay.com 
Simplicity in HTML structure 
