Since HTML 5, the rel="" attribute (for "Link types") no-longer accepts "first" and "last" as valid values. These keywords are meant to represent the first and last pages in a page sequence, however only "prev" and "next" are supported:
https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types
first - Indicates that the hyperlink leads to the first resource of the sequence the current page is in. This is an obsolete API and is no longer guaranteed to work.
last - Indicates that the hyperlink leads to the last resource of the sequence the current page is in. This is an obsolete API and is no longer guaranteed to work.
next - Indicates that the hyperlink leads to the next resource of the sequence the current page is in.
prev - Indicates that the hyperlink leads to the preceding resource of the sequence the current page is in.
Curiously, the HTML 4.01 specification (December 1999) does list "Start" as a valid value - this value does not appear in the HTML5 specification nor Mozilla's MDN page: https://www.w3.org/TR/html401/types.html#type-links
Start - Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
Going back further in time, the HTML 3.2 specification (January 1997) does not suggest any "first" or "last" equivalents, only next and previous ( https://www.w3.org/TR/REC-html32#anchor ).
Does anybody know of a valid alternative for rel values first/last, or should I just carry on using them just in case Google or other search engines still care to understand them?
These values were deprecated because they were used rarely and inconsistently. Only a couple of user agents did anything interesting with these values, and many validators did not even check them.
I don't agree with the rationale for deprecating these (because rel may be used for internal anchors too), but I suppose it is a lost cause.
So to answer your question, there is no 'standard' alternative. If you need to add this information to your site, I suggest using a data- attribute instead. For example:
<link data-rel="first" href="slide01.html />
<link data-rel="last" href="slide999.html />
There is a javascript API for accessing these values, and it's valid HTML5. Just don't expect the browser to pay much attention to them.
The whole point of data attributes is to insert whatever data you (as page author/developer) need to associate with a given element. You might ask yourself why you want to add this data, and (more importantly) who/what will consume this data.
Related
I'd like to refer to a specific part of a web page which I am not the author of, and which is not tagged with the NAME attribute. The specification of the part I have in mind could be made, e.g., as the location a certain word appears, and which could be manually reached via a FIND operation. I imagine something like
http://somesite.com#search-for:foo-bar
Is there some feature in HTML allowing for this?
No.
You can only link to elements with an id and a elements with a name.
While doing Code Review on Wikimedia Gerrit, I stumbled across comments saying:
$htmlForm->setAction( wfScript() );
Reviewer: not needed, wfScript() is the default for the action.
So I consulted the documentation about HTMLForm::setAction (huge page).
Set the value for the action attribute of the form.
When set to false (which is the default state), the set title is used.
However, what I do not understand is how wfScript (Get the path to a specified script file, respecting file extensions; this is a wrapper around $wgScriptPath etc. except for 'index' and 'load' which use $wgScript/$wgLoadScript) could be extracted from the title (instance of Title?).
This doesn't make any sense to me as wfScript() returns an entry point and all Titles usually share the same entry point.
Looking up HTMLForm::getAction, I see the code really uses Title. Only conditionally, though. Simply said, if Title::getLocalURL would return a URL containing a query string, e.g. /mw/index.php?title=Special:Contributions, wfScript() is returned, and the title isn't used at all, as opposed to what is documented in HTMLForm::setAction(). The rationale is clear: This is because browsers may strip or amend the query string, which is unwanted here.
Why isn't the hidden form field approach always used and why does the Title have to know about its entry point?
How is $this->getConfig()->get( 'ArticlePath' ) related to $this->getTitle()->getLocalURL() [The former is used as a condition in and the latter is possibly returned from HTMLForm::getAction.]
I'm not totally sure I understand your question, so if this answer doesn't really answer your questions, feel free to comment on it and I'll try to fix my answer :)
Why isn't the hidden form field approach always used and why does the Title have to know about its entry point?
Why should it? It would be possible, yes, but the only reason to use it is, that browsers strip out parameters passed to the action parameter of the form. Other values (such as short urls) works fine. The other aspect is, that, if you configure short url's (e.g. yourdomain.com/wiki/Special:UserLogin instead of yourdomain.com/w/index.php?title=Special:UserLogin), why should HTMLForm use
yourdomain.com/w/index.php?title=Special:UserLogin&wpusername=test&wppassword=123 (bad example, because UserLogin doesn't use HTMLForm and wouldn't use GET, but think about any other example :P) instead of the (for the user) nicer one yourdomain.com/wiki/Special:UserLogin?wpusername=test&wppassword=123? So it doesn't have a real technical background to not use always the hidden title field, iirc.
How is $this->getConfig()->get( 'ArticlePath' ) related to $this->getTitle()->getLocalURL()
The wgArticlePath configuration variable specifies the base URL for article links, which means, if you call getLocalURL on a Title object, the config var is used to build the URL/Link if no query is specified (see the code of getLocalURL to know how it works). That means, that the config variable specifies, how links are returned from this function (e.g. /w/index.php?title=$1 or /wiki/$1). So it's a very important part for this function and (to close the circle to HTMLForm) the important condition to decide, if wfScript() is used or the local url (from the Title object), as it is the condition for Title::getLocalURL() to decide if a question mark is used or not.
I hope that helps a bit to understand what HTMLForm does, if not, feel free to comment :)
I've faced two strange attributes of an html tag . They are "data-url" and "data-key".
What are they and how can they be used?
For some reasons i can't show the exact example of the HTML file I've found them in, but here are some examples from the web with such tags:
data-key
data-key
data-url
PS: I've tried to Google, but no useful results were found.
When Should I Use the Data Attribute?
Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.
This time the data attribute is used to indicate the bubble value of the notification bubble.
Profile
This time is used to show the text for the tooltip.
This is the link
When Shouldn’t I Use the Data Attribute?
We shouldn’t use data attributes for anything which already has an already established or more appropriate attribute. For example it would be inappropriate to use:
<span data-time="20:00">8pm<span>
when we could use the already defined datetime attribute within a time element like below:
<time datetime="20:00">8pm</time>
Using Data Attributes With CSS (Attribute selectors)
[data-role="page"] {
/* Styles */
}
Using Data Attributes With jQuery (.attr())
Google
$('.button').click(function(e) {
e.preventDefault();
thisdata = $(this).attr('data-info');
console.log(thisdata);
});
Examples and info from here
Those are called HTML5 Custom Data attributes.
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements. These attributes are not intended for use by
software that is independent of the site that uses the attributes.
Every HTML element may have any number of custom data attributes
specified, with any value.
The reason why you can't find it in Google is because those attribute are custom attributes generated by user for their own usage.
From seeing your code it seems:
The person who has written this code, wants to store some additional
information with the elements. Not sure he may handle this in
Javascript too.
What you should do is to check the Javascript code completely,
whether he is handling those data attributes or if possible check
with him.
Since you code is using jQuery library, check for .data()
method. After a complete code review, if you find it has no use,
then feel free to remove.
data-* attributes are for adding arbitrary data to an element for use solely by the code (usually client side JavaScript) running on the site hosting the HTML.
In order to tell what the three examples you give are for, we would have to reverse engineer the code that comes with them (unless they are documented on the sites) since they don't have standard meanings.
A new feature being introduced in HTML 5 is the addition of custom data attributes. Simply, the specification for custom data attributes states that any attribute that starts with “data-” will be treated as a storage area for private data (private in the sense that the end user can’t see it – it doesn’t affect layout or presentation). This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:</b> <span>Hello, how are you?</span>
</li>
I'm using mobile template HTML files on a PHPBB forum.
I tested the html for errors at http://validator.w3.org/
The test results showed the following error
Line 24, Column 66: {navlinks.FORUM_NAME}
Bad value up for attribute rel on element a: The string up is not a registered keyword or absolute URL.
Not having heard back from the author and not finding much on Google search, I'm trying to understrand what rel="up" does, if anything constructive.
Can't find any mention as an official HTML attribute
http://www.w3schools.com/tags/att_link_rel.asp
wondering if it's probably safe to just remove the phrase rel="up"
The Internet Assigned Numbers Authority (IANA) keeps a list of link relationships The latest version is from March 21 2013.
up: Refers to a parent document in a hierarchy of documents.
Unfortunately, despite the fact that this registry was long established, it was decided that HTML5 would not use this registry and would use a Wiki page to list the conforming link types instead.
Up, is listed in a rather insane section marked "dropped without prejudice", which nobody seems to know what to do with, or how to get those link types out of.
It's safe to drop it, but some browsers and browser plugins make use of it. For example, I use a Firefox plugin called "Link Widgets" like this to make use of the link type.
From: http://www.w3.org/MarkUp/html3/dochead.html
REL=Up
When the document forms part of a hierarchy, this link references the immediate parent of the current document.
If this is causing any specific problems or unexpected results, please post your code. Thanks.
I have a PHP script that will generate <input>s dynamically, so I was wondering if I needed to filter any characters in the name attribute.
I know that the name has to start with a letter, but I don't know any other rules. I figure square brackets must be allowed, since PHP uses these to create arrays from form data. How about parentheses? Spaces?
Note, that not all characters are submitted for name attributes of form fields (even when using POST)!
White-space characters are trimmed and inner white-space characters as well the character . are replaced by _.
(Tested in Chrome 23, Firefox 13 and Internet Explorer 9, all Win7.)
Any character you can include in an [X]HTML file is fine to put in an <input name>. As Allain's comment says, <input name> is defined as containing CDATA, so the only things you can't put in there are the control codes and invalid codepoints that the underlying standard (SGML or XML) disallows.
Allain quoted W3 from the HTML4 spec:
Note. The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire ISO10646 character set.
However this isn't really true in practice.
The theory is that application/x-www-form-urlencoded data doesn't have a mechanism to specify an encoding for the form's names or values, so using non-ASCII characters in either is “not specified” as working and you should use POSTed multipart/form-data instead.
Unfortunately, in the real world, no browser specifies an encoding for fields even when it theoretically could, in the subpart headers of a multipart/form-data POST request body. (I believe Mozilla tried to implement it once, but backed out as it broke servers.)
And no browser implements the astonishingly complex and ugly RFC2231 standard that would be necessary to insert encoded non-ASCII field names into the multipart's subpart headers. In any case, the HTML spec that defines multipart/form-data doesn't directly say that RFC2231 should be used, and, again, it would break servers if you tried.
So the reality of the situation is there is no way to know what encoding is being used for the names and values in a form submission, no matter what type of form it is. What browsers will do with field names and values that contain non-ASCII characters is the same for GET and both types of POST form: it encodes them using the encoding the page containing the form used. Non-ASCII GET form names are no more broken than everything else.
DLH:
So name has a different data type for than it does for other elements?
Actually the only element whose name attribute is not CDATA is <meta>. See the HTML4 spec's attribute list for all the different uses of name; it's an overloaded attribute name, having many different meanings on the different elements. This is generally considered a bad thing.
However, typically these days you would avoid name except on form fields (where it's a control name) and param (where it's a plugin-specific parameter identifier). That's only two meanings to grapple with. The old-school use of name for identifying elements like <form> or <a> on the page should be avoided (use id instead).
The only real restriction on what characters can appear in form control names is when a form is submitted with GET
"The "get" method restricts form data set values to ASCII characters." reference
There's a good thread on it here.
While Allain's comment did answer OP's direct question and bobince provided some brilliant in-depth information, I believe many people come here seeking answer to more specific question: "Can I use a dot character in form's input name attribute?"
As this thread came up as first result when I searched for this knowledge I guessed I may as well share what I found.
Firstly, Matthias' claimed that:
character . are replaced by _
This is untrue. I don't know if browser's actually did this kind of operation back in 2013 - though, I doubt that. Browsers send dot characters as they are(talking about POST data)! You can check it in developer tools of any decent browser.
Please, notice that tiny little comment by abluejelly, that probably is missed by many:
I'd like to note that this is a server-specific thing, not a browser thing. Tested on Win7 FF3/3.5/31, IE5/7/8/9/10/Edge, Chrome39, and Safari Windows 5, and all of them sent " test this.stuff" (four leading spaces) as the name in POST to the ASP.NET dev server bundled with VS2012.
I checked it with Apache HTTP server(v2.4.25) and indeed input name like "foo.bar" is changed to "foo_bar". But in a name like "foo[foo.bar]" that dot is not replaced by _!
My conclusion: You can use dots but I wouldn't use it as this may lead to some unexpected behaviours depending on HTTP server used.
Do you mean the id and name attributes of the HTML input tag?
If so, I'd be very tempted to restrict (or convert) allowed "input" name characters into only a-z (A-Z), 0-9 and a limited range of punctuation (".", ",", etc.), if only to limit the potential for XSS exploits, etc.
Additionally, why let the user control any aspect of the input tag? (Might it not ultimately be easier from a validation perspective to keep the input tag names are 'custom_1', 'custom_2', etc. and then map these as required.)