Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Welcome to 'ciwas',this is our FAQ for stylesheet authors v1.16


[ Usenet FAQs | Web FAQs | Documents | RFC Index | Neighborhoods ]
Archive-name: www/stylesheets/authoring-faq
Posting-Frequency: twice a week (Mondays and Thursdays)
Last-modified: April 10, 2003
Version: 1.16
URL: http://css.nu/faq/ciwas-aFAQ.html
Maintainer: Jan Roland Eriksson <rex@css.nu>

See reader questions & answers on this topic! - Help others by sharing your knowledge
ciwas stylesheet authoring FAQ v1.16
______________________________________________________________________

The Purpose, Scope and Notation of this FAQ-list.

This FAQ-list contains the edited result of a collective effort among
regular participants in the Usenet newsgroup...
  comp.infosystems.www.authoring.stylesheets

The purpose of this document is to provide answers to a few of the
most frequent questions raised in the 'ciwas' Usenet newsgroup.

At the moment, almost all discussion on this group relates to CSS,
although that might not always be so. This document does not aim to be
a complete tutorial in stylesheets or in CSS.

There is a separate FAQ-list about the Usenet group itself, its
charter, customs and posting conventions. For further information
about stylesheets and about CSS see the resources listed in the
resource sections of  http://css.nu/faq/ciwas-mFAQ.html

The following notational convention is used in this FAQ.

Single quote marks are used to denote keywords,
  e.g. 'font-family'
and those quote marks are not a part of the keyword.

Double quote marks are used to denote text that is quoted from
another source, and/or to mark jargon.
  e.g. "Generic font family names are keywords..."
would indicate that the line contains quoted material.

Stars denote emphasized text...
  e.g. *not*
would put emphasis on the word "not".
______________________________________________________________________

00: ===== T O C =====
01: I want my page fonts to look the same every where as in...
 a) Why are my font sizes different in different browsers ?
 b) Why are my font sizes different on different platforms ?
02: Why shouldn't I use fixed sized fonts ?
03: Which font names are available on all platforms ?
04: How can I make a page look the same in e.g. NS and MSIE ?
05: Why is my external stylesheet not working ?
06: Why does Netscape lose my styles ?
07: How does a simple CSS style rule look ?
08: How can I suggest a different link appearance in various sections
    of my page ?
09: Why is it my ':hover' declaration for links does not work ?
10: Where can I learn more about CSS ?
11: How can I check my CSS creations and find out about errors ?
12: What is this thing I hear about <!DOCTYPE... declarations ?
13: Where can I find the latest version of this FAQ ?
14: Is this FAQ available in other languages ?
15: What is the difference between ID and CLASS ?
______________________________________________________________________

01: ===== Q & A =====

Q:  I want my page fonts to look the same everywhere as in...
 a) Why are my font sizes different in different browsers ?
 b) Why are my font sizes different on different platforms ?

A:  These questions represent the tip of the iceberg of a large topic
    about which whole essays have been written and a wide range of
    different views are held.

    The WWW was originally devised to present the same *content* in
    different presentation situations and for a wide range of readers:
    on that basis, "looking the same" is not a design criterion,
    indeed different presentations would be *expected* to look
    different.

    Some would have it that this original aim is no longer relevant,
    and that the purpose of web design is now to factor out the
    differences between display situations and put the author in
    control of the details of the presentation. Others point out that
    CSS was designed to give the reader a substantial amount of joint
    control over this process, and that this is desirable, for example
    to accommodate users with different visual acuity.

    Reading of textual matter on a computer screen is quite a
    delicate business, what with the relatively coarse pixel structure
    of a computer display; even with a close knowledge of the display
    details, it isn't possible to achieve the detailed control that
    would be possible, say, on a printer. Whatever one's aims, the
    practical truth is that many of the efforts made to guarantee the
    precise result on the screen have seriously counterproductive side
    effects in a www situation.

    The CSS specifications themselves recommend that authors should
    not use absolute size units in a situation where the properties of
    the display are unknown. There's a lot to be said for flexible
    design, that in an appropriate situation looks the way you had in
    mind, but still successfully conveys content and message in a wide
    range of other browsing situations.

    And so, before looking at the technical detail of what can be
    specified, it's strongly suggested that you read some of those
    essays on web design, and reach your own conclusions as to
    the strengths and weaknesses of the medium, and how you can best
    exploit the strengths in a web environment, without falling foul
    of the weaknesses.

    Suggested reading material...
    http://style.cleverchimp.com/
    http://www.westciv.com/style_master/house/good_oil/not_paper/


