

I'm hiding nothing from the W3C consortium this time though. Here again, the IFrame is calling in a completely separate page that actually contains the lyrics to the song. The "455 Rocket Lyrics" scrollable IFrame situated directly to the left of this text is contained within its own table but that table is also contained within the left cell for page positioning. That was because I was "hiding" the fact that they were not part of the index page. In the first 2 examples frameborder was set to OFF. (scrolling="auto") and frameborder is set to ON. In this example scrolling is set to AUTO. In the first 2 IFrame examples, scrolling was set to NO. This example contains "scrollable" content.
#Html iframe example code#
So, if you were to also examine the source code of each of those 2 pages, you will see that both pages contain CSS styling that will eliminate page borders.ĬSS styling that I've used at the targeted pages to eliminate page borders. If not, placement within the IFrames gets all messed up. It is very important to have margins and padding set to ZERO at the targeted pages. You will see how the music controls in the first targeted page and the Killer Klown graphic located within the second targeted page BOTH hug the upper-left corners of both browser windows. 001-opacity-example.htm (IFRAME #2's targeted separate page) 001.htm (IFRAME #1's targeted separate page)Ģ. You should have already noticed this, but if you didn't, click on both these links:ġ. So, the Killer Klown graphic that you see on the right is NOT contained on this page, but is instead coded within the IFrame's targeted page, and the width and height of the IFrame are set to accommodate the image's dimensions.Ĭode for the above IFrame referencing the separate page displaying the Killer Klown graphic. That *bad* code exists within the IFrame's targeted page. So, in order to have my index page (and this page) successfully conform to W3C recommendations for valid HTML 4.01, I use the IFrame to the right so that the *supposedly bad* opacity code cannot be parsed/picked up on this or my index page. there is NO way that this page or my index page would ever get through the W3C Markup Validator if the validator detected the *supposedly bad* opacity coding I use for the graphic (for an interesting cross-browser mouse-over effect). Here again, the IFrame is calling in a completely separate page that actually contains the graphic. In reality there is another IFrame being used.

The Killer Klown graphic that you see on the right *appears* to be situated directly alongside this text on both this page and on my index page, but it is NOT. The HTML5 audio code for the above IFrame within the separate page that displays the music controls.

Using an IFrame in this way allows this page (see bottom of this page), and any of my other pages, to indeed conform to W3C recommendations and pass as valid HTML 4.01.

So, in order to have my page(s) validate, I use the IFrame where the "bad" code (according to the W3C consortium geeks) cannot be parsed/picked up on my web page. There is NO way that a web page would ever get through the W3C Markup Validator if it detected the "extended" HTML5 audio coding on the page. Why did I do it that way? Well that's part of the beauty of using IFrames. Now, the above music controls "appear" to be embedded directly into this page, but in reality what you see above is an IFrame, calling in a completely separate page that actually contains the HTML5 audio code for the media player controls.
