I encountered this page https://www.google.com/accounts/ServiceLogin, a Google service login page that (beyond just omitting a doctype), contains 6 instances of </img>
For example,
<img src="https://www.google.com/accounts/google_transparent.gif"
alt="Google">
</img>
Why would they ever do that? What benefit/functionality/grandfathering do they possibly achieve?
Anything I've ever read about HTML and XHTML has made it pretty unequovical:
In HTML 4.01 and prior, <img> tags are never to be closed ( <img src="img.gif" alt="text" >).
In XHTML, <img> tags are to be closed using self-closing syntax ( <img src='img.gif' alt="text" />)
In HTML5, (my understanding is that) either syntax (open or self-closed) is acceptable, but still never </img>.
I'd say this is a bug. In at least one case it seems to be just producing totally invalid code:
<img class=logo
src='https://www.google.com/intl/en/images/logos/accounts_logo.gif'
alt="Google" />
</img>
You can see the img tag is self closing and being closed by a separate closing tag. Clearly unintended. And its inconsistent which is a little weird too. I'd suggest e-mailing them and asking. :)
I've found the only (proposed) way this code is ever actually compliant, though it does not apply in Google's case (since they lack a DOCTYPE).
XHTML 2, which was proposed and then scrapped, implements a </img> tag as a way to replace the alt attribute.
So, instead of this in XHTML 1.0/1.1:
<img src="monkeys.gif" alt="Monkeys throwing feces" />
You'd have this
<img src="monkeys.gif">Monkeys throwing feces</img>
Where 'Monkeys throwing feces' only displays if monkeys.gif fails to load.
This would make <img> behave as other content embedding tags, like <object>.
In the spec's words,
The img element is a holder for
embedding attributes such as src.
Since these attributes may be applied
to any element, the img element is not
strictly necessary, but is included to
ease the transition to XHTML2. Like
the object element, this element's
content is only presented if the
referenced resource is unavailable.
Maybe their HTML-generator closes every <tag> with a corresponding </tag>, which is just a programmatically lazier alternative to writing <tag/> for such single tags.
Related
Is it necessary to close an img tag?
<img src="" alt="" />
versus
<img src="" alt"">
I'm purely wondering as someone learning HTML who has never learned the proper way, but has seen both methods used. I tend to use the first i.e. close all my tags.
In XHTML, all elements must be closed. In HTML, some (like <img>) are optional.
(X)HTML5 has both syntaxes: HTML and XHTML. Then, it's your choice if you use HTML5 or XHTML5.
If you doubt, you can always use W3C Validator to check if your code is valid.
You don't need the "/" at the end . This is W3 standard for tags in HTML5. If using XHTML, you should close it.
I don't see why you would ever intentionally exclude the closing slash. It makes the tag more readable and your HTML will pass a lot more validators.
However, if you're 4.01 strict, it doesn't look to be required: http://www.w3.org/TR/REC-html40/struct/objects#h-13.2
I always learned to close HTML tags like img, meta etc. like this:
<img src="..." />
<meta charset="..." />
<hr />
<br />
<input type="..." />
But I've seen numerous sites that don't put the /> at the end. They simply put > at the end. Which results in:
<img src="...">
<meta charset="...">
<hr>
<br>
<input type="...">
But to me that doesn't seem right... How can a browser know if a tag still needs to be closed somewhere when you do it like that? That's also how I learned it years ago.
But even Twitter Bootstrap is closing input tags without /> at the end.
Is this really valid HTML? And is it now a preferred way of doing it?
<foo /> is XML syntax. It is meaningful only in XML (including XHTML).
However, let us deal with HTML.
How can a browser know if a tag still needs to be closed somewhere when you do it like that?
Some elements have required end tags. These must have an explicit </foo>
Some elements cannot have any child nodes and must not have an explicit </foo>. For example <img>.
Some elements have optional end tags (such as <p>). Browsers will close these elements when either they encounter an explicit end tag (</p>) they they encounter the start tag for an element that is not allowed as a child node inside that element (such as a <div> inside a <p> or a <li> inside another <li>).
Browsers know which elements have required, optional or forbidden end tags because they are programmed to recognise HTML.
HTML 5 allows the /> syntax on elements either forbidden end tags, but that is just syntactic sugar for people addicted to XML.
This is valid in HTML5, but not in XHTML. I personally prefer using this, just because is saves some bytes.
I'm trying to use the <a> tag in HTML5 more as a container as this tag can now have block elements as children, example:
before (valid XHTML 1.1)
<div>
<h3>
article title
</h3>
<p>
text
</p>
<a href="page.html" title="article title" >
<img alt="image">
</a>
<a href="page.html" title="article title" >
read more
</a>
</div>
after (valid HTML5)
<a href="page.html" title="article title" >
<h3>
article title
</h3>
<p>
text
</p>
<img alt="image">
<div>
read more
</div>
</a>
Does this new way of markup have any effects for SEO?
OK, removing pure semantics from your question (which, in my mind, does have a material impact on deciding on implementing your chosen method) and concentrating on pure "SEO" value and impact:
The first example needs to be qualified more, as if we take your example as literal, then you are linking to the same page.html 3 times. Google (specifically) only takes the link anchor value from the 1st link to any page that it comes across, so - the value for the first example is only extracted from that first link. The 2nd link (using an IMG tag with an ALT attribute as the anchor value), and the 3rd link using read more as the anchor value are effectively "ignored". It's important that other signals are used to supplement the first link's true intended value, such as surrounding text, images etc.
The 2nd example (HTML5), wraps all of that semantic/surrounding content up to make the effective 'anchor' value from which search engines will derive the link's intended meaning, and then as a consequence, the meaning of the destination page of the link.
Using an anchor tag as a containing wrapper for content that contains additional emphasis (the H tag), an image and an additional div only increases the difficulty that a search engine has to decipher the intended meaning of the link so it can associate it with the destination page.
Search engines (and Google predominantly) are constantly improving their crawling ability to enable better algorithmic parsing and processing of the HTML. Apart from emphasis signals (which are very low), Google mostly ignores the mark-up. The exception is of course links - so making an effort to simplify the parsing/processing by providing clear signals as to a link's anchor text is the safest way forward. Expecting them to understand all of the differences of HTML3, vs HTML4, vs HTML5 and all of the transitional, strict and other variations of each, is probably expecting too much.
TL;DR
Possibly, but only in terms of true link value.
As far as i know in the second way is not bad in anyway in term of seo But first may be slightly better as the titles,images are more closely linked to link.
Q. But better by how much?
A. May be not too much
If I make an anchor element and don't want text within it, because I'm gonna to css-i-fy it with a nice image and a hover-effect...
I wonder if it is legal to write <a id="hoverimage" href="google.com" />
validome.org & validator.w3.org say YES ?
BTW: anyone knows an equivalent to alt element for this case?
It is valid in XHTML. It is not HTML-Compatible so likely to break in a document served as text/html. Having a link with no content is bad practise (background images are not content (which is why there is no equivalent to the alt attribute)).
I'm trying to get everything in the anchor tag to be a clickable link. Unfortunately, in IE6 (which is the only browser I'm concerned with currently), the only thing that isn't a clickable link are the inline images. I know that it's not valid html to put a div inside of an anchor but it's not my markup and I've been asked to avoid changing it. Any suggestions to altering the CSS to enable the images as clickable links? If changing the markup is the only solution... any suggestions there? My initial thought was to set the image as a background of it's parent (.ph-item-featured-img), although I'm unclear if that will solve the problem.
Thanks!
<div class="tab-panel-init clear ui-tabs-panel ui-widget-content ui-corner-bottom" id="ph-flashlights">
<a href="#" class="last ph-item-featured clear">
<div class="ph-item-featured-img">
<img src="#">
</div>
<strong>
PRODUCT CODE
</strong>
<p>
PRODUCT CODE Heavy Duty Aluminum Led Flashlight
</p>
<span>Learn more ></span> </a>
<a href="#" class="last ph-item-featured clear">
<div class="ph-item-featured-img">
<img src="#">
</div>
<strong>
PRODUCT CODE
</strong>
<p>
PRODUCT CODE Heavy Duty Aluminum Led Flashlight
</p>
<span>Learn more ></span> </a>
</div>
The problem is that it isn't valid html. Explain that you have to change the markup to make it work as desired. Changing the div to a span and setting the class .ph-item-featured-img to display: block should produce the same look-and-feel and be correct html.
Edit: Another, not as clean solution, is to add a click-listener with JavaScript and invoke the link upon a click on the image.
If you can't change the mark up (which you admit isn't valid), I don't think there is anything you can do here.
You should reconsider changing the markup. This example is bad in so many ways it could serve as a textbook example of what not to do.
Alternate strategies:
Remove everything but the image and
give it an onclick handler that does
the link mechanics.
Remove the DIV and just have the IMG
inside the anchor tag.
etc.
Well i looks like youre already using jQueryUI so why not just through a click even on the containing DIV. Also you should definitely change the markup. If its not valid, its not valid. That can lead to all kinds of problems other than the one youre currently facing. If there is a good reason for change this is it.
This is what the w3c validator returns when I pass in the snippet you posted:
Line 15, Column 46: document type does not allow element "DIV" here; missing one of "OBJECT", "MAP", "BUTTON" start-tag
<div class="ph-item-featured-img">
The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element.
One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").
If I remember correctly, IE6 requires that every element inside of the <a> tag to be an element with CSS display: inline set on it (or inline-by-default elements like <span>, <b>, <strong>, etc.), or else it doesn't get linked, or links act weird.
Perhaps it is even IE6's HTML parser that is to blame. Maybe it sees the <img src="#"> and thinks, "that's not a valid URL to an image! :ignore:". IE6 is strange that way, often acting in a way that is a diametric opposite to how standards-compliant browsers act.
Truth is, this I have no way of checking all this; thankfully, every Windows computer I have access to has IE7+ on it. Perhaps you should take Google's route and just explicitly say that you're not going to support IE6, redirecting all IE6 browsers to a place where they can upgrade.
I believe you can do this with conditional comments like so:
<html>
<head>
<!--[if lte IE 6]>
<meta http-equiv="refresh"
content="2;url=http://www.microsoft.com/windows/internet-explorer/default.aspx" />
<![endif]-->
...
</head>