I want to implement a simple feature into my node.js/express app that allows the users (registered and nonregistered) to quickly change some settings in the CSS theme.
Is there a way of implementing it in a way that I don't have to record the user's preference into the db, instead the app just remembers the preference of the current browsing session and shows a different CSS theme depending on what the user selected.
And I need these styles to not be in a separate CSS file, but some kind of adjustment to the existing ones.
What would be the best way to implement it?
I thought about adding a few style modifications in a separate CSS file and then when the user selects a different theme, recording it as the current preference and loading that additional css for those users.
Do you think it's a good way or there's a more efficient one?
Look into LocalStorage (available in just about every modern browser) for storing the preference, or instead store the preference in a non-expiring cookie. The first approach is best if your preferences are complex (like overriding individual elements) and the second if they're simpler (like just one file override).
As for the updated CSS, don't modify existing files. Use the cascading nature of the language, which is built for overrides. In other words, inline the changed CSS into your html. It will usually take precedence over separate CSS files unless individual rule weights are different for some reason (like more specific selectors, which increase rule weight/priority).
Related
In extensions (I'm praticularly focused on Chrome's extensions), css identifiers and classes injected in a page may enter in conflict with other elements on the page.
I'm trying to define their name with an extension prefix, but it's not perfectly sure. So, is there a way to define scurely names of css ids/classes?
It's not possible if "perfectly sure" is your requirement. Someone could always download your extension, look at the classnames you're using, then change their website's CSS to conflict with (or more likely attempt to override) your classnames. This is a feature, not a bug; extensions extend web pages, so they're supposed to be able to commingle with and alter their DOMs.
If you wanted to invent a system where others would not intentionally conflict with yours, why not use the Java namespace scheme: take a domain you own, and use it as a prefix, like com-example-myclassname? Slightly less readable and no more secure would be either the ID of your extension or a randomly generated SHA-1 hexcoded hash:
abcdefghijklmnop-myclassname
da39a3ee5e6b4b0d3255bfef95601890afd80709-myclassname
I'm intentionally not including dynamic solutions here because CSS typically isn't dynamic in a Chrome extension or app. Moreover, CSP would probably make this approach anything but straightforward (which is a good thing).
We all know that we're supposed to combine our CSS into one file, but per site or per page? I've found pro's and cons to both.
Here's the scenario:
Large site
CSS files broken out into one file for global styles and many for modules
Solution A: Combine ALL the CSS files for the whole site into one file:
Best part is that the one file would be cached on every page after the initial hit! The downside is that naming convention for your selectors (classes and id's) becomes more important as the chance for a namespace collision increases. You also need a system for styling the same module differently on separate pages. This leads to extra selectors in your CSS which is more work for the browser. This can cause problems on mobile devices like the iPad that don't have as much memory and processing power. If you're using media queries for responsive design, you're troubles compound even further as you add in the extra styles.
Solution B: Combine one CSS file per page template:
(By page template I mean one layout, but many different pages, like an article page)
In this scenario, you lose most of the issues with selecting described above, but you also lose some of the cache advantages. The worst part of this technique is that if you have the same styles on 2 different page templates then they'll be download twice, once for each page! For instance, this would happen with all your global files. :(
Summary:
So, as is common in programming, neither solution is perfect, but if anyone has run into this and found an answer I'd love to hear it! Especially, if you know of any techniques that help with the selector issue of Solution A.
Of course, combine and minify all the global styles, like your site template, typography, forms, etc. I would also consider combining the most important and most frequently used module styles into the global stylesheet, certainly the ones that you plan to use on the home page or entry point.
Solution B isn't a good one: the user ends up downloading the same content for each unique layout/page when you could have just loaded parts of it from the last page's cache. There is no advantage whatsoever to this method.
For the rest, I would leave them separate (and minified) and just load them individually as needed. You can use any of the preloading techniques described on the Yahoo! Developer network's "Best Practices for Speeding Up Your Web Site" guide to load the user's cache beforehand:
Preload Components
By preloading components you can take advantage
of the time the browser is idle and request components (like images,
styles and scripts) you'll need in the future. This way when the user
visits the next page, you could have most of the components already in
the cache and your page will load much faster for the user. There are actually several types of preloading:
Unconditional preload - as soon as onload fires, you go ahead and fetch some extra components. Check google.com for an example of how a
sprite image is requested onload. This sprite image is not needed on
the google.com homepage, but it is needed on the consecutive search
result page.
Conditional preload - based on a user action you make an educated guess where the user is headed next and preload accordingly. On
search.yahoo.com you can see how some extra components are requested
after you start typing in the input box.
As far as the conflicting selectors go: combining all the files and doing it any other way should not make a difference, this is a problem with your design. If possible, have all modules "namespaced" somehow, perhaps by using a common prefix for classes specific to the module, like blog-header or storefront-title. There is a concept called "Object-oriented CSS" that might reduce the need for lots of redundant CSS and module-specific class names, but this is normally done during the design phase, not something you can "tack on" to an existing project.
Less HTTP requests is better, but you have to take file size into consideration as well as user behavior and activity. The initial download time of the entry page is the most important thing, so you don't want to bog it down with stuff you won't use until later. If you really want to crunch the numbers, try a few different things and profile your site with Firebug or Chrome's developer tools.
i think you can make global.css that store style that need every template.
And you could make css in each template.
Or simply use css framework like lescss
I would like the user to have limited access to controlling certain CSS attributes of divs. The divs would all be similar, all have a some class name, and be displayed across the site with the styling rule of the user. So kind of like a user CSS stylesheet, except with certain rules that they can change.
Allow change to:
.className{
font:all attributes;
all four borders:all attributes;
float:cannot change;
}
Would the best way to be to store these in a database? Store the color, border width, etc in a MySQL database? Seems like a lot, with all of the information.
Allowing the user to have their own CSS document is risky, and I do not want them to be able to change the layout. I want to make this a part of my site, one anyone can use with no knowledge of CSS. I would like for them to have their choice of styles; like letting them have their own theme on a Drupal site, but make the changes easy to make for anyone (like have a list of pre-defined or something). But also they must have full control if they want, of the attributes I allow them to change.
Would preprocessing this information from a database and putting it in a style tag be inefficient? Seems like a lot of queries unless it was all in one query.
You should check out the jQuery UI ThemeRoller script, it uses a number of fields which are passed via the URL. Click on any of the themes on the left and see what happens to the URL.
You could easily replicate it to fit your needs, and instead save those values in a database. You could use the same naming convention too, if you like.
I think it's a great place to start.
To have your users able to generate and preview the styles dynamically, they must be parsed with Javascript (or server side to get tricky). Either way, you have to get a CSS rule out of it somehow, so you might as well do it before you throw it into the database. You're doing what you were going to do anyway, but saving yourself the trouble of making a big table.
Since Themes in ASP.NET are used to style elements of your site, I was just wondering why would you use Themes rather than CSS, or is it common practice to use both? If so, when would you opt for one versus the other and why?
Just seems to me like Themes are kind of unnecessary, so I am just looking on clarification if there really is a good reason to use them, or it's just a part of the framework as an alternative(unnecessary) step to styling your site.
Imagine you have a site that, for whatever reason, uses dozens of asp:Calendar controls.
To style them with CSS alone, you'll have to set loads of properties on each one: DayStyle and TitleStyle and NextPrevStyle and on and on...
Using a theme will allow you to set all of those properties just once, and have it apply to every asp:Calendar on the site. The theme would contain the same CSS, but also the declaration of how to apply that CSS to server controls, which is something you can't easily do otherwise.
Of course, as Brian Hasden already said, you'll probably need some "global" CSS that lives outside of the theme (particularly if your site has multiple themes).
Themes have the benefit of being tightly integrated into the whole .NET environment so that things get themed without needing to specify their styles. It happen automagically like lots of other things in .NET. Based on that I can see the appeal for some people.
That being said, I personally never use the whole themes deal because I feel like it requires you to maintain two different sets of styles. One that's part of the theme and then others that are inevitably needed outside of the whole theming deal.
Maybe I'm just a control freak or dislike themes due to bad usage on previous projects.
I would like to have user customizable look and feel options on a website. I envision an interface for selecting background and text colors, images, fonts, etc.. I'm just not sure what the best way to store and use the information is. I plan on storing all options in a database table tied to the user.
Is there a good way to dynamically generate css for each user? Is it better to generate the css as they make changes and just store it, or to regenerate it for each page view? Are there established patterns for doing this kind of thing?
Separate out the parts of the CSS that are customisable from the parts that are static. That way you can still serve most of the CSS as you normally would.
Dynamically generate the CSS that is customisable. Don't try to do any optimisation or fancy caching unless you observe there's a performance problem.
The only potential performance problem is that the browser can't cache the customisable CSS. However, you probably don't want the browser to cache it anyway as that could mean that the user's colour scheme doesn't immediately update when they edit it.
If you do have a performance problem I wouldn't worry about ETags. ETags are designed to save the browser from re-downloading a component that it already has, but the customisable portion of the CSS is likely to be very small.
In case of a performance problem, consider inlining the customisable CSS directly into the HTML page. That will save an extra HTTP request. However, don't do this unless you are sure there is a need.
First of all, use appropriate caching headers for generated CSS and also use ETag header to re-validate CSS source when client asks for it. You must implement some fast ETag calculation algorithm, for example increment version field each time users changes some setting and return its value as ETag. In this scenario you may choose not to "generate the css as they make changes and just store it" but "regenerate it for each page view", because actually CSS will be stored in user agent cache and even when user presses F5 ETag will be used to ensure that CSS on client side is still valid.
Of course, CSS must be returned by some http handler (usercss.ashx or something like this). When including link to this CSS into HTML page, make sure to add some parameter to work around cached content issues, for example `
From my own experience I'd recommend you to use handler to serve user CSS as separate resource and do not embed it into HTML page each time it is generated, because in last case you must either recalculate CSS every time page is generated or somehow cache it on the server, both cases are rather bad ideas. Besides, this CSS may be rather large, there is no reason to download it on every request.