HTML: element breakdown - html

Suppose I have the following HTML element:
<foo spam="eggs">bar</foo>
I know that foo is the 'tag', but what are the technical names for spam, eggs, and bar?

spam="eggs" is attribute (as a whole) and bar is the child node.
You can also break the attribute down to attribute name and attribute value.

spam is an attribute name
"eggs" is the attribute spam's value
and bar is a child node, in this case, a child of type textNode. Children can also be "elements" (aka tags).
Read more on elements (aka tags) here: http://www.w3schools.com/html/html_elements.asp
And on attributes here: http://www.w3schools.com/html/html_attributes.asp

I recommend this one and the next chapter: http://www.w3schools.com/html/html_elements.asp
In any case, these are called attributes, values and content.
EDIT: whoa, ninjas abound.

Related

Terminology - The types of elements in HTML

A while ago there was a term that I remembered that described two categories of elements. I forgot the term and I want to know what that term was. The information I can remember is that the first category of elements get their values from within HTML like <p> or <a> or <ul> but there is another category of elements which get their values from "outside" of HTML like <img> or <input type="textbox">. I want to know the terminology for these types.
Edit - I've went through Zomry, Difster and BoltClock's answers and didn't get anything. So I remembered some extra piece of information and decided to add it. The two categories are Lazy Opposites of each other. For example if one is called xyz, then the other is called non-xyz.
Probably you mean replaced elements (and non-replaced, respectively)?
However, the distinction between them is not so unambigous. For example, form controls were traditionally considered replaced elements, but the HTML spec currently explicitly lists them as non-replaced (introducing the "widget" term instead).
The HTML specification mentions for tags like <img> and <input> the following: Tag omission in text/html: No end tag.
Tags with an end tag are defined as: Tag omission in text/html: Neither tag is omissible.
So as far as I can find, the HTML spec does define a technical name for this, apart from void versus normal elements, so what Watilin pointed out in the comments should be fine: standalone vs containers.
As an added side-note: HTML has a lot more HTML content categories. You can find a complete overview at the HTML spec here: https://html.spec.whatwg.org/multipage/indices.html#element-content-categories
Also interesting to read to visualize that a bit better: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories
Elements whose contents are defined by text and/or other elements between their start and end tags don't have a special category. Even the HTML spec just calls them normal elements for the most part in section 8.1.2.
Elements whose primary values are defined by attributes and that cannot have content between their tags are called void elements. img and input are indeed two examples of void elements. Note that void elements are not to be confused with empty elements; see the following questions for more details on that:
Are void elements and empty elements the same?
HTML "void elements" so called because without content?
<input type="text" id="someField" name="someField">
With an input selector, you can get a value from it like so (with jQuery):
$("#someField).val();
Where as with a paragraph or a div, you don't get a value, you get the text or html.
<div id="someDiv">Blah, blah, blah</div> You can get that with jQuery as follows:
$("#someDiv").html();
Do you see the difference?

XPath to select all href's in element

i have a trouble with XPath. I have a HTML page with complicated structure and i want to select ALL href's elements in particular div, regardless of the depth of nesting.
Why next code doesn't work and what can I do to fix?
//*[#id='some_id']//*//a
Matching #href attributes
Select all #href attributes, not all anchor tags.
//*[#id='some_id']//#href
If you only want to match the #href attributes of anchor tags, go for this query, which selects all anchor tags inside that "some_id"-element, and then their #href tags.
//*[#id='some_id']//a/#href
// and the descendant-or-self-axis
I'm not sure what you wanted to achieve with the .//*//a construct. This is an abbreviation for
./descendant-or-self::node()/child::*/descendant-or-self::node()/child::a
so there must be some element in-between. If the anchor tag is directly contained within the #id='some_id'-element, it will not be found, for example for this input:
<div id='some_id'>bar</div>
//*[#id='some_id']//a would have matched this element.
// addresses the entire descendant axis, so this is sufficient:
//*[#id='some_id']//a
Otherwise, you wouldn't get a elements that are immediate descendants of the element addressed with //*[#id='some_id']. (If your environment recognizes id attributes as being IDs, you can also address this element with id('some_id').)
But your problem is likely to be something different. //a usually addresses all a elements in the null namespace. Possibly your a elements aren't in the null namespace but in the XHTML namespace. You could match them like
//*[#id='some_id']//*[local-name()='a' and namespace-uri()='http://www.w3.org/1999/xhtml']
or, if you only have to expect HTML elements anyway
//*[#id='some_id']//*[local-name()='a']
or in XPath 2.0 even simpler
//*[#id='some_id']//*:a
Depending on your environment, you can also register a namespace prefix so that you can do something like
//*[#id='some_id']//html:a
in both XPath 1.0 and 2.0.

Why should one add ID to their HTML tags?

A simple question: why should we add the id into our HTML tags if they work perfectly well without them? I know that one of their uses is being able to navigate though the page via hashtags (#), but is there any other use for them?
Uses of id attributes in HTML
As a target for a fragment identifier on a URL.
As a target on form controls for the for attribute on <label> and <output> elements.
As a target on <form> elements for the form attribute on form associated elements.
As a target for element references via the microdata itemref attribute.
As a target for element references via some ARIA attributes including aria-describedby, aria-labelledby and 4 others.
As a target on <th> elements for the headers attribute on <td> and <th> elements.
As a target on <menu> elements for the contextmenu attribute.
As a target on <datalist> elements for the list attribute on <input> elements.
As part of a hash-name reference to <map> elements for the usemap attribute on the <img> and <object> elements.
As an identifier of an element in a CSS selector
As an identifier of an element for JavaScript processing
They're most often used to uniquely identify elements for styling (CSS) and scripting (JavaScript et al) purposes.
But if you're asking about HTML and only HTML, then one example where declarative IDs are useful is associating a <label> with its <input>, <button> or <textarea> control via its for attribute:
<label for="ex">Example field:</label>
<input type="text" name="ex" id="ex">
Without assigning this attribute, activating the label does nothing, but when you pair both elements together using for and id, activating the label causes its control to gain focus.
The other way to associate a form label with its control is to contain it within the label:
<label>
Example field:
<input type="text" name="ex">
</label>
But this doesn't always suit the structure of a form or a page, so an ID reference is offered as an alternative.
Other circumstances where an id attribute serves a function are covered extensively in Alohci's answer.
You can use IDs to acces your divs from javascript, CSS and jquery. If you don't use IDs it will be very difficult for you to interact with your HTML page from JS.
AFAIK, they are used to uniquely refer to a tag.And makes it easier for you to refer to the tag.
IDs are used for accessing your elements in CSS and JavaScript. Strictly speaking IDs should uniquely identify an element. You can also use class attributes to identify groups of elements.
The id attribute provides a unique identifier for an element within the document. It may be used by an a element to create a hyperlink to this particular element.
This identifier may also be used in CSS code as a hook that can be used for styling purposes, or by JavaScript code (via the Document Object Model, or DOM) to make changes or add behavior to the element by referencing its unique id.
see http://reference.sitepoint.com/html/core-attributes/id
for more info on class see here: http://reference.sitepoint.com/html/core-attributes/class
it is there to help you identify your element in java-script code.the getElementByID function in java-script give the handle of an element with specific ID for you.like this.
var someElement = document.getelementById("someID");
// do whatever with someElement;
I myself also prefer class for styling through CSS but sometimes you need an element to be unique. For accessibility reasons you use id to input elements to "connect" its label to it by using for attribute. And for Javascript it's much simpler to select an element if it has got id attribute.
The main reason I use ids for my HTML elements is the fact that their selection is faster, in Javascript with getElementById and in CSS as well, using the #id class.
Of course, I'm not saying this is always a good idea, especially in CSS, where having classes based on ids can cause a lot of redundancy, it's just one of the reasons
First, only add ID when you will need to use them. In most cases id is used to do other things like:
A reference for scripts,Selecting elements to apply scripts to,
A style sheet selector, selecting elements for styling
Named anchors for linking to, which is what u called page navigation
So simply because in most cases you will want to do something to or with your content in any tag, its good to put an identifier, that is the id attribute.

When using HTML5 Microdata, should the 'itemscope' and 'itemtype' always be used on the same element?

I'm trying to understand the reason behind the existence of two attributes instead of just making the element holding the 'itemtype' the one that wraps the scope for the item.
Is it valid to have 'itemtype' attribute on one element and 'itemscope' attribute in some other? like this:
<section itemtype="http://data-vocabulary.org/Person">
<div itemscope>
<span itemprop="name">Alonso Torres</span>
</div>
</section>
If this case is not valid then why the existence of the 'itemscope' attribute at all? Why the spec didn't come up with the idea of making the element holding the 'itemtype' attribute to be the one which sets the scope. That would have make sense for me.
You're right, the itemscope attribute seems redundant. Someone else pointed this out on the W3C's HTML mailing list: http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0517.html
The answer ( http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0523.html ) was that:
The HTML spec editor did user-testing
of the feature earlier, and if I
recall correctly, several of the test
subjects found it much easier if there
was an explicit indicator of the
container, rather than it being
implicit due to the type.
In other words, it's better for attributes to have a single clear definition than multiple implied definitions. Not sure I agree but that's the official view.
itemscope is mandatory if itemtype is used on the same element
The example you show is invalid. The spec has been updated to include this:
The itemtype attribute must not be specified on elements that do not have an itemscope attribute specified.
Here, "must not" is to interpreted as in RFC2119: "the definition is an absolute prohibition of the specification".
I don't believe that it is useful to place an itemtype attribute anywhere but on the same element as the itemscope attribute. The spec says:
The type for an item is given as the
value of an itemtype attribute on the
same element as the itemscope
attribute.
The reasons why two attributes are needed isn't clear to me either. Semantically they serve different purposes, so for clarity of usage it may have seemed more sensible. For simple use, it's possible to create an item using itemscope without giving it a type. That means that itemscope is a boolean attribute, whereas itemtype takes a string value. It's not possible in HTML for an attribute to behave as boolean when used without a value, and a string when used with one, so separate attributes makes sense.
I know that Google did a usability study on the Microdata mark-up before it was announced, so it was likely that such questions were addressed there and that the separate attributes was the preferred outcome. (Although that study also resulted in a preference for itemref being an element, not an attribute, something that was subsequently changed.)

What values can the HTML5 aria-label attribute have?

Can someone give me some examples of what type of values are valid for the aria-label attribute.
It can be any string, which is used to name an element. The ARIA spec: aria-label says:
Most host languages provide an
attribute that could be used to name
the element (e.g. the title attribute
in HTML), yet this may present a
browser tooltip. In the cases where a
visible label or visible tooltip is
undesirable, authors MAY set the
accessible name of the element using
aria-label.
So it's like the HTML title attribute.
Like Alohci said, it can be a string. Any value you want. You use it like so:
<input aria-label="This can be anything inside quotes. It can be very long or very short. Can have numbers 1234567890 or symbols !##$%^&*()-.,<>;/'[]{}\|-_=+å∫ç∂´ƒ©˙ˆ∆˚¬µ˜øπœ®ß†¨√∑≈ÅıÇÎ´Ï˝ÓˆÔÒ˜Ø∏Œ‰Íˇ¨◊„˛Á¸">