If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Suggested CSS does not validate

I have a question about a snippet of CSS that has been recommended on several posts on this forum:

Code:

* {
border:0;
margin:0;
padding:0;
}

This accomplishes the desirable object of having getting rid of various browsers' proprietary margins and padding on elements. I put that snippet in a stylesheet; but when I sent the page for validation, it came back as a parse error:

Parse Error - ���* { border:0; margin:0; padding:0; }

(Using the Firefox Web Developer toolbar feature to Validate Local CSS; the three empty boxes are actually three black diamonds with white question marks, if that means anything to anyone...)

The only other errors in the CSS had to do with my use of opacity, which I know is not part of the standard so I expect and tolerate those errors.

Can someone please explain what that snippet of CSS is and why it is necessary/recommended but not valid? And is there a valid way to accomplish the same thing? Or is that another error to expect and tolerate...

Can someone please explain what that snippet of CSS is and why it is necessary/recommended but not valid? And is there a valid way to accomplish the same thing? Or is that another error to expect and tolerate...

That snippet is fine, as you can see by pasting just that portion into the direct input validator here:

And here is the other stylesheet the page references; it is for the thickbox.js functionality (thickbox.css); obviously, I did not write this (it is courtesy of ThickBox3) but it has a similar piece of CSS at the very beginning:

Pasting those two pieces of CSS into the validator you linked I get the expected errors about the opacity and filters, and a couple of warnings (which did not show up on my page... odd). But not the two parse errors my page received.

I will continue to pare down my page to try to find why the same CSS alone gives a different result than when it is referenced on my page.

Thanks for the link to the validate from textarea site; I will use it frequently.

(Using the Firefox Web Developer toolbar feature to Validate Local CSS; the three empty boxes are actually three black diamonds with white question marks, if that means anything to anyone...)

I believe that the black diamond character is the Unicode Replacement Character (U+FFFD). You see it when a character is unrecognized in a document encoded as UTF‐8 (like the CSS validator pages are). I often see the character when a document is displayed under the wrong encoding.

Make sure that you’ve saved and served the document using the correct encoding. For example, if the CSS/HTML/XHTML document encoding is ISO-8859-1, make sure that you specify ISO-8859-1 and not UTF‐8. The encoding can be specified by HTTP headers, an @charset at‐rule in the CSS file, or by use of a byte order mark (BOM) in UTF encodings.

Also make sure that you don’t have any invisible characters in your document. You might try copying your entire CSS file to a new file or deleting that rule and then manually retyping it to see if you can get rid of such characters if they are there. If using an editor like Notepad++, you can click the paragraph icon to show invisible control characters.

For every complex problem, there is an answer that is clear, simple, and wrong.

This is on a local machine using the ASP.net 2.0 web developer server for the time being (real server (Windows Server 2003) for local intranet is under reconstruction at the moment). So when you say it should be saved and served with correct encoding, what else am I to do?

Thank you for all of your help; this forum is the best site I've found in ages to help novices learn from the experience of others.

I am not sure I understand where I am to specify the document encoding. Here is the head section of the page; my charset appears to be windows-1252, right?:

Well, the document declares itself as such anyway. You can’t really tell the encoding without looking at the file itself though. Basically, you save it (encode it) then declare it.

I’m not really sure of a general method to tell what the encoding of your documents is except to always save them with the same encoding. In Notepad++, it says the encoding in the status bar for ANSI and UTF‐8; maybe your editor, “Expressions Web”, can do that too.

You can save the document encoded as this or that in various ways, depending upon editor. In Microsoft Notepad, you go to Save or Save As and select your encoding from the drop‐down box. In Notepad++, you select it from the Format menu. I would always recommend UTF‐8; you can then enter characters from any language (plus symbols) directly into your document instead of encoding them via character references (e.g., ➤, directly, instead of &x#27a4;, indirectly).

Anyway, if your style sheet is not embedded in that XHTML document, then you’re looking in the wrong place since it was the CSS file that, apparently, had the error. You can declare the encoding of a CSS document by using, for example, @charset "UTF-8";; it has to be the first thing in the document.

For every complex problem, there is an answer that is clear, simple, and wrong.

I copied and pasted the CSS in Notepad and saved it with UTF-8 encoding as you suggested. When I viewed the page again in FF, a little set of odd characters showed up at the top of the page:

ï»¿

Just as you suspected, HIDDEN SYMBOLS... I have no idea what this is or where it came from; I do remember there was another post last week on this forum that had something similar.

The weird thing is I could not see it in the code in MS Expressions Web or in Notepad. It showed in the View Source of Firefox, but I could not change it from there. I finally opened the page in HTML-Kit and was able to delete the cryptic symbols. Saved the page again and now everything validates just fine.

Does anyone have any idea where that thing came from? (I'm kind of looking around for that guy from 'The Net' at this point...)

Notepad always includes one and it cannot be disabled. Good text editors can save files as UTF-8 without the BOM. You should really never save your UTF-8 files with the BOM in web development. This can lead to other more serious problems in PHP.

This is not a really a problem for style sheets because you rarely need any non-ASCII characters. In such cases you can just save the file as ANSI/ASCII in Notepad. It will then be identical to a file saved in UTF-8 without the BOM.

So, koyama, can you recommend a good plain-text editor that won't give me the BOM? Or will it suffice to just make sure that in Notepad I always use the ANSI rather than UTF-8 (I don't remember where I read it, but quite a while ago I did read something that suggested always saving CSS and JS as UTF-8... Confusion reigns!)

So, koyama, can you recommend a good plain-text editor that won't give me the BOM? Or will it suffice to just make sure that in Notepad I always use the ANSI rather than UTF-8 (I don't remember where I read it, but quite a while ago I did read something that suggested always saving CSS and JS as UTF-8... Confusion reigns!)