02: ===== Q & A =====

Q:  Why shouldn't I use fixed sized fonts ?

A:  Only in very rare situations we will find users that have a 
    "calibrated" rendering device that shows fixed font sizes correct.
    This tells us that we can *never* know the *real* size of a font
    when it's rendered on the user end.

    Other people may find your choice of font size uncomfortable.
    A surprisingly large number of people have vision problems and
    require larger text than the average. Other people have good
    eyesight and prefer the advantage of more text on the screen that
    a smaller font size allows. What is comfortable to you on your
    system may be uncomfortable to someone else.

    Browsers have a default size for fonts. If a user finds this
    inappropriate, they can change it to something they prefer.
    You can never assume that your choice is better for them. So,
    leave the font size alone for the majority of your text. If you
    wish to change it in specific places (say smaller text for a
    copyright notice at the bottom of page), use relative units so
    that the size will stay in relationship to what the user may have
    selected already.

    Remember, if people find your text uncomfortable, they will not
    bother struggling with your web site. Very few (if any) web sites
    are important enough to the average user to justify fighting with
    the author's idea of what is best.

    Suggested reading material...
    http://css.nu/articles/font-analogy.html

    See also Q & A - 01: above.


03: ===== Q & A =====

Q:  Which font names are available on all platforms ?

A:  The simple answer is "None" which is why CSS offers five generic
    font names as 'serif', 'sans-serif', 'cursive', 'fantasy' and
   'monospace'. Never put any of these generic font names in quotes.

    A CSS aware browser should make a suitable choice from the
    available fonts in response to each of those generic names.

    Specifying any other font name in a www environment comes out as
    a *suggestion* only, that may or may not be acknowledged by a
    browser.

    The problem with using names of specific fonts is that there is
    little point in naming fonts that few users will have, so you're
    down to listing a few mass-market font names. This will then
    override any superior selection that a minority of discerning
    readers may have made for themselves.

    Note also that fonts may differ in their character repertoire,
    but this is often not evident from the font name itself:
    by selecting an inappropriate font name, you might prevent
    internationalized content from displaying correctly for a
    proportion of users.

    Also beware of the fact that MSIE on Windows platforms has a few
    bugs in the font selection area, as described here...
    http://css.nu/pointers/bugs.html

    For more details on the 'font-family' property, see...
    Section 5.2.2 "font-family" in the CSS1 specification...
    http://www.w3.org/TR/REC-CSS1#font-family


04: ===== Q & A =====

Q:  How can I make a page look the same in e.g. NS and MSIE ?

A:  The simple answer is, you can't, and you shouldn't waste your time
    trying to make it *exactly* the same. Web browsers are allowed,
    per definition, to interpret a page as they like, subject to the
    general rules set down in the HTML and CSS specifications.

    As a web author you can not have a prior knowledge of the exact
    situation and/or medium that will be used to render your page, and
    it's almost always rather counterproductive to try to control that
    process.

    There is no necessity for a well-written page to look the same in
    different browsers. You may want to strive to ensure that it looks
    *good* in more than one browser, even if the actual display (in
    the case of graphical browsers) comes out a bit different.

    "Looking good" can be achieved by adopting sensible design and
    guidelines, such as not fixing the size or face of your fonts, not
    fixing the width of tables, etc...

    Don't fight the medium; most web users only use one browser and
    will never know, or bother to find out, that your page looks
    different, or even "better", in any other browser.

    So accept that the flexibility built into the www medium is your
    friend and just make sure that users can get at your content in an
    easy way, and design your pages accordingly.


05: ===== Q & A =====

Q:  Why is my external stylesheet not working ?

