I just stumbled upon something amazing. HTML allows colons (:) and periods (.) in ID tokens.
At first I thought this was awesome because, well, how cool is that?! But then I realised that neither of these are any use in CSS:
#foo:bar{ /* Looks for an element with an ID of foo and a pseudo-selector(class/element) of bar */ }
#foo.bar{ /* Looks for an element with an ID of foo and a class of bar */ }
So, whilst these are perfectly valid in HTML, they’re useless in CSS they can be styled with CSS. Kinda sucks, huh? But! If we know they’re okay in HTML and totally pointless in CSS, can we use that to our advantage?
Answer: yes!
Fragment identifiers
This is just the fancy name for when you link to an element with an ID on it, e.g. <a href="#content">Skip to content</a>.
I regularly use fragment identifiers when writing long articles with certain sections in them. The best and most relevant example I have is my epic on web type on Smashing Magazine.
Here I have a list of links to sections in the article, but you should notice I prefix each ID (and therefore its corresponding link’s href) with #tt-. This is so that I know that my sections will (almost definitely) not be picked up by Smashing’s CSS. If I had a section called #face and, for whatever crazy reason, Vitaly had a huge photo of himself with an ID of #face there would have been conflicts.
This was a situation where I needed IDs for no styling whatsoever, but rather to be used as fragment identifiers. And, to circumvent any of these potential hiccups, I namespaced all my fragment identifiers with #tt-, standing for technical type.
Here enters my little discovery…
If we want an ID that won’t be styled with CSS because we only want to link to it then we can use a colon or a period in there to:
- Ensure that CSS cannot touch the element even if it wanted to.
- Namespace the fragment identifier to show that it is meant as a link hook and give it some more human-friendly semantics.
Demo
I’ve made a demo page of this to a) prove that it works and b) show you how it works in situ.
Run it through the validator, see, it works!
I’ve also tested it in IE7+, Chrome and Firefox Mac and Win.
Problems?
Not that I can think of right away, but bear in mind that these elements cannot be styled via that ID.
For the most part the elements will be styled on an element-level basis (e.g. table{}, pre{} and so on) so styling them explicitly should not be too important.
If you do find you need to style them individually you could:
- Use a class.
- Revert to the tried and tested non-colon-or-period syntax.
A standard
I’ve never ever seen this anywhere before but I am already thinking it will be incredibly useful to me and any others who write documentation, articles or anything else with sections.
I propose a (loose) standard whereby you namespace your fragment identifiers with relevant information, so if you’re linking to a table in a document give the table an ID of #table:sales-figures, a figure showing a technical drawing an ID of #figure:engine-section, a section of an article an ID of #section:intro and so on.
I have created a GitHub repo with an initial list of potential namespacing values there could be. I encourage and appreciate your contributions!
Any thoughts and feedback on this would be great!
Addendum
Ben ‘Cowboy‘ Alman points out that escaping the colon will allow you to style the ID via CSS, as will escaping the period:
#foo\:bar{ /* Works! */ }
#foo\.bar{ /* Works! */ }
By Harry Roberts on Monday, June 20th, 2011 in Web Development. Tags: CSS, HTML, Semantics | 15 Comments »
+
"Cowboy" Ben Alman said on 20 June, 2011 at 6:37 pm
Harry, you can declare CSS like this: #a\:b { … } to match an element with an id=”a:b”. Just escape the “special” chars with a backslash.
http://jsfiddle.net/cowboy/tERrd/show/#a:b
Harry Roberts said on 20 June, 2011 at 6:39 pm
Ah nice one, good knowledge. Thanks!
Mark S said on 20 June, 2011 at 6:49 pm
My only worry (now) is the proposal for a standard, which then causes the issues that you were expressing before with ID’s
Otherwise, I love this article!
Ian Devlin said on 20 June, 2011 at 7:00 pm
Ok, that explains your excitement. Nice find for sure!
Ilia said on 21 June, 2011 at 10:09 am
Hmmm, it’s an interesting discovery, though if these can be styled after all I’m not sure how useful it is. My worry here is that it’s definitely a bit confusing – it’s unfamiliar code, both on the HTML side (but at least with HTML it’s unusual and that’s about it), and on the CSS side where it gets even more confusing because it looks like something else.
I’m not usually one to argue against more options as it were, but in this case, I think if anything the spec should be more restrictive and prohibit the use of colons and periods in IDs.
Harry Roberts said on 21 June, 2011 at 10:13 am
@Ilia:
I get where you’re coming from, but the fact that these are so ‘hard’ to style with CSS (i.e. you can’t really accidentally type an escaped selector) means the chances of styling is nigh-on zero.
All new things are to begin with!
The idea is to avoid styling these, that’s the whole point, so you’d not see them in your CSS at all…
Gaël Poupard said on 21 June, 2011 at 11:48 am
Very interesting !
But with css3 attribute selectors you could style fragment identifiers using this, too :
E[attribute*=value]
It works on every modern browsers.
And I’m not sure, but I think it could be useful using this tip as a new semantic level. Microformats may just be the first step of a more subtle semantic, adding some kind of roles (or whatever you want) directly to classes and IDs.
In fact, using this in order to “unstyle” elements is a good idea, but you can’t avoid element’styles or parent selector’styles to be applied. But there is so much to do with colons and periods that it could inspire very powerful tricks !!!
Henrique Erzinger said on 21 June, 2011 at 12:22 pm
Is there any need to use the tule of element in te namespace? Sounds linda dumb to me.
Luke Connolly said on 21 June, 2011 at 3:03 pm
This is great stuff, Harry. Coupled with the fact that you could always go back in and use the ‘/:’ trick above, this gives a lot of flexibility. Definitely support this as a standard for id labels that are solely for fragment IDs.
Ben Demaree said on 22 June, 2011 at 1:46 pm
This is a very cool strategy; I like it.
My only question is how this runs into HTML5. For example you have doubly defined
articleandfooterin your spec. Won’t this cause semantic confusion?Harry Roberts said on 22 June, 2011 at 1:55 pm
I’m not entirely sure I follow… The namespaces are tied to elements or types of elements already defined in HTML, regardless of the version number.
Could you provide more info please?
Cheers,
H
Ben Demaree said on 22 June, 2011 at 2:19 pm
I spent some time hacking together a demo page and I think my point is irrelevant if you’re being strict with your markup…which I assume you are. :-p
Apologies for the confusion. Thanks again for the technique.
Mathias Bynens said on 24 June, 2011 at 12:58 pm
I wrote about which characters HTML allows in
classandidattributes before: http://mathiasbynens.be/notes/html5-id-class That article has some crazy demos, and it also explains how to escape any character so it can be styled with CSS.Travis Forden said on 7 July, 2011 at 1:21 pm
While an interesting idea, I think adds unnecessary confusion and complication.
Namespacing the ID with the element is rather brittle, particular if you need to change your HTML. You now have to change your ID to match the new element, which essentially breaks URLs that use the old fragment.
Colons and periods have specific uses in CSS and it complicates a readers understanding of what these do. Seems to make maintenance harder. Not sure why these characters are more useful than a hyphen, which allows you to achieve the same effect but without introducing potential points of confusion.
How does it work in the JavaScript case? Are you now escaping all your IDs? Do these characters have special meaning in JavaScript? I often use fragments to set up controls like tabbed boxes, where the fragment on the tab identifies which block of content to show (having that ID).
Mathias Bynens said on 8 July, 2011 at 5:25 am
@Travis, you could use mothereffingcssescapes.com to answer all those questions. Here’s an example: http://mothereffingcssescapes.com/#foo%3Abar