While it’s great how simple and effective the process is of “linking” pages together, I think there’s room for improvement.

If you’ve never heard of the term fragment identifier, well, that’s just the official name for the part of a URL that follows the hash symbol (“#”). Some people refer to links with fragment identifiers as “in page links”. So for example, in the following URL, the fragment identifier would be the string “scroll-to-fragid”:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid

If you visit the above URL (which is the WHATWG HTML5 spec that discusses fragment identifiers), the page will automatically jump to the section that’s been identified by the browser as the “scroll-to-fragid” section.

Fragment identifiers also come in handy for deep linking and preserving state in Ajax-based applications. So these certainly have an important role on the web.

How Are Fragments Identified?

In order for the browser to correctly identify which section of the page the window should scroll to, the fragment needs to be identified within the HTML by means of the id attribute. This means that if a web developer hasn’t done his job, then there will be no way to link to a specific fragment of any particular document.

So, if you were linking to a document that was five screens long that didn’t have any id attributes in the source, and you wanted to link to a specific section three screens down, you would have no way to do this. You’d have to link to it, then place the words “Scroll down to section B” or something ridiculous like that.

The Problem With Fragment Identifiers

The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments.

Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

So why is it up to the developer (or content creator) to define whether or not a specific portion of the content can be linked to? When any page of content is created, there is no way of knowing which sections of the page are worthy of being identified. The developer or content creator may have a general idea of how a page’s content might be divided up, but ultimately it will be the linking resource that should have full control over what portion of the page they want to highlight.

That, after all, is how linking works. A page that’s displayed as a result of a web-based hyperlink is displayed to the end user only because the referrer (i.e. the page linking to it) defined the link that way. This means that, regardless of what the developer has done behind the scenes in the HTML, all HTML fragments on that page should be identifiable by external referrers.

The Solution: Power to the Browser and User

The solution, as I see it, is for the HTML spec to require that browsers have an internal mechanism for identifying fragments that can optionally be overridden by the developer. Just as the browser, by default, makes all links blue and underlines them, and allows these styles to be changed via CSS, likewise the ability to link to specific sections of a page should be built into the browser, and then the developer should have the option to change this.

Here’s a simple example of how this might be implemented. Suppose you have the following HTML page:

<h1>Page Title</h1>
<p>Some introductory text.</p>

<h2>Page Subhead 1</h2>
<p>Some text for subhead 1.</p>

<h2>Page Subhead 2</h2>
<p>Some text for subhead 2.</p>

<h2>Page Subhead 3</h2>
<p>Some text for subhead 3.</p>

<h2>Page Subhead 4</h2>
<p>Some text for subhead 4.</p>

This type of structure is common on almost all blog posts. The post is divided into sections by means of headings, but unless the developer actually hard-codes id attributes onto each heading tag, there is no way to link to any of those unique sections of the page.

To solve this problem, the browser should allow native fragment identifiers that use the HTML elements themselves in a CSS selector-like fashion. So if you wanted to link to “Page Subhead 3″ in that HTML page, you could do something like this:

<a href="http://www.example.com/example.html#h2:3">Check this out!</a>

Notice the string h2:3 that appears after the hash symbol. This tells the browser to link to the third <h2> element on the page. This example, of course, is just theoretical, and not meant to imply that this is the way it will be implemented. This is just to illustrate how it could be done without being dependent on developer-added attributes.

Why Should Fragments Be Identified By Users?

The reason fragments should be identifiable by users is because a user, not the content creator or the developer, will ultimately decide whether or not a portion of content is valuable or notable in some way.

Yes, the content creator should have the ability to decide how a page is generally divided, if they choose to do so. But the end user should not be restricted from linking to content fragments just because a developer couldn’t be bothered to add id attributes to every element on the page. And that’s besides the fact that it would be a waste of time for a developer to do that or to have to build a CMS that does it automatically.

Blog Comments Get It Right

Linking directly to someone’s blog comment is very useful. Even if a blog doesn’t have an active link for each comment, it’s pretty easy to use developer tools to find the comment’s id and link to it. I’ve done this many times on Smashing Magazine (they don’t have live links on each comment).

If there was no way to link to an individual blog comment, this would be a great hindrance to linking on the web. It would not be enough to link to the “#comments” section and then hope for the best. So CMSs like WordPress do the right thing by dynamically adding a unique identifier to each comment.

As mentioned, this saves the content creator from having to do it themselves, and puts the identifiability (or, the decision on what’s valuable) in the hands of the user or the referring website.

It’s Already in the Works

Being fearful of writing an article like this and having someone smarter poke holes in my proposal, I ran a draft of this piece by Paul Irish and he pointed out that an improvement to fragment identifiers is already in the works, but in very early stages.

A developer named Simon St. Laurent is hosting an “unofficial draft” of a specification called Using CSS Selectors as Fragment Identifiers. The draft is authored by St. Laurent and Eric Meyer and seems to be in the works for about a year (based on the date on that page). There’s even a jQuery script with a GitHub repo that attempts to implement this new type of fragment identifier. (Thanks to Ahmad for the GitHub link.)

And on a related note, media fragments (i.e. deep linking in audio and video, similar to what you can do on YouTube) have now been introduced and have some browser support (evidently WebKit and Firefox). Check out this part of the spec for the syntax.

All credit to Paul Irish for filling me in on these details.

Conclusion

Although implementing better fragment identifiers could be a challenge to support and publicize, for the reasons I’ve explained here, I think it’s a worthwhile addition to the HTML/CSS spec. I’m glad someone is already working on a proposal for this, and I hope this article serves to help make this known so that control of linking to content fragments ends up where it’s supposed to be: in the hands of users.

No related posts.

At the end of the article, she pointed out that rather than wasting time debating HTML tag use, developers should focus on learning how to program. I think this is great advice. So to that end, I’ve compiled a roundup of sources where beginners can expand their skills past HTML and CSS.

Codecademy

Codecademy dubs itself as “the easiest way to learn how to code.” This is testified to by the site’s more than 200,000 users.

Their “about” page explains: “Codecademy was created out of the frustrations Zach and Ryan felt with learning how to program. Tired with less effective text and video resources, Ryan and Zach teamed up to create Codecademy, a better, more interactive way to learn programming by actually coding.”

Treehouse

You’ve probably seen this one advertised on CSS-Tricks. The Treehouse mission is “to teach Web Design, Development and iOS to people everywhere, in order to help them achieve their dreams and change the world.” Sounds like an overly-optimistic mission to me, but from their testimonials, Chris Coyier’s endorsement, and the overall design of the site, this looks like a great way to learn a whole slew of different technologies.

With the Treehouse method, users watch videos, then takes tests to unlock badges. Seems like a simple and effective concept that’s worth looking into.

appendTo Developer Learning Center

The appendTo Developer Learning Center looks like a great option for aspiring developers who want to learn jQuery and JavaScript. As they describe on the home page: “Level up your skills with our on demand, pragmatic training solution. No signup required. No catch. No kidding.” And best of all, it’s free!

According to their about page: “More and more companies are implementing jQuery in their websites and applications, and they are looking for developers that are highly skilled in jQuery and JavaScript. We see [appendTo] as a vehicle to train and mold these skilled professionals.”

MDN: A Re-Introduction to JavaScript

This is not a fun, interactive course like those already mentioned, but definitely worth a look if you want something simple and text-based. The opening explains: “Why a re-introduction? Because JavaScript has a reasonable claim to being the world’s most misunderstood programming language. While often derided as a toy, beneath its deceptive simplicity lie some powerful language features. 2005 has seen the launch of a number of high-profile JavaScript applications, showing that deeper knowledge of this technology is an important skill for any web developer.”

Although the opening’s reference to “2005″ seems to imply that the article is somewhat old, it is editable and continues to be maintained and updated, so I think it’s safe to say this would be a fairly reliable and relevant resource for those desiring to learn JavaScript.

jQuery Fundamentals

Another text-based resource, but a much larger one, jQuery Fundamentals by Rebecca Murphey boasts “contributions by James Padolsey, Paul Irish, and others.”

Although this project is maintained on GitHub, the GitHub repo has been changed to this one and evidently the entire project will be moving to learn.jquery.com. My guess is that the current project is not the most up to date in terms of jQuery’s features, but is probably still a great resource for those learning jQuery or JavaScript from scratch.

Eloquent JavaScript

Eloquent JavaScript: A Modern Introduction to Programming is a book by Marijn Haverbeke, that has a free HTML version available online. The book provides not only an introduction to JavaScript, but also serves as a brief introduction to programming in general. It comes with a strong endorsement from Brendan Eich (the creator of JavaScript) who says the book “rekindled my earliest joys of programming.”

Although the online version can serve as a fine introduction to JavaScript, the print version (which I have a copy of) is revised, thoroughly edited, and updated.

JavaScript 101

Yet another JavaScript-based course, edited and released by Addi Osmani. This one is a free 10-hour audio course on JavaScript fundamentals, released more than a year ago. The download package for the course includes slides in PDF format and course exercises.

The course is a set of audio recordings taken from lectures done by Tony Pittarese, an assistant professor of Computer and Information Sciences at East Tennessee State University. Addi endorses the course, however he does point out that there are some minor things in it that would not be considered best practice today.

Conclusion

I can’t personally vouch for all the material in these resources. But all of these have come, in one way or another, endorsed by well-known front-end developers in our industry. So if you’re a beginner whose been working with HTML and CSS for some time now, any one of these resources could be used to help you step up your game and start programming.

As always, if you know of another resource in the category of learning to program for beginners, post it in the comments.

Related posts:

1. Skills for Front-End Developers
2. How Do You Decide Which Web Design or Programming Books to Buy?
3. Some JavaScript Resources Worth Checking Out

Well, now that’s all changed, which I discovered while researching additions to my CSS3 Click Chart. The word-wrap property has been removed from the CSS3 spec and other related properties have been added.

Text-Wrap

The text-wrap property “specifies the mode for text wrapping”. Well, that description doesn’t tell us a whole lot, so let’s break down the values.

normal
This is the initial, or default, value for text-wrap. This is what happens when you don’t have any text wrap settings specified, so a value of “normal” is what you see occurring in any given element that has text.

none
This tells the browser that text in that element should not break at all. So if the text reaches the end of the parent container, it will overflow its parent and any overflow settings would handle the text’s visibility.

avoid
This value will still allow line breaking to occur, but this tells the browser to be selective as to where breaks happen. A nice example is shown in the spec in this section which basically shows that the browser will interpret parts of the markup so as to decide where to break lines and where to avoid breaking them.

Browser Support: None that I know of.

Overflow-Wrap

The overflow-wrap property is the replacement for the now-obsolete word-wrap property. The values are either “normal” or “break-word” — the same values that word-wrap uses.

This particular property, like word-wrap, handles what the spec refers to as “emergency wrapping”. The spec explains: “This property specifies whether the UA may break within a word to prevent overflow when an otherwise-unbreakable string is too long to fit within the line box.”

The spec also explains that if text-wrap is set to “none”, then overflow-wrap will have no effect. Also, although this is for breaking a line in the middle of a word, the word will not be hyphenated. More on hyphenation below.

Browser Support: None that I know of.

Line-Break and Word-Break

According to the spec, these two properties have been introduced to help deal with the problems that arise from browsers assuming that lines and words need to break as is common in the English language. For example, in English a browser will not break a line within a word, but only where there is a space or certain punctuation marks. But in other languages, these rules don’t apply.

As the spec explains, although English lines may break at space characters or punctuation, this is not true in other writing systems that don’t use spaces and punctuation. In these writing systems “a line break opportunity is based on character boundaries, not word boundaries”. Thus, line breaks often have to be supressed within certain character combinations.

I honestly don’t fully understand all the values for these properties, so I won’t attempt to expand on them here. And judging by the description, it seems these two properties would be most useful to those dealing with content in languages that require different line breaking rules than that of English.

Browser Support: None that I know of.

Text-Overflow

The text-overflow property defines how to handle text that overflows its parent when the parent’s overflow is set to something other than “visible”. It accepts the following values:

clip
With this value (the default), the text will be cut off and the remainder would be invisible. This happens by default in all browsers now. Keep in mind that in order for this to take effect, the text would have to be inside an element that, for whatever reason, doesn’t allow natural line breaking.

ellipsis
With this value, the text will still be cut off but the fact that it’s incomplete will be indicated by an ellipsis (i.e. three dots “…”).

As shown below, browser support is very good for this property. Old versions of IE did include support, but it seems the implentation has changed and so newer IE uses prefixes. For more on this and a working live example, see this section on the click chart.

Browser Support: IE6+, Firefox 7+, Chrome 1+, Safari 1.3+, Opera 11+

Hyphens

And finally, CSS3 now introduces a hyphens property that can be used to tell the browser whether or not to automatically insert hyphens.

none
A value of “none” tells the browser to never hyphenate, even if break points are somehow defined.

manual
This value is the default and is how browsers naturally do hyphenation. This means that the browser won’t do any hyphenation unless there are hyphenation characters indicated. You can actually do this using the soft hyphenation character, which, inside of a word, looks like this: hy­phens.

auto
With a value of “auto”, the browser will automatically insert word breaks and hyphenation in accordance with the language defined for that page.

Hyphens have some support so you can see a working example with the accompanying code here.

Browser Support: IE10+, Firefox 6+, Safari 5.1+ (all require vendor prefixes; thanks to Hans for letting me know about support in Safari)

Conclusion

Although browser support is not great for these new features, it’s nice to know that in the future we’ll have some powerful tools at our disposal to handle overflow and line breaks in a more fine-grained manner.

Related posts:

1. Word-Wrap: A CSS3 Property That Works in Every Browser
2. List of Cross-Browser CSS Properties
3. Mixing CSS3 Prefixed Properties with Keyframe Animations

• Two sections to choose from: Common Stuff and Cutting-Edge
• Totally new layout and colors
• A separate domain name
• A GitHub repo
• Ajax calls that could use some optimizing
• Tons of new stuff added, especially in the “cutting-edge” section
• “Polyfills/Tools” and “Tutorials/Articles” sections for each feature

Thanks to Schmíz Péter and Thierry Koblentz who offered some early feedback when I tweeted about it yesterday.

I’m sure there’s lots more that could be improved, added, or modified, (for example, a “find” feature, maybe a way to alphabetize the list, etc.) so feel free to browse around it and if you see anything that could be improved, you can open an issue on Github or post a comment here.

I’d also like to update the data for each feature, so if you have built, written, or know of any tools, polyfills, or tutorials covering any of the features, post a link here or on GitHub and I’ll add it.

Now stop reading this and check out the new CSS3 Click Chart! :)

