Re: [WSG] The Big Lie about CSS
I haven't seen many problems with updating css files yet. As someone else pointed out most browsers check whether it's been updated or not. 99% of the time it all works fine. What's worrying though are developments such as server-side CSS. While it can do some nice things it really defeats the purpose of CSS. Yet quite some people are advocating it. Shaun Inman for example: http://www.shauninman.com/plete/2005/08/css-constants If you use that you might as well go back to font tags and change those server-side all the time ;) - Marco On Mon, 19 Sep 2005 [EMAIL PROTECTED] wrote: I was thinking this morning that we constantly tell people two things about CSS, as in this wonderful presentation: http://www.hotdesign.com/seybold/ (pages 9 and 10) we tell them a) it's more efficient because the style sheet only gets downloaded once! and then we tell them b) you can reformat your whole site just by changing the CSS file! and what, we just hope nobody notices that they contradict each other? In other words, what do you do to ensure that your newly-updated stylesheet isn't cached? In the past, I've resorted to doing this: !--#include virtual=link-rel.txt -- where link-rel.txt contains link rel=stylesheet href=/css/2005-09-18.css type=text/css so that when changes are made, I can just change the include to refer to 2005-09-19.css and be sure there's no caching going on. Or, in the case of a major browser-hanging bug, 2005-09-19-11-15AM.css ... Have You Validated Your Code? John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- Marco van Hylckama Vlieg - Senior Web Developer http://www.i-marco.nl/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
On Mon, 2005-09-19 at 09:13 +0200, Marco van Hylckama Vlieg wrote: What's worrying though are developments such as server-side CSS. While it can do some nice things it really defeats the purpose of CSS. Seeing as no-one else has said anything, I thought I'd complain on this point. Even if you lose _a_ benefit of CSS, to say that this [bandwidth savings] is the purpose of CSS is pretty... narrow minded. We've still got parsable, semantic data with considerably extended longevity because we didn't scatter it with presentational attributes. And our sites are still viewable in low bandwidth devices that don't bother with stylesheets (or, download lighter-weight mobile/handheld media type stylesheets). ATs don't choke on our unwieldy table-structured pages, either. The bandwidth advantage is only ancillary to CSS' core purpose -- namely, the _presentation_ of content in a certain way, without the markup-muck that font tags bring on. Kind Regards, Joshua Street base10solutions Website: http://www.base10solutions.com.au/ Phone: (02) 9898-0060 Fax: (02) 8572-6021 Mobile: 0425 808 469 Multimedia Development Agency E-mails and any attachments sent from base10solutions are to be regarded as confidential. Please do not distribute or publish any of the contents of this e-mail without the sender’s consent. If you have received this e-mail in error, please notify the sender by replying to the e-mail, and then delete the message without making copies or using it in any way. Although base10solutions takes precautions to ensure that e-mail sent from our accounts are free of viruses, we encourage recipients to undertake their own virus scan on each e-mail before opening, as base10solutions accepts no responsibility for loss or damage caused by the contents of this e-mail. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
I should have called the class 'importanttext' or something similar in my
example indeed. However it still holds. One can either manipulate the way
output looks by dynamically changing the CSS or by dynamically changing
the HTML output. I prefer the latter to be honest.
- Marco
On Mon, 19 Sep 2005, Martin Heiden wrote:
Marco,
on Montag, 19. September 2005 at 11:01 you wrote:
Still I'd prefer server side manipulation of the HTML over manipulating
the CSS. If you have a span class=bluesome text/span and you want
it to be red at certain times you can either server-side change the color
value of the .blue class in CSS or you can change the HTML output to
become span class=redsome_text/span and define .red in the CSS as
well. Simplified example maybe but it explains things a little bit.
But you mix structure and visual display. If you'd call the class
importanttext you'd only have to change the css if you want to let
it appear blue instead of red:
span class=importanttextsome_text/span
.importanttext {
/* color: red; */
color: blue;
}
regards
Martin
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
--
Marco van Hylckama Vlieg - Senior Web Developer
http://www.i-marco.nl/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] The Big Lie about CSS
On 9/19/05, Martin Heiden [EMAIL PROTECTED] wrote:
on Montag, 19. September 2005 at 11:01 you wrote: CSS or you can change the HTML output to
become span class=redsome_text/span and define .red in the CSS as well. Simplified example maybe but it explains things a little bit.But you mix structure and visual display. If you'd call the class
importanttext you'd only have to change the css if you want to letit appear blue instead of red:span class=importanttextsome_text/span.importanttext {/* color: red; */
color: blue;}
Martin's correct, class=red is putting presentation in the markup.
The main problem is you'll be tempted to change the color: red to
color: white in teh CSS and then you've got a class name of red that's
actually displayed as white. You'd have to adjust all your html to fix
this ( ss template or otherwise ).
Back on the topic of caching, HTTP v1.1 has better cache control than
1.0. Older proxies and web servers using HTTP v1.0 are problematic
since they don't support / pass the correct header paramaters back to
the browser. Hopefully all these v1.0 systems will be put out to
pasture.
Kym mentioned the HTTP return code 304 Not Modified. This is the
correct mechanism for cache control and designed to reduce the
redundant over head of requesting unchanged content.
I advise anyone interested in understanding this process look at these Firefox extensions
http://livehttpheaders.mozdev.org/
https://addons.mozilla.org/extensions/moreinfo.php?id=967
Chris
RE: [WSG] The Big Lie about CSS
Marco van Hylckama Vlieg One can either manipulate the way output looks by dynamically changing the CSS or by dynamically changing the HTML output. I prefer the latter to be honest. But the question is: why do you prefer it? Just gut feeling, or any valuable/measurable reason? Also: of course, if you have dynamically generated pages, template driven CMSs etc, it's easy to change the HTML output. However, for those still publishing sites by hand, without an automated system behind it, a change in the markup on all pages would require a complete re-upload of the entire site. Thinking about systems like Blogger where (from what I gather...not using it myself) individual blog entries are actually written out as complete HTML files, a change to the markup on all pages would require a complete rebuild of the site as well. Patrick __ Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
On Mon, 19 Sep 2005 05:59:02 -0400, Chris Blown [EMAIL PROTECTED] wrote: Martin's correct, class=red is putting presentation in the markup. I disagree. span style=color:#f00;some_text/span is puttiing presentation in the markup. class=red is still a class that can be changes in the sheet. In my mind, the word red in this case is just a word, not a color. -- Tom Livingston Senior Multimedia Artist Media Logic www.mlinc.com Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
Tom, on Monday, September 19, 2005 at 14:57 you wrote: Martin's correct, class=red is putting presentation in the markup. I disagree. span style=color:#f00;some_text/span is puttiing presentation in the markup. class=red is still a class that can be changes in the sheet. In my mind, the word red in this case is just a word, not a color. Technically yes, but you'll agree that it is confusing to call the class red which gives the text a blue color, don't you? If you want to change the color, you've got to change the class name and probably the css too. So you'll agree that the name for the class is badly chosen. It is from the semantic point of view a bad idea to use names of colors as class names. Sometimes it might seem or even be more flexible to use classes that just add floats, clear or similar and which can be mixed with other classes that give styling to the content. And yes, I do that too, but I always feel guilty ;-) regards Martin ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
Tom Livingston I disagree. span style=color:#f00;some_text/span is puttiing presentation in the markup. class=red is still a class that can be changes in the sheet. In my mind, the word red in this case is just a word, not a color. It's just a word, but it does have presentational associations. Sure, to a machine it doesn't make a difference, and it's not breaking any technical standards, but it makes maintenance and generally working with pages highly confusing. Same for classnames such as left/right or bigbrownbox. See also: http://www.w3.org/QA/Tips/goodclassnames Patrick __ Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
On Mon, 19 Sep 2005 09:22:08 -0400, Martin Heiden [EMAIL PROTECTED] wrote: Technically yes, but you'll agree that it is confusing to call the class red which gives the text a blue color, don't you? If you want to change the color, you've got to change the class name and probably the css too. I do agree. A class of 'red' that creates blue text is... well... just wrong! ;-) But I was speaking technically, obviously. And shamefully, if a client at the last minute wanted a change like the example, I can see myself just changing the sheet and letting it go. Gasp! :o) -- Tom Livingston Senior Multimedia Artist Media Logic www.mlinc.com Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
Hi Patrick, FYI, Blogger does use templates which will update earlier posts as well as current posts when you make a change to them. I'm not a programmer, so I can't say how (thinking javascript), but I just made a change to my navigation thoughout my site. Then I made it separately to my Blogger blog template and checked to see if it's showing on older pages, and it is. I also opened an older HTML page in the archives and the change has been made there as well. I don't disagree with you, but wanted to keep the record straight (US expression). Best regards, Marilyn Langfeld Langfeldesigns http://www.langfeldesigns.com On Sep 19, 2005, at 6:39 AM, Patrick Lauke wrote: Marco van Hylckama Vlieg One can either manipulate the way output looks by dynamically changing the CSS or by dynamically changing the HTML output. I prefer the latter to be honest. But the question is: why do you prefer it? Just gut feeling, or any valuable/measurable reason? Also: of course, if you have dynamically generated pages, template driven CMSs etc, it's easy to change the HTML output. However, for those still publishing sites by hand, without an automated system behind it, a change in the markup on all pages would require a complete re-upload of the entire site. Thinking about systems like Blogger where (from what I gather...not using it myself) individual blog entries are actually written out as complete HTML files, a change to the markup on all pages would require a complete rebuild of the site as well. Patrick __ Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
Marilyn Langfeld FYI, Blogger does use templates which will update earlier posts as well as current posts when you make a change to them. I'm not a programmer, so I can't say how (thinking javascript), but I just made a change to my navigation thoughout my site. Then I made it separately to my Blogger blog template and checked to see if it's showing on older pages, and it is. I also opened an older HTML page in the archives and the change has been made there as well. I know, but I thought Blogger then had to go through a (server-side) process of rebuilding every single static version of the pages, which on a large blog can take quite a while...or maybe I'm thinking of Movable Type? Ah, whatever...you catch my drift, which is surprisingly coherent for a Monday ;) Patrick __ Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
Hi Patrick, I know, but I thought Blogger then had to go through a (server-side) process of rebuilding every single static version of the pages, which on a large blog can take quite a while...or maybe I'm thinking of Movable Type? Ah, whatever...you catch my drift, which is surprisingly coherent for a Monday ;) I'm sure you are correct about the server-side work involved. And yes, it does take some time (you see a spinning clock hand while it's doing it's thing), but it's surprisingly easy to do. The other nice thing about Blogger is that many if not all of the templates are well designed. Mine was originally designed for Blogger by Zeldman. I've modified it a lot, but the framework is his. Unfortunately, I added Haloscan trackback and comments, which make it fail validation. Otherwise it validates XHTML 1.0 strict, which is think is fantastic for a free blogging tool. All cms's and blogging tools should do so well! Best regards, Marilyn Langfeld Langfeldesigns http://www.langfeldesigns.com [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
The other nice thing about Blogger is that many if not all of thetemplates are well designed. Mine was originally designed for Blogger by Zeldman. I've modified it a lot, but the framework is his.Unfortunately, I added Haloscan trackback and comments, which make itfail validation. Otherwise it validates XHTML 1.0 strict, which isthink is fantastic for a free blogging tool. All cms's and blogging tools should do so well! Some do work that well. Check out Wordpress, Nucleus, and Textpattern. They are all XHTML 1.0 Strict or Transitional out of the box, and very easy to modify in order to reach XHTML 1.1.
Re: [WSG] The Big Lie about CSS
That might be an issue if you're changing the stylesheet all the time (although even then browsers should still update the cached file if it's changed) but generally people are talking about updating it infrequently and irregularly. In that case it might take a while to filter down to everyone's cached stylesheet but it's not going to be a major problem. I know if I see a site with what looks like bad stylesheet I'm going to refresh which will generally fix the problem. Jake On 19/9/2005, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I was thinking this morning that we constantly tell people two things about CSS, as in this wonderful presentation: http://www.hotdesign.com/seybold/ (pages 9 and 10) we tell them a) it's more efficient because the style sheet only gets downloaded once! and then we tell them b) you can reformat your whole site just by changing the CSS file! and what, we just hope nobody notices that they contradict each other? In other words, what do you do to ensure that your newly-updated stylesheet isn't cached? In the past, I've resorted to doing this: !--#include virtual=link-rel.txt -- where link-rel.txt contains link rel=stylesheet href=/css/2005-09-18.css type=text/css so that when changes are made, I can just change the include to refer to 2005-09-19.css and be sure there's no caching going on. Or, in the case of a major browser-hanging bug, 2005-09-19-11-15AM.css ... Have You Validated Your Code? John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
G'day a) it's more efficient because the style sheet only gets downloaded once! b) you can reformat your whole site just by changing the CSS file! and what, we just hope nobody notices that they contradict each other? To me it's only a contradiction if you read once to mean once in your lifetime while I'm sure the intention is to say that the presentation does not need to be reloaded with every (x)html page you load on the site during a visit. Having said that, I don't know how long browsers would actually cache the style sheet - I have had plenty of cases where I've updated it and had to resort to Ctrl+F5 to see the update (in various browsers). That might just be a server setting, but I don't know. Changing the css filename is not a good idea as you would then need to edit every html file to point to the updated file? Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
Browser DO go back out and update files (according to the policy set by either a network admin or the user - which may mean NEVER). BUT - the biggest problem is all the Proxy Servers inbetween the user and the site. You cannot always gaurantee that the policy on the proxy is set correctly (or if it even works). There are proxies out there that ignore the request to refresh objects. Then you are stuffed. We have experienced this before. On 9/19/05, Jake Badger [EMAIL PROTECTED] wrote: That might be an issue if you're changing the stylesheet all the time(although even then browsers should still update the cached file if it's changed) but generally people are talking about updating itinfrequently and irregularly. In that case it might take a while tofilter down to everyone's cached stylesheet but it's not going to be amajor problem. I know if I see a site with what looks like bad stylesheet I'm going to refresh which will generally fix the problem.JakeOn 19/9/2005, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:I was thinking this morning that we constantly tell people two thingsabout CSS, as in this wonderful presentation: http://www.hotdesign.com/seybold/ (pages 9 and 10)we tell them a) it's more efficient because the style sheet only gets downloaded once!and then we tell them b) you can reformat your whole site just by changing the CSS file!and what, we just hope nobody notices that they contradict each other?In other words, what do you do to ensure that your newly-updated stylesheet isn't cached? In the past, I've resorted to doing this: !--#include virtual=link-rel.txt --where link-rel.txt contains link rel=stylesheet href="" 09-18.css type=text/cssso that when changes are made, I can just change the include to referto 2005-09-19.css and be sure there's no caching going on. Or, inthe case of a major browser-hanging bug, 2005-09-19-11-15AM.css ...Have You Validated Your Code?John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/** The discussion list forhttp://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting helpThe discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
I wrote: Changing the css filename is not a good idea as you would then need to edit every html file to point to the updated file? Unless like you (John) mentioned, one uses an include (I missed that bit). Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
Changing the css filename is not a good idea as you would then need to edit every html file to point to the updated file? Well, that's the point of my trick, unwieldy though it is. Every html file would have a server-side include, which contained a client-side include. Next, a rabbit out of a hat. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
Except that then that stylesheet gets cached (more likely cached on the proxy) and you have the same problem all over again. Jake On 19/9/2005, Geoff Pack [EMAIL PROTECTED] wrote: John, There's no need for a server-side include to do this. Just use a linked stylesheet to import the real stylesheet: i.e. in your html pages: link rel=stylesheet type=text/css media=screen title=Default href=screen.css in screen.css: @import url(nav.css); @import url(main.css); ... This has the additional benefit of excluding NS4. cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Monday, 19 September 2005 11:17 AM To: wsg@webstandardsgroup.org Subject: [WSG] The Big Lie about CSS I was thinking this morning that we constantly tell people two things about CSS, as in this wonderful presentation: http://www.hotdesign.com/seybold/ (pages 9 and 10) we tell them a) it's more efficient because the style sheet only gets downloaded once! and then we tell them b) you can reformat your whole site just by changing the CSS file! and what, we just hope nobody notices that they contradict each other? In other words, what do you do to ensure that your newly-updated stylesheet isn't cached? In the past, I've resorted to doing this: !--#include virtual=link-rel.txt -- where link-rel.txt contains link rel=stylesheet href=/css/2005-09-18.css type=text/css so that when changes are made, I can just change the include to refer to 2005-09-19.css and be sure there's no caching going on. Or, in the case of a major browser-hanging bug, 2005-09-19-11-15AM.css ... Have You Validated Your Code? John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
There is a simply option: 1. add a link to a generic css file: link rel=stylesheet href=basic.css type=text/css media=screen, print 2. inside this file, import any css file you need: @import advanced.css; The advantages are: 1. by using two media types in first link you will stop NN4 from following the link and (in specific NN4 cases) from crashing on the @import. 2. you can update the css file or files in the basic css file any time you like without touching the html files - the original lionk will always be the same. 3. you can make the @import css files modular and change as needed. The basic.css file could include a range of imported css files: @import header.css; @import nav.css; @import content.css; @import footer.css; @import colors.css; Russ Well, that's the point of my trick, unwieldy though it is. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
What about setting the content expiration in the HTTP headers, you can do this from within the webserver. Isn't that how it was intended to work? Taco Fleur - Pacific Fox an industry leader with commercial IT experience since 1994 . http://www.pacificfox.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of russ - maxdesign Sent: Monday, 19 September 2005 12:08 PM To: Web Standards Group Subject: Re: [WSG] The Big Lie about CSS There is a simply option: 1. add a link to a generic css file: link rel=stylesheet href=basic.css type=text/css media=screen, print 2. inside this file, import any css file you need: @import advanced.css; The advantages are: 1. by using two media types in first link you will stop NN4 from following the link and (in specific NN4 cases) from crashing on the @import. 2. you can update the css file or files in the basic css file any time you like without touching the html files - the original lionk will always be the same. 3. you can make the @import css files modular and change as needed. The basic.css file could include a range of imported css files: @import header.css; @import nav.css; @import content.css; @import footer.css; @import colors.css; Russ Well, that's the point of my trick, unwieldy though it is. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
But my point was that in this situation (proxies caching out of date stylesheets) the proxy will hold an old version of the importing stylesheet and so only link to the old sheets. This won't solve the initial probelm, but I haven't seen it happen all that often and I don't really think it's all that big of an issue. Jake On 19/9/2005, Geoff Pack [EMAIL PROTECTED] wrote: You can still change the filenames of the imported stylesheets as needed to get around the cache issues. The point was to avoid the SSI and do it all on the client side with link and import. Geoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jake Badger Sent: Monday, 19 September 2005 12:07 PM To: wsg@webstandardsgroup.org Subject: RE: [WSG] The Big Lie about CSS Except that then that stylesheet gets cached (more likely cached on the proxy) and you have the same problem all over again. Jake On 19/9/2005, Geoff Pack [EMAIL PROTECTED] wrote: John, There's no need for a server-side include to do this. Just use a linked stylesheet to import the real stylesheet: i.e. in your html pages: link rel=stylesheet type=text/css media=screen title=Default href=screen.css in screen.css: @import url(nav.css); @import url(main.css); ... This has the additional benefit of excluding NS4. cheers, Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Monday, 19 September 2005 11:17 AM To: wsg@webstandardsgroup.org Subject: [WSG] The Big Lie about CSS I was thinking this morning that we constantly tell people two things about CSS, as in this wonderful presentation: http://www.hotdesign.com/seybold/ (pages 9 and 10) we tell them a) it's more efficient because the style sheet only gets downloaded once! and then we tell them b) you can reformat your whole site just by changing the CSS file! and what, we just hope nobody notices that they contradict each other? In other words, what do you do to ensure that your newly-updated stylesheet isn't cached? In the past, I've resorted to doing this: !--#include virtual=link-rel.txt -- where link-rel.txt contains link rel=stylesheet href=/css/2005-09-18.css type=text/css so that when changes are made, I can just change the include to refer to 2005-09-19.css and be sure there's no caching going on. Or, in the case of a major browser-hanging bug, 2005-09-19-11-15AM.css ... Have You Validated Your Code? John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
John, There's no need for a server-side include to do this. Just use a linked stylesheet Intra-corporate controversy! Fair enough, but as Jake has pointed out, this isn't absolutely guaranteed, because screen.css may still get cached, leaving users with the old @import statements. Caching is, by its nature, beyond our control. jh Have You Validated Your Code? John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] The Big Lie about CSS
Sorry to be thick, I get it now. I guess you have to use the SSI if you want to be absolutely sure. Though if you are only changing the styles, does it matter? The content will still be correct (unless the html is also cached...) cheers, Geoff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Monday, 19 September 2005 12:39 PM To: wsg@webstandardsgroup.org Subject: RE: [WSG] The Big Lie about CSS John, There's no need for a server-side include to do this. Just use a linked stylesheet Intra-corporate controversy! Fair enough, but as Jake has pointed out, this isn't absolutely guaranteed, because screen.css may still get cached, leaving users with the old @import statements. Caching is, by its nature, beyond our control. jh Have You Validated Your Code? John Horner(+612 / 02) 8333 3488 Developer, ABC Kids Onlinehttp://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] The Big Lie about CSS
Bert Doorn wrote: G'day a) it's more efficient because the style sheet only gets downloaded once! b) you can reformat your whole site just by changing the CSS file! and what, we just hope nobody notices that they contradict each other? To me it's only a contradiction if you read once to mean once in your lifetime while I'm sure the intention is to say that the presentation does not need to be reloaded with every (x)html page you load on the site during a visit. Yes, no matter how many pages on a site you visit, if they all reference, say, common.css, then the file will already be in cache and will not be downloaded again. However, see caveat below. Having said that, I don't know how long browsers would actually cache the style sheet - I have had plenty of cases where I've updated it and had to resort to Ctrl+F5 to see the update (in various browsers). That might just be a server setting, but I don't know. Changing the Actually, there are settings at the server level, within the individual browser, and which can be added to the page itself as meta-tags, which will affect whether and for how long a page is cached. Internet Explorer, for example, allows settings all the way from never check for a new page to every time I visit the page, although my experience has been that IE is extremely flakey about honoring cache settings, even sometimes requiring a manual deletion of cache files before it will reload a changed page. css filename is not a good idea as you would then need to edit every html file to point to the updated file? Cheers, Scott ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
