Tag Archives: CSS

Cascading Style Sheets (CSS) and PHP

Posted on by
Reply

Often when dealing with Cascading Style sheets, or CSS, I find myself wishing that the CSS mechanism included variables. This is especially true when dealing with colors, since you want the same color applied to lots of different things. It can be a real pain to go back through an old style sheet and find the code for the color you want. I was quietly surprised that no one making up how CSS worked had addressed something like this.

Then, a while back I was giving a buddy of mine a few exercises to introduce him to the exciting world of Web programming, touching on CSS, HTML, PHP and MySQL. I gave him pretty much no guidance; I just thought up plans that would introduce him to the concepts and gave him a list of my favorite references. (I’ll be posting those exercises here in the nearish future.)

Anyway, without me to tell him how to do things, he went and dug around and one of the first style sheets he sent me for evaluation had a .php extension rather than .css.

Bingo! Once you see it in action, it’s obvious. PHP can be used to generate CSS files just as easily as it can be used to generate HTML files. Now my style sheets can change based on external conditions or can simply define a set of colors that all the style definitions share. Why did it take me so long to figure this out? It seems like this technique should be a lot more common than it is.

Here’s a quick code snippet for those who want to try it for themselves:

<?php
	header('Content-Type: text/css');
 
	$header_back_color = '#dddddd';
?>
 
#corner_table th {
	background-color:<?php echo $header_back_color ?>;
	text-align: center;
}

A couple of notes: the <?php MUST be the very first thing in the file. No empty lines, no spaces. The reason is that the next line, with the header() function, has to be called before the server sends any page content. (Once the server starts sending content back to the browser, it’s too late to be fiddling with the headers. Any whitespace outside the <?php tag will be considered content.) The header line is necessary because you need to tell your browser that what you are sending really is a css file.

In the <head> of the html file, you call the style sheet just like normal, but of course the file you fetch will have a php extension:

<link rel="stylesheet"
      href="http://yourdomain.com/css-tables.php"
      type="text/css"
      media="screen" />

That’s all there is to it. Why have I not done this with every css file?

Thanks!

Filling a Need

Posted on by
1

I dragged my sorry butt out of bed just before 7 a.m. Big meeting. I put on my fuzzy bathrobe and plunked down in front of the computer while my sweetie made me tea. Then she went back to bed. We stayed up way too late last night.

Skype lit up and away we went. The meeting was more about my employer and the evolution of their corporate character than about technology, deadlines, or the transient issues of the day. How do you make a company run smoothly when you span from San Jose to Moscow? How do you make sure everyone is having a good time while you’re at it?

At one point in the conversation I was asked for bio data for my employer to put up on their Web site. I thought I would throw them a link to the bio page here here first, as a joke and also to let them learn a little more about who I am (or who I want to be, at least). I popped over here and saw… that this site had been suspended by my Web host. I checked my email. No notice. I checked my account on MMHosting’s site. Suspended, no reason given.

Some Mondays are Mondayer than others.

I sent off an urgent help request and spent the rest of the day bouncing between databases, php server code, and Flex client code, generally trying to be smart enough to deserve what they are paying me. Eventually I got a message back from MMHosting.

First, they said they had in fact sent an email. I searched everywhere I know how to search, and I couldn’t find it. No matter; they also turned the site back on. The guy said that some of my php files (code that runs on the server and builds these pages) was loading bazillions of times and slowing down the server. Uh, oh! Looks like some plugin I’m using ran amok. The people sharing the server with me probably weren’t happy.

That’s what I thought until I started looking at the numbers, anyway. Runaway software? Not at all! It turns out this table I wasted way too much time on got mentioned in a prominent place, and twitter and digg took care of the rest. When you look at the graph, remember that the site was down for much of the time during that traffic spike. Holy Schnikies!

Traffic for the last month. The bulge at the beginning is from Cyberspace Open traffic. Things have been slow since I started working - until today!

