Should I be using class names in HTML page that describe it completely, eg. navbar-static-8 to describe a fixed navbar containing 8 items?
Or should I be wrapping the metadata into separate attributes e.g. type="static" items="8".
I want such names to be parsed in javascript.
Cleaner would be to use data attributes like:
<div data-type="static" data-items="8"></div>
John Resig wrote a nice article about this http://ejohn.org/blog/html-5-data-attributes/
But if "static" refers to something you want to use for the design of the item, you should use classes since these are designed to be used in CSS. The data attributes are more used in Javascript as meta data about the object.
yes you can use navbar-static-8 type of name of class , and you can 'type="static" items="8"' your custom attribute but test on all browser (specially Intenet Explorer)
You should use descriptive class names for a intuitive css use, like "navbar navbar-static" and use the html5 data for js, like data-navitems="5"
Make use of cascading, use two css classes, navbar to describe general nabvars properties, and navbar-static to describe styles only for the static navbars.
Related
Is it possible to get a class that contains some name? I have many classes with repeated part of the name, like: first_class, second_class, third_class etc.
I want to do something like:
$('selector').getChildren('.*_class')
is it possible?
MooTools uses the CSS selectors in the W3C specs. So you could use [class*="bar"] like this: $('myDiv').getElements('[class*="_class"]').
Just keep in mind if the search string is too generic you might also target other elements. Adding a common class could be a better idea, or even try to match some DOM pattern in the relations between elements.
jsFiddle: http://jsfiddle.net/h49s551s/
One solution would be to add a common class name to each item, i.e.
<div class = "first_class common_classname">foo</div>
then call your objects by using the common class name. Another solution is to call them all at once
$('selector').getChildren('first_class, second_class, thirdclass')
When using element directives I have seen Angular element directives used in two ways:
1. As block level components
The element is styled as display:block, is the component and its children are the component's children, so the element itself is the component.
Use of directive:
<example class="Example"></example>
The directive's html:
<header class="Example-header"></header>
<img class="Example-image">
<footer class="Example-footer"></footer>
2. As an inline wrapper of the component
The element is left as display:inline and effectively acts as an invisible wrapper for the component itself:
Use of directive:
<example></example>
The directive's html:
<div class="Example">
<header class="Example-header"></header>
<img class="Example-image">
<footer class="Example-footer"></footer>
</div>
Obviously each have advantages and disadvantages for example extra markup, loss of layout context due to inline element etc, but is one the correct way? or is this another of Angular's vagaries?
I'm surprised no one responded, but the idea behind creating custom directives is the ability to create reusable pieces of code that fulfill a specific bit of functionality on your site.
This functionality, however, doesn't care about the styles that you are going to use. You can of course conditionally change classes and styles from within Angular, but the core component when dealing with the framework is the data.
With that being said, there is no "correct way" as you bolded in your question. Develop the directive to fit your needs and style of your site.
First this is probably opinion based but i'd really like to share my point of view about this.
If you really follow angular way of doing directives none of theses are a correct way.
Directives are intended to add a behavior to an HTML element.
The less the directive add HTML the best it is as it allow you to have a better control on this element.
Lets take an exemple.
We have a data grid (let say ui-grid, it doesn't really matter)
<ui-grid ...>
...
</ui-grid>
I had a the idea to add some button to add or remove element in the grid.
I first came up with this
<ui-grid ...>
...
</ui-grid>
<button ng-click="addItem()">Add</button>
<button ng-click="removeItem()">Remove</button>
I'm really happy with this and that's ok, but finally i need to use theses buttons in some other views. I'll have to duplicate the HTML, duplicate the JS and adapt it to the collection.
The common mistake
That's obviously not a good idea.
Instead i will do a directive. Lets say "button-list" : it produce the same html and behavior.
<ui-grid ...>
...
</ui-grid>
<button-list></button-list>
That's pretty cool.
Now i have some need. On one view i need the add button to be blue, on an other one i don't need to have a remove button, and on a last one i want the button text to be "X" and "+" (That's was some request by a client in a true story).
I could make a big object with a list of option and etc... but this is really painful and you need to touch the directive each time you need to add a custom different little behavior.
The good way to go
Now lets just think again about what i wanted to do.
I want the button to interact with the grid... and that's pretty much all. This is how we should go building a custom directive.
We could then produce this directive this way :
<div grid-button-container collection="mycollection">
<ui-grid ...>
...
</ui-grid>
<button grid-add-item>Add</button>
<button grid-remove-item>Remove</button>
</div>
So what do we have here ? We have three different directives.
grid-button-container : Its responsibility is to hold the list for the sub-directives.
grid-add-item : It add a function on click that add an element to the collection of grid-button-container.
grid-remove-item : It add a function on click that remove an element to the collection of grid-button-container.
Both grid-add-item and grid-remove-item will be requiring the grid-button-container to be used.
I cannot describe all the implementation of this (it would take too long) but i think this is how directives should be used. Such as almost no angular build-in directives (ng-*) add HTML and just add a behavior i think all the directives should be build in this way.
Pro :
You have a full control about your HTML
Directives are tiny and trivial
This is really re-usable
Cons :
Can be harder and longer to implement.
To make a final point, the two way you're asking about are just different. No one is better than the other it will just depend on your own HTML organisation and it will depend on the directive use.
Hope it helped.
Newbie to ASP.net MVC 4 and trying to make sense of Razor. If I wanted to just display some text in my .cshtml page, can I use
<label class="LabelCSSTop">Introduction</label>
or should I use:
#Html.Label("STW", htmlAttributes: new { #class = "LabelCSSTop" })
Not sure if one is preferred over the other or if either is okay. If the latter emits the label tag anyway, should I just stick to the former?
Again, if I just wanted to display a text box, can I just do this:
<input id="txtName" type="text" />
or should I do this:
#Html.TextBox("txtName", "")
Is there a situation when I should use the #Html over the regular html tag?
Thanks in advance!!
In the case of your label snippet, it doesn't really matter. I would go for the simpler syntax (plain HTML).
Most helper methods also don't allow you to surround another element. This can be a consideration when choosing to use/not use one.
Strongly-Typed Equivalents
However, it's worth noting that what you use the #Html.[Element]For<T>() methods that you gain important features. Note the "For" at the end of the method name.
Example:
#Html.TextBoxFor( o => o.FirstName )
This will handle ID/Name creation based on object hierarchy (which is critical for model binding). It will also add unobtrusive validation attributes. These methods take an Expression as an argument which refers to a property within the model. The metadata of this property is obtained by the MVC framework, and as such it "knows" more about the property than its string-argument counterpart.
It also allows you to deal with UI code in a strongly-typed fashion. Visual Studio will highlight syntax errors, whereas it cannot do so with a string. Views can also be optionally compiled along with the solution, allowing for additional compile-time checks.
Other Considerations
Occasionally a HTML helper method will also perform additional tasks which are useful, such as Html.Checkbox and Html.CheckboxFor which also create a hidden field to go along with the checkbox. Another example are the URL-related methods (such as for a hyperlink) which are route-aware.
<!-- bad -->
my link
<!-- good -->
#Html.ActionLink( "my link", "foo", "bar", new{ id=123 } )
<!-- also fine (perhaps you want to wrap something with the anchor) -->
<span>my link</span>
There is a slight performance benefit to using plain HTML versus code which must be executed whenever the view is rendered, although this should not be the deciding factor.
Depends on what your are doing.
If you have SPA (Single-Page Application) the you can use:
<input id="txtName" type="text" />
Otherwise using Html helpers is recommended, to get your controls bound with your model.
If you want to just display some text in your .cshtml page, I do not recommend #Html.Label and also not to use the html label as well. The element represents a caption in a user interface. and you'll see that in the case of #Html.Label, a for attribute is added, referring to the id of a, possibly non-existent, element. The value of this attribute is the value of the model field, in which non-alphanumerics are replaced by underscores.
You should use #Html.Display or #Html.DisplayFor, possibly wrapped in some plain html elements line span or p.
The helpers are there mainly to help you display labels, form inputs, etc for the strongly typed properties of your model. By using the helpers and Visual Studio Intellisense, you can greatly reduce the number of typos that you could make when generating a web page.
With that said, you can continue to create your elements manually for both properties of your view model or items that you want to display that are not part of your view model.
When it comes to labels, I would say it's up to you what you prefer. Some examples when it can be useful with HTML helper tags are, for instance
When dealing with hyperlinks, since the HTML helper simplifies routing
When you bind to your model, using #Html.LabelFor, #Html.TextBoxFor, etc
When you use the #Html.EditorFor, as you can assign specific behavior och looks in a editor view
#html.label and #html.textbox are use when you want bind it to your model in a easy way...which cannot be achieve by input etc. in one line
Trying to learn html/css. I've been looking at the html & css files of a couple different websites that have something along the line of:
<span class="mytest anothertest">some text goes here</span>
I understand the "mytest" part but what does "anothertest" do? There's no reference to that anywhere in their css or html files.
anothertest is just another class like mytest. You can apply more than one to an element.
There are several possible reasons for the presence of a class name in a class attribute value. Using the class in page stylesheets is probably most widely known, but not the only one:
The class name can be used in JavaScript in order to process a set of elements conveniently. (Using document.getElementsByClass is one way to achieve this; another way is to use jQuery; and you could even hand-code it rather simply.)
Designated class names are used in some metadata systems, such as microformats. Some search engines recognize such names and use them to provide semantic searching (though this approach probably loses to microdata, which uses different attributes).
A class name can be used in a user style sheet, e.g. by a developer who wishes to do some testing. This could well be the case if the class name is literally “anothertest.”
The name might be there to allow future development, e.g. so that elements of a class will be or may be styled in some future version. The designers might have ideas on styling but they haven’t decided on it—they just want it to be easy when they are ready.
It could be just a holdover. It was a class that had some use, but things changed. There was really no particular reason to remove it.
This is a very good question. It involved the difference between id and class.
ID
An ID placed on an element, is a unique identifier for that element. An element may only have one ID, and only one of the same ID may exist on a page. So for instance, the following examples are not possible.
<a id="someid anotherid">Multiple IDs - Wrong</a>
<a id="someid"><span id="someid">Same ID twice - Wrong</span></a>
Class
A class name however, is the exact opposite. An element may have several class names, and the same class name may appear multiple times on a page. Like so:
<a class="someclass anotherclass">Multiple Classes - Correct</a>
<a class="someclass"><span class="someclass">Same Class twice - correct</span></a>
In short, the syntax displayed in the question is simply having 2 class names on one element, which is perfectly acceptable.
Class name are also used to easily select elements in the page with JavaScript. You can use the getElementsByClassName method to access them or using your favorite CSS selector library (ex.: Sizzle) if you need compatibility for older browser.
Like a tag that I can use to store some necessary info? But really isn’t required or used by the HTML? Works like the tag attribute for objects on Visual Basic?
Up until HTML5 no. With HTML 5 there is provision for this with the data-* attribute.
For example:-
<div id="myStuff" data-mydata="here is my data">
In current technology there is no "official" away to do this. However all browsers allow you to add any arbitary attribute to a HTML element so in HTML4 you can do this:-
<div id="myStuff" data-mydata="here is my data">
Which as you can see is identical but not offically sactioned and if you want strict XHMTL compliance will be considered "broken".
You can access the attribute just as you would any other:-
var mydata = document.getElementById("myStuff").getAttribute("data-mydata");
You could perhaps use the html5 data-* attributes? It'll fail validation on html4, but it is still probably the best option...
If you're storing data to use in javascript, you can also use something like jQuery's Metadata plugin. Basically, you can store data within the element's class="" attribute, like so:
<div id="aaa" class="class1 class2 class3 { type: 'food', color: 'green' }"></div>
Then in javascript:
alert($('#aaa').metadata().color) // "green"
Other kits use the title or rel attributes to store data. While this is more validation friendly, it may or may not be better than using AnthonyWJones' answer of just using non-standard attributes. It'll "break" validation, but then again according to Dojo, custom attributes are perfectly valid HTML, even if they don't validate against a DTD.
So no - there isn't a single well accepted specific attribute where you can dump all data. All existing attributes are for specific uses. But you can either 1) create your own attributes, or 2) coopt an existing tag to reuse for your purposes. Just wanted to point out the alternative.
Have a look at www.htmlref.com or W3C for the used attributes.
Other than those you can just add your own, they will render and they will be accessible via code for instance in C# you can access a controls attribute collection.
Control.Attributes["MyCustomAttribute"] = "Hello World";
there’s rel and rev attributes, which work in elements with an href-attribute. they have a semantic meaning, but are often abused as an attribute to store additional information