Related posts:

1. More Additions to the CSS3 Click Chart
2. Not Another CSS3 Click Chart Update!

It seemed like a simple task. After doing a search to see what types of plugins and scripts were floating around to do this, the examples I found seemed a little overly complex. While most solutions seemed to incorporate some complex math calculations, I thought of a better way.

Using a Hidden Clone Element

A <div> element will naturally stretch to fit the height of its content (assuming no floats or absolutely positioned elements are involved). So to get the height of the textarea, I just need to do the following:

• Grab the content loaded into the textarea
• Create an invisible clone div
• Give the clone the same width and typographical properties as the textarea
• Place the content into the clone
• Get the height of the clone
• Apply the height of the clone to the height of the textarea

The Code

One of the keys to this solution is the CSS. As mentioned, the invisible clone needs to have the same typographical properties as the textarea. Not only does this include stuff line font-size and font-family, but also the white-space and word-wrap properties of the clone need to be set to mimic what happens inside the textarea.

First here’s the CSS for the textarea:

textarea {
    width: 500px;
    min-height: 50px;
    font-family: Arial, sans-serif;
    font-size: 13px;
    color: #444;
    padding: 5px;
}

.noscroll {
    overflow: hidden;
}

Take note that I’ve added a separate class with overflow: hidden, to prevent scrollbars from appearing. Normally this would not be a good thing to add to a textarea element, but because I’ll be resizing it with JavaScript, it’s fine. This class will be added to the textarea with JavaScript, to ensure that if JavaScript is turned off, the textarea will scroll normally.

