Disable <a> click without the help of jQuery/Javascript [duplicate] - html

This question already has answers here:
How to disable a link using only CSS
(25 answers)
Closed 8 years ago.
Is there anyway to inhibit the click handler on a tags in HTML without the help of jQuery/Javascript?
disabled only works on button and input, but I've chosen to use a tags in my code. I suppose I can use span and simulate the exact a styles I currently have, but it would be nice if there's a simple way around this.
Thanks in advance.

Use # as href or omit the href. The link won't work anymore. As cocco noted, setting href to # has the disadvantage, that the history gets messed up and the browser jumps back to the top of the page. Nevertheless, the value # has been used on numerous pages.
Disabling the onClick is not possible, but you can use onclick="return false". This way nothing happens on click.
There is also a partial solution using css (described in this already answered question).

there are many ways to do that..
1.simplest:
a.onclick=function(){
return false
}
2.standard/modern:
a.addEventListener('click',function(e){
e.preventDefault()
},false)
example with class=active to activate the link.
http://jsfiddle.net/y7vVq/

onclick="return false"
This is the simple way to disable click in a tag

Related

Is it possible to use Emmet in a blank CSS sheet, outside of a selector?

I am currently making my live easier with various custom emmet short forms for code I use a lot. So I tried to make something like the ! in html for CSS so that I can have a * margin reset, comments sectioning my code, media queries etc.
The problem is that for me, emmets validation only allows it to work inside of a selector.. so I would have to type a p{} and the the ! inside that which adds unnecessary work. Do you guys know a way to change the validation?
I went thru all the settings and files I could find, also checked out the documentation.
thx ^^

HTML: Why there is no native support to restrict state change in check-box without disabling it? [duplicate]

This question already has answers here:
Can HTML checkboxes be set to readonly?
(48 answers)
Closed 8 years ago.
In HTML, only text controls like text-box, text-area, password-box have read-only property. Why didn't they support check-box/radio-button?
I know I can achieve this feature using script by putting onclick="return false;". (I don't want any workaround, I want to know only the reason for not providing native support to achieve this)
But my question is there any specific reason for not supporting read-only in check-box/ radio button even-though it accepts input from user.
EDIT 1:
I found this but it doesn't answer my question - Why there is no native way to restrict the user to change the state without disabling it?
It's important to understand that READONLY merely prevents the user
from changing the value of the field, not from interacting with the
field. For many types of fields, READONLY is irrelevent because you
don't normally change the value. In checkboxes, for example, you can
check them on or off (thus setting the CHECKED state) but you don't
change the value of the field. DISABLED, however, actually prevents
you from using the field.
Notice in these examples that you can set the checkboxes even though
they are "read only":
SOURCE
EXAMPLE from faqs.org
HTML 4.01 allows readonly for input in general without restrictions by type. However, it seems that it was generally not implemented in browsers, possibly because the implementors did not see much need for it. In HTML5 CR, readonly is explicitly disallowed for input type=checkbox, and HTML5 CR (or some other “HTML5 spec” such as HTML 5.1 Nightly or WHATWG Living HTML) is generally what implementors use as the guideline these days.
There have been proposals to allow it in HTML5, e.g. a discussion in May 2011 at the whatwg list, as well as browser bug reports (rejected on the basis of what HTML5 says), but apparently without sufficiently good use cases. Although real use cases exist, they are probably too marginal, and reasonable alternatives can be presented, such as the use of a checkbox image (checked or unchecked as desired) with suitable associated text and, if the pseudo-checkbox is set to checked, a hidden field carrying the desired information.
Use jquery to make it disable(readonly) or enable. Only text fields are possible to make them readable at the time of rendering.
<input type="checkbox" id="chk1"/>
then by using Jquery
$(document).ready(function(){
$("#chk1").prop('disabled',true);
});
First, you shouldn't intersect the onclick event of a checkbox for the mere purpose of checking whether it is checked or not. You should use the onchange event instead. Why? Because the onclick event triggers before the onchange event, so if you intersect the onclick event you will not be able to get the actual state of the checkbox unless you do some ugly javascript acrobatics with setTimeout
If you want to make the checkbox "read-only" you have to use the disabled attribute. Like below...
<input type="checkbox" disabled/>
To answer your question, I think it's better explained by the HTML Specs in W3.Org
The difference between disabled and readonly is that read-only controls are still focusable, so the user can still select the text and interact with it, whereas disabled controls are entirely non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make sense for checkboxes or buttons, for instances.)

