I always thought the standard way to specify a fragment identifier is by <a name="foo"></a>.
go to foo
<a name="foo"></a> <!-- obsolete method, it seems -->
<p>some content under that anchor with name</p>
But it seems like this is the old way, and the new way is using an id, like this:
go to bar
<p id="bar">some content under that p with id</p>
In fact, the W3C validator says that name is obsolete for the <a> element. So are there 2 ways to jump to the fragment identifier but 1 of them is obsolete? (And when did that happen?)
(there are other questions about the difference between id and name, but this one is about fragment identifier)
So are there 2 ways to jump to the fragment identifier but 1 of them is obsolete?
There are two ways to identify a fragment.
(There are also two ways to jump to one, since you can do it with a URL or write a pile of JavaScript to scroll the page).
And when did that happen?
id was introduced in 1996 when HTML 4 came out. It effectively obsoleted the name attribute for anchors.
name was made officially obsolete in HTML 5 in 2014 (or in Living HTML on some date that I'm not going to try to figure out).
Yes there are two ways to jump to a fragment identifier and both aren't obsolete ( except a element).
That's rules applied to all HTML 5 elements other than a (because in a hasn't name attribute in HTML5).
So shortly it's obsolete to idenfity name attribute as fragment idenitifier for a element as that's attribute depricated since HTML4.
Flow of accessing fragment from HTML5 Specification:
If there is an element in the DOM that has
an ID exactly equal to fragid, then the first such element in tree
order is the indicated part of the document; stop the algorithm here.
If there is an a element in the DOM that has a name attribute whose
value is exactly equal to fragid, then the first such element in tree
order is the indicated part of the document; stop the algorithm here.
Otherwise, there is no indicated part of the document.
Both ways of doing fragment identifiers work.
Using id="fragment" is the newer, recommended way of jumping to fragments in HTML. It was introduced with HTML4, and works basically everywhere (I just verified this with IE5).
<a name="fragment">, the older way, still works, but is obsolete since HTML5.
Answer to your question: Yes, There are two ways to identify a fragment and one is obsolete.
What is Fragment Identifiers ?
Fragment identifiers for text/plain.
URIs refer to a location in the same resource. This kind of URI starts with "#" followed by an anchor identifier (called the fragment identifier).
Fragment Identifier using JS like below.
location.replace('#middle');
More information on the name attribute.
Basically, the name attribute has been deprecated (obsolete in HTML5-speak) for just about everything except for form elements. Forms retain them as the method of identifying data, and it is the name plus the value property which is sent back to the server. (The id in form elements is used for attaching label elements, and has nothing to do with the actual data).
There is a fundamental weakness in the name attribute, which the id attribute addresses: the name attribute is not required to be unique. This is OK for forms where you can have multiple elements with the same name, but unsuitable for the rest of the document where you are trying to uniquely identify an element.
The id attribute was specifically required to be unique, which makes it better for identifying a link target, among other things. CSS is pretty relaxed about applying styles to multiple elements with the same id, but JavaScript is more strict about this requirement. And, of course, you can’t have a practical link target if you can’t guarantee uniqueness.
Related
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?
Is it possible to make an <a href> link to the same page when your destination doesn't have an ID?
Jump to Topic 1
...
<!--destination is below-->
<h1 class="tab-title" data-editor-style="title" style="color:#444444">Topic 1</h1>
Sadly, the answer is no. You need an ID or at least a name, like CBroe mentioned in a comment of your question.
However, I found this here:
Today, all browsers recognize top as being the top of the page. If you
want the visitor to go to the very top of the page, the ID tag can be
left out and the A HREF link will still work.
A URL fragment identifier can only target an element with a matching ID, or a corresponding named anchor. You cannot link to arbitrary elements without IDs. (There was a proposal that would have allowed the use of CSS selectors as fragment identifiers, in which I was personally involved, but it never took off.)
The best you can do is to use JavaScript to select the element you want and give it an ID that is reserved for your hyperlink. If the elements matching this selector will change then you will additionally have to listen for such changes and handle them accordingly, but that's probably beyond the scope of this question.
I'm asking this because I ran into the weirdest problem today. An apparently valid HTML document fails to render properly.
The markup contains lots of deeply nested <b> tags. Here's an example.
It appears that after ~10 levels, the browsers move the tags somewhere at the end. The HTML validator reports:
Line 82, Column 24: End tag b violates nesting rules.
Then I get a few errors about stray closing tags, which make sense if the first error does. But to me it doesn't. What nesting rules does it violate if it's correctly nested?
Having deeply nested <b> tags in itself shouldn't be a problem (except perhaps semantically The b element should be used as a last resort when no other element is more appropriate (See W3C B Element)) - for example, this demo shows quite deep nesting and it validates fine.
...(24 levels deep)
<b>
<b>
Deep nesting
</b>
</b>
... (24 levels deep)
However, perhaps there is some limit - but much further than you guessed.
If I validate your document on the W3C validator, it complains about the closing tag on line 90. If I remove the contents of this tag (testing for a mis-match) it validates okay.
If I then separately validate the contents of the tag that I removed (hoping to narrow the mis-match further) this surprisingly validated also.
If I put the two back together, the validator fails, which suggests the W3C validator has a limit.
And as an interesting final discovery - if you switch it all to <span> elements (for example) it validates just fine - as per this conversion.
The answer is here in the HTML5 spec: http://www.w3.org/TR/2014/REC-html5-20141028/syntax.html#push-onto-the-list-of-active-formatting-elements
It says:
If there are already three elements in the list of active formatting elements after the last list marker, if any, or anywhere in the list if there are no list markers, that have the same tag name, namespace, and attributes as element, then remove the earliest such element from the list of active formatting elements. For these purposes, the attributes must be compared as they were when the elements were created by the parser; two elements have the same attributes if all their parsed attributes can be paired such that the two attributes in each pair have identical names, namespaces, and values (the order of the attributes does not matter).
So: if you have more than three nested "active formatting elements" (such as <b>, <i>, <u> etc.), the browser will remove them from a list that it uses during parsing, and all sorts of strange things can happen.
Total newbie question, but I cant figure out what im doing wrong. I want a make a link that jumps down the page to a header. I believe these are called fragment links. Here is my code thats not working:
My Link
<div id="cont">
<p>Lots of content here, abbreviated in this example to save space</p>
<h2 id="Frag">Header I want to jump to</h2>
</div>
Pretty sure you need to specify the name attribute for an anchor to work, for example:
Skip to content
<div name="content" id="content"></div>
Okay, so 'pretty sure' was a euphemism for 'guess' and I thought I'd look it up, so, from the HTML 4.01 Specification we get this from section 12.2.3 Anchors with the id attribute:
The id attribute may be used to create an anchor at the start tag of
any element (including the A element). This example illustrates the use of the id attribute to position an anchor in an H2 element. The anchor is linked to via the A element.
You may read more about this in Section Two.
...later in the document
<H2 id="section2">Section Two</H2>
...later in the document
<P>Please refer to Section Two above for more details.`
To carry on the convention of guesswork, perhaps your page isn't long enough to allow jumping to that content (that is, your page might have nowhere to jump and the content to jump to is already visible.)
Other than that, and from the same section of the spec previously linked, here is some general info on when to use what as the anchor identifier (in terms of the link its self) that could be otherwise valuable:
Use id or name? Authors should consider the following issues when
deciding whether to use id or name for an anchor name:
The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
Some older user agents don't support anchors created with the id attribute.
The name attribute allows richer anchor names (with entities).
Your code works fine in firefox anyway you can use as well name instead of id..
http://www.w3schools.com/tags/att_a_name.asp
if you want to have a nice scrolling you can use jquery scroll http://api.jquery.com/scroll/
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.)