Here is the CSS I’ll be applying to the hidden clone element:

.hiddendiv {
    display: none;
    white-space: pre-wrap;
    width: 500px;
    min-height: 50px;
    font-family: Arial, sans-serif;
    font-size: 13px;
    padding: 5px;
    word-wrap: break-word;
}

A quick break-down: First, I set it to display: none because I don’t want it visible to the user. I believe this should be fine for screen readers, because I don’t want it read out to them either. If anyone has a better solution for hiding it for assistive devices, let me know.

I’ve also set the white-space property to a value of “pre-wrap”. This ensures that lines will wrap correctly, but everything else gets pre-formatted. I’ve also set the width to be equal to the textarea, and duplicated a few typographical properties. In both examples, I’m giving the clone and the textarea a min-height so it will always start out at a standard, usable height.

Now for the JavaScript (which is using jQuery, sorry):

$(function() {
	var txt = $('#comments'),
	hiddenDiv = $(document.createElement('div')),
	content = null;

	txt.addClass('noscroll');
	hiddenDiv.addClass('hiddendiv');

	$('body').append(hiddenDiv);

	txt.bind('keyup', function() {

	    content = txt.val();
	    content = content.replace(/\n/g, '<br>');
	    hiddenDiv.html(content);

	    txt.css('height', hiddenDiv.height());

	});
});

