(Это приложение является формальным)
The minimal CSS (i.e., any version of CSS) grammar that all implementations need to support is defined in section 7. The grammar below defines a much smaller language, a language that defines the syntax of CSS1.
It is in some sense, however, still a superset of CSS1: there are additional semantic constraints not expressed in this grammar. A conforming UA must also adhere to the forward-compatible parsing rules (section 7.1), the property and value notation (section 5) and the unit notation (section 6). In addition, HTML imposes restrictions, e.g., on the possible values of the CLASS attribute.
The grammar below is LL(1) (but note that most UA's should not use it directly, since it doesn't express the parsing conventions, only the CSS1 syntax). The format of the productions is optimized for human consumption and some shorthand notation beyond yacc [15] is used:
* : 0 or more + : 1 or more ? : 0 or 1 | : separates alternatives [] : grouping
The productions are:
stylesheet
: [CDO|CDC]* [ import [CDO|CDC]* ]* [ ruleset [CDO|CDC]* ]*
;
import
: IMPORT_SYM [STRING|URL] ';' /* E.g., @import url(fun.css); */
;
unary_operator
: '-' | '+'
;
operator
: '/' | ',' | /* empty */
;
property
: IDENT
;
ruleset
: selector [ ',' selector ]*
'{' declaration [ ';' declaration ]* '}'
;
selector
: simple_selector+ [ pseudo_element | solitary_pseudo_element ]?
| solitary_pseudo_element
;
/* An "id" is an ID that is attached to an element type
** on its left, as in: P#p007
** A "solitary_id" is an ID that is not so attached,
** as in: #p007
** Analogously for classes and pseudo-classes.
*/
simple_selector
: element_name id? class? pseudo_class? /* eg: H1.subject */
| solitary_id class? pseudo_class? /* eg: #xyz33 */
| solitary_class pseudo_class? /* eg: .author */
| solitary_pseudo_class /* eg: :link */
;
element_name
: IDENT
;
pseudo_class /* as in: A:link */
: LINK_PSCLASS_AFTER_IDENT
| VISITED_PSCLASS_AFTER_IDENT
| ACTIVE_PSCLASS_AFTER_IDENT
;
solitary_pseudo_class /* as in: :link */
: LINK_PSCLASS
| VISITED_PSCLASS
| ACTIVE_PSCLASS
;
class /* as in: P.note */
: CLASS_AFTER_IDENT
;
solitary_class /* as in: .note */
: CLASS
;
pseudo_element /* as in: P:first-line */
: FIRST_LETTER_AFTER_IDENT
| FIRST_LINE_AFTER_IDENT
;
solitary_pseudo_element /* as in: :first-line */
: FIRST_LETTER
| FIRST_LINE
;
/* There is a constraint on the id and solitary_id that the
** part after the "#" must be a valid HTML ID value;
** e.g., "#x77" is OK, but "#77" is not.
*/
id
: HASH_AFTER_IDENT
;
solitary_id
: HASH
;
declaration
: property ':' expr prio?
| /* empty */ /* Prevents syntax errors... */
;
prio
: IMPORTANT_SYM /* !important */
;
expr
: term [ operator term ]*
;
term
: unary_operator?
[ NUMBER | STRING | PERCENTAGE | LENGTH | EMS | EXS
| IDENT | hexcolor | URL | RGB ]
;
/* There is a constraint on the color that it must
** have either 3 or 6 hex-digits (i.e., [0-9a-fA-F])
** after the "#"; e.g., "#000" is OK, but "#abcd" is not.
*/
hexcolor
: HASH | HASH_AFTER_IDENT
;
The following is the tokenizer, written in flex [16] notation. Note that this assumes an 8-bit implementation of flex. The tokenizer is case-insensitive (flex command line option -i).
unicode \\[0-9a-f]{1,4}
latin1 [¡-ÿ]
escape {unicode}|\\[ -~¡-ÿ]
stringchar {escape}|{latin1}|[ !#$%&(-~]
nmstrt [a-z]|{latin1}|{escape}
nmchar [-a-z0-9]|{latin1}|{escape}
ident {nmstrt}{nmchar}*
name {nmchar}+
d [0-9]
notnm [^-a-z0-9\\]|{latin1}
w [ \t\n]*
num {d}+|{d}*\.{d}+
string \"({stringchar}|\')*\"|\'({stringchar}|\")*\'
%x COMMENT
%s AFTER_IDENT
%%
"/*" {BEGIN(COMMENT);}
<COMMENT>"*/" {BEGIN(0);}
<COMMENT>\n {/* ignore */}
<COMMENT>. {/* ignore */}
@import {BEGIN(0); return IMPORT_SYM;}
"!"{w}important {BEGIN(0); return IMPORTANT_SYM;}
{ident} {BEGIN(AFTER_IDENT); return IDENT;}
{string} {BEGIN(0); return STRING;}
{num} {BEGIN(0); return NUMBER;}
{num}"%" {BEGIN(0); return PERCENTAGE;}
{num}pt/{notnm} {BEGIN(0); return LENGTH;}
{num}mm/{notnm} {BEGIN(0); return LENGTH;}
{num}cm/{notnm} {BEGIN(0); return LENGTH;}
{num}pc/{notnm} {BEGIN(0); return LENGTH;}
{num}in/{notnm} {BEGIN(0); return LENGTH;}
{num}px/{notnm} {BEGIN(0); return LENGTH;}
{num}em/{notnm} {BEGIN(0); return EMS;}
{num}ex/{notnm} {BEGIN(0); return EXS;}
<AFTER_IDENT>":"link {return LINK_PSCLASS_AFTER_IDENT;}
<AFTER_IDENT>":"visited {return VISITED_PSCLASS_AFTER_IDENT;}
<AFTER_IDENT>":"active {return ACTIVE_PSCLASS_AFTER_IDENT;}
<AFTER_IDENT>":"first-line {return FIRST_LINE_AFTER_IDENT;}
<AFTER_IDENT>":"first-letter {return FIRST_LETTER_AFTER_IDENT;}
<AFTER_IDENT>"#"{name} {return HASH_AFTER_IDENT;}
<AFTER_IDENT>"."{name} {return CLASS_AFTER_IDENT;}
":"link {BEGIN(AFTER_IDENT); return LINK_PSCLASS;}
":"visited {BEGIN(AFTER_IDENT); return VISITED_PSCLASS;}
":"active {BEGIN(AFTER_IDENT); return ACTIVE_PSCLASS;}
":"first-line {BEGIN(AFTER_IDENT); return FIRST_LINE;}
":"first-letter {BEGIN(AFTER_IDENT); return FIRST_LETTER;}
"#"{name} {BEGIN(AFTER_IDENT); return HASH;}
"."{name} {BEGIN(AFTER_IDENT); return CLASS;}
url\({w}{string}{w}\) |
url\({w}([^ \n\'\")]|\\\ |\\\'|\\\"|\\\))+{w}\) {BEGIN(0); return URL;}
rgb\({w}{num}%?{w}\,{w}{num}%?{w}\,{w}{num}%?{w}\) {BEGIN(0); return RGB;}
[-/+{};,#:] {BEGIN(0); return *yytext;}
[ \t]+ {BEGIN(0); /* ignore whitespace */}
\n {BEGIN(0); /* ignore whitespace */}
\<\!\-\- {BEGIN(0); return CDO;}
\-\-\> {BEGIN(0); return CDC;}
. {fprintf(stderr, "%d: Illegal character (%d)\n",
lineno, *yytext);}
(This appendix is informative, not normative)
HTML documents may contain any of the about 30,000 different characters defined by Unicode. Many documents only need a few hundred. Many fonts also only contain just a few hundred glyphs. In combination with section 5.2, this appendix explains how the characters in the document and the glyphs in a font are matched.
The content of an HTML document is a sequence of characters and markup. To send it "over the wire", it is encoded as a sequence of bytes, using one of several possible encodings. The HTML document has to be decoded to find the characters. For example, in Western Europe it is customary to use the byte 224 for an a-with-grave-accent (à), but in Hebrew, it is more common to use 224 for an Aleph. In Japanese, the meaning of a byte usually depends on the bytes that preceded it. In some encodings, one character is encoded as two (or more) bytes.
The UA knows how to decode the bytes by looking at the "charset" parameter in the HTTP header. Typical encodings (charset values) are "ASCII" (for English), "ISO-8859-1" (for Western Europe), "ISO-8859-8" (for Hebrew), "Shift-JIS" (for Japanese).
HTML [2],[4], allows some 30,000 different characters, namely those defined by Unicode. Not many documents will use that many different characters, and choosing the right encoding will usually ensure that the document only needs one byte per character. Occasional characters outside the encoded range can still be entered as numerical character references: 'Π' will always mean the Greek uppercase Pi, no matter what encoding was used. Note that this entails that UAs have to be prepared for any Unicode character, even if they only handle a few encodings.
A font doesn't contain characters, it contains pictures of characters, known as glyphs. The glyphs, in the form of outlines or bitmaps, constitute a particular representation of a character. Either explicitly or implicitly, each font has a table associated with it, the font encoding table, that tells for each glyph what character it is a representation for. In Type 1 fonts, the table is referred to as an encoding vector.
In fact, many fonts contain several glyphs for the same character. Which of those glyphs should be used depends either on the rules of the language, or on the preference of the designer.
In Arabic, for example, all letters have four different shapes, depending on whether the letter is used at the start of a word, in the middle, at the end, or in isolation. It is the same character in all cases, and thus there is only one character in the HTML document, but when printed, it looks differently each time.
There are also fonts that leave it to the graphic designer to choose from among various alternative shapes provided. Unfortunately, CSS1 doesn't yet provide the means to select those alternatives. Currently, it is always the default shape that is chosen from such fonts.
To deal with the problem that a single font may not be enough to display all the characters in a document, or even a single element, CSS1 allows the use of font sets.
A font set in CSS1 is a list of fonts, all of the same style and size, that are tried in sequence to see if they contain a glyph for a certain character. An element that contains English text mixed with mathematical symbols may need a font set of two fonts, one containing letters and digits, the other containing mathematical symbols. See section 5.2 for a detailed description of the selection mechanism for font sets.
Here is an example of a font set suitable for a text that is expected to contain text with Latin characters, Japanese characters, and mathematical symbols:
BODY { font-family: Baskerville, Mincho, Symbol, serif }
The characters available in the Baskerville font (a font with only Latin characters) will be taken from that font, Japanese will be taken from Mincho, and the mathematical symbols will come from Symbol. Any other characters will (hopefully) come from the generic font family 'serif'. The 'serif' font family will also be used if one or more of the other fonts is unavailable.
(This appendix is informative, not normative)
See the Gamma Tutorial in the PNG specification [12] if you aren't already familiar with gamma issues.
In the computation, UAs displaying on a CRT may assume an ideal CRT and ignore any effects on apparent gamma caused by dithering. That means the minimal handling they need to do on current platforms is:
"Applying gamma" means that each of the three R, G and B must be converted to R'=Rgamma, G'=Ggamma, G'=Bgamma, before handing to the OS.
This may rapidly be done by building a 256-element lookup table once per browser invocation thus:
for i := 0 to 255 do
raw := i / 255;
corr := pow (raw, gamma);
table[i] := trunc (0.5 + corr * 255.0)
end
which then avoids any need to do transcendental math per color attribute, far less per pixel.
(This appendix is informative, not normative)
The goal of the work on CSS1 has been to create a simple style sheet mechanism for HTML documents. The current specification is a balance between the simplicity needed to realize style sheets on the web, and pressure from authors for richer visual control. CSS1 offers:
<H1>H<FONT SIZE=-1>EADLINE</FONT></H1>
with the style sheet:
H1 { font-style: small-caps }
<H1>Headline</H1>
CSS1 does not offer:
We expect to see extensions of CSS in several directions:
We do not expect CSS to evolve into:
Copyright © 1996 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Назад | Содержание | Вперед