Re: [whatwg] Drop tabindex=
Dropping tabindex /might/ make sense if HTML5 was to be so feature complete that no-one would ever build a DHTML widget out of generic elements ever again. Is this likely to be the case? Because, if not, tabindex looks like part of a solution: http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets Of course, we might want to try to improve on tabindex and fix the scoping problem. Perhaps: div id=foobar div tabgroup=foobar taborder=2/ div tabgroup=foobar taborder=1/ /div -- Benjamin Hawkes-Lewis
Re: [whatwg] Drop tabindex=
On Wed, 21 Mar 2007 04:16:41 +0100, Simon Pieters [EMAIL PROTECTED] wrote: 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. That holds true for Opera on desktop. Keep in mind that there are devices without useful 4-way navigation, such as the Sony Ericsson M600i, where your only means of (keyboard) navigation is through the scroll wheel on the side of the device. -- Arve Bersvendsen, Web Applications Developer Opera Software ASA, http://www.opera.com/
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 img width=... height=... is a palliative. I have an open bug with Safari requesting support for the multipart/ mixed Content-Type. This would provide the ziped content you request (and you can use a Transfer-Encoding to compress it before sending) In this particular case, multipart/related would be more appropriate. See http://fr.wikipedia.org/wiki/MHTML If you talked about serving the images in a multipart/* envelope, multipart/alternate is more appropriate than multipart/mixed. But, hey, RFC2046 states (§5.1.3) that « Any multipart subtypes that an implementation does not recognize must be treated as being of subtype mixed », so in terms of client implementations, supporting multipart/mixed might be enough. -- Thomas Broyer
Re: [whatwg] video element feedback
Also sprach Laurens Holst: object is *very badly* implemented. It has been a decade since object 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 problems with object are so severe that it can
Re: [whatwg] video element feedback
This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. image image/* video video/* application application/* audio audio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. Gaz On 20 Mar 2007, at 23:42, Nicholas Shanks wrote: On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote: Ian Hickson wrote: However, I think if object 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 content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). So again, I ask for an image element to replace img. Benefits include: • As video would cater for video/* MIME types, image would cater for image/* • The alt and longdesc attributes can be part of the fallback content, allowing markup. • You don't have to provide a type attribute and match on: object [type^=image/] • and more… - Nicholas.
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 col and colspan, where it would affect td cells (but not th cells). Just a random thought. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video 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? form method=MEDIA video src=pretty.ogg/ button type=play/ /form I thought about this myself. My thought looked like this: form action=video: target=video element id input type=button name=play /form However, my thought would abuse a possible video: protocol and make input or button or forms in general even more complicated. I don't think implementors would be interested in hacking up forms this way, but I could be wrong. -- burnout426
Re: [whatwg] video fallback behaviour (was: Re: video element feedback)
On 3/20/07, Robert Brodrecht [EMAIL PROTECTED] wrote: Simon Pieters said: Oh. I thought video fallback would work pretty much like object fallback, but I see that's not the case. When I think about it it makes sense; video is pretty much like iframe, it never falls back in UAs that support it. Oh, damn it. I thought it'd work like object, too. I'm not sure I like the only-fallback-if-no-support idea. I'm getting the feeling that there won't be one common video format among the browsers. I think not having fallback to nested video elements to get at other formats would ultimately be a bad thing. It is different than expected, but I can now see why video would want to avoid these things. If you load an applet, with the object element, it'll never fallback (even if the class file can't be found) unless java is turned off or not supported. If you load object type=application/x-mplayer2, in some browsers, it might never fallback unless plugins are off or the plugin is not installed (same with REAL and other plugins). In other browsers, it might fall back because there's no data attribute. However, there are use cases where data is not needed or not even wanted and it shouldn't fall back because of this missing data. The object element only really falls back like we want it to half the time. Usually, it only works right with native stuff. However, with the video element, we have the chance to described exactly when fallback should happen in every case. Right now, as was said, it works more like an iframe. -- burnout426
[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: ^ [ ]$ input type=text filter=\d 2) Auto tabbing for a 4 digit code: input type=text filter=\d autotab=4/ Regards Christian
Re: [whatwg] video element feedback
Ian Hickson [EMAIL PROTECTED] wrote: However, I think if object 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 content, e.g. tutorials for how to embed flash which encourage use of object. 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 object coffin [2]. That makes tutorials that haven't taken this into account outdated, and since UAs are not going to drop their existing support for the element I don't see why this should be an issue with regard to deprecation. [1] IE7 Information bar displayed when it encounters an object element (embedding a PNG image): To help protect your security, Internet Explorer has restricted this webpage from running scripts or ActiveX controls that could access your computer. Click here for more options. A further Security Warning dialog is produced if a user were to consider allowing it: ! Allowing active content such as script and ActiveX controls can be useful, but active content might also harm your computer. Are you sure you want to let this file run active content? Yes / No [2] Virtually since there are some cases where by using conditional comments authors can still use the advantages of the object element whilst feeding IE an img element instead. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
Re: [whatwg] video 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, and some of which need just video playback under the control of the author. I thought the idea of the Web was that the user is always in control (because the author cannot know the user's browsing environment). Why would authors ever have to be in control? [...] If JS is turned off, applications won't work. :-) Just like when you turn JS off and try to use Google Calendar, or turn off Flash and try to use YouTube. If video is to be a first-class Netizen, it'd better not be javascript-dependant. Currently Flash and QT plug-ins handle embedded video just fine without JS (unless when misguided authors purposely made it javascript-dependant). If video is specced to be javascript-dependant, you make it too difficult for both users and authors. I'd have to vote against that. Simply video src=URL should suffice. (I'm all for allowing more sophisicated things through javascript, just not for *dependancy*.) 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: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. (Or better yet, if this can be achieved reliably, don't fetch the entire movie, but only from 21:08 on.) Without this/currently, video consumption just costs too much time. It's usually much more practical to deal with text, because users can imediately go to the part they're interested in. With video (and audio) you are forced to watch the whole thing to find out if there is anything interesting. It seems to me that's one of the main reasons video is very much a second-class Netizen today. Note that such an implicit anchor mechanism would in a sense make video even better than text, because this wouldn't require authors to bother to provide anchors. The less work for authors, the better the chance at first-class Netizenry. (Btw, the same mechanism could be used to, through cookies, or even through a cache-like local mechanism (and thus again not author-dependant), allow UAs to provide a bookmarkish function for a start playing from where I left last time feature.) [...] I agree that video needs a standard UI (in v2, at least). It needs it right from the start, in v1.0. Without it, it would be like a browser without its own back button, relying on authors to provide such functionality. 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. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video 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: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? Agreed. On the right-click menu or somewhere where it doesn't take up space? Implementation should be left up to the browser author, but it would probably be useful if the spec lists some suggestions. Both to help browser authors understand what the spec means, and to help content authors realise that how their favourite browser behaves may not be how some other browser behaves. I agree it would probably be important to state that the UI must not take up extra space. (An author-provided UI however should be allowed to take up author-defined space.) Btw, please let's not have the spec say right-click, when contextual menu is meant. How to bring up a contextual menu is entirely environment-dependant: my mouse has no right button at all, but I use contextual menus all the time. Also, my preferred OS offers a native Action button/menu (typically in a toolbar) to contextually provide access to actions. Another possible UI would be straight from the keyboard, as is already the case with the QT plug-in for example. The mouse hover-based UI of QT and VLC that has been mentioned is probably another good example (although requiring users to hover over the video will mean many won't ever discover this functonality, just like the contextual menu -- I imagine this is what Apple's Action button aims to solve). -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
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 keyboard accessibility of DHTML widgets: http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets Gerv
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://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets Gerv 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. Colin
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.
[...]
input type=submit validate=no /
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 achieved using script?
One way is to use a button with the following onclick handler:
for (var i = 0; i form.elements.length; i++) {
var element = form.elements[i];
if (!element.validity.valid) {
element.type = 'text';
element.required = false;
element.maxLength = -1;
element.setCustomValidity(null);
}
}
form.submit();
Is there a more elegant solution?
Christian
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.
[...]
input type=submit validate=no /
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 achieved using script?
One way is to use a button with the following onclick handler:
for (var i = 0; i form.elements.length; i++) {
var element = form.elements[i];
if (!element.validity.valid) {
element.type = 'text';
element.required = false;
element.maxLength = -1;
element.setCustomValidity(null);
}
}
form.submit();
Is there a more elegant solution?
Attach a handler for the 'invalid' event on the form to cancel them
all and call setCustomValidity(null) on the event.target? (eventually
using a second form, specific to the non-validating submit buttons so
that you don't have to attach/detach the handler depending on the
clicked button; or maybe you could just, in the 'click' event of the
submit button, attach the 'invalid' event handler, call form.submit()
and then detach the handler?)
form action=... id=validating/form
form action=... id=non-validating/form
...
input type=submit form=non-validating
...
script type=text/javascript
document.getElementById(non-validating).addEventListener('invalid',
function(e) {
e.preventDefault();
e.stopPropagation();
e.target.setCustomValidity('');
}, false);
/script
— or —
form action=...
...
input type=submit id=non-validating
...
script type=text/javascript
function cancel_invalid(e) {
e.preventDefault();
e.stopPropagation();
e.target.setCustomValidity('');
}
document.getElementById(non-validating).addEventListener('click',
function(e) {
e.form.addEventListener('invalid', cancel_invalid, false);
e.form.submit();
e.form.removeEventListener('invalid', cancel_invalid, false);
e.preventDefault();
}, false);
/script
Just ideas, I don't know if this would work at all...
--
Thomas Broyer
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: ^ [ ]$ input type=text filter=\d See the inputmode= attribute in the current draft. 2) Auto tabbing for a 4 digit code: input type=text filter=\d autotab=4/ This can be easily achieved with a simple script but I wonder if it's desirable. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video 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: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. (Or better yet, if this can be achieved reliably, don't fetch the entire movie, but only from 21:08 on.) Well besides the fact that fragment ids cannot start with a number nor contain a colon, you have to consider the problem of multiple unequal representations. In this example equivalent content is not at the same time offset. Clicking the link should take you to the relevant place whether the UA is rendering the video, the audio or the transcript: pYou a href=#gegenscheinsee the gegenschein/a if you really squint./p video src=video-with-visual-splash.mpeg fragment-position for=#splash time=00:00 / fragment-position for=#gegenschein time=02:13 / audio src=audio-with-spoken-splash.aiff fragment-position for=#splash time=00:00 / fragment-position for=#gegenschein time=02:24 / !-- transcript fallback -- section id=splashpProduced by Foo Corporation/p/section … section id=gegenschein … /audio /video - Nicholas. smime.p7s Description: S/MIME cryptographic signature
[whatwg] Full screen for the video 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 HTMLVideoElement interface: the .fullscreen boolean. This should be used to toggle full screen video rendering. The way this works should be left at the discretion of the UA: it can be real full screen, or only full screen within the viewport. The UA must be required to provide a way to exit the full screen mode. (pardon me if this was already discussed on the mailing list) -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Web Forsm 2.0 possible omissions
[EMAIL PROTECTED] wrote: 2) Auto tabbing for a 4 digit code: input type=text filter=\d autotab=4/ 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 field containing a formula from view mode to edit mode.
Re: [whatwg] video element feedback
Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. imageimage/* videovideo/* application application/* audioaudio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. What do you imagine application being used for? The application type category is pretty-much just miscellaneous.
Re: [whatwg] video 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 match any current HTML IDs, that's even better. you have to consider the problem of multiple unequal representations. In this example equivalent content is not at the same time offset. Clicking the link should take you to the relevant place whether the UA is rendering the video, the audio or the transcript: 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. -- regards, Kornel Lesiński
Re: [whatwg] video 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 application would be a download, where the author wants you to get the content, as opposed to stream it or view it in-place. On 21 Mar 2007, at 19:50, Martin Atkins wrote: Gareth Hay wrote: This is a bit of a sideways step here, but why not make tags reflect MIME type, e.g. imageimage/* videovideo/* application application/* audioaudio/* That way we have a clear identification of what is going to be in the tag, API's can be tailored sufficiently for each one. Each tag can have appropriate fallback also. Just a thought, and it gets us out of the object hole. What do you imagine application being used for? The application type category is pretty-much just miscellaneous.
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: This can be easily achieved with a simple script but I wonder if it's desirable. but the point of webforsm is to avoid scripts where possible (so it works for high security peeps as well as accessibility peeps...), isn't it? as for desireable - well if WEb forms is part of the WEB API initiative and both legacy applications (unix/dos based), contemporary applications (key code fields in installation dialogs) and future apps (my next project!! ;-)) I suspect it is both useful and desireable (if you've ever been a data inputter you'll know what i mean. If you are uncomfortable with 'autotabbing' then a trimmed down version might be making a field with readonly elements e.g. 01/02/1945 as __/__/___ Still autotabbing is a feature I have been asked to deliver about once ever six months for the last 10 years (and using script have done so) I just want to make it work for my banking friends who have scripts turned off and who are ALWAYS using legacy style apps so get frustrated when clunk web apps don't provide the facility (especially when hitting the right arrow on a form element doesn' jump you to the next element. My feelings is that it is both desireable and useful (and I'd like to see improved keyboard accessibility (such as arrow keys too) but this is probably not the place for that rant!... Christian On Wed Mar 21 10:52 , Anne van Kesteren sent: 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 tabbing for a 4 digit code: This can be easily achieved with a simple script but I wonder if it's desirable. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
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 filtering/refusing certain keys - I will dig back in incase I missed something in Xforms... That's a UI issue really. Re: This can be easily achieved with a simple script but I wonder if it's desirable. but the point of webforsm is to avoid scripts where possible (so it works for high security peeps as well as accessibility peeps...), isn't it? as for desireable - well if WEb forms is part of the WEB API initiative and both legacy applications (unix/dos based), contemporary applications (key code fields in installation dialogs) and future apps (my next project!! ;-)) I suspect it is both useful and desireable (if you've ever been a data inputter you'll know what i mean. If you are uncomfortable with 'autotabbing' then a trimmed down version might be making a field with readonly elements e.g. 01/02/1945 as __/__/___ Still autotabbing is a feature I have been asked to deliver about once ever six months for the last 10 years (and using script have done so) I just want to make it work for my banking friends who have scripts turned off and who are ALWAYS using legacy style apps so get frustrated when clunk web apps don't provide the facility (especially when hitting the right arrow on a form element doesn' jump you to the next element. Well, for dates for instance there's a native input type. So that isn't really a good use case. My feelings is that it is both desireable and useful (and I'd like to see improved keyboard accessibility (such as arrow keys too) but this is probably not the place for that rant!... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] video 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 anti-JavaScript as end-users, because of the repeated security issues in various implementations - and how it keeps popping up in things like Quicktime where you wouldn't necessarily expect it. I am all for using JavaScript to improve a site, and I understand that there are some online applications that just don't work without it, but I'm against throwing in the towel and making ever more content, and pages, depend on JavaScript. -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
[whatwg] object, 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 object coffin [2]. I haven't seen this myself. Admittedly, I use Firefox for all my browsing, but I do have IE7 and I use it for testing pages. Some of our sites at work have Flash, and object is used. For example, from http://www.cyphermint.com/ object type=application/x-shockwave-flash data=main_assets/main_banner.swf width=576 height=389 id=top_banner param name=movie value=main_assets/main_banner.swf / param name=quality value=high / param name=wmode value=transparent / /object I've never seen a warning for Flash embedded like this. -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
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 could always offer the ability to override/disable tabindex in documents - as they can offer user stylesheets, etc. People who dislike the tabindex could disable it, and those who prefer to use the pages as the author index them can do the so. -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
Re: [whatwg] object, 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 object coffin [2]. I haven't seen this myself. Admittedly, I use Firefox for all my browsing, but I do have IE7 and I use it for testing pages. Some of our sites at work have Flash, and object is used. Oops, you're right. It appears that the warnings do not happen for IE's so-called Internet zone. IE's default restrictions appear to be most strict when loading a file from the local file system, more relaxed when loading from a domain that falls under IE's Local intranet group, and most relaxed for domains in its Internet group. I was expecting the opposite and had tested by loading a file from my local file system. -- Spartanicus (email whitelist in use, non list-server mail will not be seen)
[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 different from ordinary HTML nowadays, most people don't even give all header-level elements unique ids, let alone individual paragraphs. But that doesn't mean the facility shouldn't be made available to those who want/need it. It is possible to implement it using JavaScript - you can read location.hash and seek() video appropriately. This however is a little help to users who want to bookmark videos or share links to certain parts of them - without a standard way of doing it UA's won't be able to provide UI for it. Even if you implement that for yourself using UserJS, you won't be able to share those links, etc. -- regards, Kornel Lesiński
[whatwg] Apple Proposal for Timed Media Elements
Hello WHAT Working Group, With the recent discussions about the video 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 technologies. A number of Apple Engineers will follow and participate in further video discussions, including myself and my colleague Dave Singer, who has represented Apple in a number of media-related standards groups. We started work on these documents before the video element was added to the spec and indeed before Opera made their original proposal. But in the interests of getting them out quickly, we decided to publish what we have, rather than revising the documents to be relative to the current spec. This document is still a work in progress, and I hope together we can refine it and fold it into the Web Apps 1.0 spec. There are a few areas of difference worth highlighting: - Our proposal includes a CSS module, which we will eventually submit to the CSS Working Group. We believe that many aspects of controlling timed media are presentational, and so are best represented in CSS. Although Web Apps 1.0 is not the final destination for this document, we think it makes more sense to consider the whole design at once. - We have included a more thorough set of events and properties which we think are needed to build good custom controller UI. In general, we would like to enable not just current web use cases but also somewhat more advanced uses. - We have included an audio element as well as video. - We have included a mechanism for static fallback based on container type and codec, so that it's possible to choose the best video format for a client even if user agent codec support varies. We will be starting separate threads on these and other key issues. We've posted our current proposals here: 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 We also have a list of areas where we think the proposal could use refinement or additional features, but where we do not yet have a final design to present: http://webkit.org/specs/Timed_Media_Elements-Open_Issues.html Regards, Maciej Stachowiak
[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 the context of dynamic changes. In addition, I'm not convinced there is much in the way of multi-codec data on the Web that would be addressed by this. ON FALLBACK I think the lack of multi-codec data is in part because it's not easy to automatically present the right video stream out of several streams using object. It's hard enough to write the object markup to work in all browsers with a single codec! But I think that having a good mechanism to do this is important. Here are some reasons: - Even if all browsers end up supporting Ogg Theora/Vorbis, these are not the best-compression codecs available. So a large-scale video content provider that wants to save on bandwidth may wish to provide H.264/AAC content to those browsers that can handle it, even if all browsers could handle a lower-quality codec as well. - Many mobile devices cannot practically implement decoding in software, and rely on custom hardware which can handle only a fixed set of codecs. While hardware decoders for H.264 are widely available, I don't think there are any for Ogg Theora. Even in cases where the CPU in theory has the power to do some software decoding, this will be a much bigger battery drain than hardware decoding. So you really want the ability to serve the right codec to such devices. So while your average blogger may only upload media content in one codec, larger scale video service providers may want to take advantage of codec-based selection. I think the fallback mechanism specified avoids some of the pitfalls of other fallback mechanisms: A) It is specified to take the declared type as authoritative for fallback purposes, so dynamic fallback and its attendant complexities do not have to get involved. B) It lets you select based on codec and even codec profile, not just container format. C) The video syntax itself is simple enough that it won't reduce to an incomprehensible jumble like it sometimes does with object. However, it's true that in general you may also want to consider issues such as screen size and data rate when choosing from several available video options. QuickTime has a concept of selector movies than can choose to download one of several separate resources based on such criteria, but it makes more sense to do it in markup or CSS. We discussed the possibility of using CSS media queries to account for screen size and data rate. However, this has a couple of issues: - You probably still want a mechanism for codec-based selection. Exposing available codecs to media queries seems like it will be very complex, comparing to declaring what codecs you use and letting the UA decide. - To emulate fallback with CSS media queries, you need to make sure your queries are mutually exclusive, which generally means query 2 has to include not query1 and..., query 3 has to negate both queries 1 and 2, and so forth. This seems more complex to author than a fallback model. All that being said, we are not entirely sure what the best approach is for screen size and data rate fallback, but type seems like a good model for format-based fallback. ON RECOMMENDED OR MANDATED CODECS We think it is a mistake to require Ogg support, even as a SHOULD- level requirement, for several reasons. - 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. - 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. Often, parties holding a submarine patent wait for a company with very deep pockets (like Apple, or Microsoft, or Google) to infringe on the patent before they sue. On the other hand, MPEG codecs have been implemented by many large corporations already, and no patents have appeared besides the ones that can be licensed from MPEG-LA for a fee. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. We are very sympathetic to the desire for interoperability, and we would really like there to be a codec that every browser can feel comfortable implementing. But we are not sure such a codec exists at this time (except for really primitive things, if you want to count animated
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 playing or the available frames per second encoded in the video? No, it is a multiple of the file's intrinsic (or natural) rate. Frames per second loses meaning quickly with digital media files, where individual frames can have arbitrary duration (true even for animated GIF files). The DOM attribute hasAudio returns a value that specifies whether the element has audio media. Does a video element hasAudio return true or false? Is this based only on the existence of some media or will it determine if the video actually has an audio track? It is based on the presence of absence of an audio track, so a video element may or may not return true. eric
[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 wants to target those devices with a better codec, they can do so, and use Theora as the fallback. If they don't care, they use Theora and at least the content is still playable on the devices. What's the problem here? It's still a net win over the no-standard-codec alternative. - 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. Often, parties holding a submarine patent wait for a company with very deep pockets (like Apple, or Microsoft, or Google) to infringe on the patent before they sue. On the other hand, MPEG codecs have been implemented by many large corporations already, and no patents have appeared besides the ones that can be licensed from MPEG-LA for a fee. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. Just because no patents have appeared against MPEG doesn't mean there aren't any outside the MPEG-LA pool. Submarines can surface at any time. See Forgent. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. Just because previous HTML specifications have been deficient in this regard doesn't mean we have to repeat the mistake. I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
[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 Web: http://groups.msn.com/whatwg-legal/homepage Internet Email Address: [EMAIL PROTECTED] People with legal concerns should send their messages there, while the WHATWG in general focuses on technical matters. thanks for understanding, Robert Sayre
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 assume Theora is a bad format for some devices. If someone wants to target those devices with a better codec, they can do so, and use Theora as the fallback. If they don't care, they use Theora and at least the content is still playable on the devices. What's the problem here? It's still a net win over the no-standard- codec alternative. 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. Others would simply burn battery at an unacceptable rate while doing software video decoding. Would these too be justified in omitting Ogg support under the SHOULD clause? If so, then not much interoperability is being gained, ultimately. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. Just because no patents have appeared against MPEG doesn't mean there aren't any outside the MPEG-LA pool. Submarines can surface at any time. See Forgent. While it's hard to have certainty, I am pointing out that the relative risk assessment can look different depending on one's position. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. Just because previous HTML specifications have been deficient in this regard doesn't mean we have to repeat the mistake. I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. I agree that a baseline set of codecs would be good. I'm just not sure it is possible to reach consensus on what that set should be. From Apple's point of view, MPEG is significantly more attractive than Ogg. Regards, Maciej
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 video decoders? That sounds like a possible technical point. While it's hard to have certainty, I am pointing out that the relative risk assessment can look different depending on one's position. Sounds like an interesting discussion for two lawyers. It certainly seems like it would be difficult to speak for all Gecko or WebKit embedders, though. -- Robert Sayre
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 whatwg-legal: Homepage On The World Wide Web: http://groups.msn.com/whatwg-legal/homepage Internet Email Address: [EMAIL PROTECTED] People with legal concerns should send their messages there, while the WHATWG in general focuses on technical matters. Excellent idea ! I suggest formally invite Microsoft there right now... Discussing and solving what they think are legal problems with WHATWG process and specs may help *a lot* the HTML WG. /Daniel
