COBOLdinosaur

The page has validation errors and is bloated with excessive scripting. It is likely the change is cause by sme scripting referring to the referral values or that the server side scripting is referencing it.

Trying to fix a page full of errors generally needs to start with the elimination of the errors, otherwise most of the effort is wasted, and the underlying instability may cause additional problems.

The validation error on the input may have something to do with it. However the rel problem is trying to use Dreamweaver design view and expecting it to render like a browser. If you want to see what something is going to look like in a browser, then the only reliable way to do it is by looking at it in a browser; actually a selection of browsers to cover those you are going to support is the only way to test rendering and know how it is going to present.

Your first step in any testing should be to put the markup through the validator (takes less than 10 seconds) because it is not logical to expect correct rendering with defective code.

You might want to re-think putting in a lot of styling that you are not using. There is no way for the parsers to kinow what will actually be used by the page so they must parse and serialize all declarations and properties. That will add a small additional time to the page load and make the display slightly less responsive because the re-paint cycles take longer and you end up with fewer paint cycles per second because the rendering engine has to work with a larger amount of data then is actually needed.

The degradation is not big unless you create a really big mess, but from a maintenance standpoint you may be creating more work for yourself instead of less when you look at how simple it is to add, remove of change CSS rules.

The first thing you need to do is make sure the image can actually be found by the CSS parser. The url you are using might need a path depending on the location of the image file in relationship to the location of the page file, and the css file.

Hmmm.... there seems to be a communication problem here. CSS is worthless to you if the HTML is not correct. The code you posted does not come anywhere near being valid and until you have correct HTML you cannot expect any consistent performance of either layout or presentation.

So let me see if I can make this clear.

YOU WILL NOT GET ANYTHING TO WORK RELIABLY IN HTML OR CSS UNTIL YOU FIX YOUR ERRORS

The browser cannot process BBcodes. On the server there is scripting to convert the BBcodes to HTML. BBCodes are used, because allowing HTML codes in postings is a security risk. For some very primitive implementations of BBcode to HTML it is possible to use javascript to do the replacement and then re-write the page, but that is pretty much worthless because the post needs to go to the server to be saved; and very few developers would accept the text containing HTML without stripping it and sanitizing the post before it is sent to the DB.

Without seeing the code or a link to the page, I can only guess that you have conflicts coming from inappropriate combinations of properties that impact positioning.

Actually it does NOT default to top:0; left:0; it follows the flow of the document elements, UNTIL you set at least top and left properties.

 

You're right, which can make it strange if you don't set the position; get real weird in a mobile friendly design using media queries.

can we make it so that even though it is set to 100vh, that it actually appears a little smaller

 

That would be counter to the nature of the unit of measure. if you need to modify the the value thenyou need to use the CSS calc() to adjusted. however the value has to be a literal as there is no support for variables in calc().

So you could use height:calc(100vh - 50px); or whatever value you need the bugs that plagued both IE and Chrome for that kind of format seem to be resolved. As for the other two issues it might simply be that the browser is choking on:

.pageWrap {
	margin: 10rem 0 0 0;
	width: 100%;
	height: 100vh;
	overflow: auto;
	position: fixed;
}

which does not seem to make sense. the margin means it cannot be 100vh and remain in the window and setting position fixed without setting top, left, right, or bottom, defaults to top:0;left:0; which would force the margin to be outside of the viewport and actually result in the height of the element being being 100vh+10rem;

There is an exploration of calc used with vh/vw on my site: http://coboldinosaur.com/pages/css-calc-function.html that might help you dig through the issues.

 

many top results in Google searches yield sites with hierarchical menus.

Of course. Why would that not be the case. You will also see top results for pages with no doctype, misspelled titles, no keywords, broken layouts, hundreds of validation errors, and duplicate content. They are all there because because they have enough content of value to be well placed in the index. They are also likely to have been around for a while, be in a specialize niche, carry Google ads, by ads from Google, or are cross-domain login partners. All of which add to Google juice.

I'm only going to give you a single reference where I'm sure you will be impressed by the example and the source:

http://www.w3schools.com/TAgs/tag_nav.asp

When W3C upgraded HTML3.2 to HTML4 it took 4 or 5 years to figure it out and there was enough disagreement that W3C had to create the transitional doctype that made things worse. There is no agreement on most of HTML5 among developers, manufacturers ot W3C itself where the gap between traditional W3C methods and the helter skelter WHATWG approach where anything is allowed that Hixie says is okay. Somewhere down the road it might shake out so one of us (or possibly both us) turns out to be right.

