- From: Joe D Williams <joedwil@earthlink.net>
- Date: Sat, 13 Jun 2009 22:21:22 -0700
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "Boris Zbarsky" <bzbarsky@MIT.EDU>, "HTML WG" <public-html@w3.org>
Ian > It's not a conforming attribute, you're not supposed to use it, but we have to define what happens when someone does anyway. It looks like the sequence for "the user agent must run the following steps to determine what the object element represents: ... " tells very clearly. The first attribute examined is @classid. If the browser doesn't do that or any classid, then move along to type. I haven't checked on the ones @classid used to or still crashes, but it is a great authoring tool for specialized plugin makers and authors wanting to try for a specific plugin. Plus, a very proven technique to give power to the author and even maybe that can help keep a plugin maker from needing to munge type registrations. Earlier in this thread I saw a partial description of how Safari now deals with @classid. I haven't tested @classid anywhere for a while but selection by MIME seemed a lot better everywhere last time I looked. Although I never needed them, of course I hope that getting rid of the need for conditional comedy, eeerrr conditional comments that is, would be an essential goal. As long as HTML 5 browsers don't crash on it but keep processing and take the next hint(s) and try to get the plugin running and give proper fallback for failure, skipping @classid is OK. I would say all HTML 5 browsers don't need to provide any @classid registrations alongside MIME and file extensions if it is too much, but it would be nice, I think. Thank You and Best` Regards, Joe In my mind honoring or at least allowing @classid would end the last vestige of bw. Of course I also think HTML 5 should not worry abut html browsers that didn't do object properly even without classid - obsolete the always dreaded (to me) embed nested fallback in object:)
Received on Sunday, 14 June 2009 05:22:23 UTC