I've encountered weird problem with anchor links. I have some on a page, and they suddenly stopped working (checked in chrome and firefox).
I noticed that after clicking anchor, let's say <a href="#news">, address changes to http://mydomen.net/index.html#/news and anchor doesn't work. If i manually remove that / after # and open new link it works as intended, but adds / again.
Did I miss some changes in HTML? Or what could it be? Thanks!
The only possibility is that this is coming from either your script (but you are only talking about HTML, so there is no clue for that) or URL rewriting on your server.
There is absolutely no possibility for plain HTML with your provided example code to behave like this.
(Browser extension is not an option since you tried different browsers)
Still don't know what caused this, but renaming anchor target to <div id='/news'> worked.
Related
I have a problem with my site.
I'm using HTML and CSS only.
I'm using several "a hrefs" that are supposed to slightly change their background colors when hovered.
The problem is, whenever I clear the browser's cache (or go into inprivate mode) I need to refresh the webpage or click on a link, which ONLY then (all of them) starts to do the hovering effect. Only by clicking a second time I'm able to open that link.
This happens in all browsers.
I have the following code on the head section.
<link href="css/sticky-menu.css?v=2.4" rel="stylesheet">
Anyone suspects what is happening here?
I've found the problem, and it's related to a third-party script, in this case from sharethis.com
I guess I'm going to contact them about this.
Thanks, anyway.
While these insertions are not there in source-code.
Also my images don't load even though they are there on host server. Don't know if this problem is related to insertions mentioned in title of my post or some other reason!
I tried deleting images from server and upload again. Page works fine when opened from computer but same files when uploaded to server, don't show images.! Any advice is much appreciated.
Update: I restored firefox to factory defaults and that did the trick. Now images are showing. and also "::before" is not being inserted in inspect-element window. But a closing tag is still inserted. If someone could please explain the probable cause that stop images from showing, before factory-reset was done? Now I'll work on chrome, as it is also not showing the images
$0 indicates that this is the "current" element being inspected. You can type $0 into the chrome console and it will be the HTMLImageElement you are inspecting. See Chrome DevTools API
I recently faced the same thing when trying to put content in the <img> tag with javascript.
When I use the img tag without src parameter being set, same thing happens. As soon as I declared at least src="";in Firefox it shows proper unclosed <img> tag without the ::before.
I'm going to search for more info on this to expand the answer, just wanted to clarify - are your img tags possibly declared without the src attribute and then worked with after in some fashion? (<- this is a comment to the original question, I can't comment.)
My multi-page jQuery Mobile app spans a couple directories. One stateful page is cached with data-dom-cache="true". When I navigate to it, the base path used for relative links ($('base')[0].href) isn't restored to the proper subdirectory; it's one level up. Seems like a jQuery Mobile bug.
To work around, I tried $('base')[0].href = 'subdir';. But executing that sends it down a rabbit hole of subdirs. Inside the page it gives me subdir/subdir, and from the Chrome console it's subdir/subdir/subdir.
Is this a quirk of Chrome or jQuery Mobile, and what else can I do to work around? It's not easy for me to test with another browser.
Woops, I forgot to answer this back then. I believe the solution was to add another <base>, rather than modifying the existing tag, to avoid any quirks with relative URLs.
I have a code snippet that is installed on third party websites. I can't get into the details, but it loads HTML, CSS and JS onto the page through the use of a <script> tag.
Part of the code is a JS function that executes when this link is clicked:
?
If there are JS errors on the page that prevent the function from executing, clicking the link obviously just adds the hash to the URL and takes the user to the top of the page. This is the expected fallback behavior.
However, on one third party site with a multitude of JS errors, clicking the link removes everything after the top level domain, adds the hash, and directs to that page (the home page). For example, the link would take the user from:
http://www.example.com/2010/05/14/very-interesting-blog-post/
to
http://www.example.com/#
Notably, the issue occurs in Firefox and Chrome, but not IE9. I know it may be impossible to properly diagnose the issue without more detailed code, but I'm not at liberty to provide it. I'm just hoping to get some kind of reasonable explanation for this strange browser behavior.
If it helps at all, the site in question is a WordPress blog. Thanks in advance.
EDIT: This is apparently not caused by any JS on the site, because turning off JS and adding the link with the inspector produced the same behavior.
I had a similar error where clicking on any <a href="#"> causes a full page reload. I managed to solve this by removing the <base href="/"> tag from the <head> of the page. I couldn't find any informations on this (yet). I'll add more if I can find any additional info.
This problem happens when you use windows.onpopstate to handle back or forward buttons and load page using ajax. Try to solve your js code for handling history.
For example, the link below triggers something in jQuery but does not go to another page, I used this method a while back ago.
<a class="trigger" href="#"> Click Me </a>
Notice theres a just a hash tag there, and usually causes the page to jump when clicked on, right? [I think]. It is only for interactive stuff, doesn't go to another page or anything else. I see a lot of developers do this.
I feel like its the wrong thing to do though. Is there another recommended way to do this without using HTML attributes a way where it is not suppose to be used?
Not using <button> ether because the link would not be a button.
Maybe without a hash?
<a class="trigger"> Click Me </a>
& in CSS:
.trigger {
cursor: pointer;
}
So the user still knows its for something that you should click?
I like to make such links return false on click, that way, clicking them doesn't result in any jumps.
With jQuery that would be as easy as
$(selector).click(function(e)
{
e.preventDefault();
});
or in the HTML as such
<a class="trigger" onclick="return false;" href=""> Click Me </a>
Don't remove that hash.
It's true that under (modern, at least) versions of Firefox, Chrome, Opera, and Safari, an anchor tag with an empty href (i.e. href="", not a missing href) will display as a normal link that simply doesn't respond when clicked, unlike the hash-href which jumps to the top of the page. Internet Explorer, however, takes a different approach.
When a link without an href is clicked in Internet Explorer, it responds by opening your Desktop directory in Windows Explorer. I got this response in IE7 and IE8 (IE6 just crashed, though that could be unrelated - I've had issues with that VM).
If a user browses your site in IE with JavaScript disabled, do you really want all your links to open their Desktop? I think not.
Also important is that removing the href attribute from an anchor element entirely causes it to be rendered as plain text - i.e. it doesn't act as a link, you can't tab to it, etc. Not good.
As for controlling the behaviour of the link when clicked, #partoa has the right, but possibly incomplete answer.
I'm no JavaScript guru by any stretch of the imagination,but from what I've read you don't want to use return false; for this. According to this article I came across a while ago, return false; has some additional behaviours you might not actually want. It recommends you just use preventDefault to stop the links normal behaviours (i.e. navigating to a new resource). Read over that link to see what return false; really does before deciding how you want to handle it.
For interactive purposes:
Removing the href="#" from your tag will also remove it from the default tab order, so users browsing with the keyboard will not be able to activate your link.
I recommend keeping href="#" in your tag and adding return false to the end of the script that is run by the link.
I can't see a reason why you would want to use an A tag for style purposes.
in konqueror (kde browser), you can disable pointers to change. Then your solution fails. But in general, I'm agree with you.