Traffic for the last month. The bulge at the beginning is from Cyberspace Open traffic. Things have been slow since I started working - until today!


I really did put a lot of work into that dang table, so I’m glad people are picking up on it. Maybe there are other CSS3 features I could tote up – transform and shadow come to mind.

Boy, I sure wish I had a killer episode at the top of the blog to hook some of these visitors. Oh, well.

1

Thanks!

Rounded Corners and CSS3

Posted on by
3
NOTE — June 7, 2010:
This page is a little out of date; the main Webkit browsers now work better with NO prefix on the styles. It’s time to say goodbye to -webkit-. In the following discussion, using the standard syntax will work with Chrome, Safari, and Opera as well. The table referenced below has been updated to reflect the newer browsers.

If you poke around this site you will see boxes with rounded corners. If you use Safari or Firefox, you will see even more.

Rounded corners are implemented here in two different ways. The main boxes with the drop shadows are done the old-fashioned way, the way that works on most browsers. Each corner is a graphic with an alpha-channel shadow, and the edges are yet more graphics, repeated as needed to span the distance between the corners. The boxes expand and contract infinitely in both directions. It’s not bad. It’s also a pain in the butt.

Yet, I like rounded corners. They seem friendlier. I have broken down, therefore, and in a few places I have added browser-specific style information to create a softer-feeling blog. Since the rounded corners are purely cosmetic — everything still works just fine in browsers that don’t support border-radius — I’m not too worried about it.

However, while I was looking into the border-radius CSS property, I discovered several sources that didn’t get it right.

Here’s the deal. The CSS3 standards draft includes a property called border-radius. Exactly how that property is going to work has not been finalized, but it’s not likely to undergo any more major revision. Meanwhile, Firefox and Safari have already worked out their own border-radius implementations, called -moz-border-radius and -webkit-border-radius respectively. Other browsers see the -moz and the -webkit prefixes and ignore the property.

Unfortunately, neither implementation matches how the proposed border-radius property will act. Oh, dear. When the browsers are updated to match the standard, those -vendor-border-radius properties may break. A lot of Web designers out there don’t seem to realize that.

NOTE: probably at this point you should open up this handy table to follow along.

It’s not all doom and gloom, however. As long as people using the vendor-specific border-radius properties keep things really simple, there won’t be a problem. Here’s the skinny:

std-br-15
All four corners with 15px radius
<style type="text/css"> .roundedBox { -webkit-border-radius: 15px; -moz-border-radius: 15px; border-radius: 15px; } </style>

will put a nice rounded corners on any block element of class roundedBox. Safari 4 and Firefox 3.5 (the browsers I have to test on) will work today, and when the formal border-radius is adopted and the other browsers support it, everyone will be happy. (Remember, of course, that in the meantime a large part of your audience will still see squared-off corners.)

The tricky part comes when one wants to specify elliptical corners, or specify different radii of curvature on different corners. When you start getting fancy, things get a little messed up. Let’s tackle the second one first, because it’s possible to find a way to specify the different corners that makes everyone happy. It’s just long-winded.

border-radius is really shorthand for four properties: border-top-left-radius, border-top-right-radius, and so forth. Therefore it’s perfectly safe to specify each corner independently, and all the browsers will act the same way:

moz-br-20-10
top-left and bottom-right 20px radius, others 10px
<style type="text/css"> .roundedBox { -webkit-border-top-left-radius: 20px; -webkit-border-top-right-radius: 10px; -webkit-border-bottom-right-radius: 20px; -webkit-border-bottom-left-radius: 10px; /* different! */ -moz-border-radius-topleft: 20px; -moz-border-radius-topright: 10px; -moz-border-radius-bottomright: 20px; -moz-border-radius-bottomleft: 10px; border-top-left-radius: 20px; border-top-right-radius: 10px; border-bottom-right-radius: 20px; border-bottom-left-radius: 10px; } </style>

