Problem
Currently an active stylesheet loads by JS on HTML DOM ready event, i.e. a user does not see a results of their selected style until the whole page is fully rendered.
A problem of the technique used is that it is a browser based hack and it does not allow to set one of styles to be visible initially.
Proposed resolution
Instead of list of <link rel="alternate stylesheet"> tags we can use only one <link rel="stylesheet"> with 'href' attribute initially pointing to active CSS and make JS change that 'href' on switching.
Remaining tasks
Patch to come shortly.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | styleswitcher-changed-switching-technique-1966982-0.patch | 12.09 KB | pingwin4eg |
Comments
Comment #1
pingwin4egBesides the main task this patch also does following subtasks:
Comment #2
mglamanTried using patch via git, came up with these errors (did a git clone of project)
Comment #3
pingwin4egIt seems that you are trying to apply the patch to wrong branch ('master', I think). This patch is for '7.x-1.x' branch (as stated in 'version' field of an issue).
Please checkout to 7.x-1.x and try again.
Comment #4
rafal.cygnarowski commentedThe patch have problem with different css file include techniques. In my installation default way to include css is
@imort()when patch assumes it's
tag still exists but with media attribute set to "styleswitcher" and tag is created with "styleswitcher-css" id. I didn't checked what is causing all the mess but it's need a change. For now following change made it work for me:tag. Even more: if I refresh the page, then
Comment #5
rafal.cygnarowski commentedAfter few tests I had to made changes to deal with browser cache and make it work with IE8.
Comment #6
kingfisher64 commented#5 appears to work fine.
Comment #7
kingfisher64 commented#5 is the starting point at present to get this module up and running. Apply this prior to other patches.
Comment #9
pingwin4egTo rafal.cygnarowski:
I am trying to understand how did you run into such problem. The code you provided in patch is unneeded in normal flow:
because we set 'preprocess' option to FALSE in
drupal_add_css(). It means our css should always be rendered as separate <link> tag and never as <style>@import url();</style>.So it seems like something's gone wrong in process of update from the old version to the patched one. Can you please provide more info on what did you do. Did a patch apply flawlessly? Did you clear caches after patching? What did you mean by "your installation" in phrase
? What exactly could cause using @import where it should not be? What Drupal version did you use? Any other information that to your notice can be useful.
P.S.: I'll hide your patch from display in the issue because of the reason I mentioned above until more information comes.
Comment #10
kingfisher64 commented@pingwin4eg would you recommend that any new people download the 2.x branch from git for now?
Many thanks
Comment #11
pingwin4egI've added new dev release for 2.x on project page. So yes, use it instead of 1.x.
I'm closing this issue since the patch already committed. Please start new issue for 2.x if needed.
Comment #12
rafal.cygnarowski commentedTo pingwin4eg:
It was some time ago, so I don't remember well the way to reproduce this behavior.
But, AFAIR: check how the page looks like when you enter it for the first time, and then after page refresh. It's possible that using browser private mode is required.
It was tested with Drupal 7.24 (or near this version).
Comment #13
rafal.cygnarowski commentedOk, I checked newest 2.x-devel and it looks as follows:
1. Newly opened browser in privet mode. The default stylesheet is loaded by following code:
<style type="text/css" media="styleswitcher">@import url("http://test.site.pl/sites/all/themes/mytheme/style-normal.css?n4j1kd");</style>2. Switching to ohter style and next css file is loaded with following code:
Switching back to default theme is not possible because JS is generating exception:
Comment #14
pingwin4egAs I understand you are testing it as anonymous Drupal user, right? Can you report the status of page caching and CSS aggregation/compression in your environment?
Probably we should start another issue.
Comment #15
rafal.cygnarowski commentedYes, anonymous user. Anonymous pages are not cached and css files are not aggregated/compressed.
Comment #16
pingwin4egI'm sorry but I can't reproduce that. Closing this issue. Feel free to start a separate one, but please give us a more information.