This code assumes we’re targeting a single textarea element on the page. If you need this to affect more than one element, then just change the first line inside the function that defines the element we’re working with.

I’m dynamically changing the height based on jQuery’s keyup event. You could easily change this to respond to an Ajax request instead, if you happen to be loading the content that way.

Using keyup, however, is a good solution because it’s the most likely reason that you’ll want to auto-resize a textarea — user-entered data.

What About IE6-8?

I almost didn’t write this article, because the code wasn’t working at all in IE6-8. The reason for this had to do with the poor way IE handles grabbing content using innerHTML. So after I had written this simple solution that seemed to work in all the newer browsers, I came across this jQuery plugin. That solution uses the exact same method that I’m using (the cloned element), and it worked (mostly) in IE.

So the line that I borrowed from that example that (mostly) fixed mine in IE was:

// fixes the IE innerHTML problem
content = content.replace(/\n/g, '<br>');

But even after adding this line, there was still an issue: Long, unbroken strings of text wouldn’t affect the height of the textarea (which isn’t a big problem, really). A simple fix was adding word-wrap: break-word to the CSS for the clone element.

Bugs? Problems?

Like the other solutions floating around, this could easily be turned into a plugin. In that case, I’d have to add a little more jQuery so that the characteristics of the clone element aren’t dependent on the CSS. Also, if the width of the textarea is fluid, then you’d have to use jQuery to grab that, and then apply it to the clone.

