Slashdot Mirror

I'm not sure how you missed the point so spectacularly.

Not only is there CSS to do the things people used tables, for, but table has always been an abuse of the semantic intent of that HTML document tag, muddying it and confusing parsers. Yes, HTML could use more tags, but tables are hardly necessary.

And setting aside the semantics, people who actually have to restyle your table layout later (when rewriting the site is not an option) will have every reason to curse you.

The decoupling of the layout CSS offers is a powerful tool.

And, no, web pages are not, and have never been intended to be, mapped to application UIs. Is nice that they can, but that's a very limited case, and not even the main use of web pages.

"Explore the intricacies of HTML and CSS here: http://www.htmlhelp.com/ , http://css-discuss.incutio.com/ , http://www.brainjar.com/ , http://www.htmldog.com/ , http://css.maxdesign.com.au/"
-- ZofBot db

I'm with you, except that I lament that the only way to get the "boxes and springs" tabular model that has been used by pretty much every UI ever invented is to use tables for layout. Which gets you crucified by the web standards crowd. The options that CSS gives you are a sad joke in comparison: in CSS, even creating a layout of three divs in non-overlapping columns is an art. Don't even think about trying to give it rows!

Without attributes, you'd be right. But I can see one use of presentational elements, in a document that uses a microformat within HTML or otherwise uses features of HTML and CSS that not all user agents support. You might want a particular kind of inline element to gracefully degrade to italics in the legacy visual user agents used by a sizable population. For example, <i lang="x-tokipona">nimi mute</i> would mark the words nimi mute as being in toki pona (semantically) and in italics that signify a foreign language (presentationally). Though the same effect could be achieved with a span element and CSS attribute selectors, the still-widely-deployed Internet Explorer 6 doesn't recognize CSS attribute selectors at all, and IE7 still doesn't apply multiple attribute selectors. We are still in the Transition.

But will it blend? And how did we get from Blender to this?

The issue with coding is not compliance with CSS standards (those are well published) but rather in how the various browsers interpret those standards.

The code is standard; the parsing and rendering methodologies are not.

I, for one, appreciate a book that addresses these non-standard behaviors when parsing standard code. The review posted by samzenpus exposes these insights, and contrasts them from the plethora of "standards reference" books. (many from the same publisher)

Sometimes, hacks are the way to do it. (conditional HTML comments, like CSS itself, are only partially effective) It's not that any, given book leads us to write "non-compliant code", (unless you count FrontPage) but that the differences of current browsers in-use require the "non-compliant" variations.

In my book, when the page you create works for everyone viewing it, it is compliant.

And in digging up that link I discovered the tantek hack is apparently valid CSS, which rather undermines my original point! Still, see AvoidingHacks if you like the train of thought anyway.

See "box within a box" at the CSS-wiki discuss page on the box model - as that page notes it's not without it's own drawbacks ("The only issue is that this is done within the HTML markup, rather than the CSS. Many people consider this to be bad practice, because years down the road, when a hack is finally cleaned from your code, a CSS hack is quickly removed, while markup hacks are scattered hither and yon. Plus it complicates the HTML, structurally speaking.") but I personally consider that a lesser of two evils.

1. Floated elements are out of the normal "page-flow". Use a clearfix, or as you stated, an overflow: auto.
2. Why would the height of your right column depend on the height of the left one? See if faux-columns help you better.
3. Ah, I read the rest of your comment, and you don't want to fake it. See the css-D wiki for "Equal Height columns". [1]

[1] http://css-discuss.incutio.com/?page=AnyColumnLong est

It wasn't a 'corporate' effort. See:

http://simon.incutio.com/archive/2006/08/08/ydn

Agreed, that's useful. The disappointing thing is that this is something that web developers can fix, without waiting for browser support, simply by adding a CSS signature to their sites. Usually web developers are stuck waiting for browser support, but in this case they are not and there's really no excuse not to include them.

Ignoring support by ISP's

That's the #1 issue by far. Even if all the competition were ten times better than PHP, if the average person can only find cheap PHP hosting, that's what they are going to use.

