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
Related
Are there any docs or training materials available that advise the best way to include multiple jQuery plugins in an abstract way, allowing for extension of those plugins, and also global control of things like events, setTimeout() etc?
I want to be able to do these kind of things:
Extend someone else's jQuery plugin, e.g. if I want to add a new feature, but not touch the original codebase
Have my own server-side detection script pass a value to JS (using a HTML meta tag) so JS can detect that and then decide which script to use (e.g. tone down some of the jQuery for lesser devices)
Better control all the events that are attached
setTimeout() - I have loads of these dotted around the place at various intervals - I want to control all this in one function
Add my own fixes to jQuery scripts. If I download a ready-made one and use it I always find I can improve usability - especially on mobile devices - so I want to add my own fixes and improvements.
Control the resize event. There's all sorts going on at the moment and it's quite a job triggering a full re-size when I write new code (and the resize is pretty slow on some mobile devices)
You can use RequireJS or similar library to load scripts dynamically depending on screen size or navigator's user agent parameter (You will need to set condition checking yourself though).
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.
There are so many lightboxes to choose from, I'm looking for a very lightweight one to use in an embedded javascript widget that would be a single domain name. I saw the perfect one on chainreactioncycles.com, it popped up out of nowhere so I took a screenshot:
I tried looking for info on it on the page source, but couldn't find anything that would let me trace where it came from... Would anybody know of one like this? Or exactly that one?
If not exactly like above, anything similar would be great too, keeping the following in mind:
Very small javascript download (animation not needed)
Self contained, not dependent on any libraries other than jquery (since I'm already using that anyway).
Works in major browsers
Close button (like GetSatisfaction or UserVoice)
Dims background
Avoids javascript namespace conflicts (or can easily be made to avoid them)
CSS styling of lightbox does not interfere with site styling
Have you used an existing lightbox scripts for this same purpose with similar requirements? Did you roll your own? Insights welcome!
What you are looking for is called a modal box.
Here is a list of them
... and here is a striking replica of what you are looking for
Check out Zoombox.. It sounds like what you're looking for... Simple to use... Allows custom content.. jQuery Module... From past experience it covers what you have outlined as requirements etc
http://www.grafikart.fr/zoombox will tell you all you need to know.
Is there a way to create your own HTML element? I want to make a specially designed check box.
I imagine such a thing would be done in JavaScript. Something akin to document.createHTMLElement but the ability to design your own element (and tag).
No, there isn't.
The HTML elements are limited to what the browser will handle. That is to say, if you created a custom firefox plugin, and then had it handle your special tag, then you "could" do it, for varying interpretations of "doing it". A list of all elements for a particular version of HTML may be found here: http://www.w3.org/TR/html4/index/elements.html
Probably, however, you don't actually want to. If you want to "combine" several existing elements in such a way as they operate together, then you can do that very JavaScript. For example, if you'd like a checkbox to, when clicked, show a dropdown list somewhere, populated with various things, you may do that.
Perhaps you may like to elaborate on what you actually want to achieve, and we can help further.
Yes, you can create your own tags. You have to create a Schema and import it on your page, and write a JavaScript layer to convert your new tags into existing HTML tags.
An example is fbml (Facebook Markup Language), which includes a schema and a JavaScript layer that Facebook wrote. See this: Open Graph protocol.
Using it you can make a like button really easily:
<fb:like href="http://developers.facebook.com/" width="450" height="80"/>
The easiest way would be probably to write a plugin say in Jquery (or Dojo, MooTools, pick one).
In case of jQuery you can find some plugins here http://plugins.jquery.com/ and use them as a sample.
You need to write own doctype or/and use own namespace to do this.
http://msdn.microsoft.com/en-us/magazine/cc301515.aspx
No, there is not. Moreover it is not allowed in HTML5.
Take a look at Ample SDK JavaScript GUI library that enables any custom elements or event namespaces client-side (this way XUL for example was implemented there) without interferring with the rules of HTML5.
Take a look into for example how XUL scale element implemented: http://github.com/clientside/amplesdk/blob/master/ample/languages/xul/elements/scale.js and its default stylesheet: http://github.com/clientside/amplesdk/blob/master/ample/languages/xul/themes/default/input.css
It's a valid question, but I think the name of the game from the UI side is progressive markup. Build out valid w3 compliant tags and then style them appropriately with javascript (in my case Jquery or Dojo) and CSS. A well-written block of CSS can be reused over and over (my favorite case is Jquery UI with themeroller) and style nearly any element on the page with just a one or two-word addition to the class declaration.
Here's some good Jquery/Javascript/CSS solutions that are relatively simple:
http://www.filamentgroup.com/examples/customInput/
http://aaronweyenberg.com/90/pretty-checkboxes-with-jquery
http://www.protofunc.com/scripts/jquery/checkbox-radiobutton/
Here's the spec for the upcoming (and promising) JqueryUI update for form elements:http://wiki.jqueryui.com/Checkbox
If you needed to validate input, this is an easy way to get inline validation with a single class or id tag: http://www.position-absolute.com/articles/jquery-form-validator-because-form-validation-is-a-mess/
Ok, so my solution isn't a 10 character, one line solution. However, Jquery Code aside, each individual tag wouldn't be much more than:
<input type="checkbox" id="theid">
So, while there would be a medium chunk of Jquery code, the individual elements would be very small, which is important if you're repeating it 250 times (programmatically) as my last project required. It's easy to code, degrades well, validates well, and because progressive markup would be on the user's end, have virtually no cost on the server end.
My current project is in Symfony--not my choice--which uses complex, bulky server-side tags to render form elements, validate, do javascript onclick, style, etc. This seems like what you were asking for at first....and let me tell you, it's CLUNKY. One tag to call a link can be 10 lines of code long! After being forced to do it, I'm not a fan.
Hm. The first thought is that you could create your own element and do a transformation with XSLT to the valid HTML then.
With the emergence of the emerging W3 Web Components standard, specifically the Custom Elements spec, you can now create your own custom HTML elements and register them with the parser with the document.register() DOM method.
X-Tag is a helpful sugar library, developed by Mozilla, that makes it even easier to work with Web Components, have a look: X-Tags.org
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.