my point is that this is not something a beginner needs to be worrying about

 

Hmmm. at what point do we teach children the right way to cross a street; is it ever alright to just let them learn without guidance. when someone care enough about what they are doing to post in a forum for help with it, then they deserve enough respect to receive an honest response whether it is positive or negative.

With modern browsers and the range of CSS presentation options available then is no menu presentation or effect that cannot be presented in a nav wrapper. If we are going to go to the silly approach of multi-level drop downs it is irrelevant and ul or nav does not matter because the amount of damage a multi-level drop down does is far more than can be mitigated by semantics. It is the single worse way to do navigation in terms of higher bounce rates, lost ad presentation opportunities, lost opportunities to upsell, reduce page exposure for potential backlinks and a reduced footprint in the SE index.

When someone is a novice developer it is not a favor to ignore flaws so they learn bad practices and then need to "unlearn" the bad habits if they decide they want to do the work professionally. If I come across as harsh it is because I care about people struggling to learn what I already know; and I respect them enough to express honest opinions which frequently are not what they want to hear or padded with soft expression to please mods.

I would just use a nav for each link list within a div wrapper to cascade the styling I want to use.

<div class="menu">
 <nav>
   <h2> Cat1 </h2>
   <a etc...>
   <a etc...>
  </nav>
 <nav>
   <h2> Cat2 </h2>
   <a etc...>
   <a etc...>
 </nav>
</div>

While

<ul>

<li> <a> ... etc.

is at least clear on semantics it is a list and if the list contains links I guess they can be treated a item.

However

<nav>

<ul>

<li> <a>... etc

does not make semantic sense because it says this is a list of navigation link; no wait it is a list of items! So it is wrong.

BTW concerning the reputable sites. I am a member of the communities for three of them and the support for list inside of nav is split in those communities.. I was going to let it pass, but if I have to justify pointing out that something is wrong then I guess we need to also clear up the "endorsements" as well.

The issue and debate have little to do with the semantics as it does with maintenance issues because poorly written CSS declarations will have to be changed so developers do not continue to bloat the code with unnecessary ul and li tags that carry styling that should have been inherited from a wrapper. If you look at the supporters of the nested format they are also the one who use things like
#nav ul li a {properties...

instead of #nav a{ properties

The second works for either format, but the first first format ties presentation to content structure and fails if you don't keep the ul and li tags.

If the amount of data is small enough that downloading all of it does not cause a noticeable reduction in load time, then I would just download it all. 99.9% of the time AJAX methods are fast enough to result in no serious lag, however the other .1% can result from the user having a poor connect, the load on the server is at a stress level, the user is running something else which can slow down javascript, or the user has a heavy download going on in background.

The action on the form need to be the url of the target page which is where the script should be inside the container element that you want to hold the data.

How can I make the boxes float under another even if the height is different?

 

Post a link to the page. Post your code. Provide some detail.

Those are all possible starting points. Unfortunately we have not been able to master telepathy to the point where we can read minds across the internet.

Hacking the page by overwriting after it is loaded will work, but you need to understand that you will be making the page worse for future maintenance, reliability, and efficiency. If you you have the url to the script you should be able to download it. though if the jquery is minified it might be a little difficult to do anything with it. Even if you cannot directly download it, it should be in your cache.

If you have the coding skills to fix it, then you might want to consider getting rid of the script and writing your own. Anything that is so restrictive that you cannot do simple changes without jumping through hoops is not a helpful tool, and the more you hack around it, the close you get to it crashing.

I assume by "dropdown" you are talking about a select, and not a datalist which behaves quite differently and not the save across all browsers.

Instead of sending the value of the option, you need to send the text of the option.

The easiest way is probably to add a hidden input

<input type="hidden" id='selVal" name="selVal">

then in the scripting:

SEL=document.getElementById('Idofselect');

target=document.getElementById('selVal');

target.value=SEL.options[sEL.selectedIndex].text;

You can trigger the code as part of whatever client side validation you are doing, or just add an event listener to the select triggered from the chage event

Let's start with this CSS rule :

div#container {background-color:rgb(106,183,239);
color:rgb(0,0,0);
float:left;
border:1px solid black;
padding:0%;
margin:0% 10% 1% 8%;
width:83%;
border-radius:25px;

