WebReflection::encode (just a click to give it a try)
javascript:(function(src,w,h,i,s){if(this.WebReflectionEncode)return this.WebReflectionEncode();function p(){s.top=(document.documentElement.scrollTop||(document.body&&document.body.scrollTop)||0)+'px'};try{i=document.createElement('<iframe frameborder="0" src="'+src+'"></iframe>')}catch(e){i=document.createElement('iframe');i.src=src};s=i.style;s.border='1px solid black';s.width=w+'px';s.height=h+'px';s.position='absolute';s.right=0;s.zIndex=99999;p();w=setInterval(p,250);(document.body||document.documentElement).appendChild(i);this.WebReflectionEncode=function(){clearInterval(w);i.parentNode.removeChild(i);w=h=s=i=null;this.WebReflectionEncode=null;}})('http://www.3site.eu/encode/',280,320);
P.S. WOW, to make it possible I had to use raw format ... at least now the bookmark link seems to work fine in every browser!
What am I talking about?
We, as developers, too often post code in this or that website/blog, and often we loose our post or its meaning because of enabled html, and some mess in in the code. Basic example:
for(var i = 0; i<length; ++i) ...
Above snippet, extremely common, could cause unexpected problems due to the "i less than length" where the "<" character create a never-ending tag.
How can we solve the problem?
Usually I copy and paste code in a new document via CTRL+N inside Notepad++, and I replace every "<" with < ... but I have to admit: boring stuff!!! I discovered yesterday in Dustin Diaz blog, and I messed up completely a couple of comments, that there is a service, called postable, "to make your code friendly". First of all, I'll never get why that Ajax call exist, safetuze.php will never do anything different from an htmlentities or an htmlspecialchars but apparently I am wrong:- plus signs disappears, probably the author send without the proper encodeURIComponent JavaScript function, annoying
- there is no reason at all to send back the entire textarea, we deal with a field, we would expect to wait only for what we wrote in that field (AHAH way for a textarea?), annoying
- why we have to wait a server side call, is an absolute mistery ... as a plus, I am experiencing an USB pen to surf the web, and every single byte costs, annoying
- a basic page like that with just a call to the server and prototype plus scriptacolous to do it? unacceptable!!!
postable, in my opinion, is a "not that good answer" to a truly common problem ... so
again, how can we solve the problem?
I created a totally cross browser page, thinking about bandwidth, simplicity, and performances. So here I am with en-code, the same purpose of postable, except it just escape code snippets on client side (N times faster) and it does not require an entire framework to do a single thing.3KB Against 183KB
... and only congrats via Web Page Analyzer ...Let me know what you think, enjoy ;)