I'm not even aware of where I could find documentation on Python libraries to communicate with MySQL

Seriously? Go to python.org. Scroll down the page to where you see the "Using Python for... databases" link. Click it.

There's another point - Python modules come with help built into them, and Python comes with a help browser. And if you don't want to use that, just load the Python interpreter and run help(module). I don't think PHP has anything similar to that yet.

PHP allows you to inline your code into your documents

So does mod_python.

Instead of using some WYSIWYG editor I decided to strike it out on my own and write a page from scratch using the "standards" that the W3C touts.

Writing web pages following the standards is a good thing, but making a complex CSS layout work with some buggy browsers out there is hard. The solution is to not recreate the CSS from scratch, but starting from an already debugged existing layout.
E.g.:

1. http://css-discuss.incutio.com/?page=CssLayouts
2. http://www.dezwozhere.com/links.html
3. http://www.positioniseverything.net/articles/onetr uelayout/

Too many CSS web developers are trying to reinvent the wheel.

CSS3 is still a working draft, there is no point in implementing everything, as it might come changes or that behavoirs for properties change. Currently Gecko supports several CSS3 properties, especially they have implemented support for several css3 selectors.

As CSS3 is still under development mozilla use vendor-specific extentions to those properties. This is not a bad thing, it is also the correct way to implement things according to w3. You can see it is a reminder that you use those propties of your own choice and that they might change over time as they are implemented for testing purposes. Take the opacity property as an example, it was first implemented in Gecko as -moz-opacity, which took values from 0 to 100, later it changed to take values from 0.0 to 1 according to the specs. Now you can use opacity without the -moz- extention as it probably wouldn't change in the draft for css3. So I see nothing wrong in using such extentions for testing purposes, it is much better than what Microsoft does it just adds its own css-properties without any use of vendor extentions.

You cry for better support for standards yet you want them to implement the non-standard "document.all" ? You have to make up your mind ;) If you don't like it take it up with w3 not mozilla.

PHP, like all scripting languages, suffers from having to parse all script files each time a page is displayed.

This isn't something common to all scripting languages. For example, when Python scripts are executed, they are compiled to byte-code, and the result is saved for faster execution next time. Of course, in typical web hosting situations, the web server doesn't have permission to write to the filesystem, but you can quickly and easily compile the bytecode yourself. ASP.NET also compiles once only.

In fact, I believe it's an oddity of PHP that it needs add-ons in order to do this, and I think the next version of PHP will have fixed this. I don't know where they got the idea that all scripting languages must always parse the script on every invocation.

I would like to ask a follow-up question: Do the replacement of tables with div-elements really help anybody (besides giving job security to web developers)?

Note that I am not at all against css. But I just find the table-tag very usefull for layout. If you need to do a three-column layout it will be much easier and give cleaner code to just use a table, than to use one of the many css "hacks" needed to give the wanted result in most browsers. If you want the layout to do something "extra" (eg. "make the center column 400px wide, but allow it to grow if the cell contains a wide image, pushing the right column") it will (probably) be impossible using divs, but trivial using tables.

One reason to not use tables, that is usally given, is that tables should only be used to tabular data and not for layout, as to not create problems for blind users. But just an empty alt-attribte on an image signals to the user-agent that the image is for layout only, a empty summary -attribute on a table could for example be used to signal that the table is for layout only. My guess is that, that convension would be much easier for user agent implementors to use that to parse through all of the css hacks. I also feel that it would be semanticly much cleaner to have a table with one row and three cells than to have three or four divs nested and floated in strange ways.

I've just realised that I was missing one of the sort-of vital components - the URI id extension. This enables you put stuff like body#www-google-com { background-color: #ddf !important; } in the userContent.css file and have it apply only to www.google.com.

And there seems to be an even better alternative built in for Firefox 1.5 and recent Mozillas. Though I haven't had a chance to try this out yet, it looks good.

Yeah, you really can't make a stylesheet for one webpage and have it apply automatically, you can make a style and then apply it, but it effects all webpages that you visit until you turn it off, or switch sheets. Shift + G in Opera 8 turns on/off User style mode. Alt + P, Advanced, Content, Style options... to point to your stylesheet.