Note that the names of the four corner properties are different for Mozilla. Aargh. All the more reason to hope the spec is finalized soon. I put the four properties in the order the software considers them when parsing the shorthand notation, just to get into the habit.

All those lines of CSS can be a pain in the butt, but it’s bulletproof and will work on into the future. But wouldn’t it be nice if you could use shorthand for the border radius the same way you do for margins and padding? The boys at Mozilla thought so, and the CSS3 standards team thought so, too. Webkit (Safari) seems content to only support the long-winded method for now (at least support it properly – more on that later).

Before talking about the differences between the browsers and the CSS3 spec, let’s take a quick look at the theory. As with properties like border, the border-radius property is just a shorthand so you don’t have to specify each corner individually. If you use one number, like border-radius: 10px; the style will be applied to all the corners. If you supply four values, the four corners each get their radius set, starting with the upper left and working clockwise. So far, so good, but there’s trouble ahead.

[The following has been edited since it was first published. I first said that Mozilla was doing the following drawing wrong, but it looks like they have it right and Safari is wrong. Sorry for any confusion. To make up for it I added box-shadow here and there for browsers that support it. They’re sweet!]

The difference is elliptical corners. CSS3 calls for them, but the draft isn’t very well-written. The mystery lies in what should happen when two values are specified: border-radius: 20px 10px. When you are specifying a single corner, the result will be an elliptical curve. When using the shorthand, however, Safari draws all four corners with the same ellipse, but Firefox (and the CSS3 spec) draw round corners that turn out just like the example above.

According to the spec (by my reading), when using shorthand if you don’t use slashes you don’t get ellipses.

std-br-20-10
All four corners with elliptical curvature
<style type="text/css"> .roundedBox { /* four elliptical corners */ -webkit-border-radius: 20px 5px; moz-border-radius: 20px / 5px; border-radius: 20px / 5px; } </style>

NOTE: The most recent builds from webkit.org match the spec. I don’t know when those changes will reach Safari, but sites using the two-value shorthand may have to deal with some inconsistencies between browser versions. Not sure, but I would avoid using that syntax just in case.

What about if four values are specified?

std-br-20-10-5-30
All corners different
<style type="text/css"> .roundedBox { /* four different circular corners */ /* no effect! */ -webkit-border-radius: 20px 10px 5px 30px; -moz-border-radius: 20px 10px 5px 30px; border-radius: 20px 10px 5px 30px; } </style>

Once again Webkit-based browsers like Safari and Chrome fall short. The Webkit team seems content to get the longhand method of specifying corners right, but not the shorthand. Mozilla, in the meantime, has worked out the most complex and versatile form of the shorthand, but disagrees with the spec fundamentals.

To use shorthand to specify four different elliptical corners, you would use something like:

-moz-border-radius: 20px 10px 20px 5px / 5px 10px;

where you specify up to four horizontal radii and then up to four vertical radii. The numbers before the slash are the horizontal radii, starting from the top left. If only two numbers are given, they alternate. Three numbers means top-right and bottom-left share. The y-radius values are the numbers after the slash, and are distributed the same way. Clear? Good.

I have read that if the text rendering is vertical, the horizontal and vertical parts are reversed, but I see nothing about that in the proposed specification.

This will make a lot more sense if you study the twoblue-shaded lines of the table.

While we’re looking at the table, note that Safari is perfectly capable of displaying the most complex borders, but they have not implemented the shorthand notation (except for the bit they did wrong). They’ve done the hard part, but left out the one-day coding job of parsing the shorthand strings into the properties for each corner. Odd. The rules are really very simple for a machine.

So what does this all mean?

In conclusion, while it’s possible to write different sets of -vendor-border-radius CSS properties and get what you want, things start to get quite messy. It’s a lot of effort for aesthetic touches that half your audience won’t see for the next couple of years. I’d advise just staying away from elliptical corners for now, and specifying round corners individually if any are different. It’s a bit more typing, but it’s a lot safer. Stay away from -webkit-border-radius: with two values.

