Greg Laden's Blog

I think the new layout bites. With the old layout I could open different blogs in new tabs. Not any more. I wish they would go back.

Posted by: pete | January 27, 2009 10:11 AM

Since I usually use Google Reader to check the blogs, I have no clue what the difference is with the front page. But after taking a look, I'd have to agree with the first commenter. When the list of blogs were links, you could open them in tabs, but that option is eliminated with the dropdown automatically opening the blog. The new functionality is great if you're drilling directly to one blog, but it is too restrictive with regards to different users browsing habits. I would recommend that the dropdown stay and that the links be added back.

Posted by: CyberLizard | January 27, 2009 10:42 AM

There seems to be no support anywhere on any page for mobiles.

Posted by: Andrew | January 27, 2009 11:15 AM

Didn't know the drop-down was there. Still sucks. Have to go to one of the topic pages to find the list again (for the same reason others have noted - tabbed browsing. I hate it and won't use it. Have to change my start point if they keep it.

Posted by: Rocky | January 27, 2009 11:50 AM

Well, not bad as far as basic visual layout goes, but there are some issues.

The page can't be validated because the stated character set (utf-8) is not used for the encoding of the "Most German" links. (Someone has some work to do on displaying that text.) If you increase the text size (in Firefox, at least), the layout is completely screwed (entire right column drops below the main content - this doesn't happen on the individual blog pages). Serious styling issue (CSS) with the subscription box at the top right. That section also has a level 6 heading (H6) which is very inappropriate for the document structure. Some other heading levels are skipped throughout the document. I think someone chose them based on the "look" rather than a semantic context.

Somebody there at SB needs my help. *grin*

Posted by: Dan J | January 27, 2009 1:56 PM

I like it just for the links to blog categories along the top of the page - for one thing, it means less editing to do when I periodically scrape the blogroll in the left-hand column for my local homepage - and that 'channel' page reads like http://news.google's text mode, so it's a pleasure in lynx.

Posted by: gruebait | January 27, 2009 7:23 PM

Well, I think it's less the "designer" than the person implementing that design with the XHTML and CSS. They're having to pull information from myriad sources and include files, and they're not all done as thoroughly as hoped. There is a problem with text (that's supposed to be inside a link) overflowing onto the right column from the link to Blog Around the Clock. The button for the newsletter form at the top is half-hidden, dropping below the bottom of its container, and it's also flush left in that container, unlike the rest of the content. The "Rightful Place Project" isn't quite positioned as the rest of the right-column content: needs a little more margin on the left.

This is in Firefox 3.0.5 in Linux (64-bit).

Posted by: Dan J | January 27, 2009 8:16 PM

Something that I frequently do, that I'm sure most people don't, is to look at the HTML source of web pages. I've never really done that with Scienceblogs.com before today. What I see is not pretty. The home page itself is bad enough, and the blogs themselves have more problems.

Yes, it works (to a certain extent), but it's definitely not up to standards. The pages are full of errors and non-semantic markup. The content-type meta tag is needlessly duplicated in the individual blog pages. Using tags like and for bold and italic is no longer seen as a good way to do things. Those tags imply the "look" of the text, not the "meaning". It's preferable to use and to imply "emphasized" and "strong" text, which can be displayed in any manner suggested by the CSS (defaulting to italic and bold, respectively). The accessibility of the pages isn't good at all. Without javascript, many functions of the site simply disappear, rather than having a viable alternative presented.

The inline CSS here on Greg's pages (borrowed from PZ) should really be moved to an external style sheet. It's eating up bandwidth that isn't necessary. (Personally, I prefer the styling used in that CSS compared to Scienceblogs.com's default styling.)

I could go on, but it's late and I'm off to bed. Let's just say that as I see it, the Scienceblogs.com XHTML has a very long way to go.

Posted by: Dan J | January 27, 2009 11:39 PM

Although I personally use (out of habit) 'em' and 'strong', I don't understand why 'i' and 'b' are wrong. If a writer wants it bold, it should be bold, and any post hoc rethinking by CSS sheet is not good.

Especially in science, where, for instance, species names are supposed to be italicized, not 'emphasized'.

The use of the 'b' and 'i' tags is not wrong, per se, but let's say that it doesn't conform to one of the primary goals of XHTML, which is the separation of content and presentation. The XHTML markup should signify the type and structure of the document's content, while the presentation of that content is the sole responsibility of the CSS (though the browsers have default presentation attributes for each type of content).

For content such as the species name, take the following example:

Australopithecus anamensis, Australopithecus afarensis and Australopithecus africanus are among the most famous of the extinct hominids.

The species names should be italicized, per common convention. How best to do this? You could surround each name with an 'i' tag, rendering the italics suitably. What does this suggest to a machine parsing the document? Nothing. You could use the 'em' tag, which by default will render italicized, but (as you suggested) you aren't really emphasizing the names, just setting them apart, as their content is distinct.

My preferred method would be like this:

'span class="species"'Australopithecus anamensis'/span', 'span class="species"'Australopithecus afarensis'/span' and 'span class="species"'Australopithecus africanus'/span' are among the most famous of the extinct hominids.

And in the CSS:

span.species {font-style:italic;}

This would indicate that the text within that span has a special class, 'species', and the CSS indicates that it should be rendered as italicized.

Does this make more sense? I suppose to most people it really doesn't make any difference, as they see the same thing on their web page. To a machine parsing that text, be it a screen-reader or a search engine spider, the text takes on special meaning because of its content and context, not because of its presentation.

Posted by: Dan J | January 28, 2009 11:24 AM

However, this leads us to two other problems that is ignored by the XHTML and CSS based standards:

1) If all contributors of text have to understand XHTML standards, then writing on the web becomes a restricted and/or elitist activity; and (not unrelated)

2) People writing comments in or blog posts who do not control CSS are forced to either not have access to certain conventions at all or to cheat with incorrect, non standard, or depricated code.

This is (in my opinion) the really big barrier to self-publishing on the web for the masses. Most blog software includes an editor such as TinyMCE for WYSIWYG page generation. Unfortunately, these editors are rather generic. They allow the person editing the post to select various types of content, but often don't present this content in the way intended, or using XHTML that does not conform to standards. This is a problem endemic to many web page editors, though many improvements have been made in the past couple years.

The ability to specify classes for specific tags is often included in the editors, but what about the associated styling? The author of a science article should not have to be an expert in XHTML/CSS in addition to their primary area of study.

For a site such as Science Blogs, there are many instances of specific classes of information that are routinely used within the blog posts. Perhaps each of these types should be identified, and a consensus reached as to how each should be presented. Then these classes would be specified in the CSS, and a "cheat sheet" presented to the blog authors to let them know which classes are available for their use. Better yet, the WYSIWYG editor could be customized to allow these types of items to be selected at the click of a button. How about a "scientific edition" of the editor in use?

Posted by: Dan J | January 28, 2009 5:11 PM