Valid html/xhtml using <embed>

liunx

Guest
Valid html 4.01 and xhtml 1.0 using <embed>, where flash and/or quicktime are used in non-supporting browsers, Netscape/Mozilla.<br />
<br />
First time I've ever done this, so any thoughts are welcome. Mainly, is it worth it?<br />
<br />
Have made example pages here: HTML Version (<!-- m --><a class="postlink" href="http://www.extonall.fsnet.co.uk/happy/validembedhtml.htm">http://www.extonall.fsnet.co.uk/happy/v ... edhtml.htm</a><!-- m -->) - XHTML Version (<!-- m --><a class="postlink" href="http://www.extonall.fsnet.co.uk/happy/validembedxhtml.htm">http://www.extonall.fsnet.co.uk/happy/v ... dxhtml.htm</a><!-- m -->). The source is commented with all details and relevant links. Links are on each page to submit the code to the wdg custom dtd validator.<br />
<br />
Been reading about this and much that I found said "the preffered method" was by use of a custom dtd. The only modification to a standard w3c 4.01 transitional dtd, or xhtml 1.0 transitional dtd is the <embed> element and its attributes, nothing else.<br />
<br />
Custon dtd's and more info for both are available from <!-- m --><a class="postlink" href="http://www.yoyodesign.org/doc/dtd/dtd.html">http://www.yoyodesign.org/doc/dtd/dtd.html</a><!-- m --> There are two dtd files available for html and xhtml.One allowing the use of EMBED and its attributes. The other, allowing the use of non-standard attributes in the FRAMESET element, FRAMESPACING, FRAMEBORDER and BORDER. These are still required in older browsers in order to get rid of eventual gaps between frames.I dislike frames anyway, so that's irrelevant to me.<br />
<br />
Macromedia and Apple recommendations for using <embed> can be read here:<br />
<!-- m --><a class="postlink" href="http://www.macromedia.com/support/flash/ts/documents/tn4150.html">http://www.macromedia.com/support/flash ... n4150.html</a><!-- m --><br />
<!-- m --><a class="postlink" href="http://developer.apple.com/quicktime/compatibility.html">http://developer.apple.com/quicktime/compatibility.html</a><!-- m --><br />
<br />
WDG info on using a custom dtd can be read here:<br />
<!-- m --><a class="postlink" href="http://www.htmlhelp.com/design/dtd/customdtd.html">http://www.htmlhelp.com/design/dtd/customdtd.html</a><!-- m --><br />
<br />
Questions: Is it worth it? Even though it's valid code the validator will never show a level of html or xml but it will show "Congratulations - no errors". Can the w3c validator process code where a custom dtd is used? Where flash is used, is it better to just ensure your code is valid by commenting out <embed> during validation, then re-introduce it and remove the doctype? Is the use of a custom dtd a hack or a neccesary workaround?<!--content-->personally I hate the dtd. they mess up the code and nobody knows why. I leave them out.<!--content-->Originally posted by scoutt <br />
personally I hate the dtd. they mess up the code and nobody knows why. I leave them out.<br />
<br />
Me too, I'm with you there. I've seen it cause big problems in Netscape browsers. However, in this test I had to specify it as it's a custom dtd. But at the end of the day you can never stick a w3c icon on it! After doing this I'm drawn to thinking that where flash is used it's best just validate the code omitting the <embed> stuff, then just re-introduce it and remove the doctype all together. It did seem a lot of hassle for one element!<!--content-->I would argue that with the modularization of XHTML, modifying the dtd is almost expected. It seems to me that one main idea behind the move to modules is to allow greater flexibility in that area (customization).<br />
<br />
Removing the doctype is a very poor solution. The doctype is needed so that the user agent can correctly identify the type of document that it is being served so it can then correctly render it.<br />
<br />
personally I hate the dtd. they mess up the code and nobody knows why. I leave them out.<br />
I have seen that as well, on occassion. I wish I knew why that happened. But you are right in that leaving out the absolute address of the dtd in the doctype usually solves the problem.<!--content-->
 
Back
Top