Thanks!

The Worst Thing That Ever Happened to the Internet

Posted on by
25

I mentioned in the last episode that Internet Explorer was the second-worst thing that ever happened to the Internet. Today I’ll talk about the absolute worst. It’s really a long technical rant that doesn’t matter, but it feels good to let it out. What follows is an underinformed ramble about the scourge that did the most harm to the developing computer network that went on to transform our lives — damage that we still live with today. Without this one corrupting influence, we would have had Internet applications that didn’t suck a decade ago, if not longer. In fact, it was because of this electronic plague that Microsoft was able to cause so much harm with Internet Explorer.

The culprit? The ball and chain that modern technology has dragged along despite its obvious flaws? Hypertext Markup Language, or HTML.

First, let’s start with the name. HTML is not a language. Not even close. It is a document format. That its inventors did not recognize the difference tells you that the wrong guys were doing it.

Second, it’s not a very good document format. At its heart, the inventors wanted a format that did three things: connect related documents, embed external resources (like images) and contain standard formatting information that would be interpreted by viewing software consistently. They were not the only ones developing systems like this; Josten’s Learning invented a similar system when they built the first multimedia encyclopedia for Compton’s New Media. Where Berners-Lee and friends had URL’s, Josten’s engineers created BRU’s, but beyond the initials the function was the same.

I don’t want to be too harsh on Berners-Lee, Cailliau, and the others who grew HTML, but I wish they’d been a little more far-sighted. I say ‘grew’ rather than ‘invented’ because it’s clear that they never sat back and asked themselves “What is a tag? What roles do they perform?” Even now, XHTML, the supposedly more rigorous (if still misnamed) descendant of HTML has fundamental inconsistencies.

For a simple example, take the <br /> tag. It exists because in HTML all whitespace (tabs, spaces, and returns) are mushed together and presented on the screen as a single space. Thus

<p>this markup</p>

and

<p>this
 
        markup</p>

come out the same on the screen. That’s fine if you know what’s going on. But what if you want to put in a line break or a space? Well, for a space you add a special character code &nbsp; and for break you add a tag <br />. Why is one a character and one a tag? Because on the day HTML’s inventors decided they needed line breaks, a tag seemed like a good way to go, even though semantically it had nothing to do with the roles of other tags. It could just as easily been &br; or something like that. That’s how HTML grew up. And thus the World Wide Web was born.

Another fundamental flaw is that the content (what to display) is all mixed up with the presentation (how to display it). What if you want to show the same document in different formats? Nope. While some tags were geared toward identifying the type of content that they enclosed (like the <p> tag), others were direct formatting instructions (like the <i> tag). This inconsistency in the role of tags in a document is a reflection of the organic (and sloppy) way that HTML was grown.

I really can’t blame the inventors of HTML for what came next. Everyone started using it. Everyone. The flaws and inadequacies of the format quickly became apparent. Different document viewers (browsers) rendered things differently. Formatting options were extremely limited. The systems were vulnerable to abuse by unscrupulous people. Right then, there was a chance for people to say, “hold on a second! Let’s take the idea of HTML and apply the lessons we’ve already learned in other branches of computing, and make something that doesn’t suck.”

Rather than scrap HTML, browser makers and others set out to fix it. That was the Big Mistake. After twenty years of tweaking and bickering and incompatible extensions introduced by browser manufacturers and squabbles and lawsuits, HTML has been upgraded from awful to poor. Along the way, companies like Adobe and Macromedia thought to get their technology adopted as a replacement to HTML (the Web in pdf? Interesting…) but those efforts were doomed from the start because they did not provide free, simple tools to create the content.

HTML’s greatest shining virtue (and it’s an awesome one) is that it’s accessible to anyone who can type. Anyone. No special tools required.

