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.