When making angular directives, it seems there are a set directives that could just as reasonably be defined as an HTML element, or an attribute. I am trying to figure out what the community convention (if any) is around which one to pick, and why.
So for example, an attribute centric view may be:
<div list-container>
<div list-filter/>
<div list="listOptions"/>
</div>
and the same in a element style view:
<list-container>
<list-filter />
<list controller="listOptions" />
</list-container>
My personal preference is for the second one (seems easier to read, dont have to worry about spans vs divs, etc), but most of the examples and libraries i've seen seem prefer the attribute approach (makes for valid html?)
If you want to support IE8 or below, forget elements. Attributes or class names is the way to go.
Otherwise, I think it largely depends on the type of directive:
If the directive is meant to be used as a component, i.e. substantial functionality, has it's own template etc, I would go for an element. Examples are tab controls, accordions, calendar etc.
If the directive is just about adding a small behavior to either a built-in element (input, select etc) or a custom directive of the first kind, I would make it an attribute.
Related
Is there a way to find out, for any given element, which AngularJS directives were applied on it/its attributes?
In a large web application, I am looking at an HTML element that has an additional attribute that I suspect might invoke a directive (the attribute name is obviously specific to our application). Or it might simply be dead code.
It looks something like this:
<button ctl-remember-special data-ng-click="handleAction()"></button>
(ctl-remember-special being the possible directive in this example)
I cannot seem to find a directive of the appropriate name in our project, but I am not entirely sure because some of the identifiers in our application are assembled at runtime. (To provide an impression of the dimensions, I am seeing more than 6000 directive definitions in our code.)
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.
I am starting to learn some Javascript using Meteor and am looking at their examples.
One bug that tripped me up for a bit happened when I was adding a text-field for input with a button next to it; users would type in a name they wanted to add to a list and then click the button to actually add it.
My question is: why does it seem to be the case that in the html, the text field has to be named with id="..." while the button has to be named with class="..."?
For additional reference, in my javascript file, I am using textfieldname.value and 'click input.buttonname'. Does the id vs. class requirement stem from how I'm using them?
The "id" attribute is used to supply a globally-unique identifier for an element. The "class" attribute is used to categorize or typify an element according to its meaning, its intended use, its relationship to other elements, or whatever else your application requires.
Usually it's more flexible to use classes to identify things, because more than one element can be given the same class, and an element can have as many classes as are needed. Any single element may only have one "id", and the values must not be re-used in the same document. There are clear use cases for both attributes in which one or the other is obviously more appropriate, and many other cases where it's less clear and for which either could be used.
This isn't really a JavaScript issue so much as a "web application design" issue. How one labels HTML elements is dictated by the nature of the content (HTML), the needs of the presentation (CSS), and the intended behaviors (JavaScript).
I understand that using custom html tags is improper for a variety of reasons, but I wanted to run a specific situation by you that might warrant a custom html tag and hopefully get told otherwise or possibly a better way of achieving my goal.
Throughout my code I have what I term as templates that are made up of a div tag with a template and a hidden class attached to it. This is not visible on the screen, but basically these "template" tags contains html that I use in Javascript to create a variety of different items. I do this so that I can style my templates in html rather than have to worry about mixing CSS in with my Javascript.
<!-- TEMPLATE -->
<div class="template hidden">
<span>Random Container</span>
Random Button
</div>
In javascript I would do something like
var template = document.getElementById("template");
var clone = template.cloneNode(true);
clone.removeClass("template hidden");
I would rather be able to do something like this
<template class="hidden">
<span>Random Container</span>
Random Button
</template>
So that if I have multiple templates in a single div I can grab them all rather than having to give them unique class names. Of course my reasoning for needing an implementation goes a lot deeper than this, but its not necessary to waste your time with the details. Let's just say that it will help clean up my Javascript ALOT.
Because the custom template tag is hidden and really is nothing more than a container that is convenient to call within javascript with document.getElementsByTagName("template"); Is this ok to do? I would probably prefix the tag with a custom name in case template ever gets implemented into html.
Modern browsers generally “support” custom tags in the sense of parsing them and constructing DOM nodes, so that the elements can be styled and processed in scripting.
The main problem is IE prior to IE 9, but it can be handled using document.createElement('...') once for each custom tag name.
Another problem is that validators will report the tags as errors, and if there are loads of such errors, you might not notice some real errors in markup. In principle you can create your own DTD to deal with this (I have an HTML DTD generator under construction, but it is trickier than I expected...).
With these reservations, use custom tags if they essentially simplify your job as compared with using classes.
Why not use one of HTML5's data attributes? They are for storing private data or custom info.
For your case, you could add data-type="template" or data-name="template" and then search and remove based on that. One simple function just like you would write to remove your <template> tag, but without breaking rules.
So, using your example, <div data-type="template" class="hidden"></div>
This is a follow-up question for In jQuery is it a bad idea to use name=X for all selectors?
I am using Backbone and decided that I wanted a way to differentiate between HTML elements that were bound and those that were not.
So I would write (in HAML):
.container
.title(name='title')
.separator
As you can see it's clear that the dynamic element is title.
The reason for this was so I could mess around with the style and rename classes without worrying about breaking the app. It also means in the template I can tell what the dynamic elements are without needing to go back and forth with the Backbone View.
My question now is, without using the [name] selector, does anyone have a code convention to keep track of which HTML elements are referenced from JS.
I have considering:
Using a common prefix on class names (e.g. class=bind-title)
Using some sort of custom HTML element (
Thanks!
FYI: I'm using CoffeeScript, Backbone and haml_coffee templates.
Updated jsperf to test all suggestions:
http://jsperf.com/class-or-name-attr-lookup/3
I would consider using a class to indicate that it is dynamic.
I'm not sure if you are aware of this but you can have multiple classes on one element. Like so:
.container
.dynamic.title(name='title')
.separator
This works in traditional HAML but I have not tried it with haml-coffee. If it doesn't work, you might have to specify the class like .title{:class => "dynamic"}(name='title').
I prefer this over a prefix on the class name because it's more semantically meaningful, which is how HTML should be used.
I am using data-view attribute on elements being set when rendering my Views.
This helps me to then show a tooltip in a browser window when I hover over View(s).