A:  There may be several different reasons behind that, but one very
    common mistake is to have an external stylesheet that contains
    HTML markup in some form.

    An external stylesheet must contain *only* CSS rules, and if
    required, correctly formed CSS comments; *never* include any HTML
    syntax, such as <style type="text/css">...</style>, in your
    external stylesheets.

    CSS comments are defined as anything that is placed between
      /*  (the comment start mark) and
      */  (the comment end mark). I.e. as follows...

    /* This text right here is a correct CSS comment */

    CSS comments may span multiple lines in the stylesheet.
    Nesting of CSS comments is *not* allowed.

    Another reason for external stylesheets (and even embedded and
    inline stylerules) not to function as expected may be that you
    have tried to make use of some CSS-features that are not supported
    in the browser you are using.

    Browser support for CSS varies and a good place to find out more
    about what is or is not supported is "The Mastergrid"...
    http://www.webreview.com/style/css1/charts/mastergrid.shtml

    External stylesheets shall also be served from the www-server with
    a MIME-type of 'text/css' in its 'Content Type:' HTTP header.

    You may need to negotiate with your server admin to add this
    MIME type to your server if you are not able to configure the
    server yourself.

    Registered MIME types can be found in the IANA repository...
    ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/

    RFC2318 describes the specific 'text/css' MIME type.
    http://www.ietf.org/rfc/rfc2318.txt

    HTTP header content for www resources may be checked here...
    http://www.rexswain.com/httpview.html
    http://www.delorie.com/web/headers.html
    http://www.webmastermatrix.com/webtools/HTTP%20Header%20Viewer.htm


06: ===== Q & A =====

Q:  Why does Netscape lose my styles ?

A:  Netscape 4.x has poor support for CSS. Having said that, the
    following points should be noted.

    Invalid HTML will almost certainly cause Netscape to ignore your
    CSS suggestions at some point. You will find that valid HTML is
    your best friend, but for Netscape to work properly you must
    ensure that *all* elements in your markup which permit closing
    tags are explicitly closed.

    Check and correct your CSS suggestions for the very same reason,
    Netscape 4.x is in fact doing "the right thing", as per CSS specs
    (as opposed to MSIE) when it ignores style rules with errors.

    Netscape 4.x has what's called an "inheritance problem" into its
    TABLE element. It can be argued that NS is all within its right to
    behave as it does in this case, but since the workaround is quite
    simple it's easy enough to just use it and be done with it.

    Let's say you want your TABLE content to "look the same" as your
    BODY content? "Redundant" styling comes to your help as in e.g.

      BODY, TABLE, TH, TD { /* insert your styles here */ }

    On a generic level, Netscape 4.x likes to have style rules applied
    directly to the elements where they are needed. You can never
    really trust the inheritance principle to work correctly at any
    level in Netscape 4.x.

    See... http://css.nu/pointers/bugs.html for more details of bugs
    and workarounds in Netscape's CSS support.

    A good method to limit the influence of CSS in the Netscape 4.x
    family of browsers is to make use of the '@import' trick to serve
    only such levels of CSS to Netscape 4.x that it can cope with.

    Johannes Koch describes svereal methods that can be used to
    isolate certain browsers from CSS rules that are supported less
    than good...
    http://pixels.pixelpark.com/~koch/hide_css_from_browsers/


07: ===== Q & A =====

Q:  How does a simple CSS style rule look ?

A:  P { font-family: serif; font-size: 1.2em; }

    Here we see a rule with a 'selector' P that has been given two
    style declarations, i.e. two 'property:value' pairs.

   'font-family'  and  'font-size' are properties of the content of
    element P, and these properties are assigned the values of 'serif'
    and '1.2em' respectively.

    A colon ':' is the *value assignment symbol* in CSS, so using an
    equal sign '=' instead is an *error* and is required by the CSS
    specification to be ignored. Any browser that appears to honor
    this style is behaving improperly.

    For length values a 'unit' is always needed and there shall
    *never* be any space between a number and its length unit.

    A value given as e.g. '1.2 em' is an *error* and is required by
    the CSS specification to be ignored. Any browser that appears to
    honor this style is behaving improperly.

    A semicolon ';' *between* declarations is required but it's also
    good "rule of thumb" to put a ';' even after the last declaration.

    Finally, curly braces '{...}' group one or more declarations into
    a final CSS rule.

    For more details on the basics of CSS style rules,
    see Section 1 "Basic concepts" in the CSS1 specification...
    http://www.w3.org/TR/REC-CSS1#basic-concepts


08: ===== Q & A =====

Q:  How can I suggest a different link appearance in various sections
    of my page ?

