How do we disable hyperlink for an input field within hyperlink area?

Hallo,

We are doing a New Year theme, linked to a related New Year Video, and having a lil a problem.
You can see the page that is being working on, here:

So we want the entire area which has the background image saying “Happy New Year 2016” linked to a related Video.

But we do not want the (Search) Input field, also hyperlinked to this Video, for obvious reasons that such hyperlinking will then stop people from using the field to enter what they want to search for.

So my question is: How do we maintain this hyperlink of “HappY new Year” image area in place while not hyperlinking the (Search) input field which is at the center of this area?

FYI, we tried this in the search input tag area:
onclick=“location.href=‘’”
and also tried:
onclick=“set_focus();”
which would the focus back onto this field
but Neither worked?

Thanks for your answer.

Dean @ Anoox.com

Hi,

You’ve made this a lot harder than it needs to be as simple css and html could have accomplished this without the need for any javascript redirection.:slight_smile:

You should have put the background image inside an anchor and that would have take you to the destination as required without any js. You could then have simply absoluetly positioned the form on top of the background image to keep it separate from the anchor and so it would not follow the link.

As is stands you will need to add js to stop any clicks bubbling up from your form.

Add this js at the end of the html.

<script>
function stopDefAction(evt) {
	evt.preventDefault();
	evt.stopPropagation();
}
document.querySelector('#search_ntwrk form').addEventListener(
    'click', stopDefAction, false
);
</script>

Then remove the inline click handler that you placed on the cell around the form and the one on the button and move your form element around the table as a form element cannot start in one cell and finish in another as that is invalid.

 <div id="search_ntwrk" style="margin-top: 120px;">
          <form method="post" action="find.php" name="my_find">
            <table width="100%" border="0" cellspacing="0" cellpadding="1" align="center">
              <tr>
                <td align="left" width="10%"></td>
                <td align="right" width="50%"><input type="text" name="find" maxlength="75"  class="input_txt_new" style="height: 30px; font-size: 18px; width: 600px; color: black;" id="search_field"></td>
                <td align="left" width="10%"><input type="submit" name="submit" value="Search" class="form_button_hp"></td>
                <td align="right" width="30%"><!--
									<a href="new_year.php?trk=yes">
									<img src="images_new/new_year.gif" width="240" height="60" border="0"></a>
								   
									<a href="http://www.fifa.com/womensworldcup/?src=anoox" target="_blank">
									<img src="images_new/wcup_2015_3.jpg" width="200" height="50" border="0">
									</a>
								   --></td>
              </tr>
              <tr>
                <td></td>
                <td align="right"><span class="oval_white" style="background: #F5F3EE; margin-top: 1px; font-size: 13px;"> <span class="anx_text_orange" style="padding-left: 1px; padding-right: 1px;">Search engine:</span> <span class="anx_text_lbl" style="padding-left: 1px;"> <I>Powered by People Like <a href="anoox_serach_engine_overview.php">YOU</a></I> </span> </span></td>
                <td colspan="2"></td>
              </tr>
            </table>
          </form>
        </div>
        <!-- Closes Div: search_ntwrk --> .

That code is pretty ancient and should really be modernised.

1 Like

Paul,

1st, thanks for your suggestion, But it is too complicated for the purpose.
2nd, I resolved this issue, but with a Table based “ancient” solution. But it works perfectly as you can now see it on anoox.com homepage
3rd, it is really not right to say that Table based base design we use for pages is “pretty ancient”. That would be same as saying that Eifel Tower is “pretty ancient” because it was built 100+ years ago and does not use all latest design ideas.
4th, we are a search engine that is powered by the People and Volunteers, as well as few paid staff members… So if you want to Volunteer to design/code for this effort, you can submit a new design for the homepage as well as other pages.

Regards,
Dean @ Anoox

It is true though too say that it is not semantic and is using the wrong tags for the wrong purpose since using a table implies that the content is tabular data - and search engines will treat it that way (meaning that you will be severely penalised in where the page appears in the results if the content doesn’t make sense as tabular data). Also many browsers will now display the borders between the table cells as some modern browsers do not allow them to be turned off (and many people also turn the borders on in other browsers to make the tabular data more readable).