The solution I linked to in the previous section is just about perfect — you just need to add the word-wrap fix that I mentioned.

For a demo, you can view my JSFiddle using the link below. Just be sure to hit the “run” button before you test it. Let me know if you find any problems with it.

Related posts:

1. The CSS3 Resize Property
2. Word-Wrap: A CSS3 Property That Works in Every Browser

On current client project, client says CSS only needs to work in Chrome. Let me know how jealous you are.

The responses weren’t too surprising.

Below I brainstormed a list of some other things we wish clients would say. I guess this is the polar opposite of what you find here, except these quotes aren’t real. Enjoy.

I don’t need to see any design mockups, you just create whatever you think works best.

I’ve never heard of Internet Explorer… I use Firefox.

I’d love to make some recommendations for you, but let’s be honest — I don’t know diddly-squat about design.

I really love how you made the design look *TOTALLY* different in Internet Explorer! You must have put in some extra work on that! Here’s another $500…

I have an idea… Why don’t I just pay you the whole amount up front, so we don’t have to bother with that later?

Feel free to post screenshots of your progress on that basketball-logo website, so you can get feedback from other design professionals.

Can you make the logo smaller?

I hate animation, so make sure nothing moves unless the user wants it to move.

My grandmother wanted to see the site and give you a few suggestions, but I told her to get real.

I know I’ve been paying you $45 per hour for 2 years now, but I think we should increase that to $50. You’ve earned it.

Internet Explorer is a text-only browser, right?

We won’t be having any long, boring meetings. I want you to just focus on what you do best — design and code.

Why would I tell you how to do your job? I don’t tell my mechanic how to do an oil change, do I?

I was going to tell you to create a separate gallery for my cat photos, but my harddrive crashed and I lost all of them.

I don’t want it to look anything like Facebook.

Remember those 10 other projects I said I would ask you to work on if you did this one for a good price? Here’s the downpayment for those — now let’s iron out the details!

That design is not at all what I had envisioned — I love it!

Add Your Own

What do you wish a client would say? Add them to the comments and I’ll feature any good ones here with a link back to your site.

Related posts:

1. The 3 Most Important Things to Consider Before Starting a Design
2. Things You Might Not Know About Conditional Comments
3. Things Worth Noting About CSS Attribute Selectors

His main point is summarized in this quote:

Do you really need a 90k JavaScript library (and thats the minified version) to toggle the size of a menu?

I think his point is valid, and it’s something I’ve seen before in comments, and even from experienced JavaScript developers and bloggers. For example, in an article on SitePoint covering Drag and Drop in HTML5, Alexis Goldstein uses jQuery to demonstrate HTML5′s drag and drop feature. A comment from James Edwards on the post makes a similar point to that of Matt Pass.

I almost responded to James’ commment at the time, and I had written a comment for Matt’s post, but felt this was something I wanted to open up to my larger audience.

Is Library-less Code a Reality Anymore?

Yes, there are small sites built all the time. There are brochure sites, there are one-page info sites, there are microsites — which may not have any, or very little, JavaScript. But those sites are becoming less and less common.

JavaScript libraries are virtually mandatory in websites and web apps today. And sure, it’s nice be able to write things raw like Matt demonstrates in his post. But I feel that in almost all real-world cases, developers will be including at least one major JavaScript library.

So, the problem that Matt points out (i.e. using a sledgehammer to crack a walnut), is actually not a problem at all. In fact, the opposite is true. Because if you are including a library, and you still choose to write lots of raw JavaScript, then you’re probably writing more code than is necessary and are letting the library be a wasted resource.

Yes, in some cases, for performance reasons, even with a library loaded up, you might be better off using raw JavaScript (for example, a simple for loop might be more performant than jQuery’s each() or find() or whatnot). So I’m not completely downvoting the using of raw JavaScript. And that’s besides the fact that oftentimes I just remember the raw version easier than the jQuery version, because that’s how I learned.

But in my opinion, simple code examples that use jQuery are not overkill at all, but are simply catering to the needs of modern developers — the majority of whom are using jQuery in the very projects where they might be using the simple tutorial code Matt is talking about.

JavaScript is Often Beside the Point

Finally, the other reason I think it’s okay to use jQuery in a post like that is that, well, the point of those posts is often more about principles or concepts, not code architecture, cross-browser issues, or other peripheral matters that would, in my view, distract from the point of the post.

So, although a discussion of some of the extra code used with raw JavaScript might have its benefits, I think it’s better to stay focused on the main point of the post, and not get clouded with other more complicated issues. And if anyone wants to learn raw JavaScript, there are plenty of sources for that.

Thoughts?

I will continue to use jQuery even in simple posts that are more focused on CSS3. But maybe there’s something I’m overlooking. Would love to hear anyone’s feedback on this.

