Re: [whatwg] video element proposal
Maciej Stachowiak wrote: Restricting the types of content that the video element can handle will stifle future innovation, and will likely be ignored by browser vendors who decide they would like to support new formats. It would also be unprecedented relative to type restrictions on other HTML elements. Having a baseline set of formats is something to consider, but the spec should allow supporting any format that can reasonably considered video. Indeed. There's a big difference between mandating a baseline set of formats and stating that these are the _only_ formats that may be supported. Let's definitely do the former, and definitely not do the latter (and if we did, browser makers would probably ignore us eventually anyway). Gerv
Re: [whatwg] video element proposal
James Graham wrote: Widespread deployment (despite not working in many situations Flash has close enough to 100% of the desktop market for content producers to ignore the rest). In practice this means at least two things. Firstly, browser manufacturers without significant in-house video expertise should be able to implement the spec using an external library. Secondly it means that we should be able to implement it in existing versions of IE somehow. A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? While it's not as neat in spec terms, if it makes the difference between IE can't support it and IE can support it with additional software, then a carefully defined subset of object might be a better route than a new tag. Something like Any object tag with the following attributes exactly should be treated in the following fashion... (and from then on pretend it's a video tag). Gerv
Re: [whatwg] JavaScipt in output?
On Mon, 05 Mar 2007 20:33:55 +0100, Ian Hickson [EMAIL PROTECTED] wrote: Are there any restrictions on what you can put in such an attribute? It's an open issues in HTML5. In HTML4, there's a Content-Script-Type thing that can be used, I guess we could move this into HTML5 too now that we have the pragma directives thing. So if Content-Script-Type is not a MIME type user agents support they must ignore all event handlers? What if a script element in the page is set to text/javascript and sets a few event handlers? I suppose it could be made to work... If nobody has set Content-Script-Type to some weird value that would stop their site from working... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video element proposal
Gervase Markham schrieb: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? Well, I guess everybody here will hate me for proposing it... and I think it's ugly... but well... video Perhaps a verbose description of what can be seen here? novideo D'oh, your browser is outdated... let's embed an object here /novideo /video Downside: Bloat. Upside: The author can either embed an object (e.g. in IE video would call the Windows Media Player - and that can be extended to support basically every media format - including MPEG, the Ogg formats (there is software for this in existance) or whatever else is out there) or simply tell the user to get a decent browser (yay, browser buttons all over again!). Plus it would feature a description of the video content for browsers that can't possibly display video (text browsers, mobile phones that don't have the bandwidth). Anyway: With external software it should be possible to get the IE to support a video tag. In worst case just grab the document source and substitue video with object and make sure the user has a fitting plugin for the mandatory format installed. Maik Merten
Re: [whatwg] video element proposal
* Gervase Markham wrote: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? Why would you need an add-on? Internet Explorer has had support for a video element in HTML documents for pretty much the whole millenium, see http://www.w3.org/TR/1998/NOTE-HTMLplusTIME-19980918 for the spec and for a working example see e.g. http://www.w3.org/2001/SMIL20/testsuite/interop2/media/media_clipBegin_clipEnd_repeatCount.htm More up to date documentation is available from the MSDN, and from http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] article: do we really need this?
fantasai wrote: This element would be extremely useful to someone with a screen reader. It would create an implied UA hook for skip to main content, for one. With multiple postings within a page, it would create a reliable way of skimming the main sections (by reading the first bit of content on each posting), even when there are no headers or when the postings themselves have internal sectioning and headers (especially if those are inconsistent). But how would it do this when section or section role='article' would not? If the authors can't make the internal sectioning consistent, do you expect them to make the internal articling consistent? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
Maik Merten wrote: Well, I guess everybody here will hate me for proposing it... and I think it's ugly... but well... video Perhaps a verbose description of what can be seen here? novideo D'oh, your browser is outdated... let's embed an object here /novideo /video I don't think we need a novideo element. This would work: video p Complete marked up transcript of the video. /p /video This is much more accessible and great for search engine optimization. Of course, not everyone has the resources to provide full transcripts all the time, but we should encourage that for those publishers that can. We can even throw in embed elements for users whose browsers don't recognize video. Must ignore wins again. :-) -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] video element proposal
On Tue, 06 Mar 2007 14:40:51 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: I don't think we need a novideo element. This would work: video p Complete marked up transcript of the video. /p /video Yup, that was also in the proposal, fwiw. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video element proposal
Elliotte Harold schrieb: Maik Merten wrote: I don't think we need a novideo element. This would work: video p Complete marked up transcript of the video. /p /video This is much more accessible and great for search engine optimization. This makes sense, although I'm not sure if it's always a good idea to mix legacy browsers handling with content that is supposed to be valuable for all browsers. Your full transcript would thus perhaps contain an object tag that isn't targeted at browsers supporting video but is nonetheless part of the content that is valuable for such browsers. I'm not sure if this actually is considered to be an issue. Maik Merten
[whatwg] getImageData()
The specification should probably indicate that for non-positive arguments for the widht and height this method must throw an INDEX_SIZE_ERR exception. It would also be nice if it was made more explicit that the height and width you ask for with getImageData() don't necessarily reflect the height and width attributes of the ImageData object you get back. Maybe putImageData() should throw a TYPE_MISMATCH_ERR for non ImageData objects as first argument? Similar to drawImage()... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] base versus xml:base
Geoffrey Sneddon wrote: xml:lang and xml:base are the actual attribute names – the XML namespace exists so they work within namespace aware parsers (as XML-Names is a separate spec that extends XML) – therefore, it must be explicitly allowed within the DTD (like xml:lang is). When I read http://www.w3.org/TR/xmlbase/ it seems to me that if a parser understands XML it should be OK to use xml:base. The very last line of that document: XHTML [XHTML] uses URI references beyond those expressible in XLink. These URI references might be resolved by an application relative to the base URI defined by XML Base. The XHTML specification might want to describe their level of support for XML Base. Apart from faulty grammar in the last sentence I interpret this as It is a good idea to explicitly state how this attribute is supported. It *might* want to describe this. I think that it would be wise to answer questions such as if both base and xml:base are present, which one should win? (I've only tested in FFox and the attribute wins over the element.) What authority do you rely on when you say that the attribute must be explicitly allowed? Lars Gunther
Re: [whatwg] base versus xml:base
Anne van Kesteren wrote: On Mon, 05 Mar 2007 22:07:03 +0100, Keryx Web [EMAIL PROTECTED] wrote: It may be that I've implemented this in the wrong way - corrections are welcome - but it seems to me that even though xml:base is legal today, it is **not** supported by UAs. Which makes Anne's proposal, that base should be allowed in both serializations, even more important. There's nu such thing as an xml:base element. It's an attribute. And it is supported although there may be some bugs with dynamic changes etc. Oh man! I thought it was strange that it did not work in spite having been told that it would by several people on the help list... Well, now all the world knows that I've never before used xml:base in my coding or teaching. But maybe my error in itself illustrates the value of letting base be allowed in the XML serialization. The element is known. The attribute is not. No one has argued against allowing the element. Does that mean we have reached consensus? Lars Gunther
Re: [whatwg] video element proposal
On Tue, 06 Mar 2007 10:11:01 -, Gervase Markham [EMAIL PROTECTED] wrote: A good point. I know nothing about extending IE; would it be possible to have an IE addon which implemented support for a video tag, or would it need to be a plugin and therefore use object-style markup? A script could easily fake video element using dynamically created object. That's almost what SWFObject/QTObject scripts do now (and that's probably de-facto standard for embedding interactive content since Eolas patent). I think in that case video is safest solution, because this gives acces to alternative content (which is broken in IE6's object) and allows script-controlled plugin detection and workarounds for bugs in plugins/browser. -- regards, Kornel Lesiński