width is 83% plus right margin 10% and left margin 8%. That is 101%.

Not only is it already too wide, it has no slack and when you specify in percentages, you can run into problems is there is no slack because the percentage has to be converted to pixels which cannot be fractional so when the browser rounds up you get broken lay out.

What is even more curios is floating an element the is full width of its parent. There is no reason or effect to floating it except add excess coding. As for a float going below other content, the is the expected behavior when the available width is not enough to do the float. Content outside of its box is also normal when the box is nor big enough to hold it, and the dimensions are using a flexible unit of measure.

I think you problem is that you are trying to do layout with CSS. That is what HTML is for. do a base layout without any CSS. It may not look pretty, but doing HTML only will force you to think about the relationship between elements, and that is what you need to understand so you can decide what is important for understanding the site at different resolution.

Once you have layout then do the CSS for presentation. Use only what is essential. If you cannot explain the reason a property must be used or cannot explain the reason for the specific value, then you need to stop and think. If you can't explain it; then you don't need it. If you needed it you would see why as soon as you removed it and something broke.

Once you have the basic layout styled you need to learn about media queries and how to use them to adjust the presentation cross-resolution and cross-device.

for example you can't style the elements of the second list differently than the ones in the first list.

 

Really nav h2:nth-of-type() is no longer valid ... see this page

as for the list of "reputable sources"... reputation has nothing to do with it. None of them is the authoritative site for setting the standards. If we go back far enough we can probably find "reputable sources" advocating all kinds of things like table layouts, framesets, activeX, and transitional doctypes; all quite legitimately, and with the best of intentions. However web sites present content to attract users and sell adds not set the standards.

The only research I have done is the effect on SEO. When I changed a number of internal link lists from ul to nav the search traffic on those pages increased by 4.6% over the next 6 weeks while the overall increase across my site was 1.7% during the same period. Unfortunately, I just did it out of curiosity instead of serious research and did not set up a control where I changed from nav to ul. So the result does not carry much weight in my mind. I have a couple of clients interested in participating in more detailed testing, so I should be able at some point be able to say whether Google prefers nav, ul, or a nested nav/ul structure.

I'm not sure what you think you need for documentation. Most of the values are not named colors. The standard color pickers list the named values. In the full rgb range there are over 16 million colors, and I guarantee you that no one is going to try and give them all names.

The important thing with the numbers is not so much the colors they produce, but the calculations to determine contrast between foreground and back ground.

After you look at the color pickers on w3schools and other sources you might find the approach to producing good contrast in this article written by a colorblind web developer

I'm not sure if what you are looking for is guidelines for usage but maybe that will help.

IE and Chrome do not calculate 100% the same way because they treat the space for scrollbars differently. You could try using 100vw for the width instead of the percentage and that might work, but trying to get multiple browser to render the same when you are using 100% of the available canvas in either dimension is always a challenge and they never look 100% the same.

A small margin might give you your best shot at getting the rendering close.

The nav can contain most other elements which makes it possible to apply a heading, p, or span to label them; unlike ul and ol which cannot contain anything except li elements. So if you want to label a list you have to either do it externally or use the semantically questionable technique of using the first item in the list to define the content of the list.

As for the structure posted what is wrong with:

<nav>
  <h2>Area 1</h2>
    <a href="#">Link</a>
    <a href="#">Link</a>
    <a href="#">Link</a>
<h2>Area 2</h2>
    <a href="#">Link</a>
    <a href="#">Link</a>
    <a href="#">Link</a>
</nav>

Less to parse; a lighter load for the rendering engine, a more efficient DOM; less code to maintain. With CSS it can be styled for any presentation format that you might need, and requires less complex CSS and is less likely to need scripting support.

I am starting to think that lists are today what the Table was in 15 years ago; a comfort zone where they can continue with antique methods.

Actually the definition in the specification defines it pretty narrowly:

"The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases, and no nav element is necessary for those links."

The fact that neither w3c or WHATWG provide correct usage for nav/ul relationships is indicative of them not being considered for use together unlike the kind of detail for the relationship for figure and pre or figure and img which are expected to be used together. so will it get misused as a wrapper for UL? Probably; the percentage of pages on the internet that actually validate is such that semantics are irrelevant for most sites anyway; and the only user who care are those who to use enabling devices to use web sites.

Try that with a screen reader, and tell me it makes sense.