Do you prefer that tutorials use jQuery in all cases? Or would you rather see raw JavaScript that can easily be put into a page that doesn’t require any dependencies? Do library-free websites exist anymore?

Related posts:

1. Getting Buggy CSS Selectors to Work Cross-Browser via jQuery
2. Recreating the MLB.com Content Switcher with jQuery and CSS3
3. How to Do Absolutely Everything Ever in jQuery, CSS3, & HTML5

Basically, if anyone typed a random subdomain in place of the “www”, the subdomain would remain in place in the address bar without any redirection occurring. So for example, if you visited peanutbuttersandwich.impressivewebs.com, the site would display as normal, except with the “peanutbuttersandwich” part still intact.

What’s worse is that I have other domains on my current hosting plan, and impressivewebs.com is the primary domain. So if someone typed in a subdomain for one of the other domains, they would actually see the impressivewebs.com home page. For example, if you visited peanutbuttersandwich.animationfillcode.com, you would see the impressivewebs.com home page with the animationfillcode.com URL still in the address bar.

Not exactly something that someone would be likely to stumble across, nor is it an extremely urgent issue, but I think it should be fixed. So in this post I’ll be straying pretty far away from my usual front-end development-related posts, and I’ll be documenting, step by step, exactly what I did to fix this problem on my current dedicated-virtual Media Temple plan. Even if this information doesn’t apply to your current hosting plan, it might nonetheless serve as a reminder to get the problem fixed.

Section 1: Log in to Plesk and Add a New Subdomain

The steps in each of these sections prior to Section 5 are to be done for all non-primary domains in your (dv) hosting plan. For your primary domain, you’ll fix the subdomain problem using .htaccess (see Section 5 below).

First go to your Media Temple account center and log in. To the right of your domain list you should see the “Plesk” login button. Click that button and log in to Plesk with the necessary credentials.

Once into Plesk, click the “domains’ link in the left sidebar:

That will bring up a list of your domains. In there, choose any of the “control panel” options to the right of your domains.

From what I can tell, it doesn’t seem to matter which one of these control panel links you choose. It looks like they all just take you to the same basic “control panel” for all your domains. If anyone wants to correct me on that, please do.

Once inside your control panel, click on the “Websites & Domains” tab along the top navigation:

Once that page opens, you’ll see a list of your domains at the bottom of the page. Above that list you’ll see a link labelled “Add New Subdomain”. Choose that option:

You’ll then be presented with this screen:

This is where we’ll define a wildcard subdomain that will redirect to the primary domain. But the good thing is, this will not affect any real, working subdomains that you might have set up; this will only redirect random non-existent subdomains, and this will also help solve the problem of non-primary domains redirecting to the primary domain on the account.

Section 2: Define Your Wildcard Subdomains for Each Domain

On the “add new subdomain” page, you’ll want to fill in the info to define how to handle the wildcard subdomains. First, for the subdomain “name”, you have to choose a name that will definitely be listed last in a list of named subdomains. Media Temple’s support staff recommended “zz-wildcard”, so that’s what I chose.

Next, you want to make sure to select the correct domain in the drop-down list of domain names for your account. I would assume you’ll be fixing all domains, so in that case, you’ll have to repeat this section for each of the domains you want to fix. Just make sure you don’t inadvertently leave your primary domain as the chosen domain, because that will produce incorrect and possibly harmful results.

Finally, the screen presents you with an option to fill in called “Document root”, also referred to here as the website’s “home directory”. In this option, you want to fill in the exact name of the folder where your files are located for the selected domain. On Media Temple’s (dv) plan, this home directory name was set up when you set up the domain. For my own plan, unfortunately, I had set up the home directories in a non-standard way, so it was a little more complicated for me (See Section 6 below). But for most cases, it should just be a matter of putting in the original home directory name.

Once you fill in the correct info, click “OK” to create the subdomain.

Section 3: Log in With Root Access and Create a vhost.conf File

Now it gets a little more tricky. For those with little command-line experience, it’s a bit challenging. I do some of my command line stuff using PuTTY. Whatever you choose, you need to log in to your server with root access. Evidently you can also do this type of thing via FTP, but the settings in your FTP client are a little different.

Once you’ve logged in, navigate to the home directory of the domain you’re currently fixing (the one you selected when you created the wildcard subdomain in the previous section). In my case, this would mean navigating to:

/var/www/vhosts/selecteddomain.com/subdomains/zz-wildcard/conf

In this example, “selecteddomain.com” would be the name of the home directory that matches the domain you’re fixing. That directory should be empty. In there you want to create a vhosts.conf file. In PuTTY, I do this by typing:

vi vhost.conf

This creates a file called “vhost.conf” and opens it in a text editor in PuTTY. To start editing the empty file, type the letter “a” on the keyboard. This allows you to “INSERT” text into the file. In this file, you then type the following:

ServerAlias *.selecteddomain.com

Where, once again, you would replace the domain name with the domain name you’re dealing with. Once you’ve added this line to the vhost.conf file, hit “ESC” on your keyboard to stop editing the file. To save the file, type the following in PuTTY:

:w

And then hit enter. Finally, you need to restart the server so the new changes take effect. I did this using the following command:

/usr/local/psa/admin/sbin/websrvmng -a -v

I believe there are other ways to do this, and I think you’d have the same effect if you just restarted the server from your Media Temple Account Center, but either way this seems to be a necessary final step to get the new configuration to take effect.

Section 4: Repeat for Each Domain

All the steps outlined above after you click on “control panel” need to be repeated for each domain that you want to fix. Just make sure you select the correct domain in the “Add New subdomain” section, and that you type in the correct home directory.

Also, for each domain, you have to navigate with root access to the respective “zz-wildcard” folder (or whatever you chose to call it), and create a new “vhost.conf” file with the configuration info specific to that domain.

The only domain that you don’t do this for is your primary domain.

Section 5: Fix the Primary Domain

Once you’ve corrected the wildcard subdomain issue on all your secondary domains, you’ll also need to do this with your primary domain. I don’t know squat about .htaccess stuff. Any .htaccess-related code that I ever use will be stuff I find through search.

Fortunately, Media Temple’s staff go above and beyond the call of duty, and one of their techs actually wrote a mod rewrite rule into my .htaccess file to get the subdomain problem fixed on my primary domain. Here’s the code:

<IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteCond %{HTTP_HOST} !www.impressivewebs.com$ [NC]
   RewriteRule ^(.*)$ http://www.impressivewebs.com/$1 [L,R=301]
</IfModule>

And that’s it. Now, if anyone tries to visit a random, non-existent subdomain on www.impressivewebs.com, they’ll just get redirected to the same page with the random subdomain replaced with “www”. Of course, if your domain doesn’t use “www” then you would need a different rewrite rule. All the best with that. :)

Section 6: My Non-Standard Setup

In my case, for some reason, I had set up my other domains as sub-folders of the primary domain. So the home directories were a bit weird and thus the wildcard thing didn’t quite work as expected. But once again, Media Temple’s staff went above and beyond and were able to fix the problem for me.

Basically, since my home directories were all located within my primary domain’s home directory, for each of these secondary home directories, I had to choose “z-selecteddomain” as the “document root” (See the last part of Section 2 above). Then, after creating the subdomain in Plesk, I created an .htaccess file in the new folder with the following rewrite rule:

Redirect 301 / http://selecteddomain.com

This gets done for each domain (except primary). Also the “z-selecteddomain” document root folder could be anything; this name was chosen by the tech to help group them together at the bottom of the folders list.

I really have no idea why my sub folders were configured in this way (it’s not a wrong setup, it’s just unconventional), but this redirect helped iron things out so that the wildcard subdomains were pointing to the correct location.

Conclusion

I’m obviously not a server admin, so what I’ve written above is just a superficial step-by-step reconstruction of what I did to solve this problem.

One of the benefits to having no random wildcard subdomains is the problem of duplicate content for SEO purposes. As it was before, theoretically someone could have linked to any one of my pages using a random subdomain, and if Google indexed the page in that state, it could have created a duplicate content problem. Not that you would necessarily be penalized for such a thing, but I suppose PageRank or overall backlink juice would be split if that were the case.

I also have a few client websites hosted on my account, so imagine how the client would have reacted if they had typed a random subdomain in front of their URL and saw the home page for impressivewebs.com. Not very professional looking, so even though it’s extremely unlikely anyone would notice such a thing, it’s still something that should be fixed.

And of course, if anyone has anything to add or correct, or knows of a way to do this purely with .htaccess (which I don’t think is possible, but who knows?), please offer your feedback.

Related posts:

1. Are Web Development Search Results Being Manipulated?
2. Why I Hate MLB.com’s Navigation
3. One Thing I Don’t Like About Drop-Down Menus

Here’s a list (that I’ll continue to update) containing a wide variety of skills and technologies that I think all front-end developers should be working on learning, at least to some extent. I certainly don’t know all of these, nor do I expect anyone else to.

The list is not necessarily in any particular order, but I tried to keep the more rudimentary stuff at or near the top. Also, many of the items overlap others, so there’s a lot of cross-over within the list. And of course the list has lots of potential for improvements (more on that below).