So, now we have style sheets to help separate content and presentation, XHTML to fix some of the semantic craziness of HTML, and browsers are finally starting to agree on what all the formatting instructions actually mean. We could have had that fifteen years ago if people had just let go of HTML, but here we are now, with an almost-functional system. There are still plenty of flaws, however. Things that seem so normal now that we don’t even think about how dumb they are.

Take this blog, for instance. It’s a pretty well-built Web application, based on reasonably up-to-date practices. Yet were you to click the comment link at the bottom of this episode, you would go to a new page. On that new page the browser would reload the same header and the same sidebar it just erased. What a waste! Why does it do it? Because that’s how HTML (and HTTP, the underlying part that communicates with servers) works. There have been abortive attempts to fix that over the years, but they have all been flawed. Now, at long last, techniques have been developed to overcome that problem, but they are not quite ready for prime time yet. For one thing, they are very complicated, and for another they rely on browsers working just right. Why was it so hard to implement? Because at its core the Web was not made that way.

Even in the days when almost everyone was on dialup (except the people inventing HTML), no one stopped to say, “hey, let’s make a way to only update the content that changes.” That problem has now been ‘solved’ by adding a new layer of complexity on Web sites. By adding this layer (on top of CSS and so forth), we get sensible Web applications at last, but we take away the one super-cool thing about HTML. It is no longer a simple format that can be harnessed by anyone with a text editor. We have lost the attribute that was the only reason to keep HTML around in the first place.

So now we have a system that is both inaccessibly arcane and flawed. Yay!

3

Thanks!

Pardon the Dust

Posted on by
41

Although this is now the official home of Muddled Ramblings and Half-baked ideas, there’s still a lot of construction work going on. Some parts aren’t finished yet, and others, well, they’re just a bit on the ugly side. Obviously I’m not going to win any design awards, but that doesn’t bother me much.

Don’t let the construction deter you, though! Look around, and let me know what you think!

Today: Modified the Site Meter widget to show the MOH and next big number.

Thanks!

Need a Favor

Posted on by
11

I’ve been working on a Web site for a friend of mine, and while it currently has a pretty high degree of slickness when viewed with Firefox for Mac (it has the best debugging tools available to me), I’m curious how it will perform on various Windows browsers. Specifically:

  1. graphics – I blended the images with the background using alpha channels. I’m pretty sure this is going to look bad in Internet Explorer 6, but are there other broswers that also look bad? Can anyone confirm that they do look bad on IE6?
  2. menus – I wrote up some pretty complicated scripts to make animated menus, but I’m not sure how they’re working on other broswers. For instance, on the Leadership Coaching page, there are three drop-down menus. Do they work?
  3. sub-menus – On the lowest menu on the Leadership Coaching page (beneath the picture), does a submenu appear to the right when you roll over the top menu item? (The sub-menus are currently clipped off in Safari and Opera for Mac, which I will fix tomorrow.)

Now I remember why I don’t do Web…

I’ve only spent a little bit of effort trying to make the site aesthetically appealing – mainly I’ve been playing with the CSS to figure out HOW to make the text nice, without really worrying too much about the actual result. I’m really, really trying to make aesthetics Someone Else’s Problem. Still, there are some design elements that aren’t bad for an amateur. I’ll be working on a more consistent color scheme, but what are your thoughts?

Thanks in advance! The link is Eu-LIFE. If things look really weird to you, let me know and I’ll post screen shots to help you describe what’s different.

Thanks!

Programming note

Posted on by
Reply

It doesn’t look much different, but behind the scenes it has changed dramatically. The best part is that after today I will no longer have to republish more than 350 pages when I tweak the banner.

Of course with change comes risk. I’m getting deeper into the CSS, which means that Internet Explorer users may have problems. Let me know if you have trouble, and what browser you are using. Interestingly, although much older, the Mac version of IE renders this page quite a bit better than the Windows version. I thought IE Mac would choke on the CSS.

Here’s a link to the Firefox download, for IE users who haven’t caught on yet. (Hint: Smaller, faster, safer, and standards-compliant.)

Thanks!