[TYPO3-dev] MULTIMEDIA

[Peter Klein]

Hi Martin.
For Flash, you will need to use different OBJECT tags, depending on which 
browser you are using.
As IE needs a CLASSID to stream the content correctly, but Mozilla doesn't 
work with a CLASSID as it needs a mimetype instead.

See: http://alistapart.com/articles/flashsatay

Maybe thats similar for non-flash objects too?

-- 
Peter Klein/Umloud Untd

"Martin Kutschker" <martin.kutschker-n0spam at no5pam-blackbox.net> skrev i en 
meddelelse news:mailman.1.1180705214.10088.typo3-dev at lists.netfielders.de...
> Hi!
>
> Here are my thoughts on the topic:
>
> The current implementation of the MULTIMEDIA cObject type and the 
> accompanying content element is a very simple one. Unfortunately it relies 
> also on the EMBED and the APPLET element which are not part of any W3C 
> standard and has a set of questionable default attributes. OTOH it is easy 
> to use and doesn't require much knowledge from the editor.
>
> So I suggest to modify the code such that the generated HTML code uses the 
> OBJECT element (with a possible fallback to EMBED or an image).
>
> Adding support for user defined width/height and alt/title text is easy 
> enough. More of a problem is the fact that the OBJECT element requires a 
> type attribute with a mime type unless you specify a classid attribute 
> which is Windows specific and requires a certain browser plugin. So we 
> need (for convenience) a file extension to mime type mapping (with a 
> manual override option). The mime type must be a DB field so it can be 
> accessed by TypoScript!
>
> Another point is that we may want to set the width/height attributes 
> automatically. IMHO we should incorporate the getID3 library (or an 
> equivalent) into typo3/contrib. We could use this lib also for download 
> elements to display meta data for media files (eg play length, bitrates, 
> etc).
>
> The current parameter field can easily be changed to output PARAM elements 
> instead of attributes for EMBED/APPLET.
>
> But a problem might be real compatibility. Does anyone need the old EMBED 
> tag? Will sites break if we just move on to OBJECT? Perhaps if the make 
> use of the parameter field (not all attributes may map directly onto PARAM 
> tags).  We could redefine the syntax that a line may look like this 
> "name=value[|tag]". So all params are duplicated (when we have both OBJECT 
> and EMBED) unless a tag name is appended.
>
> As for using OBJECT and EMBED/APPLET: for xhtml 1.0 strict and xhtml 1.1 
> no EMBED/APPLET should ever be created. For other DTDs I see the option to 
> use both elements or only EMBED/APPLET. The latter option is for strict 
> backward TYPO3 compatibility only. The TypoScript compatibility flag will 
> provide a default: a setting of < 4.2 will get you EMBED/APPLET by 
> default, otherwise its OBJECT. A site admin may choose both elements by an 
> appropriate TS configuration.
>
> Examples:
>
> # mime type and size auto-detection, tag defined by default
> movie = MULTIMEDIA
> movie.file = movie.mpeg
> movie.altText = last christmas
>
> # width auto-detection, tag set to OBJECT and EMBED
> movie = MULTIMEDIA
> movie.file = movie.mpeg
> movie.width = 200
> movie.mimeType = video/mpeg
> movie.tag = objectEmbed
>
> Masi
>
> PS: For a set of know mime types we could even create a flex form sheet 
> with additional parameters for well-known plugins (eg autostart, show/hide 
> UI, etc). But maybe such stuff is better suited in an extension.