• XHTML / HTML5
• CSS2.1 / CSS3
• JavaScript / Ajax
• jQuery
• HTML5 Boilerplate
• Modernizr
• YUI Library
• OOCSS
• CSS Grids
• CSS Frameworks / Resets
• Progressive Enhancement / Graceful Degradation
• HTML and CSS Specifications (W3C / WHATWG)
• UX / Usability
• Website Speed / Performance
• Debugging Tools (Firebug, etc)
• Dojo / MooTools / Prototype
• Responsive Web Design
• Mobile Web Development
• Mobile Web Performance
• Cross-Browser / Cross-Platform Development
• Document Object Model (DOM)
• Cross-Browser Bugs and Inconsistencies (primarily IE6-8)
• CSS Pre-Processors (LESS / Sass)
• Version Control (Git / GitHub / CVS / Subversion)
• HTML5 APIs (Canvas, Geolocation, Video, etc.)
• OOP
• Back-end Templating languages/technologies (PHP, Ruby, .NET, etc)
• MySql
• Accessibility
• WAI-ARIA
• Microdata / Microformats
• HTML5/CSS3 Polyfills
• CMS (WordPress, Drupal, Joomla, etc)
• Functional Programming
• Data Formats (e.g. JSON, XML)
• Internationalization / Localization
• Content Strategy
• Offline Web Apps
• Regular Expressions
• Basic .htaccess
• SVG
• Image Editing Tools (Photoshop, Fireworks, etc.)
• Web Font Embedding / Licensing
• SEO Basics

I may eventually turn this post into an extended list divided into categories plus links to articles and tutorials where these subjects can be learned or mastered — but for now you’ll just have to trust your Google searching abilities if you want to learn more on any of these.

Please Contribute

The list is a rough first draft, and I’d be happy to update it and refine it based on any feedback. So please offer your suggestions on how it could be improved and/or expanded and I’ll make any necessary updates.

Related posts:

1. Why Developers Should Be Studying HTML5′s Design Principles
2. Video For Everybody — Except Developers!
3. Decisions CSS Developers Need to Make

I wrote a similar roundup of JavaScript resources, so this time I’m covering stuff related to what we commonly call “HTML5″ (even though a lot of this stuff could easily fall under a “JavaScript” umbrella too).

The Truth About HTML5

The Truth About HTML5, written by Luke Stevens, looks like an honest and informative book on HTML5. The book isn’t released yet, but you can subscribe to get notified when it’s ready.

I don’t know much about the book itself, and it doesn’t seem to be available through mainstream outlets, but you can read a comment by the author on this Smashing Magazine post that shows that he seems to know his stuff, and this could be a good read for those hoping to get a deeper understanding of various HTML5-related features.

Mobile HTML5 Compatibility Tables

You’ve probably seen many CSS3 and HTML5 compatibility resources that mainly focus on desktop browser support. Mobile HTML5 consists of a chart that is touted as “trying to understand HTML5 compatibility on mobile and tablet browsers”.

Compatibility info covers iPhone, Android, Blackberry, iPad, and more.

Roots WordPress Theme

Roots “is a starting WordPress theme made for developers that’s based on HTML5 Boilerplate, Blueprint CSS (or 960.gs) and Starkers that will help you rapidly create brochure sites and blogs.”

The theme is said to be hNews Microformat ready, produces cleaner WordPress code output, in addition to numerous other features. I’m using HTML5 Reset’s WordPress theme for this site, but Roots looks like another good option to look into.

Polyfilling the HTML5 Gaps

Polyfilling the HTML5 Gaps is a fantastic slideshow by Addy Osmani that was part of his presentation at FITC Toronto’s Spotlight HTML5.

Addy provides some very real-world and practical advice for dealing with browser inconsistencies and even teaches you how to write your own HTML5 polyfills. Can’t say enough about this presentation. I’d love to see a video of his talk, but I’m not sure if one exists.

The Web platform: Browser technologies

The Web platform is a simple site maintained on GitHub by Michael Smith. The page links to the official documentation for a number of HTML5 technologies.

Nothing too fancy here, just a good resource to come back to if you want to see what type of APIs and other features are available to HTML5 developers.

The Latest in HTML5

The Latest in HTML5 by Eric Bidelman is another great presentation from earlier this year, and definitely not for the faint of heart. The presentation covers what Eric calls “Lesser known gems” and “smaller APIs for building more powerful web apps” as well as the Web Audio API.

Additionally, there are some neat little interactions that demonstrate some of the stuff being discussed. Some pretty powerful stuff here — you might have to go through this one two or three times.

Move the Web Forward

Finally, although this is not really an HTML5-focused resource, Move The Web Forward is a very cool new initiative put together by a number of great developers. The site promotes the idea that all of us, no matter our circumstances or skill level, can contribute in some way to moving the web platform forward and making things easier for everyone to develop powerful, cross-browser, and high-performance web sites and apps.

You can read more on the project on Addy Osmani’s Smashing Magazine article. The project website has a whole slew of great suggestions for how developers can be more involved in helping the community and ultimately moving the web forward.

Related posts:

1. Some JavaScript Resources Worth Checking Out
2. A New Book on HTML5 and CSS3
3. About Obsolete Features in HTML5