Direct Link to Article — Permalink

.not-a-square {
   -webkit-border-radius: 10px;
   -moz-border-radius: 10px;
   border-radius: 10px;
}

Why is this method of ordering properties so commonly taught? Here is what it would look like “the wrong way”:

.not-a-square {
   border-radius: 10px;
   -moz-border-radius: 10px;
   -webkit-border-radius: 10px;
}

Even doing it “the wrong way”, won’t the border radius be the same no matter what, forever? A quick investigation might lead you to conclude that it will, and this ordering of properties is rather nonsense.

1. The Long Long Ago: None of the properties are supported, order doesn’t matter.
2. The Past: Only vendor prefixes are supported, order doesn’t matter.
3. The Now: Both vendor prefixes and actual property are supported. If prefix is last, it will override actual property, but both are the same anyway.
4. The Future: Only actual property is supported, order doesn’t matter.

Here’s a simple chart with this concept at work.

Woah there, Cowboy

The fact is, the ordering of CSS3 properties is important, and the above is fundamentally flawed. “The Now” is exactly the problem. We are at a crucial juncture in browser history where some browsers are supporting both the vendor prefixed version and the actual CSS3 property. Right now it’s specifically WebKit that is doing this, and the way they have implemented it is that if you list the vendor prefix after the actual property, the vendor prefix will override and be the property that renders.

Why does that matter? In the simple border-radius example we saw above, either way, the corners on that element will have a border-radius of 10px. There is no difference in how the vendor prefix and “real” property handle rounded corners when you set only one value. The problem is that there is a difference between the implementations of the properties when passing more than one value.

.not-a-square {
   /* These do totally different things */
   border-radius: 30px 10px;
   -webkit-border-radius: 30px 10px;
}

The spec or “real” version will render the top left and bottom right corners at 30px and the top right and bottom left corners at 10px. The vendor prefix will render all four corners with elliptical corners 30px wide and 10px tall.

So if you’ve been blinding including the real border-radius at the end of your property lists using identical values, and then switch from Safari 4 to Safari 5, you’d see a dramatic change in how the above code was styling your boxes.

See here

You could fix this up by fiddling with the values to make sure they do the same thing… but if you are going to fiddle with anything, you might as well fiddle with the real property as that will be supported version in the future. Listing the real property last is definitely the way to go. Because it will be based entirely on the spec, it will match other browsers implementations, and will be the only supported version as time goes on and vendor prefixes are removed.

Border radius isn’t the only example here. Note the dramaticly different syntaxes for background-image gradients. Now there is no “real” spec version of these values yet, but when there is, the implementation will be different than what we are using now. That should be listed last in the ordering of the properties to future proof that as well.

Thanks to @mattwiebe and @snookca for helping me understand this better.

On this site, we used to ban IP’s in the forums all the time (the new forums have been much better in spam prevention). I also sometimes ban IPs from inside WordPress. There is a setting to “blacklist” IP’s in the admin area on the Settings > Discussion page. There are few in there from spammers, and a variety of people I thought just shouldn’t come ’round here no more. In looking at this list now, some of these IP’s have been in here for years. Is that acceptable?

At the time of blockage, and IP address might belong to Danny Doucher, but after sometime, the IP address might be reassigned and now belong to Susie Supercool. I certainly wouldn’t want to punish Susie for Danny’s crimes.

So, how long should we ban IP’s for? Wikipedia, who certainly needs to deal with IP blocking on a regular basis, has a few choice words:

Most IP addresses should not be blocked more than a few hours, since the malicious user will probably move on by the time the block expires.

IP addresses should almost never be indefinitely blocked. Many IP addresses are dynamically assigned and change frequently from one person to the next, and even static IP addresses are periodically re-assigned or have different users. In cases of long-term vandalism from an IP address, consider blocks over a period of months or years instead. Long-term blocks should never be used for isolated incidents, regardless of the nature of their policy violation.

I can get on board with that. IP blocks should only last a limited time, since all IPs eventually change. Most blocks should be short, but if you experience long-term bad activity, make the ban longer. In the case of this site and WordPress, the Discussion Settings also offer a Moderation list, so you don’t actually have straight blacklist IP’s at all if you don’t want, and even if you do, you can move them from the blacklist to the moderation list after a while and be fine.

Anyone else have any theories or research to share?

They make my button maker look dull and flat.

Direct Link to Article — Permalink

I saw that Andy Clarke had added a fluid width YouTube video to a particular page on one of his sites. His code relies upon a wrapping div and then images and video within this wrapper are set to the width of the wrapper:

.img img, .img object, img embed {
   width: 100%;
}

I love the idea. It’s essentially the classic technique for dealing with images in fluid width designs. Andy’s code sets max-width to 100% here too, but since the width is already 100% that doesn’t matter. Max-width works best by itself. So it can scale down images which could be larger than the wrapper, but not scale them up if they are smaller. For video, scaling up is probably fine. I’d suggest this change:

.img img {
   max-width: 100%;
}
.img object, .img embed {
   width: 100%;
}