Is it ok to place a <div> inside an <a> [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is putting a div inside an anchor ever correct?
I want to have a link on a complex element (containig images, paragraphs and other stuff).
I know it works, but is it ok to have a <div> element inside an <a> element ?
Yes … and no.
No complete HTML or XHTML recommendation allows it.
The HTML 5 draft does permit it, but you may have to do things such as explicitly setting display: block on the anchor to get it to work in some browsers. You may find that others simply don't support it (I'd like to be able to link to a reference that shows browser support for this, but don't know of one, please comment if you do.)
That said, while have nice big click targets can be useful, it isn't an approach that is friendly to the "skim through links mode" that some browsers (especially screen readers) have. You might be better off using a regular link in the content, and applying some JavaScript to react to a click on the whole element.
In XHTML1.0 and HTML4.01: no. a is an inline element that can only contain other inline elements (but not another a).
In HTML5: yes, you are allowed to do that. BUT consider why you would've hundreds of characters in a link.
It's bad for SEO (dilution I believe) and bad for many disabled users ("Hey screen reader, tell me what does this link do?" - "Let me read to you aloud this link for half a minute") and perhaps bad for usability.
Another solution would be to put a link on say your heading in your div or some meaningful text. Then in JS make your div behave like what you wanted to do initially. Then it'll work for users using an assitive technology (screen readers and alike), for keyboard users (they can tab through the link) AND for sighted mouse users with JS.
No, unless you don't care about IE7 and down. The link will not function properly in IE7, even if set to display:block.

Is there any particular good reason to keep using href='#' on javascript targeted links?

As you all know, it's extremely common to have code like this:
<a href='#' class='edit'>Edit</a>
Which is then hooked up to an event handler (using jQuery or whatever's hip these days)
or even with inline js handlers
<a href='#' onclick='editThis()'>Edit</a>
I know it's a lazy way to show the pointer/hand cursor on the link but that can easily be corrected with just this css:
a {
cursor:pointer;
}
(Which takes less time to write once in the stylesheet than writing href='#' on every link)
Having href='#' also has the annoying inconvenience of causing the browser to jump to the top of the page if for some reason the handler hasn't had a chance to attach itself to the element (mouse trigger happy user, the impatient type, ...)
My question, is there a particular good reason to keep using the href='#' ?
Would removing it break some browser behaviour in a few particular contexts?
EDIT: I'm getting some really random answer for this question, maybe I should clarify.
The question is: if I set the hand cursor (and underline and color - thanks Borealid) via css, can I get rid of the href attribute altogether
This question is NOT about what the best href is or how one should attach event handlers
in general I don't use a tags for js calls, its sloppy and gives the response you're talking about. If I am doing an anchor totally use it, but if you're not just use a class as your selector and do the rest in css.
Optimally you would would link to the page that sould be used if the user has Javascript disabled or wants to open the editing screen in a new tab:
Edit Profile
That way, if anything goes wrong, no functionality is lost.
Of course, building an AJAX editing screen and a standard editing screen is more work. If you don't want to do all of that and you don't care about Javascript free users you can use this:
Edit Profile
Using the CSS is better. No, removing the # won't break browser behavior. However, the CSS you've got isn't quite adequate: you'd also have to change the text color and underline style, plus implement hover handling and, optionally, differentiating followed links.
Setting href="#" in this case is basically wanting to stop the event from it's default behavior. I have actually answered a similar question to this here.
From a purist perspective I would argue that you are breaking the web by not including the href attribute. If a browser does not support javascript your link will not work for them. That's a purists perspective -- simply pointing an href to "#" doesn't make a difference either way.
In the past you only utilized an anchor without an href to specify a place holder on the page, but it looks like utilizing an anchor tag without an href is being deemed obsolete in HTML5:
http://www.html-5.com/changes/deprecated/a-name-tag.html
So the purist perspective is you break the web.
The realist perspective is if you have to reincorporate some behavior the browser gives you for free in CSS because of your HTML -- that would mean the browser is not happy with something in your HTML. And given that anchors without href's are being deprecated. Common sense tells me to keep using href="#" to avoid a face palm moment when you deal with a weird browser based bug that boils up due to this minor violation of the DOM.

Setting input control focus without javascript [duplicate]

This question already has answers here:
Default html form focus without JavaScript
(5 answers)
Closed 8 years ago.
Is there a way to set the focus in a specific HTML input (a textarea control, actually), without using Javascript?
EDIT: Is possible in HTML5 but the question is about HTML < 5
You can use autofocus in HTML5 documents, but it has little support at present (see chart).
Nope. Sadly JavaScript is required, because it's dynamically modifying the browser on the client-side (what JavaScript was made for).
I don't know of any, other than tabbing to the field or clicking within it.
It depends on how and when you want to set the focus on this textarea. "tabindex" might help you.