You can, however, put all your special styles class and id attributes for every page you visit in one style sheet, but I don't recommend it. It would probably slow down browsing.

You can add your styles to a drop-down list by editing the OperaDef6.ini under the [Local CSS Files] section. But you still have to switch manually.

See my other comments and try it yourself.

Wait, you know, I think some sites put a unique id in the body, but I still think it would slow down browsing if you have too many sites.

Generally, if a page is done right, you can make a generic stylesheet that works for every page, so long as div or span are not replacing everything.

Damn, must remember the Tab key moves me to "Submit" :-)

Take 2:

Assuming you just have a page containing an image having id="myImage" try:

(Or something like that.) Have a look at Centering Block Element on the css-discuss mailing list wiki.

The wiki for the CSS-Discuss mailing list is extremely helpful as well.

http://css-discuss.incutio.com/

I wrote a piece explaining some of the history of Django here: http://simon.incutio.com/archive/2005/07/17/django

Key points: it's not a Rails clone - development started around October 2003 and similarities to Rails are almost entirely coincidental. It's been used on a number of sites: http://www.lawrence.com/ is a good example. Finally, the open-source version hasn't even reached an initial release yet so naturally it's not nearly as polished or stable as Rails. Give it some time!

What with all the concern about the UA string above, and everyone saying using the UA string is dumb, I'd just like to add:

What about all of us "standards based" designers who have to exploit browser bugs for functionality? As far as I'm aware, pretty much _every_ designer who codes for standards (uses Firefox or something to build) and then tests and patches for other browsers (MSIE), we all use CSS work arounds.

**We don't know these will work!**

