- [Voiceover] As a web author,
reading through a W3C specification
can be a very tedious task.
If you've ever wondered why that is,
there's actually a really simple explanation for it.
Specifications are written for implementors,
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.
You know 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 it's 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, you know the structure
that I'm going to be talking about,
the syntax rules that I'm 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 way to sort of refresh your memory,
remember that 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 it's focus is.
You're also going to get a status for 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 it's next steps are.
That's typically followed by either a couple more sections,
or a table of contents.
You can typically read through a TOC,
get a really good idea as to what's going on
within the specification,
how it's structured,
and typically can focus exactly on what you're looking for.
Now towards the bottom of the document,
and I'm 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 implementors 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 implementors,
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
your normal index where you can go look
for a specific thing, click and jump to that,
but typically most CSS secifications
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'm 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'm going to start at the top section
in the fonts module,
which is the Basic font properties.
So I'm 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, you know,
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's 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 assisted device like that,
I know that's not a visual device,
so I know font family isn't a property
that that particular device is going to respond to.
So I can say please sort of ignore setting font family
on anything.
Whereas for 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 the 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 B and F,
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 the syntax
and the more that you see the resulting CSS syntax
it comes from,
the easier it is to read B and F,
but I'm 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're sort of grouping all this together
as a single choice,
and 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 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 can say okay.
Family name or generic family,
which is followed by family name or generic family.
We also see this comma,
that let's 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 comma family name,
we could do family name comma 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 follow group,
you could list zero or more.
If there's 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 can 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's inside here
is a computed value.
Now that could be a length.
So whenever you see these little bracket notations,
the sort of less than, greater than brackets,
that means that whatever's 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 can see that indeed,
family name and generic family are described in more detail
and I get more information about exactly
what they're looking for there.
Now another thing that I get after, you know,
I sort of slog through all of this stuff here,
is I get nice example of code.
So I can see that in this case,
here's a family name comma another family name comma
generic family.
So I can see exactly what this is telling me up here.
I can use 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 examples of invalid code
that's being written.
So, pay attention to both the good examples
that they show you,
if they ever show you invalid code,
that a look at that as well.
That's really going to help you write your syntax properly.
The 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 wait.
I can see this is very simple.
So I have these keywords separated by an or
or these values separated by ors or inherit.
So I can use one of those values,
it's 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 a couple things we haven't seen here before,
for example, these little double pipes,
those 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 white space
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 implementors.
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 implementor
how exactly to implement the code within the user agent.
So this isn't as useful to authors
as it is obviously to implementors.
So I would recommend it 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.
There's one more thing that I want to point out
about these specifications,
they are living documents.
Unless they're a published recommendation,
they're 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 a 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, you know,
I'm very excited about open type features
being available in browsers
but I know from reading this
that there's still some questions
on how that works,
and also, you know, 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
and that's one of the things I really love
about reading through the specifications
and 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 a 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.
You know, the more time that you're going to spend
reading them,
the more that's you're going to get out of them.