iKeif - Latest Comments

Re: My Experience with the Google Search Appliance

keif — Fri, 04 Jun 2010 19:20:35 -0000

I've got a follow up planned with more details.

Re: My Experience with the Google Search Appliance

Matt Sidesinger — Mon, 31 May 2010 08:25:32 -0000

Thanks for the post Keith. Hopefully, I will never have to use this information.

Re: CSS Best Practices and a Return to the Basics

keif — Wed, 06 Jan 2010 13:45:20 -0000

A combination! Some things I've done because I liked it, and found it reinforced, others are the process of reading, educating, testing and discussion.

Re: CSS Best Practices and a Return to the Basics

Dr Gregg Ramsay — Wed, 06 Jan 2010 13:41:03 -0000

Nice blog here. One question though, are the CSS rules yours or are they others that you've collected along the way?

Re: CSS Best Practices and a Return to the Basics

keif — Mon, 30 Nov 2009 23:52:19 -0000

It *can* be argued that inline styles are acceptable in some cases (i.e. CMS systems, or the current design showcase of "make each blog post it's own style") but I feel it needs to be drilled in to most devs to NOT use inline styles, period, as when they increase their competence they'll see inline styles as valid in extreme circumstances.

Re: CSS Best Practices and a Return to the Basics

walterg2 — Mon, 30 Nov 2009 12:31:41 -0000

While I would agree that inline styles are, generally, a bad practice, there are still some very valid reasons for using them, hopefully sparingly, within a site. I would say that 99.999% of those reasons are around the use of a CMS, where the user wants to have control of which background images are used for a reusable element. Without the use of inline styles, the user would need to lean on development to update and release the CSS files each and every time a new piece of content is needed using that "template".

Again, it's only in extreme circumstances that inline styles should be considered, but they shouldn't be discounted if you can still control the mechanism that the user will be using to add those in (i.e. - CMS).

Re: CSS Best Practices and a Return to the Basics

jasonkarns — Sun, 01 Nov 2009 09:46:01 -0000

I would like to see a post concerning how the various libraries handle namespacing. And perhaps I boiled the subject down a little too far. The reason I brought it up is that IE7.js works perfectly well with jQuery but not with most other libraries out there. MooTools declares at least 15 global functions. It may be 'namespaced' with its modularity, but that's false advertising when you extend natives the way it does. And extending natives is the reason IE7.js doesn't work with MooTools out of the box. So you can call MooTools namespaced, but it may as well not be.

Re: CSS Best Practices and a Return to the Basics

keif — Sun, 01 Nov 2009 01:35:09 -0000

The issue with writing off IE6 as a corporate lock down, is that is your target selling audience - if your client is on IE6, and you try to argue that "most of your users will have a better experience" you won't get a warm reception. As well, one request for one HTC file that is something that could be broken out into multiple JS/CSS files (targeting specific pages, layouts, whatever) brings up the issue again (but this still falls in the "oh gee, it's an extra 30ms").

I hate AlphaImageLoader, and the more I've tested against DD_belatedPNG the more I'm liking it. I've only seen one situation it would've needed to be tweaked for past code.

I still am not sold on using a JS fix for CSS items - it's a pain in the ass, but .first/.last isn't too much to ask to give it the same experience without the JavaScript overhead.

AAANNND lastly - MooTools is namespace. I think Prototype and Dojo are not, but I'm not going to research the various JS libraries to see which ones still do/do not have this accounted for (maybe a future post?)

Re: CSS Best Practices and a Return to the Basics

jasonkarns — Wed, 28 Oct 2009 15:47:53 -0000

Ah, I wasn't aware of IE6's issue with caching HTC files. Although I don't generally worry about overhead for IE6 workarounds that only affect IE6 users. Say your IE6 audience is ~24% (current IE usage is about 65% spread evenly over 6,7, and 8). Of those users, I would be willing to wager that over 75% of them are using IE6 due to IT lockdown, which means they are surfing your site on a T1 or T3 line. And if you declare all of your CSS behaviors with one selector, you only have one request.

As for TwinHelix in particular, yes there are certainly issues with it. But they are not due to the HTC, only the AlphaImageLoader technique in general. A standard JS library using the AlphaImageLoader has the same issues. And I prefer using the VML technique via DD_belatedPNG when the situation calls for it (which it nearly always does). However, this technique has its own problems, namely when the 'fixed' element's position or display properties are modified via JS.