Will IE7 be fixed with respect to the CSS issues, but still respond to these CSS hacks, or vice-versa (CSS hacks don't work, but CSS is still buggy)?

It is entirely plausible that "standards based" websites will need some work so they render correctly in IE7! Of course, we can't tell until we start testing, which in reality, is true of all web browsers since they all contain a few bugs!

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

What I would like to see is a book that skips all the fluff that we've seen before and goes straight to browser bugs.

Absolutely. There are a million tutorials that will teach you all about CSS in theory, and once you have a reasonable base knowledge you can actually go into the W3C spec itself and dig into the details, but when it comes time to make your pretty new XHTML/CSS2 page work in IE you better have a boatload of knowledge.

After 5 years, and the thankful death of NS4 and IE5 (for the most part), I can debug my XHTML/CSS pages extremely efficient, but good references are still necessary. My two favorites:

CSS-discuss mailing list wiki
&
Position is Everything

Prefetching is one of those things that seems like a really great idea on paper, but doesn't hold up so well in practice.

The problem is that you have things like 'rel=next' that expect the user to go to some next "logical" page, but no structure to a site to encourage that logic. You get people upping bandwidth costs and slowing down browsing time because the site maintainer THINKS they'll go to some next page but the site design actually ENCOURAGES them to go to some other, unrelated page.

In OSS, a lot of the maintainers and coders are just "hackers" or college kids contributing bits and pieces of less broad knowledge over a bigger project team, not real software engineers who have been trained to really think through the consequences of certain design decisions. They don't research their target audience to realize that, while the prefetching feature would be great in a perfect world, the world isn't perfect, and it can really cause problems when so many people are moving from professional browsers to more amateur ones that test out these features in what they THINK is a mainly geek-oriented audience.

I could see why someone at Google might think this is a good idea, but I'd expect that a company with the means to do the necessary research wouldn't go about implementing this kind of hackish "feature set" until it had thought things through a little better.

It would be a lot easier to bring the web to handheld devices if the makers of such devices supported standards consistently or completely. As the css-discuss page on handheld stylesheets confirms, support is often patchy or non-existent.

it is a drag that more website designers dont use css for mobile devices..

this http://css-discuss.incutio.com/?page=HandheldStyle sheets seems like a good resource, id say i would use it ...but none of my user base is mobile at all, maybe ill just do it for my blog :P

Another benefit is that all other user-agents won't even download it. Unless you're putting all your css inline, but then that's just a huge waste. Link your styles in the head and CC out the ie.one(s). No muss - no fuss.

first, basic styles:

<link rel="stylesheet" type="text/css" href="/includes/_css/basic.css" media="screen" />

<link rel="stylesheet" type="text/css" href="/includes/_css/extended.css" media="all" />

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="/includes/_css/ie.css" media="screen" />
<![endif]-->

I lay out in FF and give it a second pass with IE (it is truly joyful to be able to continue checking in FF when i boot into the dark side). And a lot of IE's rules are pretty much obvious from the beginning, so it's not always a complete shock when checking it in that.

OT - I keep seeing these pages where the same bloody css & js stuff is on every page. I figure whoever's put it together thought they were 'templating' because they stuck it in to head.php or something, not realizing that the browser never has a chance to cache (and thus save on both bandwidth and rendering time). All they needed to do is put some link tags in.

If a page doesn't adhere to standards, but renders well in popular browsers, what's the problem?

The problem, IMO, is that you don't know why or why not things render well.

By conforming to standards, you have a (debatably) clear set of rules that define certain behaviours. For example, you will know that if you want to have some number of pixels pad your elements, then you will not have to resort to ugly hacks to get the same layout in BrowserX as you do in BroswerY. Why? Because each browser will reference the rules for adding the specified amount of padding to an element, in the right place, and in the right proportions.

By not supporting standards, you have a number of problems:

1. You can't use the rules to plan your layout, as they may not apply to your browser. So when someone comes up with a nifty idea based on rules, you may not be able to use it yourself.
2. When you do use a supported rule, and it works in a different manner, you may have to adjust your design. This is one of those "it kind of works" situations, which only causes more headaches and confusion.
3. When you do use a supported rule, and it does work in your browser, you will only know that it works under a specific set of cirumstances defined by your instance. Does it really work, or does it work sometimes?

Imagine whipping up a simple page to test out a new design idea in your browser of choice. Everything looks good. Now you try to use it on your production page. Something looks wrong. Is it because you've included it in a tag that overrides your specifications? Is it because you've arranged it next to an element whose properties are spilling over into your space? Is it because you tested it inside of a tag, for which the specification holds, but have erroneously tried to apply it to a tag that does not support it? How will you know, unless your browser developers tell you -- assuming they know themselves?

For me, that's why CSS is useful. For the most part, it's pretty clear as to what things support what attributes.

Since your post was originally about Slashdot's (non-)adherence to CSS and other web standards, here's one major incentive to switch over: bandwidth. Does anyone really like throwing money away?

• Use the GIMP for image processing. Cost $0.00
• Go over to the CSS discuss Wiki to get lots of great example CSS, freely reusuable. Cost still $0.00
• Make sure your site looks acceptable with Internet Explorer's awful CSS. Cost: $0.00 if you have a friend with Windows, or go to the local library to look at the site. Otherwise $Bill_gates_tax
• Viola. You have a great looking site.

(Actually, I still use tables for basic layout because IE doesn't support max-width and min-width for CSS elements sizes; this can be somewhat hacked around with <td width=whatever>.)

• http://css-discuss.incutio.com/
• http://css.maxdesign.com.au/
• Layout-o-matic
• firdamatic
• http://www.quirksmode.org/index.html?/css/condcom. html
• http://www.devguru.com/Technologies/css/quickref/c ss_index.html
• CSS Quick Reference
• 181 Manually selected references

With the tag applied to all links in the posts, useful sites will not get a good search ranking even if they may deserve it.

You can get around that by removing the rel attribute for people who authenticate against their provided email address.

PS: It's not a tag, it's an attribute value.

This is another strategy invented by Simon Willison on his weblog, and followed by google a few months later. By the way, spammers don't care. I set it on my weblog, including HTML disable ; and it's still attacked by spammers.

This is another strategy invented by Simon Willison on his weblog, and followed by google a few months later. By the way, spammers don't care. I set it on my weblog, including HTML disable ; and it's still attacked by spammers.

• CSS Wiki! - + - this is extra copy so this would post
• Centering advice! - + - this is extra copy so this would post
• Centering advice! - + - this is extra copy so this would post
• Fix crappy MSIE support! - + - this is extra copy so this would post
• tips, tricks and good practice techniques! - + - this is extra copy so this would post
• Box model Illustrated! - + - this is extra copy so this would post
• links collection! - + - this is extra copy so this would post
• links collection! - + - this is extra copy so this would post
• links collection! - + - this is extra copy so this would post
• Tutorials, Demos, and Hacks! - + - this is extra copy so this would post
• Best Practices! - + - this is extra copy so this would post
• Best Practices Crib Sheet! - + - this is extra copy so this would post
• Best Practices! - + - this is extra copy so this would post
• Holly Hack! - + - this is extra copy so this would post
• 3 pixel hack! - + - this is extra copy so this would post
• Firefox webdev plugin! - + - this is extra copy so this would post
• Mozilla CSS editor! - + - this is extra copy so this would post
• Debugging Advice! - + - this is extra copy so this would post
• Page Building Process! - + - this is extra copy so this would post
• selectutorial! - + - this is extra copy so this would post

Lists

• listamatic 2 (nested lists)! - + - this is extra copy so this would post
• listamatic! - + - this is extra copy so this would post
• listutorial! - + - this is extra copy so this would post
• Piped List! - + - this is extra copy so this would post

Floats

• floatutorial! - + - this is extra copy so this would post
• float-theory! - + - this is extra copy so this would post

Filtering

• Explorer! - + - this is extra copy so this would post
• safari filtering! - + - this is extra copy so this would post
• filters! - + - this is extra copy so this would post

Type Issues

Browsercam is a good resource. Of course, you can't test functionality with it, but your layout is where you will run into the most browser bugs.

Ultimately, the best route I've found is to stick like glue to the standards and don't use nested tables or rely on Javascript.

As long as you stick valid HTML 4.01 or XHTML and CSS, the rendering bugs for IE5+/Win and IE5+/Mac are pretty well known. Older browsers can easily be sent plain text or minimal styling with media or @import hacks. Spend a lot of time lurking on the CSS-d mailing list.

Where do you find out about the "well-known" rendering bugs? There are a ton of sites out there about them, but I like PositionIsEverything and the CSS-Discuss Wiki.

How can you not find arbitrary remote code execution from a web browser highly critical? It meant that if a bad guy hacked a website popular with Mac users, they could take control of many machines potentially without their users noticing - just like the problems Windows has.

Why would you ever be hired with that attitude? The fact is, all the IE moaning is a BIG MYTH.

While I agree with you that one has to make pages work with IE; allow me to say that you are talking out of your ass.

My sites always have the proper DOCTYPE, they have to in order to validate (I validate all pages prior to posting). Sometimes _having_ a doctype makes IE show new bugs.

Frankly, unless you're building some fancy site with the absolute latest CSS and Javascript features, IE will render your page *just fine*.

Your sites are obviously _very_ basic with minimal design. The moment you pass into medium complexity you start running into problems. I don't use any Javascript.

Yet, why exactly do you need to be using 32-bit images on your page? It's quite easy (and beneficial for download speeds) to get by with 8-bit images.

We need 32 bit images in order to have variable alpha. If you don't have variable alpha, then you can't have any image without including the background it's going to be over.

Including the background in your image completely negates the advantage of declaring colors in the CSS. Normally I could change the background of my site by changing one line, now I have to change all images as well.

There's other reasons why you might want a variable alpha, say to have transparent graphics or windows (the navigation on the left). Which are not heavy as the image is just 2 x 2 pixels and weighs in at a hundred bytes or so. In fact there are tons of creative uses that people haven't even thought of.

and tell me why they play such an integral part of your development process that you cannot find a way around them.

You're missing the point entirely. The idea is to allow the designer do her thing (so I can get a beautiful unique website) and then translate that to CSS, compromising wherever needed; not just half-assedly add some design to a text document.

However, when one tries to do anything remotely interesting, Explorer completely dies on you.

The best solution I found so far is using IE conditionals and serving IE a different and sometimes strange CSS file. In the end I usually figure it out reasonably, but it takes ridiculous amounts of effort and the site is never as good as it's Safari/ Mozilla /Opera counterpart.

If you want an example you can look at my current site (I linked it above too), I've only starting the IE fixing, you can see the ugly IE file with filters: and other weird junk so that PNGs show up with alpha: here. So far it's taking a serious effort and even when finished won't look as well anyway. Look at it under both IE and then Firefox.

This foils PageRank in some ways (after all, valid comments with links should increase the rank, at least some of the time). It would be a shame to do the same with all Wikis. Otherwise more onerous authentication may be necessary, which is also against Wiki principles (though common in Wiki implementations). Or some vetting, perhaps using this PageRank-fooling measure until the page changes are approved.

Well, the designs do work and most browsers, but many of them rely on various hacks and workarounds to display correctly on all browsers, and even the most standards compliant browsers on the market have bugs. This means that developing cross-platform CSS is a lot more work than it should be.

But the CSS Zen Garden is definitely an amazing ressource, and discovering it was what helped me kick the tables-for-layout habit.

The help text was just an example. What about the technique that presents a single page as a series of tabs, or the related technique of presenting a long form as a series of pages? Search engines should certainly take that text into consideration.

Unfortunatly supported CSS in the browser and the printer engine isn't the same thing, there are lots of bugs. Progress on IE is practically discontinued, (don't expect microsoft to produce an XML-aware printing engine that can replace Office), and it's not an area where Mozilla advances very quickly either.

However if you find a simple form that suits you and can manage users changing margins etc. it can do just fine. XHTML table headers could be a simple and effective way to get multi-page layouts.

Doing a bit of Googling for people with similar ideas I came across the following blogs:
http://simon.incutio.com/archive/2003/07/17/theGoo gleBrowser
and http://www.dashes.com/anil/index.php?archives/0067 26.php

If you like this idea (or even if you don't) blog about it and give your views on it. Let as many people see the idea so we can get the pros and cons discussed.

<aol />

I was going to suggest MySQLFront, but you beat me to it. :-)

When I first started using MySQL a few years ago, I wanted to find a nice GUI front end for it, partly because relational databases are designed to hold tables of data, and I just think it's nicer to have that data presented as something looking like a spreadsheet application rather than ascii in a console. Sometimes, GUIs are just nicer tools, and for me this is one of those cases.

More importantly, I wanted to set up the company database so that other staff could work with the system in a way roughly resembling Microsoft Access, which was being used by some people in other contexts -- but I didn't want it to acctually be Access (if only to make it clear that this wasn't just something running on their desktop), so that ruled out ODBC.

