Forum Moderators: open
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
Dreamweaver's code for inserting the SWF file causes the W3C XHTML validator to thow up errors such as no attribute "width" etc.
Is there a way to rewrite the insertion code, or another doctype I should be using?
Thanks . . .
My users might not care if the page validates, but if you're trying to do something properly . . .
However :( the page is now broken in NN4 - yes I know all around say forget it, but the site I'm working on is an academic institution and who knows what machines are lurking in dusty corners of faculties, eg Deans' offices. :o
But it WILL be my last gasp at NN4 compatibility!
Thanks for the Flash Satay link - works a treat!
However :( the page is now broken in NN4
Erm... then it doesn't really "work a treat", does it? ;)
I think you need to look carefully at and understand the validation errors produced by the original code. To summarize, the validator complains about the
embedA browser is designed to ignore any tags which do not make sense. A greater problem is something like improperly-nested tags -
<b>bold <i>bold italic</b> italic</i>Aren't you kidding yourself if you think flash satay is preferable despite the fact that it breaks your requirement for NN4 compatibility? One of the advantages of flash is that it works the same in all flash-enabled browsers, and you are gaining nothing more than a badge by using flash satay. Your users should count for more than that, don't you think?
I know another method of adding flash using javascript. It's xhtml 1.1 valid
twist, could you post your code? I'll believe it when I see it...
Basically, just document.write the embed code...
That's kind of what I was guessing. The trouble is with stuff like document.write you get a document which validates but is still invalid. The browser still has to try and decipher the broken markup written by javascript. It still breaks the DOM. document.write simply fools the validator into thinking your code is valid.
It's the difference between an athlete who doesn't take drugs, and an athlete who takes drugs but has found a method of hiding them from the drug test. The latter looks OK at first glance, but he's still doing a Ben Johnson.
The validator is not an oracle, and it is not perfect - and simply hiding stuff from it in order to get your Valid! badge is entirely missing the point of the validation process. Let's stop kidding ourselves, shall we?
simply hiding stuff from it in order to get your Valid! badge is entirely missing the point of the validation process
I couldn't agree more! Validation is not about validating... It's about writing valid code.
If the browser needs the embed tag to display the flash then I give it the embed tag. I do use a document.write to achieve this. This will still validate if you are trying to validate under a browser that needs the embed tag.
This allows you to use flash and keep all your visitors happy. It also eliminates those annoying error messages on the validator. It's hard to validate all your pages, I see no reason to stop all your hard work simply over a tag that they chose to dislike on their validator.
So I guess your choice is to 1) not use flash 2) unvalidate your page 3) Not include the embed tag and lose a portion of your audience 4) simply add flash this way, keep your validation letting your visitors know that you've spent time trying to create a clean website. Your choice.
flash.html?object=true
Then use a server-side script like php to output only the object tag. Then the embed tag won't be on the page at all, once again allowing compliance.
If you wanted to be fancy you could also hide your validation link if the browser needs the embed tag.
a tag that they chose to dislike on their validator
The embed tag has never been valid, never been part of any real implementation... It was just NN4's failed attempt of implementing something of their own as a quick fix.
True, this JavaScript version works (though "works" is stretching it... since it only works if JavaScript is enabled, and all it does is fool the validator). Why not just add it to the dtd? Then it will validate even with the embed tag in there. And, then you're being more honest and upfront about what you're doing -- defining your own dtd.
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0" id="flash1">
<param name="movie" value="/flash/sample1.swf" />
<param name="loop" value="false" />
<param name="menu" value="false" />
<param name="quality" value="best" />
<param name="bgcolor" value="#000000" />
</object>
what's wrong with it?
it only works if JavaScript is enabled
If your visitors are willing to have flash enabled/installed it's most likely they will have javascript turned on. Then again, who knows. Maybe someone could start a thread asking that question.
Why not just add it to the dtd?
Because I spent hours trying to figure out how to get it to work. I couldn't find anyone who had been able to do it. I found a tutorial but, as others I talked to, couldn't get it to work.
If you know of a working tutorial please post a link. Maybe someone should figure it out and write a tutorial on webmasterworld.
P.S. For anyone wanting to use the Satay Method have a look at the discussion [alistapart.com] comments first. It has some issues you might want to be aware of before you use it.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd" [
<!ELEMENT embed EMPTY>
<!ATTLIST embed
src CDATA #REQUIRED
type CDATA #IMPLIED
height CDATA #IMPLIED
width CDATA #IMPLIED
alt CDATA #REQUIRED
pluginspage CDATA #IMPLIED
>
]>
DTD for XHTML 1.0 Strict w/ <embed>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [
<!ELEMENT embed EMPTY>
<!ATTLIST embed
src CDATA #REQUIRED
type CDATA #IMPLIED
height CDATA #IMPLIED
width CDATA #IMPLIED
alt CDATA #REQUIRED
pluginspage CDATA #IMPLIED
>
]>
That's "how you do it"... Now, that's the technical end of it. I'm in no way promising that this will work in every browser (in fact, I can almost promise one or two of them will have issues).
But, that's the "shorthand" way of adding <embed> to any DTD. The code in red effectively appends the embed element to the DTD, causing the page to validate. No messing with writing your own complete DTD or anything... (besides, using a custom DTD won't let you run the document through the W3C validator).
Anyway...
[edited by: DrDoc at 8:55 pm (utc) on Feb. 25, 2004]
If the flash object container is sized absolutely, in pixels, and has margins set in pixels, I don't think there would be any significant problems, that's unfortunately not the case though if you use relative, % sizing.
unreliable sizing
...which is related to poor support for the object tag itself, not the satay method failing. But, since you remove the embed tag, and make the object tag compatible, then the browser has no choice but to use the object tag (since it can now understand it).
However, do not correct the object tag without removing the embed tag, since this may cause confusion for browsers that all of a sudden can render the object tag, but also finds (and understands) the embed tag
But excellent advice, as usual, thanks. I went back in and tested it with only fixed pixel sizing and see no problems, but since the site I tested this on is completely fluid, that was not an option for all of the flash objects, although it works fine for the fixed sized ones as far as I can see, the only browser it's not working on is Opera5, but that's hardly a problem.
The Satay method seems to be a good choice for fixed sized object tags, better than the embed tag for certain, I got much better flash functionality with Satay than with javascripted embed tags, too bad about the object sizing problem, oh well.
However, it's not just the object tag itself causing these problems, the Satay method is definitely involved, since I got distortions using the same object id and sizing, but only once I used the satay method, some of these distortions were beyond extreme, others more subtle, they occured in IE 6 standards mode, Opera7, but not in Mozilla I think. All in all worth some thought, definitely a part of the solution I was looking for. Scripting in the embed to the DTD is a funny idea though, maybe I'll try that.
Scripting in the embed to the DTD
Not even scripting... just appended to the DOCTYPE tag...
That's "how you do it"... Now, that's the technical end of it. I'm in no way promising that this will work in every browser (in fact, I can almost promise one or two of them will have issues).
I finally got around to testing this method for a friend who needed this done. Result: Don't use that method, Mozilla displays some of the brackets, breaks other parts of the page display up, that's another one for the 'wouldn't it be nice if this worked in the real world pile'.
Result: Don't use that method
So the DTD method didn't work? That sucks. Has anybody else had luck with it yet?
Drdocs sample theoretically works, it will validate, the flash object may or may not work, but the page layout I tested it on got distorted on Mozilla, and part of the embed thing printed on the page, top of the page.
When I see a page display error this serious on my first test on a recent version of a modern browser, that's the last time I ever use that particular technique, since display and performance problems will only get worse with older browsers and slower computers (like every css dropmenu script I've ever seen, by the way).