I generally agree with everything you mentioned regarding the IE7 script. However, from my experience with it, the only fixes the script provides (that I rely on) are for 'nice-to-haves' that don't affect functionality. Things like :hover on non-anchors, :first-child, and :last-child which rarely do anything than change a border or margin property. The lack of these and other layout fixes does not impair the functionality of a site, merely its presentation, which is a perfect case for a JS solution.

And I'm completely ignoring the fact that IE7.js doesn't work with other libraries. I only use it with jQuery thanks to jQuery's namespacing (which is an entirely different conversation, ala MooTools). If I need MooTools or Prototype, et al. then IE7.js is out of the question.

Re: CSS Best Practices and a Return to the Basics

keif — Wed, 28 Oct 2009 14:29:35 -0000

My issue with it, is you're creating additional server requests - to a CSS file, to an HTC file, to fire off JavaScript - why not just request JavaScript? On top of the number of issues that the TwinHelix "fix" can introduct, including the need of a custom htaccess file, it doesn't work with PNG backgrounds and links and needing to possibly set the content expiration (http://support.microsoft.com/d... to fix excessive server requests. A whole slew of issues that can be overlooked until it's in production, or on a client's server that you can't necessarily easily fix on your end.

Dean Edward's IE7 script is a hack itself - it creates the illusion that CSS will work properly versus actually coding to account for it. You end up writing "advanced" CSS that fails without JavaScript, which can introduce more issues, particularly if you utilize it in addition to other JavaScript frameworks.

The issue with the IE7 script, is it is Dean Edward's script - there is no community of support. It has 12 accepted defects since January of 2008, and a total of 166 bugs - if there was a strong community behind it, I might say "okay" but it's just a simple "throw it in, hope it works" which can introduce more issues than it fixes, particularly since he considers it a "beta" project. I much prefer to write valid CSS that is cross-browser compliant and progressively enhance the site through the use of CSS3 and a JavaScript library to achieve cross-browser compliance.

For a majority of clients, a JavaScript solution to make it work is not a valid one if it prevents the site from functioning.

Re: CSS Best Practices and a Return to the Basics

jasonkarns — Wed, 28 Oct 2009 09:00:08 -0000

I agree that the Twin Helix technique is nothing more than a JavaScript solution in HTC clothing. However, when you're throwing in a CSS behavior to fix a browser issue, I don't see anything wrong with it. You've already got your IE-specific stylesheet being included via Conditional Comments. No need to reference another JavaScript file when you can just as easily drop in behavior references. Using IE's proprietary features to patch IE bugs is perfectly fine in my book. CSS expressions (when written properly to avoid the performance hit) can patch in support for position:fixed, and max-height/width. Throw in another HTC for whatever:hover. Although if you need all of these features patched, I would rather drop in Dean Edwards' IE7 script and be done with it.

Re: CSS Best Practices and a Return to the Basics

keif — Tue, 27 Oct 2009 02:28:02 -0000

CSS Specificity is more of a "destination" - I'm not nearly efficient as I should be, and I agree that sometimes adding in elements can help navigate a CSS file.

However, it could be argued that CSS commenting could negate the need for the element specificity (but then we're back to debating "how many milliseconds is this costing us?")

Totally missed :focus, thanks.

No reason for CSS Behaviors. At all. Twin Helix's htc file is just JavaScript shoved into an HTC file. There are one hundred (plus one) solutions for PNG's utilizing VML or AlphaImageLoader that don't try to hide behind the HTC that are just as effective (and some could argue that VML is *more* effective).

I'm looking into the HTC rounded corners fix, but I have a feeling that it too will fall into the "should be JavaScript" - unless someone can generate the benchmarks that say going the HTC route is actually more effective than a pure JavaScript route.

Re: CSS Best Practices and a Return to the Basics

jasonkarns — Mon, 26 Oct 2009 21:03:30 -0000

Rule: CSS Specificity
I admit, I tend to get a little carried away here. In general I do a good job keeping my selectors to a minimum, but I also like to throw in an extra element or two (or class or id) to help show the HTML structure in the CSS.

Rule: Link States
You're missing one! :focus. Never leave out focus, else your styles will tend to only be mouse-friendly. Be sure to add :focus to any :hover rule and you've got both the keyboard *and* the mouse covered. The mnemonic I use for the rule order is: Lord Vader's Former Handle, Anakin (:link, :visited, :focus, :hover, :active).

Rule: CSS Behaviors
No reason for CSS behaviors at all? Really? Not even as an IE PNG Fix (ala Twin Helix)?

Re: CSS Best Practices and a Return to the Basics

keif — Mon, 26 Oct 2009 19:28:49 -0000

I go all the way strict - CSS Behaviors (an IE methodology) require JavaScript to be used, therefore they should just be entered in as plain JavaScript.

The CSS a:hover work, period. Generally, I'll still utilize :hover when I can as CSS is seldom disabled, so most browsers still get a better experience than those that require JavaScript. Which is usually just IE.

Re: CSS Best Practices and a Return to the Basics

Braxo — Mon, 26 Oct 2009 15:02:33 -0000

In your rule CSS Behaviors Require JavaScript, how strict do you go with that?

I even go as far as to separate the CSS :hover effects to javascript as I view them as behaviors and snazzy extra functionality.

I am strict with content in db, html for markup, css for styles, js for behavior

Re: Making Twitter @Username Clickable in Sweetcron

keif — Thu, 20 Aug 2009 04:36:03 -0000

Awesome, thank you! I'll update the post as soon as I can.

Re: Making Twitter @Username Clickable in Sweetcron

rickmans — Tue, 18 Aug 2009 10:47:53 -0000

There is a small error in the regex, the output was http://twitter.com/@username, however those usernames do not exist. I have modified it to create the correct link:
[code]
$item->item_title = preg_replace('/(^|[^\w])@([\d\w\-]+)/', '@$2' ,$item->item_title);
[/code]

Re: Death of the Domain Name - Long Live Search Engines

keif — Sun, 16 Aug 2009 09:52:12 -0000

I still feel that keyword-rich domain names seem kind of spammy. I suppose
the key is making sure that the company name is visible as well, but there
is also the opportunity to use additional domains that can have a custom
landing page on another site (giving the benefit of no duplicate content and
a keyword rich approach).

Regardless, even if a site has a large client base (mainstream apparel,
heath and beauty) they could still have a benefit by being keword rich and
having well-structured URLs to allow for easy deep-linking and logically
paths to product discovery.

Re: Death of the Domain Name - Long Live Search Engines

dom — Sun, 16 Aug 2009 06:30:57 -0000

For most of us on the web keywords in the domain name is a necessary part of SEO,

for those of us that have a large client base maybe its not so important however it would probably increase your sites exposure to more customers

Re: Plaid is STILL IN – 10 Days to Plaid Nation

Andrew Chen — Thu, 16 Jul 2009 14:53:33 -0000

Keith, how do I get ahold of you? Couldn't find an email or contact form.

Here's my bio: http://andrewchenblog.com/abou...

Looking for some recommendations for frontend engineers...

Andrew

Re: Six SEO Experts on Twitter

keif — Tue, 14 Jul 2009 14:49:29 -0000

D'oh, thanks ravm!

Re: Six SEO Experts on Twitter

ravm — Tue, 14 Jul 2009 14:47:47 -0000

Thanks for the cool list. Matt Cutts is spelled with two Ts.

Re: Plaid is STILL IN – 10 Days to Plaid Nation

irj — Mon, 13 Jul 2009 09:39:56 -0000

Hey Keith, thanks for the PlaidNation love! Now we need to do our part. Can you email me your contact info and t-shirt size so we can send you some sweet tour gear...much like the tour gear featured in the pic on your post, only cooler? Thanks!

Re: Plaid is STILL IN – 10 Days to Plaid Nation

darrylohrt — Fri, 10 Jul 2009 19:56:06 -0000

Keith - if you decide to make the journey to Indianapolis, keep an eye on the @plaid twitter stream for our whereabouts. Snack time and lunch times are good times for meet ups. Definitely give us a shout if you decide to make the drive!

Re: Six SEO Experts on Twitter

keif — Mon, 06 Jul 2009 10:13:14 -0000

I get "too many tweets" - but I think that's just recognizing the 160 page
limit from twitter, but the service doesn't want to admit it's own
limitations.
And I agree with the history of tweets not making sense... but I've always
found it odd that twitter can't handle the amount of textual data in a
better manner.