When an <a> element is clicked on, normally it changes it's color or something to indicate it has been clicked. I just noticed that in iPhone's Safari, the CSS attribute change of a link upon click doesn't take place and the page just seems to not be responding, then it redirects to the link's URL properly, but the user will think that the link is broken because of this. Has anyone seen this problem? Have you been able to workaround it?
I have compared my website to others and it's kind of common. I have also tried a couple of things with javascript, but seems that the CSS changes are ignored and the link redirects before changing the CSS in the link. This doesn't happen on other browsers like Chrome in Android. Any help will be appreciated.
Related
I have this landing page, for some reason I can't see the check box, submit button and a div that are in the code. Everything works in chrome and Firefox. I understand that IE dosen't always get media queries so I made this landing page that calls a diferent css file when it detects IE, but it made no difference.
I have a few questions:
1. What is causing this?
2. How can I fix it? Is there a file, like modernizer, that I can load to modify code for IE.
3. I am also using this js addon on the second link with a separate css file, in order to see place holders in IE. This also doesn't work, if someone could tell me why, that would be great
I see the checkbox just fine in IE. why don't you show an image of what you are seeing. Also, clear your browser cache.
To help debug, you should press F12, then click on console. make sure there are no errors. Then click Network. Make sure all css/javascript is loaded with no errors. finally, in the dom explorer, click the arrow, and click on the page and see if the elements are there.
as i see it this is the solution to my question
at the top of the css file i had this row:
#import url(http://fonts.googleapis.com/earlyaccess/opensanshebrew.css);
once i removed it i got the mossing elemnts.
tnx for helping
Dav
The following I tested on the latest versions of Chrome and Firefox, and IE11, and the results were the same.
If you do a Google search and then mouse over a link on the search results page, the link shown in the bottom-left corner of the browser window is not the same as the actual href of the a element.
In all three browsers I tested this on, if you inspect the link in the element inspector though, you can easily see the real link (which is to www.google.com), and while the inspector is open, if you mouse over the link again, then you'll see the real URL link in the bottom-left corner of the browser window.
I have two questions regarding this behavior?
While perhaps a bit naive to ask, why does Google do this?
How does Google do this? Because I saw this behavior in Chrome, Firefox and IE11, I'm thinking that this is some JavaScript-controlled behavior (as opposed to some browser-controlled behavior), but I've never heard of this being possible in JavaScript. If it is possible in JavaScript, how do you do it?
Thank you.
Look at the initial markup:
<a onmousedown="return rwt(this,'','','','3','AFQjCNF8xnW_qOvuZURbtcZUvB6zhKtRQw','35cXyZwuoZY8hBY1VfDr8Q','0CEAQFjAC','','',event)"
href="http://en.wikipedia.org/wiki/How_Do_You_Do_It%3F">
<em>How Do You Do It</em>? - Wikipedia, the free encyclopedia
</a>
Initially the href attribute shows the "real" URL. But when you click on the link, the rwt function changes the attribute value to
http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CEAQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHow_Do_You_Do_It%253F&ei=8nSMUqXtLKfe4QSzwIDADQ&usg=AFQjCNF8xnW_qOvuZURbtcZUvB6zhKtRQw&sig2=35cXyZwuoZY8hBY1VfDr8Q&bvm=bv.56643336,d.bGE
To answer your question: they use the onmousedown attribute to change the link's href attribute when you click on it. Barmar points out why they do it.
The link in the results page points to a redirect page on the Google server. They do this so they can track which links people click on. This is more reliable than using Javascript, since it doesn't require users to have Javascript enabled.
You can see the eventual target of the link in the url parameter of the URL.
When the user clicks the href,
the onmousedown event handler gets executed
before the default behaviour kicks in.
This time frame is used to change the href of the anchor tag.
Check out this simplified version of their code:
<a
href="https://www.google.com/"
data-href='https://www.yahoo.com/'
onmousedown="this.href = this.dataset.href"
>Link</a>
I came across a very strange behaviour on Chrome which seems like a bug to me: when you click a link, the link does not receive the focus. Worse, the body takes the focus instead.
This behaviour can be observed here: http://jsfiddle.net/YfbR7/4/ (see code sample here)
Is this a bug? Is this standard behaviour? Is there any workaround to make the links receive the focus on mouse down, like on the other browsers?
Add tab index to anchor tag it should work, it's not a bug its a web kit thingy.
Click me
In addition to the accepted answer:
Since setting tabindex to 1 would change the TAB behavior, I recommend setting it to -1 instead: it won't break the TAB navigation and will still enable it from being focused.
Example
By the way, here's a very nice article regarding these concerns.
Note: the same thing happened with me, but just on Safari: probably Chrome has already that issue fixed.
A link should always natively receive focus. If your link does not have a href attribute it won't (not sure the use case of a link without a href though!).
I have iframe on my page. In firefox, when I tab into the iframe the control goes to html tag in the iframe. (I could see this with document.activeElement.contentWindow.document.activeElement on console.) The next tab gets me to the first control in the iframe.
In IE and chrome it works fine.
Can you please help me, what I am doing wrong?
Thanks
You're doing nothing wrong. Firefox is focusing the root element so that a user who's just using the keyboard can scroll the iframe if he wants to. If the focus went directly to the first text input, for example, the user wouldn't be able to scroll the frame.
And indeed, that's what happens in Chrome. If the subframe happens to not have any text controls in it, the user can scroll it fine after tabbing to it. If it has text controls, the user is screwed if he wants to scroll.
For what it's worth, I just reported this as https://bugs.webkit.org/show_bug.cgi?id=79558 because it seems like a clear accessibility bug...
While the lightbox example page works fine for me in IE7, I seem to have broken it in my implementation.
I've written a Lightbox plugin for Mango Blog and everything works fine in Firefox. However, in IE7 the "close" button doesn't work. If I'm fast enough to get my cursor into the position that the close button will be placed before it slides into place, the IE status bar shows the "#" link, but clicking or moving the cursor makes the status bar go blank -- and of course nothing happens.
Not that it was that necessary, but I made a quick screencast of the behavior in IE7. Note the cursor not switching to a hand on the close button.
Any ideas how to fix this?
Perhaps you should try to use the actual 2.0.4 version of Lightbox as a base, there seem to be several changes in the DOM code, although nothing like the bug you described is mentioned in the changelog.