Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
As a web author, reading through a W3C specification can be a very tedious task. If you've ever wondered why that is, there is actually a really simple explanation for it. Specifications are written for implementers, not authors. In the case of CSS, it means that specifications describe, in detail, how browser manufacturers or other user agents should implement the syntax contained within the spec. Now often this will feature detailed parsing information, error handling, and syntax rules.
The very nature of these documents creates a fundamental disconnect between a W3C specification and most web authors, so I want to take a moment and go through a CSS specification with you, discuss its structure and how it's organized, examine the areas that authors should be concerned with and the areas that you can maybe safely ignore, and discuss how to read the syntax that tells you how to properly format your CSS. So I want to take you on a tour of the CSS Fonts Module Level 3 specification.
And if you want to follow along with me, feel free to go to w3.org and search for and find this specification and open it up, although the structure that I am going to be talking about, the syntax rules that I am going to be talking about, are really true for every single CSS specification. So even though we're using this one, it really doesn't matter which one that we use. Now we talked a little bit about the structure of specifications in the previous movie, but just as a way to sort of refresh your memory, remember at the top of each specification, you're going to find an abstract. The abstract basically talks about the purpose of the specification, what's contained within it, why it exists, and what its focus is.
You are also going to get a status of this document. It's going to give you a little snapshot of where it is within the process, what's currently being worked on, and what its next steps are. That's typically followed by either a couple of more sections or a table of contents. You can typically read through the TOC, get a really good idea as to what's going on within the specification, how it's structured, and typically you can focus exactly on what you're looking for. Now towards the bottom of the document--and I am going to let the TOC help us with this-- you're going to typically find a few appendices, maybe some changes, definitely some references, and some indexes. And I'll talk about the indexes in just a moment, but I want to turn your attention to these References first, and this word in particular, Normative References.
You're going to find that word, normative, all over CSS specifications and you might be wondering exactly what it means if you've never run into it before. That's actually a really nice clue for you. If you see Normative, in terms of describing a section to say, like, for example, this section is normative, that essentially means that that section is written for implementers and has detailed information as to how certain parts of the specification are supposed to be implemented within the user agent. As an author, if you see that word, that's a nice clue to you that you can sort of skim through, or ignore, that section.
Now I don't mean to say it's not important. That's not what I'm saying here. What I'm saying is as an author, you're after the meat of the syntax: what can I do with this, how do I write it? You're not after, how should I parse through malformed code? That's really for the implementers, and the word normative is often a really good clue to you that this section is not written exactly for you. Still good reading, still a smart idea to skim through it, but maybe not something that you want to focus on quite as much. Now the indexes, I want to talk about those too. Indexes are great because not only do you get a normal index where you can go look for a specific thing, click, and jump to that, but typically, most CSS specifications will also have a property index.
These property indexes are great because they're going to go and give you a nice sort of overview, or snapshot, of all the properties that are contained within this specific specification. They're going to give you the property, the values that's acceptable for those properties, the initial value, what they apply to, so a really nice summary of all the properties within the specification. And often, if you're just looking for a specific property, this might be the best place to start looking. So I am going to go back up to the TOC, and I want to talk about the way that the properties themselves are written out and structured, and what you can glean from them as an author.
And I am going to start at the top section in the Fonts module, which is the Basic font properties. I am just going to jump down to that section. Okay, so the first property that I see is the font-family property. Now some properties are described in a huge amount of detail, while as others only get maybe one or two paragraphs. The font-family property is described in a large amount of detail. If I scroll through this, you can see what I'm talking about. There's a lot of information that's being given to us here. So this is a really good one to start with. They're not all that detailed, but it's nice to know that on occasion they do go into that amount of detail.
Now the first thing I want to show you is this little snapshot right here, which is actually the same information that we just saw in the property index-- value, what it applies to, that sort of thing. There is some really good information here. First off, I want to show you one that a lot of people typically ignore, which is Media. Here it says font-family applies to visual media. Now that's really helpful to know, because if I'm writing a style sheet, for example, for a screen reader, for an assistive device like that, I know that that's not a visual device, so I know font-family isn't the property that that particular device is going to respond to.
So I can safely sort of ignore setting font-family on anything, whereas for a visual like screen or projection, I definitely want to pay attention to this property. We also see that it can apply to all elements, so there's not a single element within HTML that we can't write font-family for. The values are inherited. So there's a lot of information I can glean from just looking at this little snapshot. Now the thing that probably confuses the most people when they initially start trying to read CSS specifications are the actual values themselves. I mean this looks like gibberish, but it's describing to you exactly how to write the font-family syntax.
Now this is actually something called BNF, which is the Backus Normal Form notation, and it's simply a way to represent the grammar of computer languages. So obviously, for humans it can be a little confusing to read. Now the more that you're exposed to this syntax and the more that you see the resulting CSS syntax that comes from it, the easier it is to read BNF. But I am going to give you just a couple of pointers here to help you along the way, and we're going to go ahead and use font-family to help us do this. Okay, the first thing that you're going to notice are these brackets. We can see, for example, that brackets contain this entire first section.
Well, brackets actually do two things for us. Number one, they help group content, so they are sort of grouping all this together as a single choice. They also tell you that certain things are optional. So a bracket is either grouping something together, telling you that something is optional, or it may be both. So in this case, for example, notice that we also have a grouping of family-name or generic-family. And this sort of pipe character, this vertical line that we see there, that serves as an or. So when we see that, we could say okay, family-name or generic-family, which is followed by a family-name or a generic-family.
We also see this comma. That lets us know that if we're going to use more than one of those, we're going to separate those with a comma. So we could do a family-name, family-name. We can do family-name, generic-family. And then we also see that we have this little asterisk right there. And whenever you have a group in brackets followed by another symbol, that symbol is typically telling you something. Asterisk, for example, indicates that from that following group, you could list zero or more. If there was a question mark, for example, you could use one or none from the following group.
So there's always a nice little indicator as to how many of those items. In this case, you can use as many as you want, so you could have five family names in a row if you wanted to, or two family names, or one; it's totally up to you as to how many you want to use; or you could use the keyword inherit. So there's that little "or" again. So it's like you could either use values from this group, or you could use the value inherit. Okay. One more thing too. Whenever you see these little greater than or less than brackets, that typically means that whatever is inside here is a computed value.
Now, that could be a length. So whenever you see these little bracket notations, sort of less than and greater than brackets, that means that whatever is inside of that is a computed value, meaning you don't actually use family name; you would figure out what family name you're going for. Now typically, typically, most properties are going to explain these computed values in more detail a little bit later on. So if I was to scroll down, for example, I could see that indeed family-name and generic-family are described in more detail a little bit later on, and I could indeed see that family-name and generic- family are described in more detail and I get more information about exactly what they are looking for there.
Now another thing that I get after I sort of slog through all of this stuff here is I get nice examples of code. So I can see that in this case here's a family name, comma, another family name, comma, a generic family. So I can see exactly what this is telling me up here. I can use one of these, one of these, and I can string them together using commas. And this tells me I can use as many of those as I want. Now, specifications don't always do this, but in the case of this property, we also get to see code.
We also get to see examples of invalid code that's being written. So pay attention to both the good examples that they show you, and if they ever show you invalid code, take a look at that as well. It's really going to help you write your syntax properly. Now value notation isn't always this complex, and it's not always that simple. If I were to scroll down, for example, and go down to, say, font-weight, I can see this is very simple. So I have these keywords separated by an or, these values separate by ors, or inherit. So I can use one of those values, it's an either/or.
And then a little bit later on it explains to me what exactly all these numbers mean. Now it can also be a lot more complex. If I go back to the TOC and I go down to the Shorthand font notation, you can see this is a lot more complex than what we had before. There are a couple of things we haven't seen here before, for example, these little double pipes. These little double vertical lines indicate that each value is possible and that if you use more than one of these values, you're going to separate them with whitespace instead of a comma. So these are little things that you're going to pick up on the more you look at this notation and the more that you look at the code that results from this notation.
Now as I mentioned to you before, there are always sections that you can kind of safely ignore when you're reading through the specification, because they're written primarily for implementers. If I go back to the TOC, I can go to the section of the Font matching algorithm. I would definitely encourage you to read through these sections, because they're going to help you understand how these properties are implemented within the browser. But after reading through the first couple of lines of this, it's pretty obvious that this isn't telling an author how to write styles within a style sheet; it's telling a manufacturer or an implementer how exactly to implement the code within the user agent.
So this isn't as useful to authors as it is, obviously, to implementers. So I would recommend that when you run into one of these sections, sort of skim through it. If it has some really good meaty information about how browsers are going to be implementing it, it's just going to set you apart from most authors and you're going to know more about the process. But overall, you can safely sort of skim through those sections and maybe not read through them quite as thoroughly. Now there's one more thing that I want to point out about the specifications. They are living documents. Unless they are a published recommendation, they are being revised.
And if you scroll through this one, you're occasionally going to see these little red notes that says Issue. Sometimes they'll be questions, sometimes they'll actually mention people by name, but they're basically showing you sort of issues that are still outstanding with the specification, and the next version or next few versions should be addressing these concerns. What's nice about that as an author is you can sort of read through those and get a feel for parts of the specification that maybe aren't quite as solid and aren't quite as resolved. You could sort of get an idea as to what's coming down the pipe.
For example, as an author, I am very excited about OpenType features being available in browsers, but I know from reading this that there's still some questions on how that works. And also, if you're reading through these, you may have an opinion on this as an author. You may have a specific opinion on how you think browsers ought to implement that. Well, you can join the W3C's mailing list and you can add your voice to the chorus and make your opinions known on how these ought to be implemented. It's a very, very public process. That's one of the things I really love about reading through the specifications is being a part of that process.
I know it didn't feel like it probably, but that's actually a really brief overview of how to make sense of the CSS specification from an author's point of view. If you really want to dig into CSS and learn it from the ground up, there's actually no better way to do that than spending time in the specifications themselves. I wasn't able to cover all of the syntax or formatting that you're going to encounter when reading these specifications, but you should have a pretty good idea of how to find your way around a spec, the areas that you can sort of skim over, what to pay attention to, and more importantly, how to read the syntax to make sure that you're going to format your rules properly.
If something doesn't really seem to make a whole lot of sense, just be sure to examine the provided examples really carefully, and usually they're going to help you understand what's acceptable for a property and sort of how it works. So just don't be intimidated by the CSS specifications. The more time that you're going to spend reading them, the more that you're going to get out of them.
Get unlimited access to all courses for just $25/month.Become a member
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.