Public area => The Pub => Off-topic => Topic started by: Arantor on August 8th, 2013, 03:37 AM
Browsing around the intarwebs I found this article.
It's an interesting argument specifically about Firefox but it does make me want to go back and look at what we're doing...
I've used three of those check boxes before, but always knew to change things back. Legitimately, I had a really bad connection and wasn't all too interested to see pretty pictures.
I learned what this is about. A lot of webpage authors would teach how to get rid of cache... Instead of clearing cache every time a webpage would not load the way I expect them to, why not just permanently disable it? I then disable this to always get fresh content. This shouldn't be as harmful to do than it would've years ago. I do not know the ratio for people around the world who has good connection opposed to bad connection. Mines below average. For this to be brought up, I would imagine a good chunk of 98% of people has horrible connection.To find someone who would actually do this wouldn't surprise me, I've seen a lot of dumb stuff people do with their computer. I have yet to witness this. To be fair, most people wouldn't touch this.
Override automatic cache management
This option is fairly buried in ADVANCED options, with techy-terms that should instinctively tell you that "you have no business here."
The entire certificate manager
Note the key point that the author makes, more than once, that some of this stuff is relevant for developers and that alternatives should exist for developers, e.g. in the dev tools area. But not in the main options. Perhaps not in a UI at all, just in the about:settings area, or exposed via a plugin for developers.
Turning off cache... funny you should say that. How many times have we asked people to hard refresh Wedge? Yet there are semi regular CSS changes... answer: we generally don't because we have a system that pushes a different 'filename' to the browser so it won't be cached. As a rule you should assume that a user will have a given thing cached and if that's a problem, rename the thing. One suggestion I've seen was to have files include the date of release in them.
Telling users to turn off cache is generally a really silly thing to do because it's not a per site cache. It's browser-wide meaning that everything everywhere has to be redownloaded. Which for a per-site exception is ridiculous. And the fact that the site owner has control over how they send you things means they're the ones who should be responsible for dealing with it - if you routinely have to tell users to empty their cache, you're doing it wrong. (I'm not even sure why we had to ask users to hard refresh with the smileys, actually... it certainly surprised me that we had to)
As far as turning off SSL/TLS goes, that's a classic example of the point the author is trying to make... who would legitimately turn it off? Anyone who is smart enough to know to turn off SSL or TLS should know how to do so via an about:settings type page. There is no reason I can see for having it as a UI item, especially not a fairly prominent one.
Key point taken. :) Now that you brought up the cache thing, I did had some issues where users on my old site couldn't see new CSS changes, so I made a random URL parameter which helped the situation, eventually, I decided to just manually rename files.
Opps, I meant to say "Webmasters asks users to clear out cache", not turn off. :^^;: Happens really often I see people being asked to do that. I turn off to avoid experiencing any problems/miss-out on anything new. Yes, that is silly having to tell users of your website to do that.
Turning off cache... funny you should say that.
I like this. I am working on a project that could use a feature like this.
we generally don't because we have a system that pushes a different 'filename' to the browser so it won't be cached.
Well, in Wedge's case, the CSS files aren't really CSS files and need to be run through a preparser to make actual CSS. All that happens is that we look for the most recent file out of all the ones that will be compiled together (parent + sub skins files) and use the most recent one's timestamp as the basis of the filename.
For example, the CSS files I see requested in this very page load are:
The browser is needed because some of the constructs in the WeCSS/Wess sources are browser independent (e.g. border-radius, gradients etc.) and the compiler will add the correct browser prefixes where needed. We have separate CSS for members and for guests (because we don't need to serve everything to everyone, only serving the stuff to guests that guests will see) to save bandwidth, and then the timestamp component.
As for css.gz, if the browser supports it, we'll send it pre-compressed - that way it doesn't have to be compressed every request by Apache/nginx, but only for those who actually need it to be served that way.