Skip to main content ↑ ↓
Handy stuffz (lest we forget) Started by Antechinus · · Read 12664 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Handy stuffz (lest we forget)

Just been looking into meta tags a bit. We should include this critter:


Code: [Select]
<meta http-equiv="X-UA-Compatible" content="IE=edge" />

QuoteEdge mode tells Internet Explorer to display content in the highest mode available. With Internet Explorer 9, this is equivalent to IE9 mode. If a future release of Internet Explorer supported a higher compatibility mode, pages set to edge mode would appear in the highest mode supported by that version. Those same pages would still appear in IE9 mode when viewed with Internet Explorer 9.
From Stack Overflow:
QuotePersonally I choose always have meta http-equiv="X-UA-Compatible" content="IE=edge" As older versions have plenty of bugs and I do not want IE to decide to go into "Compatibility mode" and show my site as IE 7 vs IE 8. I always prefer the latest version of IE.
This makes a lot of sense, because some people may have their browsers set to compatability mode (particularly anyone who is still on IE8) and we would want to override that, and force the use of standard mode.

Alternatively, we could include this:

Code: [Select]
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />
That one will do the above, but will also allow people the option of using Google Chrome Frame if they want to. That's stable these days, and may be a good option for anyone still stuck on an XP box (yes, they certainly still exist).

Linky: http://stackoverflow.com/questions/6771258/whats-the-difference-if-meta-http-equiv-x-ua-compatible-content-ie-edge
Last Edit: December 28, 2012, 05:18:12 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy meta tags (lest we forget)

Reply #1 –

Thanks! https://github.com/Spuds/Dialogo/issues/43
The best moment for testing your PR is right after you merge it. Can't miss with that one.

More handy lest we forget stuffz!

Reply #2 –

Not worth a new thread, but worth noting in general. The 2.0.x css wasn't that great.

https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS

Added another handy thing that we should have on call: http://caniuse.com/
Last Edit: December 27, 2012, 03:46:10 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #3 –

Just found sumpin else interesting. With css, the idea is to avoid tag names tied to classes if you want best performance. Oddly enough, when writing jQuery it's apparently the other way around. Although writing the tag name and the class gives a few more bytes of stuff to process, the processing is apparently quicker.

http://stackoverflow.com/questions/46214/good-ways-to-improve-jquery-selector-performance

Also, chaining methods is faster than chaining selectors in the one method, which I wouldn't have expected.

http://seesparkbox.com/foundry/jquery_selector_performance_testing

Also going to have to wade through this lot:

http://jonraasch.com/blog/10-advanced-jquery-performance-tuning-tips-from-paul-irish

http://24ways.org/2011/your-jquery-now-with-less-suck/

http://dumitruglavan.com/jquery-performance-tips-cheat-sheet/
Last Edit: December 28, 2012, 05:37:28 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #4 –

Hey interesting bit here. Turns out the so-called shorthand version of kicking off jQuery is actually the slowest. It's slower by quite a margin too. Just ran a test on jsperf and got these results.

So, we should never be using the shorthand version to kick things off.  :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #5 –

Meh and bollocks. jQuery .hide() is slowwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww compared to some of the alternatives.

http://jsperf.com/jquery-hide/2

 Antechinus goes to re-write silly menu code again....:P
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #6 –

I knew that the hide function was quite a bit slower than native, but cool find on using the css approach.

I believe the main reason that .hide() is slower is that it has to save what the display attribute was before, so that .show() can restore it (assuming you need that).  So to do that it uses the .data() method for storing the display information on the DOM.  Which is a fancy way of saying .hide() loops through every element twice: once to save then once to update it to none.

Like anything with Jquery, need to make sure you need the functionality / capability that the library offers for a particular task, otherwise it can be a bit of overhead.

Re: Handy stuffz (lest we forget)

Reply #7 –

Makes sense. So since it's basically just an off switch that sets display: none; anyway the css approach is going to be better.

I agree about the overhead, but a long as we're sensible about how we use it I think it's worthwhile. To my mind, the big advantage with jQ is that it works across browsers without any screwing around. They've already done that bit (yay!).
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #8 –

Just found another interesting thing. Apparently jQuery's attr and removeAttr are famously borked. Best to avoid using them if possible.

Nice rant here: http://jsperf.com/removing-element-attributes  ;D

Of the two, plain old attr is better (rather like the css vs hide() example).

http://jsperf.com/attr-foo-or-removeattr-foo


Also, it appears that adding and removing classes is faster than toggling class.

http://jsperf.com/addclass-removeclass2-vs-toggleclass

I was interested in this one because I can see toggling of css properties (particularly opacity and z-index) being very useful for making menus more accessible. Looks like the best option is to code for adding and removing css on click, rather than relying on the default toggle thingy.
Last Edit: December 30, 2012, 04:47:36 am by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #9 –

Ooooooooo000 - looky what I found! ;D 

http://marklets.com/Liquid+Page.aspx

Very nifty little toy. It even works. ;)
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Handy stuffz (lest we forget)

Reply #10 –


Quote from: TestMonkey – Thanks! https://github.com/Spuds/Dialogo/issues/43
I added this for IE ... do note that for it to work it needed to be in the first 4k of the page load (ie before the css) or IE would ignore it, and tell you that it ignored it :D ... so its at the top of the page.

https://github.com/elkarte/Elkarte/commit/40981bc04c8159be6129f278a47e10c0dc37791a