CODEWITHSUNDEEP
cssxhtmldreamweaver
Jitendra Vyas
Jitendra Vyas

Reputation: 152807

Why does Dreamweaver add CSS code in comments? Should we always use this comment to use CSS in <head>?

What is the benefit to add CSS code in comments?

<STYLE type="text/css">
<!--
   H1 { color: red }
   P  { color: blue}
   -->
</STYLE>

Should we use this always or isn't there any need? Is it same like CDATA for JavaScript?

Upvotes: 2

Views: 564

Answers (4)

bobince
bobince

Reputation: 536615

It's archaic cruft meant to support HTML 2.0 browsers from 15-odd years ago. Those browsers didn't know about the <script> and <style> tags, so unless the content inside them was hidden inside comment markup, it would spit them out onto the page as text content, causing a nasty mess.

There is absolutely no purpose to the practice today, but still it hangs on, thanks to cut-and-paste coding and poor authoring tools like Dreamweaver.

In XHTML served as XML you must not include the comment markup, otherwise your script or stylesheet really is only a comment and will be completely ignored.

Some authors use a <![CDATA[ ... ]]> section for scripts and stylesheets in XHTML, but this is for a completely different reason. It allows you to include a literal < or & character inside the content without having to do the correct XML thing and escape it to &lt; or &amp;. Apart from making code harder to read, an HTML-escape in scripts and styles would confuse legacy non-XML HTML parsers: in HTML4, the script and style elements are magic and can have those characters in without escaping (the one sequence you can't use is </ since that ends the element).

When you do use a CDATA section in a document you intend to be read by non-XML HTML parsers, you should use a CSS or JavaScript comment to hide the CDATA section markup:

<script type="text/javascript">//<![CDATA[
    ...
//]]></script>

<style type="text/css">/* <![CDATA[ */
    ...
/* ]]> */</style>

For the old-school comment-wrapping common in HTML 3.2, an exception was made to CSS and JS parsing to allow <!-- and --> sequences to slip through unnoticed, but this is not the case for <![CDATA[ or ]]> which would be seen by a CSS or JavaScript parser as a syntax error.

If, heaven forbid, you needed to support HTML 2.0, 3.2+ and XHTML parsers, you'd end up needing this hideous mess:

<script type="text/javascript"><!--//--><![CDATA[//><!--
    ...
//--><!]]></script>

<style type="text/css"><!--/*--><![CDATA[/*><!--*/
    ...
/*]]>*/--></style>

thankfully this is never going to happen.

You can usually get away with no comment or CDATA cruft at all, since CSS almost never needs to use the < or & characters, and in JavaScript you can usually recast less-than comparisons as harmless >, and logical-ands to inverted logical-ors. Both CSS and JavaScript offer native escapes for when you want to put a < or & character in a string literal (eg. '\x3C').

In any case, significant amounts of style and script — where you're most likely to want to use those characters — should generally be in an external linked file, making the point moot.

Upvotes: 5

o.k.w
o.k.w

Reputation: 25820

In Dreamweaver (DW), it's very 'convenient' to change the page's doctype declaration.

If XHTML is used, <!-- .... --> or<!CDATA[[ ... ]]> will kick in to enable strict parsing and compliance.

In any case, it is backward compatible (almost) with other doctype declarations, it make sense for DW to always use this convention.

Upvotes: -1

Doug Neiner
Doug Neiner

Reputation: 66201

You should always include your styles in external stylesheets whenever possible. When you have to include them on the page, it more common to see the contents wrapped in <!CDATA[[ ... ]]> blocks than comments.

The comments will not disable the rules in any modern browsers.

Upvotes: 1

Joel
Joel

Reputation: 19368

This is done for backwards compatibility with rendering engines that do not understand the style tag. By placing your styles in a comment, the engine will (hopefully) not render them as plain text.

This practice is less important now that the majority of clients can render styles properly, but it is still somewhat common to see. I generally neglect it in my own code, but that's personal preference.

Upvotes: 2

Related Questions