Closed ZeeAgency closed 13 years ago
New fix :
The bug can be seen with IE7 (or IE8, I'm forcing IE7 emulation) here : http://zeedev.aaz.fr/selectivizr-bug/#/test-something
If you try first : http://zeedev.aaz.fr/selectivizr-bug/ (see, no hash)
Then click the link, and refresh, you'll see there's no styling, looks like the hash is hurting the
Nice find.
I've done some local testing and come up with a different fix; Modifying the resolveUrl
function to remove hashes from the context URL achieves the same thing – but resolveUrl
is also called when processing CSS assets (i.e. images, fonts and @imports ) so this fix would also catch any issues resulting in hashes being used in those URL's
My fix is to modify line 418 from:
var contextUrlPath = contextUrl.split("?")[0];
to
var contextUrlPath = contextUrl.split(/[?#]/)[0];
P.S. I'm writing tests prior to doing any pulls which is why I haven't included your updates yet.
Hey,
I also wrote some tests, you should put them on the repo :-)
Where are your tests? - i'll try integrating them into my testing tool.
Here : https://github.com/ZeeAgency/selectivizr/tree/master/test
When I said "you should put them", I was talking about yours ;-)
Great.
The only thing my tests are doing more is async load, you should add this.
Good news anyway : my fixes are all green :)
I could add an async test to the iframe tests.
Any tests that fail, should pass when I've finished pulling in fixes :)
I've added a commit that should fix your url hash issue.
Nice, I'm taking the opportunity to ask a question :
IYO, is it possible (planned?) to make IE support the child selector ( > ) ? I had a dream about using ul > li on IE... I can use some of my free time to work on this feature but I need to know if you already thought / investigated about it.
PS : What about my onready fix ?! :)
mmh maybe this http://dean.edwards.name/IE7/ can help
Implementing '>' (and other combinators) in IE6 should be possible without too much work but, personally, I think selectivizr should focus of getting IE7/8's selector support up to the level of IE9 (and the other mainstream browsers) so that when IE6 officially retires from service (soon, I hope) the remaining IE browsers can support the full suite of CSS selectors.
Any IE6 features in selectivizr are there because they were developed for IE7/8 and worked in IE6 with little of no effort.
If we start emulating selectors specifically for IE6 then we'll end up recreating Dean Edwards IE7.js. We'd also be increasing the size of the script and it's loading / processing time for a small % market share browser. I'd argue that if you need that level of support then IE7.js is probably a better solution for you than selectivizr. I'd also like to point out; the developers I've spoken with that use selectivizr over IE7.js generally do so because of selectivizrs performance.
This is only my opinion. I'd be interested in other developers thoughts on this.
Regarding your domready fix, another solution has presented itself. I'll be testing both methods.
Well, my mistake, I think I was too tired because I totally forgot IE7 was supporting child selector… I don't really care about IE6 and, you're right, selectivizr should'nt care too ;)
What is this other solution ??
Diego Perini (discovered the doScroll trick) has been in touch. He has a new version of his cross browser DOMContentLoaded script that works with iframes. I'm planning to run some tests over the coming days.
okay, hope it works with async loading too
It should allow to lazyload selectivizr (tested with yepnope) no more doc.write() check document.readyState uses doScroll trick when not iframe uses doc.onreadystatechange if iframe
I made a few tests on IE6 and IE8, looks fine. With iframe, selectivizr does the job just before unload, which is little delayed, but without throwing errors.