Truly W3C Valid Flash

With the rising interest in so-called “web standards compliant” websites, or more accurately described – xhtml markup valid according to the W3C, it’s been a thorn in the sides of Flash developers worldwide that Internet Explorer relied on deprecated markup to present Flash content.

Drew McLellan helped us out with his Flash Satay method, that relied entirely on the object tag, as opposed to the default method also using the deprecated embed tag. This was valid XHTML, but one problem remained. Unless a “container movie” was used, Flash movies presented using the Satay method wouldn’t stream in Internet Explorer.

Until now—maybe? Thanks to discussion over at Drew’s site, I stumbled upon (Thanks Anne) a seemingly perfect and W3C valid way to embed Flash movies. Unlike the otherwise fine Flash Satay method, this method seems to stream perfectly in Internet Explorer, without extra hassles. It doesn’t even rely on hiding the embed tag using JavaScript. The method is described at Ian Hickson’s site, where a demonstration is also available.

Now if only it’s not too good to be true…

Update: Indeed it seems there are a few issues with the “Hixie” method. For one, parameters such as “salign”, don’t work with it.

I’m now recommending that you use SWFObject to embed Flash.

Responses to “Truly W3C Valid Flash”

  1. jim says:

    your header looks ok on safari. i’m using the latest version of safari after the latest os update.

  2. Joen says:

    Ok, thanks a lot jim. Maybe there are no problems at all, or maybe it’s an older Safari?

    By the way, by not working, means there’s no masthead at all.

  3. Jeff says:

    Looks great! Thanks for this, definately a bookmark.

  4. Geoff says:

    The issues with Flash Satay and Safari is because Safari ignores the param tags inside the object tag.

    So while a simple movie like a page header will work because you are using the default Flash embed settings, other more complex files that require things like flashvars or salign parameters will be broken in Safari.

    The Hixie method also suffers from the same problems since it’s still using an object tag to embed the movie in Safari – all your param tags are ignored.

    The only way you can get your pages to validate and work in every browser is to use javascript to embed your Flash content.

  5. Geoff says:

    In fact, a really quick thing you can try is this:

    Your header has a parameter to hide the Flash menu when you right click, but since safari ignores the param tags, when you right click it in Safari you get the full menu, but Firefox or IE will show you the short menu as it should.

  6. Joen says:

    Geoff,

    Thanks for the link, and thanks for the Safari check-up, it all makes a lot more sense now.

    It’s really sad, because I honestly thought “this is it”, about the Hixie method. As for the Flash Satay method, that container .swf is simply too annoying for me to work with, and as for the lastly mentioned JavaScript method, I am actually using a version of it (not yours, something I stole elsewhere) ;) – in my installments section. But even this method is not perfect, as browsers without JavaScript will not show the Flash at all.

  7. Geoff says:

    But even this method is not perfect, as browsers without JavaScript will not show the Flash at all.

    yeah, but I usually rationalize this as a necessary evil, as i’d like to think that people who turn their JS off also are the ‘Flash haters’ who won’t install the Flash plugin anyway.

    With a JS embed, you also get the added bonus of being able to mix Flash versions on a single page – if you have a Flash 6 and a Flash 7 movie on the same page, and the user has Flash 6, they will see the Flash 6 movie, but the version 7 movie will show them the alternate content or upgrade message.

    If you were using the old “detect flash and redirect” method, you would have to force all your users to upgrade to Flash 7 even though they would only be missing out on a single Flash movie on your site.

  8. beally says:

    I personally don’t care(at this point) if it is “truly W3C valid” – as long as it works.

  9. Joen says:

    Geoff,

    With a JS embed, you also get the added bonus of being able to mix Flash versions on a single page – if you have a Flash 6 and a Flash 7 movie on the same page, and the user has Flash 6, they will see the Flash 6 movie, but the version 7 movie will show them the alternate content or upgrade message.

    That is cool. However, during the course of the last some 3 years, I’ve either gotten more and more lazy, or I’ve gotten spoiled by what I can do in HTML and CSS. Like you did with deconcept, so have I built full-fledged Flash sites “back in the days”, albeit not as technically exquisite as you.

    But there comes a time when making Flash is simply too much of a hassle. It takes time to re-invent the wheel every time. My point is, while I’m sure some would love the added abilities of showing content using your method, I’m at a point where I just want to deploy it and release it (which is also doable thankyouverymuch!).

    So, to make a short story long and off-topic, don’t get me wrong: I still do love Flash, and I’m a huge proponent of it for certain purposes. I just don’t build websites that way anymore – it takes much longer, for something that’s less usable, and only might look cooler.

    beally,

    I personally don?t care(at this point) if it is ?truly W3C valid? – as long as it works.

    If that’s true, you can simply use the default embed tags that come with Flash’s publish settings or Dreamweavers “Insert Flash” button – no worries. It is the most compatible way of doing it.

  10. beally says:

    This is indeed the method I use. I suppose I just don’t see the benefit in making something that already works properly ‘W3C valid’ – so perhaps I shouldn’t have commented on a thread about this in the first place :) But I am curious: what is the advantage?

    At any rate, this is very interesting, I’ve bookmarked your blog.

    cheers

  11. Joen says:

    But I am curious: what is the advantage?

    As I see it, there’s currently only one advantage, and that is to be able to use the W3C Validator as a debugging tool. When working with complex CSS based designs, I found this very useful (especially in the beginning), to track down and eliminate errors and bugs in the markup.

    Naturally you can do this even with W3C “invalid” flash, the difference being that it’ll spew out a bunch of extra errors.

  12. beally says:

    A valid point(no pun intended).

    “Naturally you can do this even with W3C ?invalid? flash, the difference being that it?ll spew out a bunch of extra errors.”

    Oh yes, I have experience with this :-)

    On a similar note, do you know of any validators that validate for browsers(ie not just W3C standards, but known browser compatibility)?

  13. Joen says:

    On a similar note, do you know of any validators that validate for browsers(ie not just W3C standards, but known browser compatibility)?

    No, but Macromedia Dreamweaver does this, and does a mighty splendid job of it even! If you haven’t yet tried it out, get the trial now.

  14. Dino says:

    The main point in following W3C guidelines is so that we can, as developers, build accessible sites. Even though Flash can be made accessible for certain aspects, as a whole, it’s not really an accessible technology (after all, how do you describe an animation to someone that can’t see it?).

    Anyway, my point is, if we don’t follow the W3C guidelines as tightly as possible, then we’re not looking after all our visitors.

    With regards to the Hickson version, I get an ASP error because “An object tag cannot be placed inside another object tag. ”

    I think I’ll be sticking to A List Apart’s version…

  15. Joen says:

    I think I?ll be sticking to A List Apart?s version…

    I also think that’s the best choice right now. The reason for the other methods, is that they are much less of a hassle than the ALA method, as they don’t require the container movie. Otherwise I completely agree.

  16. Dino says:

    They only need the container if you want to stream, right? I’ve been using it without needing a container.

  17. Joen says:

    They only need the container if you want to stream, right? I?ve been using it without needing a container.

    Stream. Well. Yes, and no.

    The thing is, the ALA method will not show the Flash movie until EVERYTHING is loaded. That means if it’s a 2K container movie, you won’t notice. But if it’s a 250 K graphic animation, you won’t even see the preloader, you’ll just see it once it’s loaded.

    So I guess yes, it “just” won’t stream, but that’s bad enough if you ask me.

  18. Dino says:

    OK, how about making a container that get’s passed a variable which tells it would movie to load? That way, you only ever need one container, and you then change the variable in the page itself.

  19. Joen says:

    That way, you only ever need one container, and you then change the variable in the page itself.

    I think that’s what the Flash Satay (a.k.a. ALA) method does.

    The problem is, once it’s a movie that gets loaded into another .swf, the _root path changes.

  20. Dino says:

    "The problem is, once it?s a movie that gets loaded into another .swf, the _root path changes."

    You should be able to set that outside of the initial flash movie as a variable, and that way you don’t need to keep changing it.

  21. Joen says:

    You should be able to set that outside of the initial flash movie as a variable, and that way you don?t need to keep changing it.

    Yes, I do think you can re-define the _root variable some how, but unless I can do it in my container .swf, it’s not good enough. Take for instance an old client site that has dozens of .swf files, but only one template. If I could “validify” that site by just changing that one template, it would be great. But I don’t want to change all the .swf’s.

  22. Heidi says:

    You are opening two object tags and are closing only one. That gives you an error. If you close the frist object tag before the new one, you see your Flash stuff twive f.i. in Opera Browsers.

    Too bad ….

  23. [...] For more information visit: Noscope. Joen has a pretty good post ont he subject. [...]

  24. datscharlie says:

    Flash W3C valid and search engine friendly embedding using Flash, VBScript, JavaScript and CSS. Tested in all well known frameworks, learn more at http://www.its-hofmann.com/en/flash/

    cya

    datscharlie

  25. Ian Young says:

    In Opera, everything after the flash didn’t display.

    Works fine in FF, and IE6.

    I have reverted back to old format as it works!

    Any thoughts chaps/chapesses

    Ian

  26. Alex says:

    Just a thought but I don’t see why all this bother with W3C flash validation…

    Just create a additional HTML page with no margins, embed the swf in the old fashioned way. Then use an Iframe to load this additional HTML page into the main page.

    OK… I know whay you gonna say, “DONT USE IFRAMES / FRAMES!”, but since flash doesn’t get spidered anyway… and the rest of your content is in the main page, what’s the problem. All of these other solutions are excessive!

    W3C will not validate within the Iframe… so flash works as it should, using the normal embed method.

    This has been tested on IE and Netscape only. Please feel free to pick holes in my logic! You can see this working on my homepage http://www.dobos.co.uk

    Alex

  27. What about this one?:

    http://www.ambience.sk/flash-valid.htm

    It seems to have valid Flash XHTML.

  28. vijay says:

    i am not able to view the flash banner in opera and firefox browsers but the site is valid HTML 4.01 Transitional the flash colud be viewwed only in

    IE “how to view flash in all browsers with validation”.

  29. creamac says:

    I had to leave the “_root.” away in the actionscript to make it work.

    It seems to me that this little piece of code is unnecessary.

  30. Web Designer says:

    I cant understand the satay method. Is there any easy method on embedding flash?

  31. ntiremedia says:

    Works fine in FF, and IE6.