Talk:Cascading Style Sheets

• todo-list of Cascading Style Sheets

• Started: 31 October 2003
• Size: 20,000 words (Sep 2008)
• Recent changes
• All subpages
• Search: search the book in Google

CSS is not a programming language --User:CarbonUnit

I thought the whole idea of using CSS is to encourage separation of the format from the content. Or at least that is what every page on CSS in wikidom seems to indicate. So why do you include the alternate method of inlining the style tag? Thus,

Additionally, it can be added as an attribute within an HTML tag within the style attribute, as thus:

style="property:value"

Maybe you are intertwining the conversation about various methods of generating styles with the promotion of using CSS.

—Preceding unsigned comment added by 68.230.41.55 (discuss • contribs) 15 August 2005

Just adding, XHTML does NOT require CSS, XHTML behaves exactly like HTML but with stricter coding rules, and CSS is technically a programming language. —Preceding unsigned comment added by 69.204.17.68 (discuss • contribs) 8 July 2006

With all due respect our learned friend '69.204.17.68' above, I would suggest that Cascading Stylesheets are not in fact a programming language. There is a specified syntax, yes, but this about that is in common with a programming language. HTML is not a programming language; BNF is not a programming language; configuation files (e.g. .ini files) are not written in programming languages…. So, I would like to suggest we rename this book to 'Cascading Stylesheets'. Anyone concur? — Sam Wilson (Australia) 00:20, 23 May 2008 (UTC)

Agreed. CSS is not a programming language. --Sydius (talk) 03:39, 21 August 2008 (UTC)Reply

Agreed. Per Sydius; CSS has no control structures such as if or while. --Dan Polansky (talk) 08:50, 7 September 2008 (UTC)Reply

CSS should not be merged with XML and/or XHTML / HTML. (Note: It has also been suggested to merge XHTML with XML, which could potentially result in XHTML, XML, and CSS all in one project.) The beauty of CSS is that it's supposed to operate on XHTML/XML without having to change the XHTML / XML at all. Intertwining the two defeats the purpose of having CSS in the first place. A simple reference between the two, perhaps with an introductory paragraph explaining the interaction between CSS and XML, should suffice. However, combining the books would make it difficult for someone interested only in CSS (from a design standpoint) to access the information that he or she needs, as he or she would have to filter out a great deal of extraneous information.

I do acknowledge that using CSS effectively requires a simple understanding of XHTML, but merging all of these subjects into one book is going to result in way too much complexity in one project (especially considering the minutia of detail in advanced XHTML, CSS, and XML) and make it much more difficult to organize the information in a way that is accessible to a novice user or reader. Keeping the projects separate allows the contributors and editors to more easily manage the information in each topic, and allows each topic to advance at its own pace.

Regardless of whether CSS is "technically" a programming language, it should be taken into account that the primary use of CSS is design. I think you'll find that you have an entirely different type of reader reading CSS from a design standpoint as compared to someone reading XHTML or XML from a coding/standardization standpoint.