Of all the many MySQL GUIs I found -- this would have been 2000 or so -- none of them was half as well done as MySQLFront. It was small, fast, attractive, and functional. The others either had clumsy interfaces, were ugly Tk monstrosities (if ugly & broken is the price to be paid for portability ...portability isn't so important), or just couldn't do certain things with the database. MySQLFront was a dream compared to the others.

Unfortunately, for some reason, the guy developing it, Ansgar Becker, abandoned it abruptly in the middle of 2002, and it got very hard to find copies of the application after that. The last version released was 2.4 or something, but copies of 2.5 turned up, and that was it.

And that makes the current status of MySQLFront very confusing -- all of a sudden, the site is offering downloads of version 3.0. Where did this come from? Is Ansgar involved again? Did someone get their hands on the source code? I don't get it....

Actually, answering my own question, it looks like his website explains all -- in German:

Im November 2003 fragte mich N. Hoyer, ob er den Namen "MySQL- Front" ubernehmen durfte. Nach ein wenig Hin und Her schlug ich dann ein. Ab diesem Zeitpunkt steht MySQL-Front in einer vollstandig neu entwickelten Version 3.0 zur Verfugung. Die Websitewww.mysqlfront.de ist weiterhin die Anlaufstelle fur Download, Forum usw.

According to Babelfish,

In November 2003 N. Hoyer asked me whether he might take over the name "MySQL front". After a little back and forth I hit then. Starting from this time MySQL front is available in a completely again developed version 3.0. The Website www.mysqlfront.de is further the approach place for Download, forum etc..

So I guess it's a new application under the same name?

In any case, it's alive again, and that's great. It's a shame that it's Windows only, but this really is by far the best graphical MySQL frontend that I know of, and I've tried many. If the new developer[s] wants to, or the source gets opened, maybe we'll see versions of it for Linux and Macintosh some day. But just having it revived on Windows is great news...

Simon Willison recently described a method, not to stop comment spamming, but at least deny spammers to Google Pagerank counts. Check out the full post here.

Jeremy Zawodny on this:

SMTP Sender Authentication, Blog Spam, and PageRank
Cheap Viagra, Vicodin, Xanax, Prescription Drugs, and Penis Enlargement Pills!!!
Gureilla Tactics Against Blog Comment Spammers

Russell Beattie on this:
Googler Comments

Simon Willison on this:
Battling Comment Spam
Banning Google Comments

Michael Fagan on this:
Seven Ideas for a Spam Free Blog

Scott Johnson on this:
A Possible Blog Comment Spam Solution

Jeremy Zawodny on this:

SMTP Sender Authentication, Blog Spam, and PageRank
Cheap Viagra, Vicodin, Xanax, Prescription Drugs, and Penis Enlargement Pills!!!
Gureilla Tactics Against Blog Comment Spammers

Russell Beattie on this:
Googler Comments

Simon Willison on this:
Battling Comment Spam
Banning Google Comments

Michael Fagan on this:
Seven Ideas for a Spam Free Blog

Scott Johnson on this:
A Possible Blog Comment Spam Solution

Jeremy Zawodny on this:

SMTP Sender Authentication, Blog Spam, and PageRank
Cheap Viagra, Vicodin, Xanax, Prescription Drugs, and Penis Enlargement Pills!!!
Gureilla Tactics Against Blog Comment Spammers

Russell Beattie on this:
Googler Comments

Simon Willison on this:
Battling Comment Spam
Banning Google Comments

Michael Fagan on this:
Seven Ideas for a Spam Free Blog

Scott Johnson on this:
A Possible Blog Comment Spam Solution

• Jay Allen's MT-Blacklist" plug-in;
• Simon Willison's Blacklisting Comment Spam;
• Scripty-goddess' Anti-Comment Spam Tactics;
• BurningBird's Comment Spam Quick Fix;
• Kalsey Consulting's ideas on dealing with Comment spam; or
• even my own observations and suggestions on the topic

A static/fixed width layout isn't a bad thing, depending on when it's used. And I'm sure the people at CNet thought about the pros and cons of a liquid layout in their design process.

For a text-heavy site such as News.com, a fixed-width layout is very ideal. If you happen to have a very high resolution, the text in a liquid/expanding design would run past the optimum line length of about 60 characters or so. Sure, you can have the browser sized to a reasonable size, but it's an added hassle. With a fixed-width website, however, the line length is much shorter. Your eyes won't get as tired from traversing the whole width of a page in a liquid layout.

It's also the same reason why newspapers run multiple narrow columns, rather than having it go across the whole page.

As a side note, Simon Willison has a nice Narrow Bookmarklet that lets you convert a website's liquid design to a fixed 500 pixel width page with one click.

The UK government does seem to be slowly wising up. There are two MPs that have blogs, and there was a recent survey on the accessibility of the websites of companies that fall under the DDA.

This has been filed as a feature request with Moz, but is ranked as very low priority: see bug 41975.

A possible hack to get around all this would be if CSS attached a pseudo attribute to all elements specifying the page URI. This would allow you to use the CSS2 specification stuff ( e.g. [obj_uri~='gamespot'] ) to solve the problem.

If you want something that works on the fly, I think it can be done building a bookmarklet that executes javascript to embed CSS... small reference here. I had a much better page, but I can't find it now, sorry!