I saw this mentioned a few times recently, but I'd really like to put out the call again.
This group needs an FAQ *specific to this list* which helps new members /
posters integrate seamlessly... really, I'm sick of seeing non specific
subject lines like "please help", and I'm sure we're all sick of typing
replies to frequent questions, usually with a response like "I think you
should check the manual before posting".
I'm sure we're also sick of posts which don't ask specific questions
("what's wrong with my 150 lines of code??").
When I first joined this group, I too was unaware of what was considered a
"good post" (and perhaps still, I don't know!!), but some form of welcome
email when people join the group, or a reminder email sent weekly which
"keeps the peace" on this list will not go astray.
Perhaps it could:
- include some information on how to use the online manual/website (and the
simplicity of searching)
- cover some frequently asked topics which can be summarised with a link to
a few manual pages or external references (how many times do we see "user
authentication", "sessions", "mail attachments", "html email", "header
redirect" and "javascript" in the subject line???? Usually, the writer asks
a very generic question, seeks references and tutorials, or doesn't know
what function to search for in the manual, or they're just lazy. A quick
reference to these frequent topics will save a heap of time for all
concerned.
- remind people that there is an archive to this list that can be searched
(and include the URL)
Some of the posts (including OT posts, ones with meaningless subject lines,
ones which ask insane questions, etc etc) in this group would be laughed at
by members of other programming language groups (Perl for example).
As PHP grows as a language, and as the community of users grows with it,
this list is going to become higher volume. The FAQs are going to become
more frequent, and the poor use / misuse of this list will grow with it.
I can already see frustration growing in this list.
I'd like to think that the list and it's standards can be raised a little,
to make it a more valuable resource for all users, without the grief.
I attach as a reference a text file FAQ which is posted frequently to the
newsgroup comp.infosystems.www.authoring.stylesheets. It provided me with
an excellent resource when I first joined the group, and does help the list
stay somewhat moderated and "clean".
I'm not saying it's exactly what we need, but I do feel it's time we do
something.
Sure, new users *could* find the archive by hunting, the *could* get flammed
for a bad post, poor question, or for not checking the manual first, but
wouldn't it be a smarter move long term for some sort of guideline/FAQ to be
incorporated into the list upon subscription, and perhaps on a weekly
basis??
I'm happy to help in any way I can, but don't consider myself "guru" enough
to develop this from scratch.
Apologies for the long post, especially since this topic has been kicked
around before.
Regards,
Justin French
--------------------
Creative Director
http://Indent.com.au
--------------------
CSS FAQ.txt
Description: application/applefile
From: Jan Roland Eriksson <[EMAIL PROTECTED]> Reply-To: Jan Roland Eriksson <[EMAIL PROTECTED]> Organization: The CSS Pointers Group Newsgroups: <comp.infosystems.www.authoring.stylesheets>, <comp.answers>, <news.answers> Followup-To: comp.infosystems.www.authoring.stylesheets Date: Friday, 22 March 2002 7:17 AM Subject: Welcome to 'ciwas',this is our FAQ for stylesheet authors v1.14 Archive-name: www/stylesheets/authoring-faq Posting-Frequency: twice a week (Mondays and Thursdays) Last-modified: March 10, 2001 Version: 1.14 URL: http://css.nu/faq/ciwas-aFAQ.html Maintainer: Jan Roland Eriksson <[EMAIL PROTECTED]> ciwas stylesheet authoring FAQ v1.14 ______________________________________________________________________ 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: Where can I find the latest version of this FAQ ? ______________________________________________________________________ 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.delorie.com/web/headers.html 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. 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: Where can I find the latest version of this FAQ ? A: This FAQ was last updated 2001/03/10 copyright 2000, 2001 -- 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 13: ===== E N D ===== ______________________________________________________________________
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
