I've been looking through various websites and came across multiple ways to make "buttons". What are the pros and cons to each way?
<div class='btn'><a>Click Me!</a></div>
<span class='btn'><a>Click Me!</a></span>
<a class='btn'>Click Me!</a>
CSS:
.btn{
display:inline-block;
min-width:100px;
text-decoration:none;
cursor: pointer;
}
Those are all three the exact same thing. They're all just a link, the only difference is that parent class is used as a selector target. They are effectively identical.
There is one differences between the first and second 2, though. a div, by default, is a block element while a span and an a tag are both inline, thus a dive fills up the entire width of the container, but that can be changed with css (as your example does).
Why not just, I don't know.. call me crazy.. but why not just use an actual button?
The only reason I can think of to NOT use a button is if you want the links to be search spider visible. If you're going to use javascript to post a form, then i suggest using a button instead.
I recommend reading this article by Chris Coyer. It's titled "When (and when not to) use an anchor tag?".
Here's an excerpt:
I think if you are going to put a href attribute on the anchor that
actually does something even if JavaScript is disabled, then the
anchor is the right choice. If the app is totally JavaScript dependent
all behavior is attached via JavaScript, I guess it doesn't really
matter what element you use. Maybe it's even better not to use an
anchor since the behavior probably bears no resemblance to what anchor
links do. You could probably talk me out of that though. The thing is,
anchors give you ("for free") lots of the visual functionality that
you want with deep browser support. So...
I'm not sure about the a tag (more info here), but the span tag is inline and the div tag isn't. Otherwise they're all pretty much the same.
the <div> and the <span> must have an action using javascript but the <a> can have a link to another page without using java script code
If you are using a form submit i prefer to use a input button. As it doesn't need further Javascript code to submit a form.
The difference between span and div is that div is a container element whereas span is not. How this is helpful to you? Check out his link.
If you dont want to apply any style and if you are okay in writing (or) if its a simple get request to server (or) if you are willing to write some javascript event handlers then go with anchor tags
I think the best method is the third one because you use only one DOM element instead of two. This will improve the performance and will make your code more semantically because you are not creating empty DOM elements for styling.
In addition, with the example 1 and 2 if the anchor is smaller than 100px the clickable zone will be smaller than the example 3.
Related
I was wondering, can you make an element that is not an anchor (<a>) tag (for ex. <div>, <span>, etc.) behave like an anchor tag? (Link to page on click).
Or, are there any other elements that behave the same?
Only partially.
You can give any tag a tabindex to make it focusable.
You can give any tag a click event listener that sets location.href.
You can't make anything other than a real link react to :link and :visited in CSS
That leaves aside issues of getting (for example) screen readers to recognise the element as a link and annouce it to the user, and for search engines to recognize it as a link and follow it, and the JS simply failing.
In short: If you want a link, then use a real link. HTML is a semantic markup language. Use the semantics it comes with. Don't try to fake the behaviour that comes with the semantics using other elements.
First of all, I've seen this question IE Compatibility issue, but I have a slightly different issue:
I have a span with display: block and I want to put a H2 tag inside it. Will this look good in every (major) browser?
The answer on the previously stated link, was to make the H2 display:inline, which I don't want, and also I don't want to replace the span with a div, because I would have to change a lot of CSS.
PS. I don't want my HTML to validate (using the validator), I just want it to work.
When you say "I don't want my HTML to validate (using the validator), I just want it to work." You're making a very big mistake. If HTML doesn't validate, there's no telling what might happen. The standards are there for a reason.
Replace the span with a div, you don't need display block on the div as it has this by default. A span is an inline level element, whereas an H2 is block level. An inline element cannot contain a block level element (true up to HTML5, where you can wrap block level elements in anchors)
This will validate, and will work!
It works on current browsers (including old versions), and it is unlikely that this will change. Errors like this are common enough to make it rather pointless to browser vendors to change their error recovery mechanisms. HTML5 is about to make the error recovery rules mandatory.
On the other hand, what is the point of using span with display: block, instead of using div? And CSS should be written so that it does not depend on specific choices of markup elements where different choices could make sense; for example, as a rule, .foo is a better selector than span.foo.
Any extensive change to markup or style sheets has a nonnegligible risk of causing problems even when the change is a such an improvement and a simple one. (For example, a global search and replace often does too much, or misses something.) This could be a reason for continuing the use of invalid markup, in cases where it has minimal risk in practice.
we can solve IE second line problem first
h2{}
h2 span{ float:right;}
Correct way in all browsers
<h2><span>sub content</span> Heading</h2>
wrong way ie browser
<h2>Heading<span>sub content</span></h2>
Are both <h1><a ...> ... </a></h1> and <a ...><h1> ... </h1></a> valid HTML, or is only one correct? If they are both correct, do they differ in meaning?
Both versions are correct. The biggest difference between them is that in the case of <h1><a>..</a></h1> only the text in the title will be clickable.
If you put the <a> around the <h1> and the css display property is block (which it is by default) the entire block (the height of the <h1> and 100% of the width of the container the <h1> resides in) will be clickable.
Historically you could not put a block element inside of an inline element, but this is no longer the case with HTML5. I would think that the <h1><a>..</a></h1> approach is more conventional though.
In the case where you want to put an anchor on the header, a better approach than <a id="my-anchor"><h1>..</h1></a> would be to use either the id or the name attribute like this: <h1 id="my-anchor">..</h1> or <h1 name="my-anchor">..</h1>
In pre HTML 5 this one
<a><h1>..</h1></a>
will not validate. You can use it in HTML 5.
However, i would use this:
<h1><a>..</a></h1>
unless you need to add more than < h1 > inside the < a >
<a><h1></h1></a> is not W3C valid... Basically, you can't put block elements inside inline elements
<h1><a>..</a></h1> and <a><h1>..</h1></a> have always behaved almost the same, when style sheets do not affect the rendering. Almost, but not quite. If you navigate using the tab key or otherwise focus on a link, a “focus rectangle” appears around the link in most browsers. For <h1><a>..</a></h1>, this rectangle is around the link text only. For <a><h1>..</h1></a>, the rectangle extends across the available horizontal space, since the markup makes the a element a block element in rendering, occupying 100% width by default.
The following shows how a focused <a href=foo><h1>link</h1></a> is rendered by Chrome:
This implies that if you style elements e.g. by setting a background color for links, the effects differ in a similar manner.
Historically, <a><h1>..</h1></a> was declared invalid in HTML 2.0, and subsequent HTML specifications followed suit, but HTML5 changes this and declares it as valid. The formal definition has not affected browsers, only validators. However, it is remotely possible that some user agents (probably not normal browsers, but e.g. specialized HTML renderers, data extractors, converters, etc.) fail to handle <a><h1>..</h1></a> properly, since it has not been allowed in the specifications.
There is seldom a good reason to make a heading or text in a heading a link. (It’s mostly illogical and bad for usability.) But a similar question has often arised when making a heading (or text in a heading) a potential destination for a link, using e.g. <h2><a name=foo>...</a></h2> versus <a name=foo><h2>...</h2></a>. Similar considerations apply to this (both work, there may be a difference since the latter makes the a element a block, and before HTML5, only the former is formally allowed). But in addition, both ways are outdated, and using the id attribute directly on the heading element is now recommended: <h2 id=foo>...</h2>.
H1 elements are block level elements, and anchors are inline elements. You are allowed to have an inline element within a block level element but not the other way around. When you consider the box model and the HTML spec this makes sense.
So in conclusion the best way is:
<h1>Link</h1>
do you want to use a hyperlink <a href="…">/a:link, or do you want to add an anchor to your heading? if you want to add an anchor, you can simply assign an id <h1 id="heading">. you can then link it as page.htm#heading.
if you want to make the heading clickable (a link), use <h1><a></a></h1>/h1 > a – blocklevel elements first, and inline elements inside
Also, there is style hierarchy differences. If you have it as <h1>Heading here</h1>, The styles of the anchor will overrule the styles of the h1 element. Example:
a {color:red;font-size:30px;line-height:30px;}
WILL OVERRULE
h1 {color:blue;font-size:40px;line-height:40px;}
I think the <h1>text</h1> is the least problematic with weak or old browsers, but modern browsers and powerful search engines are supporting both it and <h1>text</h1>; So it's a good freedom and useful to use both to improve our web page.
«Hope that could be useful»
Both are correct. They depend on the sizing of the anchor tag which you want and how you want your website laid out.
You can do <h1>Home Page</h1>, in which case it would return: Home Page But with an Anchor.
Or you can do <h1>Home Page</h1> and it would return a H1 hyperlink instead of just heading an anchor to the H1, like so:
Home Page
However, mostly you cannot add links within H1 because it will just render it as an anchor onto the h1 rather than adding a hyperlink. However, I think I'm right in saying that you could see a difference in behaviour for this on different browsers.
But correct me if I am wrong. :)
Running the Ubuntu cloud page http://www.ubuntu.com/business/cloud/overview through http://validator.w3.org/ gives several errors, the majority of which are centred around not having <divs> and <h>s etc. within an <a> tag.
The implementation I'm interested in is the four boxes with arrows, which change colour as you hover over them (as they are <a> links). What is the valid method to implement this?
Valid ways to implement this:
separate links inside each block. Put the :hover effect on the parent div, not the link. Downside: more markup
use only inline elements inside a single link, using CSS to change them into display: block elements if necessary. Downside: potentially less semantic
use an HTML5 doctype, as [X]HTML5 allows this construction. Downside: the less easy-to-validate current moving-target nature of HTML5.
Each one of those can be a (with a :hover effect to change the background color/image), and the , which sits inside, just covers the entire div with a height and a width in your CSS.
How can you collapse div and p -elements if they are empty by CSS such that the tags are not shown for the user in the source code?
These elements are in my source code although they are empty.
This causes bugs with the rest of the site.
I run this unsuccessfully
div.unsuccessful,
div.unsuccessful p {
visibility: collapse;
}
This suggests me that you apparently cannot do such a thing by CSS.
Perhaps, other tool such as PHP is needed.
CSS has no influence on the actual HTML code, so this cannot be done. In the (upcoming) CSS3, you could stop them from being rendered using the :empty pseudo-class:
div:empty {
display: none;
}
That is of course not the same thing, but it would probably fix the problems you're having.. if only browsers actually supported it, which they don't, yet.
The best option is to remove them at the server, using a scripting language like PHP. I suppose you could do it client-side with JavaScript, but that's a horrible solution, imo.
That being said, what problems are you having with these empty tags? Why are they there in the first place? It seems to me that some redesign is in order, to prevent the unnecessary tags from being generated in the first place.
Also, be careful. Empty tags are not always meaningless. In fact, removing every empty <div> out there can be considered harmful.
Yes, if you want to stop them being in the source, you'll need to make the appropriate considerations in your server code. Alternatively, you can also set the HTML in JavaScript, but it's not the recommended approach for this problem, probably. You may like to say a bit more though, about what you're trying to do.
Visibility property is intended to set whether the content of the object is displayed or not. It won't remove the element from inside the DOM.
collapse New for Windows Internet
Explorer 8
Used in tables to remove rows and columns; for all other elements, same as hidden.
Also why do you want to do this?
div { display: none; }
removes an element completely from the page.
It'll still show up in your source code, no matter what you do with CSS. The browser combines the HTML source and the CSS directives into a displayable page, the original source is not modified. CSS can only influence the visual display of elements, it can not alter elements. To actually remove elements from the DOM you'll need Javascript (or not put the elements there in the first place).
Yes, you will have to use server side processing to show or not-show some code to the user:
if ($showAdminLink) {
echo "<p>Admin panel</p>";
}
No matter what tricks you try, anything done on the client side (HTML, Javascript, CSS) can be altered and played with.