Chrome shows file, IE10 shows dialog box

In Chrome, and IE8, when this link is selected:

<a href="../upload/[blk1.thumbnail]"><form action="../upload/[blk1.thumbnail]"><input type="image" src="../images/MI.png"></form></a>

the file appears successfully.

In IE10 and IE9, instead of the file appearing successfully, a dialog box appears asking "Do you want to open or save (the file name) from www…com? OPEN SAVE CANCEL

In FF it says "You have chosen to open (the file name) which is application/ocet-stream from www…com OPEN SAVE CANCEL

What can I add (or change) so that the file appears, upon selecting the link, in IE10, IE9 and FF? instead of a dialog box appearing?

Can we see a demo page that has the trouble? When I try just the above code on IE9, IE10, or Firefox, I’m not getting the problem, and am taken right through to the image as with IE8.

Did you test the mark-up to see if it validates?

AFAIK, having a <form> (block level) inside of an <a> (inline) is not valid.

Perhaps that’s raising an alarm with the browser(s).

Maybe try a <button> instead of the form wrapped input type image?

Unfortunately, as of HTML5, you are wrong. Anchors are the ONLY inline element where you can have an anchor parent, and block children.

Even though HTML5 anchor tags can have block-level elements within them - I believe though that they’re not allowed to have interactive content within them, such as forms or buttons.

Is that still the case?

I’m not sure. What makes you think no interactive content cannot go in them?

I’d shy away from interactive content to begin with (forms) but I’ve read nothing to say that it wouldn’t be allowed. It would just be strange.

Have you read anything which supports that statement (not trying to be argumentative, purely curius :slight_smile: )?

What makes me think that are both the w3.org and whatwg.org HTML5 specs, which says:

Content model: Transparent, but there must be no interactive content descendant.

See the HTML5 anchor specs at:

And, in the code example it says:

The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).

Yes that’s what I assumed as you can’t have any actions apart from the link destination taking place inside that element. Just as you couldn’t nest more anchors inside either.

Not quite:) ins and del can be both block or inline depending on situation and may contain block elements

1 Like

I’d have to assume that you are right then :slight_smile: . Probably for the best. It’s very strange to have that kind of setup anyway, and probably should be done another way if it exists.

Thanks for all the replies. Can you please give me an example of “a instead of the form wrapped input type image?”

Do you mean an image input?

After looking into it, maybe not as simple as I first thought.

I have used buttons outside of forms using them with JavaScript event listeners.

But it seems for them to work outside of forms, they must be used with event listeners for them to work.

And I learned something new re “Enter” vs. “Space” - bottom of

Thinking more on it, I think what I would do here is give <a> width, height, and background-image.

Though I think you might be able to use a button with an event listener (with stopPropagation) so it would work with or without JavaScript

1 Like

I don’t think so, for that’s another case of a clickable element being inside of the link - we don’t want browsers to be confused over what to do in such cases, so no interactive content within anchors.

The best you can do is to have non-interactive content in there and fake the interaction, using event listeners.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.