Style sheets never require special characters. So if you save a style sheet in Notepad as ANSI, then the file is identical to the one you would get if you could save it as UTF-8 without a BOM. There is absolutely no difference. Notepad suffices for this purpose. So I think your sources have mislead you. If you can dig up that source maybe someone here could clarify some things.

Notepad does not suffice if you need to save a file containing e.g. Japanese kanji when it needs to be saved as UTF-8 without a BOM. For this purpose you need another editor. Adobe GoLive is always mentioned as an example of an editor with such capabilities, but it is not the only one.

Yeah, in case you didn’t read koyama’s resource, look at the last sentence of the fourth paragraph for the immediate explanation. Basically, the document is UTF‐8, but being misrepresented as ISO-8859-1. This could be errors in your code, your server settings, or your browser settings.

If you want to experiment, you can see and change the current character encoding by going to “View > Character Encoding” in Firefox. Internet Explorer more conveniently allows you to do this by simply right‐clicking the page.

Originally Posted by koyama

Notepad always includes one and it cannot be disabled. Good text editors can save files as UTF-8 without the BOM. You should really never save your UTF-8 files with the BOM in web development. This can lead to other more serious problems in PHP.

PHP seems to be the main problem with the BOM; it fails entirely when a document has one. I hear that PHP 6 is supposed to fix this when support for Unicode is added.

Originally Posted by koyama

This is not a really a problem for style sheets because you rarely need any non-ASCII characters.

Personally, I save them as UTF‐8 anyway since I may use special characters (A) for thecontent and quotes properties (B) within CSS comments. I may also use UTF‐8 for (C) a consistent encoding of all documents. An example of a property that might use special characters:

Code:

a:before { content: "➤ "; }

Of course, Internet Explorer doesn’t support either of those CSS properties.

Originally Posted by koyama

Style sheets never require special characters. So if you save a style sheet in Notepad as ANSI, then the file is identical to the one you would get if you could save it as UTF-8 without a BOM. There is absolutely no difference.

Generally speaking, you’re right, although I’ve just shown how you might get a non‐ANSI character into a style sheet. The characters are not “required” though, just as they are not required in HTML, since both languages have their own character escaping mechanisms.

Originally Posted by koyama

Notepad does not suffice if you need to save a file containing e.g. Japanese kanji when it needs to be saved as UTF-8 without a BOM. For this purpose you need another editor. Adobe GoLive is always mentioned as an example of an editor with such capabilities, but it is not the only one.

Yeah, I have GoLive. It saves as UTF‐8 without the BOM. It’s not free though, I never found a way to change the encoding (not that I tried hard), and I mostly didn’t use it because it took so long to load. Like all of Adobe’s programs, it seems to be a behemoth.

My favorite editor is Notepad++ as well. The two reasons that I started using it were for encoding and being able to control the width of the tab character (some people may have noticed that I use tabs now when previously I used two spaces per indent).

I also find that it’s better for other reasons though: you get tabbed documents (like in a browser), it remembers what files you had open when you close it, you can use it to open the file in Firefox and Internet Explorer, you can show hidden characters, code is color‐coded, the program is light weight, word wrap is easy to turn on and off, you can alter the indentation of multiple lines simultaneously, etc.

About the only things that have annoyed me so far as that it doesn’t seem to support glyph substitution (so, if you use a character not in the current font, you see the Replacement Character) and it’s a bit tedious to first set up the color‐coding to suit one’s tastes.

Anyway, with regard to the current issue, Notepad++ lets you just remove the BOM via a menu. It specifically has a menu item labeled “UTF‐8 without BOM”.

For every complex problem, there is an answer that is clear, simple, and wrong.