A:  The most direct approach is to define separate classes for your
    link types and then use those classes directly in your <a href=...
    markup. The following is a simple example based on info from the
    CSS2 specification sections 5.11.2 and 5.11.3.

    http://www.w3.org/TR/REC-CSS2/selector.html#link-pseudo-classes
    http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes

      a.internal:link    { background: #c0c0c0; color: #800080; }
      a.internal:visited { background: #c0c0c0; color: #008080; }
      a.internal:hover   { background: #c0c0c0; color: #00ffff; }
      a.internal:active  { background: #c0c0c0; color: #008000; }

      a.external:link    { background: #ffffff; color: #ff0000; }
      a.external:visited { background: #ffffff; color: #0000ff; }
      a.external:hover   { background: #ffffff; color: #ffff00; }
      a.external:active  { background: #ffffff; color: #00ff00; }

    And in your markup you can then use...

     <a class="internal" href="#foo">Link to Foo</a>
     <a class="external" href="http://bar.baz">Link to Bar</a>

    ...to suggest a difference in appearance for what could be your
    internal or external links. Most CSS properties are available for
    setting up style rules for links and the example above is kept to
    a minimum only to save space.

    Also note that the grammatic rules for CSS1 only allows for this
    following link selector format to be used...
 
    a.internal:link { background: #c0c0c0; color: #800080; }

    ...while the grammar for CSS2 allows for both of these...

    a.internal:link { background: #c0c0c0; color: #800080; }
    a:link.internal { background: #c0c0c0; color: #800080; }

    Since support for the CSS1 syntax is more wide spread, it is
    advised that you only use CSS1 syntax for your link style rules.


09: ===== Q & A =====

Q:  Why is it my ':hover' declaration for links does not work ?

A:  Assuming you have already checked that your style sheet
    declarations do conform to correct CSS syntax, it could be that
    you have overlooked the importance of a correct order of style
    declarations for links.

    The CSS2 specification makes this following note on the importance
    of placing the dynamic pseudo-classes ':hover' and ':active' in
    correct positions in a list of style declarations.

   "Note that the 'a:hover' must be placed after the 'a:link' and
    'a:visited' rules, since otherwise the cascading rules will hide
    the 'color' property of the 'a:hover' rule. Similarly, because
    'a:active' is placed after 'a:hover', the active color will apply
    when the user both activates and hovers over the 'a' element."

    See also Q & A - 08: above for an example of correct ordering of
    link style declarations, and further, for the full theory, see
    these parts of the CSS2 spec.

    http://www.w3.org/TR/REC-CSS2/selector.html#link-pseudo-classes
    http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes

    Note that the ':hover' pseudo-class entered into CSS specs in CSS2.
    Browsers that do not claim to support CSS2 at any level, can not be
    expected to support the ':hover' pseudo-class. E.g. Netscape 4.x
    and Opera 3.x browsers does not have support for the ':hover'
    pseudo-class.


10: ===== Q & A =====

Q:  Where can I learn more about CSS ?

A:  The meta-FAQ for comp.infosystems.www.authoring.stylesheets has a
    resource section that lists a large number of URL's to www-sites
    that are know to contain good information on how to use and author
    Cascading Style Sheets (i.e. CSS for short).

    The meta-FAQ is posted here in this NG with the same frequency
    as this FAQ, but can also be found on the www as an HTML document.
    http://css.nu/faq/ciwas-mFAQ.html
    ...or as a plain text document...
    http://css.nu/faq/ciwas-mFAQ.txt


11: ===== Q & A =====

Q:  How can I check my CSS creations and find out about errors ?

A:  For traditional markup syntax validation...
    http://www.htmlhelp.org/tools/validator/
    http://valet.webthing.com/page/
    http://validator.w3.org/

    For CSS check-ups...
    http://www.htmlhelp.org/tools/csscheck/
    http://jigsaw.w3.org/css-validator/validator.html.en

    Make friends with the URL's above, they *will* save you a lot of
    time and frustration. To emphasize this point, *overly* correct
    HTML markup -- I.e. explicitly closing elements which do not
    strictly require this -- and correct use of CSS, is essential to
    ensure properly rendered CSS on the www.

    The validator located at webthing.com (The Page Valet, URL above)
    has an experimental "normalised markup" option that makes use of
    "spam" (SPAddMarkup) to insert, among other things, the optional
    closing tags. "The Page Valet" is based on exactly the same code
    and error messages as is used for the validator at htmlhelp.org

    "To err is human", but for once there is something that computers
    can help out with: *error checking*. Just like spell checkers may
    catch irritating typos that are so hard to spot by eye, HTML
    validators and CSS checkers are available on-line to check your
    web pages (URL's above).

    You will need to use your knowledge of HTML and CSS to interpret
    the results of these tools, but you can post follow-up questions
    to this NG, comp.infosystems.www.authoring.stylesheets for further
    discussion.


12: ===== Q & A =====

Q:  What is this thing I hear about <!DOCTYPE... declarations ?

A:  A couple of popular www browsers have been programmed to contain
    more than one document rendering mode, one mode that is designed
    to mimic old browsers rendering behavior and another mode that is
    designed to follow avilable CSS recommendations as best possible.

    The former is usually refered to as "quirks" mode and the latter
    as "strict" (or "standard") rendering mode.

    These browsers makes use of a specific entry in the document
    prologue named 'DOCTYPE' declaration and inspects the content of
    such a declaration to decide on how to proceed with the rendering
    phase for a document.[a]

    Browsers that are not designed to do "<!DOCTYPE... sniffing" will
    not be affected by the inclusion of a 'DOCTYPE' declaration, so
    from a CSS point of view, you can always include a declaration
    that makes sense for the rendering mode you want to suggest.

    The following is valid for (X)HTML documents served with a
    'Content-Type: text/html' in their HTTP document headers.

    For HTML 4.01 you should be safe to use this declaration in your
    document prologue if your target is to suggest activation of the
    "strict" rendering mode in browsers that makes use of
    "<!DOCTYPE... sniffing"

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
      "http://www.w3.org/TR/html4/strict.dtd">

    For XHTML 1.0 this following declaration should be safe in your
    prologue for the purpose of suggesting a "strict" rendering mode.

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    For additional information on the full span of variations that
    came as a result of the introduction of "<!DOCTYPE... sniffing",
    please consult the following www resources.

    http://gutfeldt.ch/matthias/articles/doctypeswitch.html
    http://www.hut.fi/u/hsivonen/doctype.html
    http://world.std.com/~mmcirvin/mypages.html#doctype
    http://www.mozilla.org/docs/web-developer/quirks/doctypes.html

[a] The concept of a 'DOCTYPE' declaration has its roots in the SGML
    standard and is used there for a completely different purpose.
    A description of that original use of a 'DOCTYPE' declaration is
    considered to be outside the scope of this FAQ-list.


13: ===== Q & A =====

Q:  Where can I find the latest version of this FAQ ?

A:  This FAQ was last updated 2002/08/28 copyright 2000, 2001, 2002
    -- Jan Roland Eriksson.

    Permission to freely reproduce this document electronically is
    given as long as the document remains uncut and unedited.

    This FAQ is posted periodically to the NG every Monday and
    Thursday and I'll endeavor to use the same subject line at all
    times so that those of you who have seen it can kill-file the
    subject.

    FAQ version number in subject line will be changed whenever the
    document has been revised. You should be able to use that fact
    when setting your kill filter to make sure that you have the
    latest version available at all times.

    This FAQ is also available in HTML on the World Wide Web;
    at... http://css.nu/faq/ciwas-aFAQ.html

    ...and as a text document;
    at... http://css.nu/faq/ciwas-aFAQ.txt

    ...with the revision history of this FAQ;
    at... http://css.nu/faq/ciwas-aFAQ-rev.html


14: ===== Q & A =====

Q: Is this FAQ available in other languages ?

A:  Matthias Gutfeldt maintains a German translation of this
    original FAQ-list on the www at...
    http://gutfeldt.ch/matthias/translation/css_faq/ciwas-aFAQ.html

    Rijk van Geijtenbeek maintains a Dutch translation of this
    original FAQ-list on the www at...
    http://rijk.op.het.net/info/niwo/ciwas/ciwas-aFAQ.html

15: ===== Q & A =====

Q:  What is the difference between ID and CLASS ?

A:  A class can appear any number of times in a document. An id can only
appear once.
    An ID can be used for:
      Anchors:  <h1 id="foo"> .... </h1> with <a href="#foo"> somewhere
in the document.
      Direct adressability by scripts:
        document.getElementById('bar').firstchild.nodeValue = 'Hello
world!';
      There's also a difference between CLASS and ID attributes as
regards to 
	  the allowable format of values. By HTML rules, CLASS is CDATA,
which 
	  basically means 'anything goes', but CSS rules impose some 
	  restrictions. And by HTML rules, ID is ID, which means that
only 
	  letters of the English alphabet ([A-Za-z]), digits ([0-9]),
hyphens
	  ("-"), underscores ("_"), colons (":"), and periods (".") are 
	  permitted, and the first character must be a letter (and
underscores 
	  don't work reliably)

16: ===== E N D =====
______________________________________________________________________

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
Jan Roland Eriksson <rex@css.nu>





Last Update March 27 2014 @ 02:12 PM