Change href of anchor in YUI - javascript

I know jQuery although I need to use YUI to change the href of an anchor with a class name (which is why I can't use straight up JavaScript).
This is what I have in jQuery, what's the equivalent in YUI?
$("a.magic-link").prop("href", "http://www.magic.com");

Use setAttribute(). See http://yuilibrary.com/yui/docs/api/classes/Node.html#method_setAttribute for reference documentation.
If you're working with DOM nodes in YUI, you should definitely read the Node user guide, it has lots of examples to help you understand how the API works in general: http://yuilibrary.com/yui/docs/node/
Edit: Thanks, Juan! Please also see http://jsrosettastone.com, which maps jQuery methods to YUI methods. The DOM APIs are conceptually pretty similar, they just have different names for things.

Related

What's the difference between .click(function () { and javascript:myfunction()?

Consider the simple link below:
Link
I understand there are two ways to run a function when a user clicks this element:
$(".mylink").click(function () {
and
Link
Is there a performance difference between the two, or any other practical reason I should use one over the other?
Using $('.mylink').click(function(){ is better as it follows standard event registration model. (jQuery internally uses addEventListener and attachEvent).
Basically registering an event in modern way is the unobtrusive way of handling events. Also to register more than one event listener for the target you can call addEventListener() for the same target.
Read jQuery.click() vs onClick
and How does inline Javascript (in HTML) work?
https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting
They have the same functional behavior, there is no difference whatsoever.
The difference is in code modularity and maintainability.
Using the first method is preferred and more appropriate because it doesn't mix between HTML and JavaScript, a concept called Unobtrusive JavaScript.
If you have worked in the early days of HTML, then you should remember when there were all those attributes like background, color, font ... etc.
Then CSS came in, and everybody told us not to use those old attributes anymore because they mix presentation with document structure, instead we should use CSS to control layout and look of the document.
This is similar to that idea but it is now used for code, separate functionality from document structure.
Edit: Quoting from #mplungjan comment in order to be more accurate:
That there is no difference is not true. href="javascript:myFunction()" does not have the ability to cancel the actual click with a preventDefault or return false. Hence animated gifs will stop running in some browsers and older browsers would even partially unload the page. Also if the function returned a value, the page would be replaced with that value, seen when beginners try href="javascript:window.open..." and get [object object] on the page
Jquery like any other good JavaScript frameworks supplies you with functionality independent of browser platform wrapping all the intricacies, which you may not care about or don't want to care about.
I think using a framework is better instead of using pure JavaScript and doing all the stuff from scratch, unless you usage is very limited.
I definitely recommend JQuery!
The first one is JQuery convention of an event listener. You need to include jquery library in order to use it. The second one is a Javascript convention. You don't need to include any library or extra code to run. There are no differences in terms of performance, but as I told if you do not want to include any kind of library you should use the second example.

Why does jQuery Mobile use data-role attributes instead of classes?

This may be a naive question, but I'm learning jQuery Mobile and unsure why everything is related to a data-role attribute. It seems that even times when the role is related to the style, they are using data-role over class
I understand that for semantics, data-role makes sense in a lot of cases but it just seems to be abused here. Wouldn't that kind of lookup also be slower?
Why do they use data-role over class?
Thanks for any insight.
Why data
They could simply use role as an attribute (like other frameworks do), but this would make
the resulting HTML invalid. Therefore a data- is added to every attribute name.
Why not classes
I think the main reason for that is to separate view from logic as far as it is possible. In larger projects, CSS and JavaScript are not written by the same person.
It provides a lot of control over powerful styling techniques especially when combined with jquery ui. I use jquery mobile, I used their tool to easily make a theme roller and now when I use elements like data-role-header, footer listview. I have great looking pages with no effort. There are hundreds of data-role attributes you can bring into your code to easily create uniform, user friendly pages. I personally like the data-role - page attribute to create multiple views in a single HTML page. They are easy to use so the best way to learn about them is to play with them.
Please find the explanation of data-roles here.
data-role attribute is used to control the behaviour of the widget of element. For example in case of button you can use input type="button" (no data-role="button" attribute required in this case, as this is standard behaviour of this element) but you can use a element, and then you need to explicitly provide it:
So for me it's rather useful solution, as buttons behavior on mobile devices can be same for different elements. You just need to provide data-role attribute, and jQuery will do the rest for you.
This is the quotation from main jQuery Mobile website:
jQuery mobile framework takes the "write less, do more" mantra to the
next level: Instead of writing unique apps for each mobile device or
OS, the jQuery mobile framework allows you to design a single
highly-branded web site or application that will work on all popular
smartphone, tablet, and desktop platforms.
They want to style every control you have in the same way, so write less, do more approach is fulfilled. So jQuery Mobile adds same styling for all elements with the same role to make things look the same way, but it doesn't mean you can't change it. It just means that they care about good look of your website, and they are aware that every button should be similar to others.
Also the page I mentioned earlier says:
The jQuery Mobile framework uses HTML5 data- attributes to allow for
markup-based initialization and configuration of widgets.
So you are reading HTML and you know how elements will behave without looking to CSS file - which I think is cool if you're not front-end dev. Of course front-end dev can overwrite CSS, but he must follow the rules, e.g. if data-inline is set to true he should style it regarding that elements must naturally follow this rule (be inline).
jQueryMobile adds a load event handler to the page, which processes the DOM looking for various data-xxx attributes. When it finds those, it does more than just stylize the elements.
In many cases it creates a type of widget tied to the data-role. For example, a <div data-role="header"> is turned into a toolbar widget, the creation of which may extensively modify the DOM within that element.
For some of the simpler widgets, like buttons, folks have seen that not much happens other than some classes get added, so why not just shortcut the process and do that directly? That can work, but it isn't future-proof. At different points in history, different versions of jQM had created buttons with different DOM structures. So I personally think it's best not to shortcut jQM, and let it process the data-attributes as it sees fit.
That being said, it would still have been possible to create widgets identified by classes rather than data-attributes, which was how people used to do these things before jQM. But then there might be an expectation that there would be CSS associated with those classes as well. Use of the data- attributes makes it clear that this is a structural/role thing rather than just styling.

alternative for jQuery .css() in Dojo

I am currently working on a project in university where is allowed to use only Dojo (version 1.8). I have following problem: I need to set element css in javascript code. So,
any alternatives in Dojo for jQuery.css()?
Looks like you are looking for the set function in the dojo/dom-style module:
http://dojotoolkit.org/reference-guide/1.8/dojo/dom-style.html#dojo-dom-style-set
And just a thing, the correct terminology for what you are trying to do is setting the inline style of your elements. CSS is just the language used to write stylesheets.

Javascript lightbox component that works with arbitrary HTML

Is there a Javascript component that allows me to simply pass it a string made up of arbitrary HTML (any HTML I wish to use) and will show that HTML in a lightbox?
I've been scouring the internet, searching for examples, but it seems like there simply isn't any component capable of doing this.
Even LightWindow, which claims to be all-purpose, still requires me to attach it to an tag with the href set to an element ID.
This isn't what I want. I want to be able to call a function and pass in the HTML myself.
(Another issue with LightWindow is that it requires scriptaculous as a dependency. The project already uses jQuery, and I'd rather not include two frameworks at once.)
Any ideas?
colorbox is great. It relies on JQuery.
To use it with an html string, you would call it like this:
$.colorbox({html:'<p>Hello</p>'});
You can use jqModal or jQuery UI dialog.
SLaks is correct. You should definitly use JQuery UI dialog. Here is an example of using the JQuery dialog as a modal, very similar to using lightbox.
$("#dialog-message").dialog({modal: true});

onClick w/ DOM vs. onClick hardcoded

In javascript, what are the pro's and con's of encoding an onclick event in the DOM and in the HTML itself?
Which, if either, is better than the other and why?
Your question almost answers itself when you refer to "the HTML itself".
JavaScript is not HTML -- Keeping the HTML and the JavaScript in separate locations is a benefit all by itself. Makes it easier to (humanly) read the HTML, and keeping all the JS in the same location makes it easier to track everything down all at once.
It is better to write your Javascript in Javascript, as OtherMichael says. It is even better to use proper DOM events (addEventListener and attachEvent) rather than on_____, in order to avoid conflicts and allow multiple callbacks for the same event.
Attaching events to an CSS-style ID (or classes), as Jquery does so well, means that if you don't have JS enabled, it will automatically fall through to any links that are referenced. That's good practice, and will help to make sure that your page works in even quite simple browsers, such as some mobile handsets.
It's also good practice to layer the underlying data (the HTML), presentation (CSS) and behaviour (Javascript). Changing individual layers is a lot easier if they are well structured.

Categories

Resources