I am assigning relative positions for button styles using internal CSS and ID selectors.
(Example docs linked below.)
Using an ID selector fails with the first of several buttons; only the first button style fails.
Assigning the same style inline works, even with other buttons using ID selectors.
Is there a positioning limitation when assigning button styles with ID selector?
(Is there a reason for the difference in the display of the two example pages, below?)
That was it; faulty comment code. Have to laugh now, having stripped original document of all other code, bit by bit, thinking I had eliminated all possible culprits.
Have been away from web design for too long…SitePoint Rocks.
Thank you Mittineague, ralph.m, and Paul O’B.
Edit
Do we mark threads “resolved” at this point, these days?
No, we just leave the threads open so you can come back to them if you later find another related issue as the details already discussed may be pertinent.
Test: [U]button-test-example-1.htm[/U]
The css-validator is directly telling what is wrong! No forum needed!
And the html-validator points also to some errors.
Your actual Example 2 is this one, with the inline styles:
Test: [U]button-test-example-2.htm[/U]
Here the css error is still present, but neutralized by the inline styles in the html; also the html-errors are still there.
Correcting all errors/warnings, we can get this one:
As ralph.m said already: it’s not a good idea to have any HTML code above the doctype. The html-validator is warning against that too: “Comments seen before doctype. Internet Explorer will go into the quirks mode.”
Internet Explorer in “quirks mode” means that IE is not following the w3c-standards, but is using the old rendering model of IE5: causing the most strange effects in the design, and mostly ruining it all.
======= From valid to better!
Now the squares are valid, but the <input type=“button”> needs javascript to go to the link. That has 2 strong disadvantages:
If javascript is disabled by the visitor or if the visitor is using a pure text browser without javascript, the buttons don’t work!
The Google-bot doesn’t use javascript either, and is unable to follow the links to other pages of the site in order to index them.
I should recommend to use normal links instead. They can be styled with css just as you want it; no difference on screen.
Note: using a relative position with a top- and left-style is often causing problems with the next elements: they have to get also a relative position and a top-style if you don’t want the next elements coming on top of the first. It’s easier to use the margin-property, then the rest will follow automatically.
======= Tips for the validators
In Firefox you can use the [U]Web Developer Toolbar[/U] extension. One click on the Tools-menu, and you have the results of the html- and css-validator.
Also for Firefox there is the [U]HTML Validator extension[/U]. With this one you can see all validator results directly if you go to View Source Code in the browser. Their explanations are more in human language then the rather mystical diagnose of the w3c-validator, and sometimes there are small differences. For optimal results I use them both.
Another helpful response, especially the mention of Tips for the validators. Thanks Francky…had been away from web noodling a ~long~ time, glad I remembered SitePoint. Having settled into the Chrome browser, your post started me looking for developer tools. (Do not mean to suggest Chrome or a preference for it, here; just adding to the information Trove y’all are building.)
If Developer Tools opened via the Inspect Element action, it is automatically drilled down to and highlighted the element under mouse. This is very useful when you are curious which HTML generated a particular page element.