I feel strongly that combining CSS and XML (and possibly XHTML) into one resource would result in a bloated, complicated project that would suffer greatly from lack of oversight and long-term planning due to its size, complexity, and unfocused scope. If you are concerned about compatibility or integration issues between CSS and XML, I think the best way to address this would be to write a common article or page which could then be included (using wiki's include markup) in both books. This would save effort and afford each book its own organization and pace of advancement. --banzaimonkey 23:50, 12 July 2006 (UTC)Reply

I'd like to make two points: 1) XML is a deep subject; a book on XML should not be a reference on all languages based on XML; 2) CSS is a distinct and significant enough subject to warrant separate coverage. I also echo banzaimonkey's view that Wikibooks should freely hyperlink among each other; this increases the likelihood of each work being used and thus maintained. —Preceding unsigned comment added by 86.42.145.83 (discuss • contribs) 26 August 2006

I have started merging duplicate content from XML: Managing Data Exchange/CSS into this book. That module will be left as an overview of CSS in the context of XML/XHTML. The details of CSS sytntax and properties will move into the relevant modules in this book. —Preceding unsigned comment added by 88.107.237.171 (discuss • contribs) 6 September 2006

Great, that's exactly how I'd do it, too. CSS is definitely a subject that can fill a whole book. Can we just remove the merging suggestion banner? It's been there long enough. Dilaudid 00:46, 25 October 2006 (UTC)Reply

I've noticed some extremely technical people roaming through Wikiland lately insisting the strictest of organizing standards. Within their world, I wholly acknowledge a deep, thorough, exposition of any topic. And if there is a Wikiway to give them that, then I'm all for it. But Wikiland will die if it becomes too hard for average folks to get any usefull information.

HTML, CSS, XHTML, XML, XSL, the many *scripts are all interrelated. Absolutely. That does not mean you lump them all into one book, page or anything. If you did that the page would lose it specialization.

Just don't do it.

--134.241.58.251 00:06, 25 October 2006 (UTC) Bill from BostonReply

The current Introduction needs improvement, but I'm not the one to do it. I'm here to learn CSS, not yet qualified to rewrite these pages.

What's missing for me in the introduction is something about how CSS is actually deployed. I'm gradually getting the idea that there are two ways: a) define style tags in the current page's header and then make calls on those tags in the body of the page; b) define style tags in a separate file and tell the current page to look to that file for tag definitions. I THINK that's what's going on with deployment, but this page doesn't explicitly say so, and should.

Further, it would be helpful if there were some sample code shown for both defining style tags and calling on them. An example with supporting explanatory text is always clearer than explanatory text on its own (which is what's currently on this page).

And because pages like this will attract two classes of readers, this first page should be written to satisfy both. By two classes I mean folks like myself who have seen some HTML code but that's about all (and looking to move to the next stage in their understanding) and those folks who already know several computer languages and live and breathe standards. It's a tough act to write to both audiences at once, but honestly that's what you've got. I submit, as difficult an act as that is, its essential, otherwise you'll confuse and frustrate both audiences.

Kind regards,

Wanapitei (talk) 22:32, 31 December 2007 (UTC)Reply

My impression is that these pages only occasionally mention the differences between the browsers, yet _real_ CSS 'programming' often consists of making web pages work as well in one browser as another (and on different platforms, too). (I'm by no means an expert, but have quite a lot of 'make it work' experience.) Is there room here somewhere for pointing out what works where? I used to use a product called TopStyle (Windows only, so I don't use it any more) which let you select a browser, or a CSS level, and you got to see what would be rendered, using the CSS you wrote. It also showed you what properties worked with which browser, before you selected them. Can some of that know-how get into here? —Preceding unsigned comment added by 80.177.18.39 (discuss • contribs) 23 January 2008

I did some cleanup on the introduction to make it easier to read, less redundant, and more professional. It's still far from good (to me), but I hope it's better. --Sydius (talk) 04:13, 21 August 2008 (UTC)Reply

I have moved the introduction to a dedicated chaper. Hope it's okay. Many more parts are now in dedicated chapters, so the first page should provide a nice overview of the content of the book, uncluttered by the content itself. --Dan Polansky (talk) 08:52, 7 September 2008 (UTC)Reply

I couldn't find it as far as I've looked... I found this method used on WP's CSS file:

#content a[href$=".pdf"].external,

It makes the links of PDF extensions have an image to the right of it. My question is: is there a term for this (bolded font), and does this book document it somewhere? -- 203.171.195.247 (talk) 20:55, 2 November 2009 (UTC)Reply

This may be a little lat for you but the answers to your questions are:

1. [href$=".pdf"] is an attribute selector, and
2. as far as I can tell at the moment it has not been added to this book yet

Hope these belated answers helps --Dlrohrer2003 22:54, 19 December 2009 (UTC)Reply

1) You are using a class name called "important" in some of the examples. Because there is a keyword "important" readers can get confused.

2) Cascading Style Sheets/Important is the ; optional for the last item in a style as implied by the examples this chapter?

QuentinUK (discuss • contribs) 12:21, 8 July 2011 (UTC)Reply

I support that the main page shows a table of contents, getting the reader as quickly as possible to the sought content. Hency my reverting edit. --Dan Polansky (discuss • contribs) 21:28, 14 February 2013 (UTC)Reply