That will scales images only down if needed, and videos up or down.

Keeping Aspect Ratios

With images, as long as there isn’t an inline “height” setting, the aspect radio will be maintained in a fluid width environment even when you only alter the width. With video (flash or otherwise) this is not the case. If we want to maintain aspect ratio while the video grows and shrinks in width, we’re going to need JavaScript.

Example YouTube Provided Code:

<object width="640" height="385">
	<param name="movie" value="http://www.youtube.com/v/EWsWFjO9MlE?fs=1&amp;hl=en_US"></param>
	<param name="allowFullScreen" value="true"></param>
	<param name="allowscriptaccess" value="always"></param>

	<embed src="http://www.youtube.com/v/EWsWFjO9MlE?fs=1&amp;hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed>
</object>

This is the plan:

1. Find original aspect ratio by dividing original height by width
2. When window is resized…
3. Measure width of parent
4. Set width of video to width of parent
5. Set height of video to width multiplied by aspect ratio
6. Trigger a fake resize on pageload to ensure video fits right away

Here, we’re using jQuery. Take note that we are target both the class name of .youtube and the embed within that class name. This is presupposing that we are adding a classname of .youtube to the object in the copy-and-paste code YouTube provides. Feel free to adjust the selectors as you wish. You may wish to target all objects themselves, or use a special wrapper. Here we’re using the #page-wrap of all the content to measure width.

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js'></script>
<script>
	var $origVideo = $(".youtube, .youtube embed");
	var aspectRatio = $origVideo.attr("height") / $origVideo.attr("width");

	$(window).resize(function() {
		var wrapWidth = $("#page-wrap").width();
		$origVideo
			.width(wrapWidth)
			.height(wrapWidth * aspectRatio);
	}).trigger("resize");
</script>

Also of note here is that we are targeting the <object>s and the <embed>s within them with this JavaScript. Targeting the objects alone will work in modern browsers. Including the embed is fine for modern browsers and makes it work with Internet Explorer as well.

Bonus Trick

You can get rounded corners on your YouTube videos! The only luck I’ve had so far is in Google Chrome (7.0.503.0 dev).

1. Add this param to your embed (within the object) <embed wmode="opaque" ...
2. Then you can add border radius to the object

   object {
   	border-radius: 10px;
   }

Credit to ubahnverleih on Forrst for the idea.

Demo & Download

View Demo   Download Files

UR DOIN IT WRG

This worked in all browsers I tried, including Internet Explorer (tested 7 & 8), but not Opera. The best I can tell is that Opera respects in the inline width and height attributes over those set via inline styling. If anyone knows of a way to fix that, or if you think my whole method here is stupid and you have something better, please let me know and I’ll update things here.

Direct Link to Article — Permalink

Today is just such an event. WordPress 3.0 has been out for a while now, and so it’s time for our second major update. This is the biggest one yet. We’ve combed through the entire book updating anything that was out of date or stale. We’ve also added a new Chapter 12, which is specific to the 3.0 update. The book is also sportin a brand new front and back cover!

If you already own our book in any form, this is old news, because we’ve already sent out an update email containing your new download. If you didn’t get it (spam filters happen), email sales@digwp.com with your original receipt and we’ll make sure you get it.

If you are considering it, but want to know more, you should check out the PDF sample of the book.

Regarding print version of the book, yes, they are coming back! It’s going to take us about a month to have them ready. If you’d rather not wait, you can buy the PDF now, and when the print version is ready forward us your receipt. We’ll send you a coupon code for exactly what you paid for the PDF to use in purchasing the print version. I’m sorry I spoke to soon on this issue. We are NOT offering any discounts on the printed version.

There is no shortage of documentation on WordPress’ famous content-spewing structure, but I still feel like there is more confusion and mystery surrounding “The Loop” than there should be. In this screencast I try and explain what it is, how it works, related parts, and then demonstrate some alterations and various tricks. Things like running multiple loops, writing your own custom queries, and handling pagination with your own custom loops.

View Screencast

The red lines indicate the column as rendered with WebKit. The background shades of gray are accurate placement of those columns in percentage widths.

It’s percentages in general that seem to be the issue. I haven’t been able to dig up a ton of information on it, although I do seem to remember reading something about it quite a while ago. I think it’s related to how subpixel values are calculated. For example, if a container is 657px wide currently, and has four columns at 25% each, they would be 164.25px each wide, and WebKit doesn’t handle that well (rounding issues?) Other browsers handle the “subpixel” value OK.

Firefox, IE, and Opera are fine.

Thanks to Nicolas Gallagher for pointing this out to me. If I’m way behind the times on this, feel free to yell at me, but throw me some links and information so I can update this post with the most accurate information I can. This link seems to indicate the issue has been around a while.

Remember this is only really an issue if you are doing something like shown in these examples with solid color columns. If you didn’t have any visual separators, it might not be a big deal, just a slight cross browser difference very few people would ever notice.

Direct Link to Article — Permalink