What I want:
I have a situation where I want to show affiliate ads on my website. These are basically javascripts, with content within them. As my site has a responsive design, I want to load different ads depending on the jQuery innerwidth property. So summed up: I want to load different javascripts depending on the innerwidth property.
What I have done:
I load two different javascripts in hiddenfields, and depending on the innerwidth, I show either one with the div.html() command. However, this gives the "potentially dangerous request.form" error when the user submits a post (ASP.NET defence of XSS), as the content loaded has dangerious characthers, which makes sense.
I could say "ValidateRequest=false" on all pages, but that's a horrible solution which would open a lot of security problems.
My thoughts...
The best way would be to load the ads from the server-side, but we don't know the browser width here. From what I've been able to read, it seems hard / impossible to get the innerwidth value at page_load.
But I would like to load my ads without making a potentially dangerious request.
Any ideas on how to solve this?
The solution I ended up with, was to set the HTML of to invisible divs, DivA and DivB, at Page_Load.
Then, in JavaScript, depending on the innerwidth property (and on the resize event), I could set the divs to visible/invisible.
Very simple solution, compared to what I was trying to do. Yes, it gives a little bit more rendered HTML, but at least it works and it's fast.
Related
I am developing a large scale HTML5 app, and I really wonder about this issue. I will have a lot of dialog boxes and tabs that will open by user interaction.
I wonder what is the best practice - writing all the dialog boxes and tabs in the HTML document with display:none to all of them, or create these HTML sections on the fly with JS or jQuery every time the user making the relevant interaction.
What is better in terms of performance, ease of development, readability, etc?
Any help will be appreciated.
I'll try to address this question as good as I can.
1 - As I said in the comments, Avoid inline styling.
First and foremost this is because inline styling voilates DRY.
Having to repeat the same thing over and over again for this is very bad for maintenance and for developing since instead of changing code once you have to change it at ~100 places.
2 - Avoiding inline styling is also good for accessibility, some screen readers and search engine crawlers do indexing work and reading work based on css selectors and thusly using inline styling will force them to either ignore or misintrepret things.
3 - When working as developers it's easy to do inline styling "just for the fun" but what you're actually doing is mixing concerns. HTML is the content and CSS is the design.
Mixing these two usually leads to headaches and making my job as a developer that comes after you a pain in the effin ass since I have no idea what's styled and how.
Now, onto performance.
When you use inline styles, what you're telling the browser is basically "hey, for every page page view apply these styles to all of these elements." Now, this just became really apparent why this is bad.
You have no ability to cache and store your css and basically forces the browser to rerender your styles every time. Using an external CSS file will actually help you speed up your site since the browser caches it.
That was that for the css part.
The javascript you had asked about.
As I said, hide things with css and show with javascript. Now why do you want to do this instead of pulling everything in?
Well, you can do both. If you're only a webbrowser experience then you can do either, it doesn't matter. I myself prefer to have stuff in the DOM because it relates to content and if you're a large app having dozens of dozens of ajax calls will only make it harder for maintenance. I believe if you have to ajax stuff in make sure it counts and is logical and not just for the kicks (I think this applies if only you have jQuery and plain javascript at your disposal).
If you're working with backbone.js, for example, it's based on views and introduces some form of "MVC" into your frontend enabling you to have views with subviews that can pull content in from the server.
Hope that helps a bit with making a decision! :)
I would say it depends on how many tabs your application has and how big these are.
Big content inside the tabs mean that the application will take long to load when started and consume much ram. If this is the case, I suppose to load them as needed.
Small content inside the tabs will load fast, so load everything at once to increase performance when the tabs are clicked.
Don't forget to run some tests on older computers with a slow internet connection to see how your application behaves. Not everyone has the newest and fastest hardware.
Basically we have this website which is a retailer of bigger brands.
They want to include the brand's own catalog which is on the brands website.
Problem is, the brand itself is selling their product on their website, too.
Is there way to actively hide the top parts (first 500px of height and last 300px of height) of the webpage inside the iframe?
I've tried many methods but they either failed or I got "unsafe" method errors such as this:
Unsafe JavaScript attempt to access frame with URL http://www.siteaddress.com/ from frame with URL http://www.othersiteaddress.com/. Domains, protocols and ports must match.
I don't want to change anything on their website, I just want to hide the top and bottom parts.
What makes this harder is that some pages inside the iframe will have different heights, so the only way is to ommit the first 500 px and the last 300px of height. But how, the last few hours didn't help me find it out.
Is this possible? Any help is appreciated.
No. There are fancy things you could try, but it would actually be easier to scrape and interact with the brand's website on the server side.
So No. Just No.
Short answer: no, you're most likely not going to be able to achieve what you are after.
Longer answer:
To run javascript on the page you are embedding it either needs to be from the same domain (as to not fall foul of browser cross-domain blocking of your javascript), or modified to include specific scripts to allow communication.
Even if you had access make changes to the website being included in the iframe, which it appears you do not, this would still cause many issues. As already indicated, pages would vary with content and structure, you would probably need to do something like hiding specific DOM elements such as a header/footer/container etc - which would then affect the layout, and so on.
There would be so many edge cases to account for, achieving the result you're aiming for is just not practical.
I have a client who wants to do a website with specific height for the content part.
The Question:
Is there any way that when the text is long / reach the maximum height of the content part, then a new page is created for the next text.
Within my knowledge, somehow I know this can't be done.
Thanks for helping guys!
You will probably want to look into something like jQuery paging with tabs
http://code.google.com/p/jquery-ui-tabs-paging/
Unfortunately you would need to figure out the maximum number of characters you want to allow in the content pane and anything after that would need to be put into another tab. You can hide the tab and use just a link instead.
Without more knowledge on what you're development is, this is a difficult question to answer. Are you looking to create a different page entirely, or just different sections on a page?
The former can be done using server-side code (e.g. Rails), and dynamically serving out pages (e.g. Google results are split across many page).
The latter can be done with Javascript and/or CSS. A simple example is:
<div id="the_content" style="overflow:hidden;width:200px;height:100px">
Some really long text...
</div>
This would create a "scroll" bar and just not disrupt the flow of the page. In Javascript (e.g. JQuery), you'll be able to split the content into "tabs".
Does this help?
(Almost) everything is possible, but your intuitions are right in that this can't be done easily or in a way that makes any sense.
If I were in your position, I would go up to the client and present advantages and disadvantages to breaking it up. Advantages include the fact that you'd be able to avoid long pages and that with some solutions to this problem, the page will load faster. Disadvantages include the increased effort (i.e., billable hours) it would take to accomplish this, the lack of precedent for it resulting in users being confused, and losses to SEO (you're splitting keywords amongst n pages).
This way, you're not shooting down the client's idea, and in the likely case the client retreats from his position, he will go away thinking that he's just made a smart choice by himself and everyone goes away happy.
If you're intent on splitting it up into pages, you can do it on the backend by either literally structuring your content into pages or applying some rule (e.g., cut a page off at the first whole paragraph after 1000 characters) to paginate the results. On the frontend, you could use hashtags to allow Javascript to paginate the results. You could even write an extensible library that "paginates" any text node. In fact, I wouldn't be surprised if one didn't exist already.
I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
We have a nav that expands on rollover (based on this code: http://www.dynamicdrive.com/dynamicindex1/droptabmenu.htm).
First, should we have a no-javascript version of the nav?
If yes, what is the best way to do so?
Yes you should always have a non-javascript version of your navigation.
The best way to do this is to apply any styles that hide sub-menus with javascript - so if the javascript isn't run the whole menu will be visible.
The HTML for the menu you've linked to looks fine - <ul>s and <a>s - nice and easy for a spider or non-javascript user to read.
It's always a good idea to have a no-Javascript version of everything.
Search engine robots usually do not interpret Javascript, so your pages might not be indexed if they can't be reached without Javascript.
A sitemap page that simply has a link to every static page on your site is the easiest way to make sure everyone can get to anywhere.
You may want to use unobtrusive javascript, which basically means have no javascript in your html page, just load the javascript files.
Now, if you start with a menu on the left, for navigation, using <li> and anchor tags then you can have some navigation without javascript.
So, if your javascript runs, the first thing it should do, when the dom tree is ready, is to set display: none on the navigation div and put in the new, more interactive navigation bar.
This way you can see how it works without any javascript.
Or, you can have a message telling them that javascript is required and do nothing else, but this would also be hidden as above.
I prefer to have things work, even if it has less functionality, without javascript, when possible.
Don't get me wrong: It's a good idea to support browsers that don't have JavaScript turned on, especially for something as simple as a menu.
However, when a project doesn't have it in the budget, or the application that you're writing is deeply dependent on JavaScript, it just doesn't make sense to support it.
Statistic from w3c and the counter indicate that 93% to 95% of users have JavaScript enabled. Now, mind you that this is a global demographic. To really determine if it's worth your time and money, it would behoove you to do your own statistics to determine what percentage of your traffic/demographic has JavaScript enabled.
As a side note: for reasons similar to why people are moving away from supporting IE 6, my company is also moving away from noscript support. Especially in large scale RIA's, it's just not practical to write the same thing twice. Maintaining two code bases for one project is not my idea of a good time. But of course, this is always based on the client and the target demographic.