Posted by fax8 on September 11, 2005 at 8:26pm
| Project: | Video |
| Version: | master |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Drupal use everywhere valid XHTML syntax.
The embed tag which we use on the play page isn't part of any W3 standards.
This makes websites using our module to be not fully W3 compilant.
We have to make our module W3 compilant where is possible.
On the web I found some hints on how to make Flash and Quicktime W3 compatible pages.
This is on my todo list but if someone have time
to do this please submit a patch.
Fabio
Comments
#1
Here there is a valid realplayer page.
And here a valid windows media page.
#2
here some valid W3 examples.
here an alternative for quicktime
#3
here a patch for quicktime player XHTML W3 compatible.
Tested with mozilla, mozilla ff, ie6, ie7 on windows with quicktime 6.5 pro.
Feedback are welcome.
Really useful Mac feddback (safari, ie mac)
#4
To apply the patch above get lates video.module from cvs.
Uncompress and put the complete directory on your modules/ folder.
then apply the patch using "patch < video.patch" from modules folder.
#5
Here's a patch for WMV that seems to validate fine to XHMTL 1.0 strict.
#6
I didn't try this patch yet..
but I think that older version of IE will not
work well... did you try this with IE 5 and IE 5.5?
These browsers are really buggy and doesn't follow
well standars.. but we have to still support them.
#7
I'm in Paris now and don't have access to any IE 5 or 5.5 machines. Are you refering to the lack of embed tags? Because when I added those it lost XHTML compliance.
Here's the HTML in use for testing: http://www.ppixel.com/index.php?q=node/33/play
#8
Paris!?! nice!
I will try your patch with older browsers..
Have a good time!
#9
Thanks, it's a great place to live. I'll be here until december.
What about handling the old browser cases in PHP by detecting the user agent ($_SERVER['HTTP_USER_AGENT']) and sending the old code. This eliminates the need for the extra CSS file which adds another file to the clutter not to mention an extra web hit. What do you think?
#10
yeah, this could be a solution.. but maintaining two codes for every video format
will make the module harder to maintain, harder to understand and really big!
I think that using a css solution should be good.
(webserver overhead should be ignored: there is caching)
Maybe using an unique solution should be the best:
http://www.mustardlab.com/developer/test/embed/
There they used a javascript for all video formats.
seems it work.
#11
Seems that wordpress people made progress in making
their video plug-in XHTML compatible.
http://www.rossgerbasi.com/2006/01/21/extreme-video-plugin-20/
I don't if their solution is backward compatible with old browsers
but.. could be useful if someone could investigate on this..
Fabio
#12
revision 1.32 has some changes to quicktime and some param tags
#13
AC_QuickTime.js file seems copyrighted by Apple.
This probably means that the licence of this file is not GPL.
So we CAN'T put it on our video module archive.
Some time ago I proposed looking at http://www.mustardlab.com/developer/test/embed/
where there is an js object bug workaround which seems to come with less copyright issues.
Fabio
#14
GPL has a copyright statement in it, too. The license grants use, reproduction, and distribution if you keep the copyright notice when you don't modify it, you don't use Apple's name to advertise the module, and you can't sue them for bugs. I didn't modify it, I left the notice, and I don't think we'll ever use Apple's name to advertise the module. It's probably not too much harder to write our own QT js stuff. I guess we'll just consider QT still open with regards to what I did.
#15
this is not a copyright problem. It's a licence problem.
If you go to http://developer.apple.com/internet/ieembedprep.html
the webpage from where the AC_QuickTime.js came from, before
you are able to download the javascript file you have to accept a licence
agreement.
On the agreement you can read:
For me the personal statement could be a problem.
Moreover users which will download the AC_QuickTime.js from drupal site
will not have to subscribe the apple licence and this could be a problem.
#16
I agree to swap it out. Do you have any features in mind that would need the dynamic object building functions of AC_Quicktime.js or could we just put the object HTML we had before in some JS document.write() outputs?
#17
I just tried to replace AC_Quicktime.js with a simpler, home-grown js file, but I need to be added as a maintainer on the video project node (see http://lists.drupal.org/pipermail/development/2006-May/016096.html). Luke should probably be added, too.
#18
ok. I added luke and you as mantainer.
but please post your changes here.
Then everyone can check for problems.
#19
Version 1.34 reverts AC_Quicktime.js use. It takes the Quicktime HTML from 1.31 and drops it in a multi-use .js file. The intention now is to create InsertXXHTML js functions for each type that needs it. Quicktime has a dual bonus to get rid of ActiveX notices and XHTML validation.
#20
Just FYI, I checked to make sure the JS method worked in IE, FF, and Opera, but I won't have access to test Safari until tomorrow.
#21
This implementation does not degrade for people with javascript disabled.
I think that the correct approach should be let php draw a object only tag
(which is fully XHTML compatible). Then javascript should take care of adding
the embed stuff for browser which need it for displaying videos.
#22
The JS for Quicktime isn't just for XHTML, though. I threw the whole thing in a .js file because I needed to get rid of the ActiveX warning IE users get on properly patched WinXP systems when the object tag loads the classid.
You're right that it doesn't degrade. What I was considering was users who have js disabled probably also have ActiveX disabled. I would also gamble if they're technical enough to be paranoid about JS, they're probably also skilled enough to figure out how to download a movie through the download tab.
My commit was selfish because 99.56% of my customers use IE and the ActiveX popup window was getting annoying on their properly patched WinXP boxes. The tradeoffs I see are ActiveX popup, XHTML, and JS.
This has made me dream up some crazy implementation ideas. One is some JS that would either set a cookie or somehow POST in a background process to set a $_SESSION var that lets the module know it can use a JS implemenation. On a direct pageload of the play page, that idea falls apart.
How do you see the priorities of solving the ActiveX popup, XHTML compliance, and JS degredation? I get the impression you don't use IE since you haven't discussed it at all (I don't, but my customers do).
#23
ActiveX popup has more priority than others.
XHTML compilance and degradable js needs to be implemented asap.
Fabio.
#24
I just get a sponsor for this.
My deadline is in 3 weeks.
Fabio
#25
task almost complete...
just few problems still need to be understood but..
I'm getting there.
Preview:
http://varesano.net/video-demo/
Fabio
#26
this feature has finally been implemented.
Get video.module v1.38 for try it out.
See http://drupal.org/node/69581 for more informations.
Fabio
#27