Comparing it to a relatively modern construction such as the eifel tower or the great pyramid is rather ridiculous as well - using tables that antiquated way is nowhere near as modern in terms of building construction as a cave dug by one of the first dinosaurs. It is the web page equivalent of a building several billion years old.

How is it too complicated?

There are a couple of minor changes that leave you with a valid form structure for that section. You seemed to have added more code than my fixes anyway to achieve what you wanted.

You have also ignored my comments about the structure and the following is invalid and you are lucky that browsers are forgiving and so it works.

 <td align="right" width="50%">
        <form method="post" action="find.php" name="my_find">
          <input type="text" name="find" maxlength="75"  class="input_txt_new" style="height: 30px; font-size: 18px; width: 600px; color: black;" id="search_field">
          </td>
          <td align="left" width="10%"><input type="submit" name="submit" value="Search" class="form_button_hp">
        </form>
      </td>

You can’t start a form tag in one cell and then close it in another. That is not allowed and not valid html. No discussion on this matter is required but feel free to ignore suggestions and use badly broken code instead.

The solution I gave you was based on your table solution!.

The css solution would have been about 3 lines of code as opposed to the 30 lines of badly formed code you are using and would not have needed javascript. You should never substitute js for what html does normally as your links don’t work when I visit your site with js turned off (I always turn js off when looking at dodgy sites or sites I have never visited before). The search bar is also badly centered.

If the Eiffel tower was built with the supports in the wrong place and the foundations missing then yes it would be right to say it was rubbish. However it was built correctly and with the proper structure unlike your badly formed code. I only called your code ancient because I was being kind but did not want to upset you by calling it badly broken and invalid.

You may have missed the fact that I spent some considerable time looking at your page and finding a fix to the solution and offering better methods but you took me to task for one throw-away comment at the end. I am a volunteer here also and give my time freely and all I ask in return is a little consideration and thanks especially at Christmas :smile:

I did say as my 1st comment that:
"1st, thanks for your suggestion, "
So 1st thing I did was acknowledge your quasi volunteer work here. But all I added is that Anoox is a Volunteer based search engine effort to create and operate an alternative (a real choice) to Google, and that we would welcome your volunteer effort to submit a new home page design or any such code, if you think you can really put the time into it and deliver an exact functional new page or code.

I am not even going to get into the debate of Table based vs pure CSS based page.

Cheers,

There is no debate - this was resolved completely about 10 years ago. There is nothing further to discuss as every possible point was raised and answered. HTML tables are only for tabular data. You can use CSS tables if you want a table like layout for the page (a table based pure CSS based layout).

2 Likes

Well, again:

1- We use CSS extensively in our page designs
2- We find it easier setting the base of the page via Tables. To be exact we find it more browser display certain, to set the base of the page in Tables.
3- We welcome new designers, on volunteer basis, submitting new pages designs. So if you want to volunteer to submit a purely CSS based page, that would be welcomed. OTN, the new home page for Anoox is under dev for the new year, which is:

Cheers,

How do you get the same table design to work in a 300px width viewport as in a 30000px width viewport using tables. I would have thought that the display would be broken far more often these days with a table layout (even apart from the fact that it is not semantic and therefore would not be ranked well by search engines).

I guess you mean more certain to be broken in most browsers.

@WorldNews the W3C HTML validator finds over 300 errors on your home page. Is that really what you want…

So it isn’t just that the OP doesn’t know how to write semantic HTML - it appears that they don’t know how to write proper HTML at all.

1 Like

Gand,

Thanks for proving my point by your reference to the W3C HTML validator, since it finds:
35 Errors with Anoox.com site which is Table based
while it finds 153 Errors with sitepoint.com

But the more important point is, that both Sites look just fine in all current or recent browsers.

So you’re saying you’ve found a solution for your OP problem?

How many of the 100+ current browsers did you test them in? They might look fine in the most popular half dozen browsers but unless those errors are fixed they may be broken in some of the other current but less popular browsers. Also those errors could have an effect on the pages at certain viewport sizes (Anoox.com is DEFINITELY broken at smaller sizes - having to scroll to the right four times to read one line of content will drive lots of people away) or when using a screen reader. Search engines may also misread the page due to those errors.

