Millennium

Actually, the latest IE7 hack adds partial support for :before/:after/:content in IE. Apparently it’s still a bit shaky, though.

The ins tag doesn’t really do anything by itself. It just means that this text was inserted in some previous revision of the text. It has a counterpart, del, which means that the text has been deleted (or is going to be deleted soon).
You can style this with CSS to do whatever you want, of course. For example, some people like to stick a border-left of a different color onto paragraphs inside an ins tag, to call readers’ attention to the fact that there’s new text. On the flip side, it’s pretty common to put a line through anything inside a del tag.

Perhaps more to the point, why would including, for example, Gemini or Trident as the default “encourage innovation” any more than Kubrick would? How does the default encourage innovation, other than by the fact that many people don’t seem satisfied by it? Does Kubrick discourage innovation simply by being good, and even if so, then what is the problem with that?

It looks to me as though Kubrick as we currently know it will not be going into WordPress 1.3. They seem to be forking it, in order to try and get rid of the current technical problems people are having.
I’m curious, though; why would Kubrick-as-default “stifle innovation” any more or less than any of the current defaults?

To Millennium: I just find it easier to work on one file than two. It makes more sense to me to have one file for a template instead of two. In Blogger you can just paste your template HTML into the editing page, republish and it’s done.

What are you talking about? Despite the fact that the “template” is HTML, that’s really a misnomer. You only need to work on one file to alter the look of your site unless you’re really doing something drastic: the CSS. Leave the HTML alone; you don’t need to edit it unless you’re using plug-ins or have some kind of fundamental design change to make, and even if you have a fundamental design change there are pre-made HTML “templates” for the most common patterns.

I know a little bit, like what you need for taking underlines off links and coloring the scrollbar, but separating the CSS file from the HTML is too confusing to me…

Why? This is an honest question. HTML for structure, CSS for presentation: how is this more confusing than mashing them together?

The CSS Zen Garden shows what people who are great at CSS can do using only CSS and it’s not much help to us lesser mortals who’ve only just about mastered HTML.

I’ve often wondered if people are learning Web technologies backwards nowadays. Perhaps CSS should be learned first, and then HTML? It would probably reinforce the concept of semantics much better.
Of course, in order to do that you need some kind of “training wheels” structure language. Perhaps an extremely minimal set of HTML would work for this?

I was thinking about moving away from Blogger but the requirement to learn CSS has really put me off WordPress. I don’t have time to learn that, I just want to blog ??

You can learn the basics of CSS in an afternoon. Once you’ve got that the rest is easily picked up as you need it.

Why are CSS properties “no fun” to edit anyway? Just edit the CSS; by doing so you can emulate pretty much any layout you want. The CSS Zen Garden shows how much you can do using only CSS, with no changes to the HTML at all.

They are lists, and so they are marked up as lists. That’s what semantic markup is all about. If you don’t like the way lists look, then make them look different. It’s not hard; a little CSS is all you need, and then you’ll have them look like whatever you want while still being what they really are: lists.

It has generally been considered that the output of a GPLed program is not bound by the GPL (though the author may, of course, GPL it if he or she wants to). This is why, for example, GCC can be used to compile non-GPLed works.
When your blog is displayed in a browser window or downloaded with wget or whatever, that is the output of a GPLed program, WordPress. Because it’s the output, you can license that however you want; it is yours.

Why not? “Semantic elegance.” Ps define paragraphs, so paragraphs should be put in Ps. A list is a list, a paragraph is a paragraph, etc, etc.

TheJason hit it right on the head. P tags mean something, and they should be used whenever that meaning applies. DIV tags don’t mean anything -that’s the point of DIV tags- and so they should be used only when a more suitable element (one with meaning) is not available.
It’s sad. Back when people wrote by hand -or even with typewriters- they thought about what things meant when they wrote. Nowadays, all they care about is what it looks like, without realizing that you can get both meaning and looks at the same time. All you have to do is think about meaning first, and then deal with looks.
Ahem. Either way, what dogfood wants to do could probably be provided via a quicktag; perhaps something mimicking the old FIG tag that was proposed for HTML some years ago? Something like the following:
(figure src=”url-of-image“)caption-goes-here(/figure)
Translate this in a quicktag to a DIV tag floated and padded appropriately. This would contain a block-style IMG tag with the src provided, and the caption above or below that. Another way to do this would be with a two-row table, one row containing the image and the other row containing the caption, but the semantics of this are dubious (though not completely invalid; a figure and its caption could be said to be a form of tabular data even though it doesn’t quite follow the typical HTML model of a table).

If you make changes to a GPL’d program and distribute your modified program, then you must also distribute the changed sources.
There are several ways around this:
1) Do not distribute your modified WordPress for download at all. Although this is generally considered to invite bad karma by the Open-Source community, it’s legal. Use it only on your own site and don’t let others download it.
2) GPL only the code that you’re including in WordPress but keep the copyrights for yourself (i.e. don’t assign them to the FSF, as they suggest). This is not the cleanest way of doing things, but you can incorporate your own GPL’d code in your own non-GPL’d products. Again, this is considered bad karma, but since you’re including your own code in your own code, no one can stop you. If you choose this route, though, be VERY careful that no code from WordPress leaks back into your other project; I can guarantee that people will be watching you like hawks over this.
3) LGPL only the code you plan to include in WordPress, and put the rest of your other project under whatever license you want. From a legal standpoint this is much cleaner than the previous option, because you’re not breaking your own licenses (not that it’s illegal to do that, but it gets rather messy).
I would suggest either Option 1 (if you’re adamant about not sharing any of your own code) or Option 3 (if you don’t mind helping out WordPress but don’t want to share this other project of yours). From a design standpoint, if you choose Option 3 then I strongly suggest wrapping your code in a WordPress plugin rather than incorporating it directly into the WP code; this makes things even cleaner because they probably won’t want to include your code in the core WordPress distribution, and this way you won’t have to keep patching the WP code every time they release a new version.

It’s only an FC, anyway; my guess is that the real release will be out in about two weeks. As others have noticed, they haven’t even changed the version number everywhere yet.

Reducing the size of the content is also doable, using font-size: 50% or something like that. The 8-up printing is more of a challenge, though.
What OS are you using? At least on OSX, you can have the system print 1, 2, 4, 6, 9, or 16 “pages” per sheet of paper; if you do that, then all you need to do is stick a “page-break-after:always” after each entry in your print stylesheet and hide everything outside the content; the OS will handle the rest. It’s not eight pages per sheet like you’d hoped (and it seems odd; why 6 and 9 but no 8?) but it would get the job done.

The best part of blog-independence is that the pages don’t use the blog software. However, that’s also the worst part of blog-independence. The pages don’t need the software to work, but at the same time they don’t respond to changes in the blog software’s design; you have to go back and edit the static pages by hand.