support for alternate ways of linking to stylesheets?

[kermit]

here is the stylesheet block from my existing static site:

Code: Select all

<style type="text/css" media="screen">
<!--
@import url("css/base.css");
-->
</style>
<!--[if IE 6]><link href="css/ie6.css" rel="stylesheet" type="text/css"><![endif]-->
<!--[if IE 5]><link href="css/ie5.css" rel="stylesheet" type="text/css"><![endif]-->
<link rel="stylesheet" type="text/css" href="css/print.css" media="print" />

the only one that can loaded using existing cmsms method is print.css

while i can upload (via file manager) the ones referenced in the non-standard way, and can reference them directly in a template, i cannot edit them in the admin interface.

possible to support these alternate methods?  perhaps radio button or pull-down selection (when you bring up a stylesheet for editing) for the options such as: "link" (the 'normal' way), "@import" (the more-or-less accepted way to hide a stylesheet from <=v4 browsers), "@import url" (same as 'import' but ie4 understands it) and conditionals (yes, proprietary microsoft junk, but it's the best way to spoon-feed styles to their inadequate browsers), such as "IE 6" and "IE 5" (and just "IE".. i suppose there'll be an "IE 7" at some point too). the selected option, of course, tells cmsms how to insert the stylesheet into the code.

i can see the process going something like this: code examines the attached stylesheets, in order. starting with the first, all consecutive ones linked the same way and using the same media get combined, in order, and inserted into the template. then on to the next one that's different and repeat. the admin interface would ensure that @imports are listed first and maybe suggests that print media ones are last in order and follow handheld and projection ones.

there are so many different ways to reference a stylesheet, it's probably not feasible to support them all. however, they are well documented (see top part of http://www.dithered.com/css_filters/css_only/index.php ), so it may not be too much to support them all and even reference the target/hidden browsers for each method.  the syntax and other info could be stored in the database for easier additions and updates down the road (the same block of php code should be able to work with any of the methods).

i don't know of any other cms packages that can handle stylesheets internally using a variety of methods like this. people usually have to resort to hard-coding them into their templates when they need to use one of the other methods. not that big a deal when the server is sitting at your desk, but when the web interface is the best way you've got (or only way for some).. then it's nice to be able to handle any layout or design right in the browser.

this would need to be in addition to being able to specify what order stylesheets get applied (because @import'ed ones go first); which is something i noticed earlier as missing from the current version.

unfortunately my php skills are not up to par to do this, best i can do is offer the idea and how i picture it working.

[kermit]

ie conditionals and @import, as well as the other methods to link to a stylesheet do not rely upon the user agent sting. they work or they don't work, as expected and documented, on specific browsers and versions. as such, they are far more reliable than simply trusting a user agent string. for instance. if an opera user is sending an ie user agent, they will still not "see" an ie conditional; however they will trick a script into sending the wrong stylesheet; while a firefox user with the 'view as ie' extension active would see the ie conditional even if their current user agent string said firefox.

while most people don't mess around with user agents, some do; and some browsers have a facility built into them (or easily added) to do it. because they are user editable, they cannot be relied upon for styling, and shouldn't be, especially when there are other methods available that work independently of the user agent string.

and by serving the same styles regardless of user agent, it means those stylesheets are properly cached (because all are attached to a page, just referenced differently). if the software determines what styles are linked to the template when served to the client, and they change based on client's user agent string, caching them becomes more difficult as they can change from visitor to visitor.

sniffing a user agent string can be handy in limited situations, such as msntv/webtv. there's not a lot of documentation out there on hiding stylesheets from msntv since they started supporting @import a couple years ago (it also supports 'screen' media type instead of a more logical alternative such as 'tv', or even 'webtv' since media types aren't set in stone by css specs). i think nesting stylesheets in one another (using @import in a css file) is the only way now; and that could be a logistics nightmare from the administration end the way things are done now in cmsms. if someone wants to ensure usability on msntv, content and primary navigation should be within the first 550px width or so of a page (without the entire design scrunching on the narrow display). let them scroll horizontally if they want to see the rest, but the main content should fit within that liimit.

[nils73]

kermit,

while I absolutely agree with you that filtering via CSS (i.e. conditional comments, @import, etc.) is much better than a browser-detection that might be tricked, I must admit that it is an expert-option and "could" be handled via CMSMS but as StyleSheets are something that do not change that often you could also link them in the template and upload the stylesheets via FTP.

However it might be handy to have a plugin for "conditional comments" CSS --- but as far as I am concerned, I can live with the current solution pretty well since I use a lot of CSS hacks and filters which do not work in the CMSMS CSS-editor. But maybe the editor itself could be changed. ;o) There are some good solutions out there (like in Textpattern) that I would prefer ... but as said before: I can live with external stylesheets since they are easier to maintain and since I update them only once in a while I do not need a CMS to handle this task.

Regards,
Nils

[kermit]

one of my points is that you shouldn't have to "hardcode" something as basic as a stylesheet in software that's designed to manage both the design of a site and it's content.

similarily, one should be able to use something like {theme_directory}/images/header.gif or {theme_directory}/scripts/menu.js to reference images or other external files in a template. the software then adds the absolute path it.  granted, something like this might be in the works for the new theme manager that's expected in an upcoming version.

the site should be entirely managable from the web-based administration. once the site is installed (if it was installed that way), one should not have to resort to ftp for anything. not everyone is comfortable with or even knows how to use ftp. i taught an office full of people how to use mambo a couple years ago, and none of them would've been able to even comprehend ftp.