The only way to ensure that your page works in ALL 100+ current browsers and gets the highest possible ranking on search engines is to get rid of all the errors and to use semantic HTML.

Of course really major sites that get millions of visitors a day anyway are not going to worry about search engines marking them down slightly because of invalid markup as they are generally so far ahead of their competition that it will not change their position in the results. A smaller site with only a few thousand visitors a day could find themselves a page or two lower in the search results due to their invalid markup.

Yes, as noted we went with the Table design as the solution rather than JS or CSS, which I was hoping would provide a quick solution, but did not.

Again:

W3C HTML validator, indicates that:

Anoox.com has 35 Errors
while it lists, for example that:
sitepoint.com has 153 Errors

So I would not give much credence to the Bot based Error indications of such things as W3C HTML validator, since it is designed to parse very simple Web pages.

Cheers,

Although an embarrassment for SitePoint, a red herring and faulty logic on your part.

Don’t let the numbers fool you, almost always, one problem will cause more than one to be reported,
The number of validator reported problems isn’t as important as what the problems are.
Don’t confuse Warnings with Errors. Warnings are more like “take a look at this and maybe fix” than “you should fix this ASAP”
The validator is a tool to help evaluate HTML, not to give a quality ranking
The validator is quite capable of parsing very large and very complex HTML

True, IMHO the typo-ed "ref="s should be changed to "rel="s. And I would be concerned about the multiple non-unique id values as they could very well cause problems both for CSS and JavaScript.

If and when the SitePoint Devs ask for help we here in the forum will be glad to help them.

You are free to use whatever HTML you like. There are several DOCTYPEs and the “proper” HTML to use for each varies.

Many of us that have been working in web development have learned the hard way what kind of practices are harder to maintain and are more likely to cause issues.
We have also learned that the better the validator results are the less likely there is to be browser problems.

Using tables for layout has long been known to be difficult and have many issues.
Inline styles have long been known to be difficult as well

But if you choose to not heed our advice, that is your choice. No one is saying you must take the easier better path.

You are experiencing some of what many of us have wrestled with in the past.

To get to your site, here’s my take on what the validator is reporting

Character Encoding mismatch!

  • Probably no problem as long as the text content is all always going to be ASCII - if not the likely result will be some characters will render as “?” eg “Hola se?or Pedro”

The “Entity” errors
These are often found in many pages. The fix is to replace the “&” with “&amp;” in the URLs
TBH I don’t know of this actually causing any problem but in any case fixing one will reduce the number of reported problems by 2-3 each

The “missing alt” errors
AFAIK these do not cause rendering issues. But they are an accessibility concern. If you don’t mind alienating some visitors they could be ignored but if you want to fix them they should be given values or changed to background images.

The “end tag” errors
I would be more concerned with the mismatched tags. Most browsers seem to “best-guess fix” non-well-formed mark-up very well, But why leave it to the browsers when you don’t know how they will fix them, if at all. Here again, fixing one will reduce the number of reported problems by 2-3 each

The “style tag missing type attribute” error
I don’t know how big of a problem this actually is. But it could be that some browsers might ignore any CSS you have there and should be easy to fix to remove that possibility.

The “no attribute” errors
These look to be mostly because of using inline CSS
I don’t know how browsers deal with these. They may still support their use, maybe not. I’m guessing most of us have moved CSS out of the HTML to make work easier, not so much because it caused rendering issues

3 Likes

Mittineague,

1st. thanks for your detailed reply.
I agree with most of what you have written, but you are totally wrong on:
"Using tables for layout has long been known to be difficult and have many issues. "
as the exact opposite is the case. That is Table layout results in much more certain rendering across browsers, old or new.

2nd, you are welcome to sign-up as a Volunteer with us, since Anoox is mainly a volunteer based effort, and take charge of a page and submit all CSS based layout for it. Of course after making sure it renders across browsers all Ok.

Cheers,

Oh dear, there are so many people will disagree with you. Enjoy the fallout of making that statement!

2 Likes

Try to achieve such a simple thing as wrapping a row into two lines at a certain media breakpoint. You’ll notice that you’ll have to set the table elements to display: block (and/or flex for that matter), which already reduces the whole idea of using tables for design to absurdity. Unless, of course, you don’t care for RWD at all. :wink: