Re: [whatwg] whatwg-legal

On 22/03/2007 05:58, Robert Sayre wrote: It seems a few people believe this list is an appropriate venue for discussion of legal issues like trademarks and patents. Well, I don't know of any lawyers that participate here, but perhaps a more focused list could attract some legal expertise. Here's

Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

On 3/22/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: There are devices that have a hardware video decoder but not enough CPU power for even relatively simple video. These could justifiably omit Ogg under the SHOULD clause. Is there something that prevents implementation of ogg hardware vid

Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

On Mar 21, 2007, at 9:14 PM, Robert O'Callahan wrote: - As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. OK, let's assum

[whatwg] whatwg-legal

It seems a few people believe this list is an appropriate venue for discussion of legal issues like trademarks and patents. Well, I don't know of any lawyers that participate here, but perhaps a more focused list could attract some legal expertise. Here's whatwg-legal: Homepage On The World Wide

Re: [whatwg] Apple Proposal for Timed Media Elements

At 17:08 -0700 UTC, on 2007-03-21, Maciej Stachowiak wrote: [...] > I'm worried about "The controller attribute is a boolean attribute. If the attribute is present, the user agent must display a user interface which allows the user to cont

[whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

- As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. OK, let's assume Theora is a bad format for some devices. If someone wa

Re: [whatwg] Apple Proposal for Timed Media Elements

On Mar 21, 2007, at 7:20 PM, Robert Brodrecht wrote: On Mar 21, 2007, at 5:08 PM, Maciej Stachowiak wrote: The DOM attribute currentRate is the rate at which a media element is currently playing. I'm guessing this would be in frames per second? Is it the frames per second it is pla

Re: [whatwg] Apple Proposal for Timed Media Elements

On 3/21/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Mar 21, 2007, at 6:16 PM, Ian Hickson wrote: > Starting with simple features, and adding features based on demand > rather than just checking off features for parity with other > development > environments leads to a more streaml

Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

On 3/21/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: - Although the Ogg codecs don't have known patents that aren't RF licensed, it's not completely clear that none of the patents out there on video/audio encoding apply. Can we move the patent discussion somewhere else? Not to be rude, but

[whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

On Mar 21, 2007, at 6:16 PM, Ian Hickson wrote: * I'm concerned about the "type" attribute for content negotiation. Historically, type attributes are very badly implemented and even less reliably used. Conditional fallback in general is badly implemented and bug-prone especially in th

Re: [whatwg] Apple Proposal for Timed Media Elements

Looping is useful for more presentational uses of video. Start and end time are useful in case you want to package a bunch of small bits of video in one file and just play different segments, similar to the way content authors sometimes have one big image and use different subregions. Or consider

Re: [whatwg] Apple Proposal for Timed Media Elements

On Mar 21, 2007, at 5:08 PM, Maciej Stachowiak wrote: CSS Timed Media Module proposal - http://webkit.org/specs/ Timed_Media_CSS.html HTML Timed Media Elements - http://webkit.org/specs/ HTML_Timed_Media_Elements.html I'm excited about Apple's video team being on board with this. While ev

Re: [whatwg] Apple Proposal for Timed Media Elements

On Mar 21, 2007, at 6:16 PM, Ian Hickson wrote: On Wed, 21 Mar 2007, Maciej Stachowiak wrote: With the recent discussions about the element, we've decided to post our own proposal in this area. This proposal is a joint effort from the Safari/WebKit team and some of Apple's top timed medi

Re: [whatwg] Apple Proposal for Timed Media Elements

On Thu, 22 Mar 2007, Ian Hickson wrote: > > * The "mute" feature is IMHO better left at the UI level, with the API > only having a single volume attribute. This is because there are > multiple ways to implement muting, and it seems better to not bias the > API towards a particular method.

Re: [whatwg] Apple Proposal for Timed Media Elements

On Wed, 21 Mar 2007, Maciej Stachowiak wrote: > > With the recent discussions about the element, we've decided to > post our own proposal in this area. This proposal is a joint effort from > the Safari/WebKit team and some of Apple's top timed media experts, who > have experience with QuickTim

[whatwg] Apple Proposal for Timed Media Elements

Hello WHAT Working Group, With the recent discussions about the element, we've decided to post our own proposal in this area. This proposal is a joint effort from the Safari/WebKit team and some of Apple's top timed media experts, who have experience with QuickTime and other media techno

[whatwg] Bookmarking videos

On Wed, 21 Mar 2007 20:19:24 -, Nicholas Shanks <[EMAIL PROTECTED]> wrote: On the other hand it depends on authors providing metadata. Most likely very few will do that, and even then provided chapters may not cover all interesting fragments in the video/audio. That situation isn't any dif

Re: [whatwg] , Flash, & IE7

MegaZone <[EMAIL PROTECTED]> wrote: >> When encountering an object element IE7 seems to block all embedding by >> default and it issues "security warnings" [1] . Afaics that virtually >> drives the final nail in the coffin [2]. > >I haven't seen this myself. Admittedly, I use Firefox for all my

Re: [whatwg] Drop tabindex=""

Once upon a time Colin Lieberman shaped the electrons to say... > Certainly that's reasonable. Yes, you are absolutely right insofar as FF > goes, although I'm not 100% convinced that authors should be left in the > driver's seat; this may be something best left 100% in the hands of UA. The UA c

[whatwg] , Flash, & IE7

Once upon a time Spartanicus shaped the electrons to say... > When encountering an object element IE7 seems to block all embedding by > default and it issues "security warnings" [1] . Afaics that virtually > drives the final nail in the coffin [2]. I haven't seen this myself. Admittedly, I use F

Re: [whatwg] element feedback

Once upon a time Spartanicus shaped the electrons to say... > But if I'm wrong and this fight hasn't yet been lost, I'd like to add my > voice to not relying on JS for anything essential at least from a > specification angle. Strongly agreed. I know more than a few people who are (still) rabidly

Re: [whatwg] Web Forsm 2.0 possible omissions

Re: That's a UI issue really / and pattern="" I think that is my point exactly - are you suggesting that some UAs might decide to use the pattern=in the key filter? that makes sense I guess... Re: case is poor clearly that's a poor case, it was a simplistic example that's all - here's some more

Re: [whatwg] Web Forsm 2.0 possible omissions

On Wed, 21 Mar 2007 21:58:34 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: RE; See the inputmode="" attribute in the current draft. I'm familiar with it from XForms but unless if totally missed a trick it is oriented towards languages and modes (such as lowerCase) rather than filteri

Re: [whatwg] Web Forsm 2.0 possible omissions

On Wed, 21 Mar 2007 21:58:34 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: RE; See the inputmode="" attribute in the current draft. I'm familiar with it from XForms but unless if totally missed a trick it is oriented towards languages and modes (such as lowerCase) rather than filteri

Re: [whatwg] Web Forsm 2.0 possible omissions

RE; See the inputmode="" attribute in the current draft. I'm familiar with it from XForms but unless if totally missed a trick it is oriented towards languages and modes (such as lowerCase) rather than filtering/refusing certain keys - I will dig back in incase I missed something in Xforms...

Re: [whatwg] Full screen for the element

On Wed, 21 Mar 2007 19:30:13 -, Simon Pieters <[EMAIL PROTECTED]> wrote: Shouldn't the video API include a way to toggle full screen on/off? Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen should only be under the control of the user, o

Re: [whatwg] element feedback

Are we speaking MIME type or tag here? Looking at the list of issued MIME types, it seems pdf and ogg can fall under this category. Under these conditions, I would imagine that would be a download, where the author wants you to get the content, as opposed to stream it or view it in-place.

Re: [whatwg] Full screen for the element

On 3/21/07, Simon Pieters <[EMAIL PROTECTED]> wrote: On Wed, 21 Mar 2007 20:11:57 +0100, Mihai Sucan <[EMAIL PROTECTED]> wrote: > Shouldn't the video API include a way to toggle full screen on/off? Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen

Re: [whatwg] element feedback

Sander Tekelenburg wrote: Something else concerning first-class Netizenry: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: http://domain.example/movie.ogg#21:08>, to mean "fetch the movie and start playing it at 21 minutes 8 second

Re: [whatwg] element feedback

On Wed, 21 Mar 2007 18:31:29 -, Nicholas Shanks <[EMAIL PROTECTED]> wrote: Well besides the fact that fragment ids cannot start with a number nor contain a colon I've checked syntax for fragment identifiers in URIs (RFC 2396) and haven't found such limitation. If such fragments cannot

Re: [whatwg] element feedback

Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. image/* video/* application/* audio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for e

Re: [whatwg] Web Forsm 2.0 possible omissions

[EMAIL PROTECTED] wrote: 2) Auto tabbing for a 4 digit code: A more general request would be an ability to display one value but have a different one behind the scenes. Obviously when the user edits it they would expose the internal value, much like in an spreadsheet when you switch a fie

Re: [whatwg] Full screen for the element

On Wed, 21 Mar 2007 20:11:57 +0100, Mihai Sucan <[EMAIL PROTECTED]> wrote: Shouldn't the video API include a way to toggle full screen on/off? Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen should only be under the control of the user, oth

[whatwg] Full screen for the element

Hello! Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. I'd suggest adding a new property to the HTMLVideo

Re: [whatwg] element feedback

On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote: Something else concerning first-class Netizenry: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: http://domain.example/movie.ogg#21:08>, to mean "fetch the movie and start pl

Re: [whatwg] Web Forsm 2.0 possible omissions

On Wed, 21 Mar 2007 13:03:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 1) Input filtering (i.e. allow only numbers to be typed) suggested implementation (like pattern takes a regexp but behaves as if inside: ^ [ ]$ See the inputmode="" attribute in the current draft. 2) Auto

Re: [whatwg] WF2: Non-validating submit buttons

2007/3/21, Christian Schmidt: Martin Atkins skrev: > It would be useful to be able to mark certain submit buttons as > non-validating. > > [...] > > > > I'm not fussed about the exact name/usage of the attribute, but it seems > like a common enough case to warrant a declarative solution rath

Re: [whatwg] WF2: Non-validating submit buttons

Martin Atkins skrev: It would be useful to be able to mark certain submit buttons as non-validating. [...] I'm not fussed about the exact name/usage of the attribute, but it seems like a common enough case to warrant a declarative solution rather than a script one. How would this be

Re: [whatwg] Drop tabindex=""

Gervase Markham wrote: Before doing that, it might make sense to consult the accessibility teams of the UA vendors. In Mozilla's case, that's Aaron Leventhal. I believe that there have been recent changes to this property to better allow keyboard accessibility of DHTML widgets: http://develope

Re: [whatwg] Drop tabindex=""

Colin Lieberman wrote: Drop tabindex altogether. It's just not useful. Before doing that, it might make sense to consult the accessibility teams of the UA vendors. In Mozilla's case, that's Aaron Leventhal. I believe that there have been recent changes to this property to better allow keyboa

Re: [whatwg] Drop tabindex=""

Drop tabindex altogether. It's just not useful. See the Web Accessibility Initiative Interest Group discussion on the subject: http://www.w3.org/Search/Mail/Public/search?type-index=w3c-wai-ig&index-type=t&keywords=tabindex&search=Search Tabindex is not a substitute for poorly organized docum

Re: [whatwg] element feedback

Sander Tekelenburg <[EMAIL PROTECTED]> wrote: >IMO this is no different than CSS being icing on the cake. It's nice to allow >authors to suggest UI-styling and even add functionaility, but it's a mistake >to make basic functinality (start, stop, pause, (fast)forward, etc.) >author-dependant. Rece

Re: [whatwg] element feedback

At 23:02 +0100 UTC, on 2007-03-20, Håkon Wium Lie wrote: > Also sprach Martin Atkins: > > > If video is going to be considered a first-class citizen, I argue that > > this needs to be possible for video as well: > > ... > > Right. I think I agree with you. Perhaps we can encourage implemen

Re: [whatwg] element feedback

David "liorean" Andersson: On 21/03/07, Robert Brodrecht <[EMAIL PROTECTED]> wrote: Christoph Päper said: > > > > > I was somewhat concerned with the script-only controls. Chris Adams: | | | "Shadow2531": | | | play Of these ideas Chris Adams', to wh

Re: [whatwg] element feedback

At 09:25 + UTC, on 2007-03-20, Ian Hickson wrote: [...] > ON NATIVE UI: > > [...] I completely agree that on the long term this is something we need to > offer. However, we musn't bite off more than we can chew. There are > several sets of use cases, some of which require browser-provided UI,

Re: [whatwg] element feedback

Ian Hickson <[EMAIL PROTECTED]> wrote: >> However, I think if is so widely derided by everyone, than I >> think it needs to be depreciated sooner rather than later. > >I have seriously considered doing this. Unfortunately I don't think we can >actually do it given the large amount of legacy con

[whatwg] Web Forsm 2.0 possible omissions

I've noticed two possible ommissions that seem to me to be essential to a useful Web Forms spec: 1) Input filtering (i.e. allow only numbers to be typed) suggested implementation (like pattern takes a regexp but behaves as if inside: ^ [ ]$ 2) Auto tabbing for a 4 digit code: Regards Chris

Re: [whatwg] fallback behaviour (was: Re: element feedback)

On 3/20/07, Robert Brodrecht <[EMAIL PROTECTED]> wrote: Simon Pieters said: > Oh. I thought fallback would work pretty much like > fallback, but I see that's not the case. When I think about it it makes > sense; is pretty much like , it never falls back in UAs > that support it. Oh, damn

Re: [whatwg] element feedback

The element did what it said on the box, and that was to provide browser vendors and plugin developers with the freedom to innovate with the plugin APIs, media types, object models and the parameters passed to them. It was a significant improvement on the element in offering progressive fallb

Re: [whatwg] element feedback

On 3/20/07, Ian Hickson <[EMAIL PROTECTED]> wrote: On Wed, 21 Mar 2007, Lachlan Hunt wrote: > > > > I only included togglePause() because Flash supports it and some > > people asked for it; I'm not convinced we should keep it. > > I'm in favour of dropping it. It's an unnecessary API for browser

Re: [whatwg] comments section 1

On 21/03/2007 05:09, Lachlan Hunt wrote: That's fine for other markup languages, but we're discussing (X)HTML. So I guess I don't really understand the relevance of your initial comment. Is there something you want the spec to say about the issue? No. That was a general comment. Since the W3

Re: [whatwg] element feedback

On 3/20/07, Christoph Päper <[EMAIL PROTECTED]> wrote: Maybe it is a stupid idea, but is something like the following imaginable to make a XHTML5 browser display inline video with a basic UI without the need for scripting? I thought about this myself. My thought looked lik

Re: [whatwg] Resurrection of HTML+'s

On Wed, 21 Mar 2007 10:55:37 +0100, Nicholas Shanks <[EMAIL PROTECTED]> wrote: I would hardly call allowing marked-up fallback rather than the crappy "alt text" we currently have as 'almost zero benefit'. How about we bring accessibility into the 21st century instead? You hardly ever went to s

Re: [whatwg] require img dimensions to be correct?

On 21 Mar 2007, at 09:37, Henri Sivonen wrote: OTOH, the left/right alignment of table cells *is* often tightly coupled with the cell data, which suggests that the cell alignment attributes should not be dropped. Alternatively it could just be allowed on the and , where it would affect

Re: [whatwg] require img dimensions to be correct?

On Mar 3, 2007, at 21:58, Ian Hickson wrote: The question isn't whether or not you should have the ability to scale images; it's clear that this is desirable. The question is whether it makes sense to put this in HTML as opposed to CSS. Why would HTML be the place to put this? Because the d

Re: [whatwg] element feedback

This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. image/* video/* application/* audio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for e

Re: [whatwg] element feedback

Also sprach Laurens Holst: > > is *very badly* implemented. It has been a decade since > > was first created and browsers STILL don't do it right in all cases (or > > even in most cases, frankly). Adding more complexity to such a disaster > > zone is bad design. > > If the existing pro

Re: [whatwg] require img dimensions to be correct?

2007/3/21, Nicholas Shanks: On 17 Mar 2007, at 23:28, Andrew Fedoniouk wrote: > I think that in most cases will be better if we could package > complex pages into zip envelopes and deliver them in the whole. > That would be real solution of "jumps". And height=...> is a palliative. I have an