Incompatible with media queries

[pyrsmk]

Hi,

I found that selectors don't work when they're inside a media query. Of course, I use Respond.js to have the real media query behavior in IE6-8.

I don't know where the issue comes... Maybe selectivizr don't match any media queries? (which will be a relevant behavior since IE6-8 don't support them).

I hope you'll find out what's going on...

[scottjehl]

hmm interesting. I'm not too familiar with selectivizr but it I'm guessing it's not seeing the css in the style tags generated by respond.js (maybe it's a timing issue). Unfortunately, I don't think I can do anything about this one in respond.js. Maybe you could run selectivizr before respond.js so that things are parsed beforehand ?

[pyrsmk]

Already done and nothing better... Pending a fix, I will juste use a CSS3 selector to do my stuff, it will good enough :)

[keithclark]

I guess this is caused by selectivizr and respond.js making separate HTTP requests for the same style sheet content and modifying the content in their own ways and overwriting each other.

[pyrsmk]

It sounds there's no way to make them work together :s

[keithclark]

I've done a little research into this and my theory above holds true. I've also done some hacking :o)

I managed to get respond.js and selectivizr working together by exposing a selectivizr object in the global scope containing a getRawCssText(href) method. This method returns the selectiviz'd version of the raw css. Next, I modified the ripCSS() function in respond.js to detect for the new selectivizr object and, if it exists, call the getRawCssText method passing the href of the current element and marking it as parsed. This allows response to work with the raw CSS patched by selectivizr.

I also had to stop response.js from automatically running itself (via ripCSS) because selectivizr requires the DOM to be completely loaded before it can run. That said, I may adopt response.js approach and download the stylesheets instantly. The final step was to get selectivizr to call response.update() after it had initialized.

The problem with this method is that both scripts need to test for the existence of each other which isn't ideal. There's also the issue of overwriting changes made by other scripts like flexIE which do the same thing (i.e. ajax calls to retrieve CSS content).

Maybe an agnostic external CSS processor object is required, it's job could be to download raw CSS, provide an interface for reading from, and writing to the raw text and ultimately writing the modified css back to the DOM. If something like this existed multiple libraries could hook into it — perhaps this should be the starting point for CSS polyfills like this?

What are your thoughts on this?

[pyrsmk]

You've made a great work, thanks for the time you've passed on this :)

I share your point, I think that's the job for a centralized library, it will save hours of making work all libs together. I can deal with it if you want.

[pyrsmk]

I'm motivated, I've begun to write Sheethub. I'll give you more news later ;)

[pyrsmk]

Hi,

I just pushed an alpha version of the library here : https://github.com/pyrsmk/sheethub

For the time, there's no unit testing since I must deal with jasmine, which only displays me errors... If someone know how to use this unit testing framework...

[pyrsmk]

Second alpha released with, nearly, full unit testing (I've some issues with events). I will write soon the documentation, then you could test it and tell me if it misses some behaviors or if others are totally useless ;)

[keithclark]

I've posted a proposed solution to this problem here: http://selectivizr.com/tests/respond/

Any feedback would be appreciated

[pyrsmk]

Good work :) But as I said 2 weeks ago, and as you said at the end of your test, it couldn't be a relevant solution. In a perfect world, we'll need all CSS polyfills to have same API, with no matter of which library is above or below from another.

Then, to my mind, we need an external library for that job, so we'll never care about which library we'll need to be compatible with. Maybe a good idea could be to have two versions of the concerned library: one standalone and one Sheethub dependent.

I hope that you don't believe I want to promote Sheethub. That's just my real thoughts on this topic :)

PS: Sheethub still needs some work to have real centralization... Or perhaps not. Does selectivizr (or Respond) change stylesheets contents? If not, then Sheethub is probably ready.

[thomasmaas]

Keith, seems you have implemented the above solution in the master branch of selectivizr and it it works well. I'm wondering if there has been any communication with Scott Jehl as respond.js' current master branch still needs the edit you propose.

[keithclark]

I intend to fork respond.js and create a selectivizr compatible branch. It will then be up to Scott to decide if he wants to merge the update into the main branch of respond or not.

[scottjehl]

Keithclark: it's a small tweak, so I'm open to adding a check.

Instead of planning to maintain a separate fork/project, if you make the change can you submit a pull request? Thanks!

[keithclark]

So your all aware, I have forked respond, added the necessary code and submitted a pull request to Scott for review.

[keithclark]

Looks like Scott has merged the pull request so I'm closing this issue.

[thomasmaas]

Just wanted to say thank you for this wonderful library. Very much appreciated.