Re: [whatwg] [html5] r5399 - [giow] (2) Define option.selected; make option disabled selected still get sel [...]
On Mon, 30 Aug 2010 20:22:56 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2010-08-30 11:22:54 -0700 (Mon, 30 Aug 2010) New Revision: 5399 Modified: complete.html index source Log: [giow] (2) Define option.selected; make option disabled selected still get selected. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10106 Modified: source === --- source 2010-08-30 18:07:53 UTC (rev 5398) +++ source 2010-08-30 18:22:54 UTC (rev 5399) @@ -48730,10 +48730,7 @@ pThe dfn title=concept-option-selectednessselectedness/dfn of an codeoption/code element is a boolean state, initially - false. If the element is span - title=concept-option-disableddisabled/span, then the element's - span title=concept-option-selectednessselectedness/span is - always false and cannot be set to true. Except where otherwise + false. Except where otherwise specified, when the element is created, its span title=concept-option-selectednessselectedness/span must be set to true if the element has a code @@ -48754,6 +48751,8 @@ title=concept-option-selectednessselectedness/span state when using the constructor./p + !-- http://software.hixie.ch/utilities/js/live-dom-viewer/saved/604 -- + /div pA codeselect/code element whose code @@ -48784,6 +48783,8 @@ pReturns true if the element is selected, and false otherwise./p +pCan be set, to override the current state of the element./p + /dd dtvar title=option/var . code title=dom-option-indexindex/code/dt @@ -48847,9 +48848,11 @@ to the new value./p pThe dfn title=dom-option-selectedcodeselected/code/dfn - IDL attribute must return true if the element's span + IDL attribute, on getting, must return true if the element's span title=concept-option-selectednessselectedness/span is true, and - false otherwise./p + false otherwise. On setting, it must set the element's span + title=concept-option-selectednessselectedness/span to the new + value./p pThe dfn title=dom-option-indexcodeindex/code/dfn IDL attribute must return the element's span Maybe select requiredoption value selected disabledChoose one... should be allowed? The spec allows select requiredoption valueChoose one...option selectedFoo. Maybe it should require the label option to be selected by default (either implicitly or explicitly) when the select has required? The spec currently doesn't require there to be any select label option if the required attribute is present on select. -- Simon Pieters Opera Software
[whatwg] Video with MIME type application/octet-stream
Quick terminology point: in this e-mail, I use the term sniff to mean examine the first few bytes of a resource, and determine its type heuristically in contrast with assuming that the type of a file is that given by its MIME type (or, heaven forfend, the file extension). On Thu, 20 May 2010, Robert O'Callahan wrote: I just became aware that application/octet-stream is excluded from being a type the user agent knows it cannot render. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render Apparently this was done in response to a bug report: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977 Neither the bug report nor the editor's response give any indication why this change was made. On Thu, 20 May 2010, Simon Pieters wrote: Apparently this was done in response to: http://lists.w3.org/Archives/Public/public-html/2009Jul/0888.html http://html5.org/tools/web-apps-tracker?from=3497to=3498 On Thu, 20 May 2010, Robert O'Callahan wrote: This change means files served with application/octet-stream will make it all the way to the step If the media data can be fetched but is found by inspection to be in an unsupported format ..., so implementations have to add support for binary sniffing for all the types they support. We didn't need this before in Gecko. What was the motivation for adding this implementation requirement? On Thu, 20 May 2010, Robert O'Callahan wrote: Hmm. I guess it doesn't add any implementation requirements beyond what you need to handle the complete absence of a Content-Type (which we currently don't handle, but I suppose we should). So this isn't really a problem. As Simon says, it was added based on a request from Mozilla engineers. :-) On Thu, 20 May 2010, Philip J�genstedt wrote: For the record, Opera implements canPlayType(application/octet-stream) and canPlayType(application/octet-stream; codecs=foo) as per spec (maybe and respectively), but I don't have any strong opinions about it. On Thu, 20 May 2010, Simon Pieters wrote: This bug report was about application/octet-stream *with parameters*, e.g. application/octet-stream; codecs=theora, vorbis. The spec had the requirement about application/octet-stream before that bug report. On Thu, 20 May 2010, Simon Pieters wrote: The spec requires binary sniffing for all the types you support even without the application/octet-stream requirement, since a WebM file labelled as video/ogg should play if both video/webm and video/ogg are supported. Currently that is indeed the case, but only Opera does it. I spoke to various browser vendor engineers about this. Microsoft's position is, as far as I can tell, that there's no point looking at the Content-Type header, so they always sniff the types of the video data once they've decided to try downloading it. I have no idea what algorithms they use, or how they would handle cases like Matroska (which doesn't have a guaranteed finite signature at the start of the file). Safari does crazy things right now that we won't go into; for the purposes of this discussion we'll assume Safari can change. Chrome right now sniffs like IE, modulo some bugs with text/plain that affect (only) the UI, but engineers tell me they're willing to change. Opera does what the spec suggests. That is, if the type isn't supported then it is treated as a signal to give up without waiting for data to sniff; if the type _is_ supported then it isn't trusted, the data is obtained and examined to determine its real type. Mozilla respects the Content-Type religiously, even if it gets data in a type it supports labelled with another type it supports, but engineers tell me they're willing to change. As I see it we have two possible destinations: we can do what the spec says now, which is a somewhat reasonable (IMHO) compromise between religiously following the Content-Type, and being pragmatic about people getting the type wrong sometimes; or we can do what IE9 will do, and just always sniff once we've decided to try looking at the data, always ignoring the Content-Type headers. I think we all know where we're going to end up, but for now I've left the spec as is. On Thu, 20 May 2010, David Singer wrote: Did anyone revise the registration of application/octet-stream to add parameters? On Thu, 20 May 2010, Simon Pieters wrote: No. It's just error handling. On Thu, 20 May 2010, David Singer wrote: It's an error to have a parameter that isn't valid for the mime type, so are you suggesting (a) that you throw away the parameter as it's invalid or (b) since it's an error to supply application/octet-stream as the mime type in the first place, we may as well process its invalid parameter in an attempt to recover? On Thu, 20 May 2010, Simon Pieters wrote: I'm just suggesting that it should be defined what to do when you get application/octet-stream with
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, 30 Aug 2010 19:06:43 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters sim...@opera.com wrote: This change clashes with data-*. How? Are you missing the fact that *two* consecutive hyphens are needed? If a vendor is called data, then data--feature becomes a data-* attribute and is included in .dataset. -- Simon Pieters Opera Software
Re: [whatwg] Cache manifests and cross-origin resources
On Fri, 27 Aug 2010 22:15:17 +0200, Michael Nordman micha...@google.com wrote: Resources from an origin different than the manifest's origin will be cached, but they will never be used to satisfy a a frame navigation. They're only eligible to be loaded as subresources into pages/workers that are associated with the cache containing those resources. Thanks. We currently have a same-origin restriction in place for explicit entries, but will update to match the specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Video with MIME type application/octet-stream
On 31.08.2010 09:36, Ian Hickson wrote: Fromhttp://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.1: Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize. So, as codecs is not defined on application/octet-stream, the parameter simply should be ignored, thus the advice [...]: The MIME type application/octet-stream with no parameters is never a type that the user agent knows it cannot render. User agents must treat that type as equivalent to the lack of any explicit Content-Type metadata when it is used to label a potential media resource. Note: In the absence of a specification to the contrary, the MIME type application/octet-stream when used with parameters, e.g. application/octet-stream;codecs=theora, is a type that the user agent knows it cannot render. is incorrect, because it requires handling application/octet-stream and application/octet-stream;codecs=theora differently. That's not incorrect. The type with no parameters is a special case that corresponds to a common configuration default. The case with parameters is not that case, and represents likely intentional configuration and thus clearly not a video format the UA supports. My point is that it's incorrect to make this distinction, and that it's furthermore misleading to mention the codecs parameter in the context of a type that doesn't define it. It's also not clear whether the note applies to all parameters or just codecs. The normative text you quote doesn't mention any specific parameters. In which case it would be a *bit* clearer if the note used a parameter that doesn't suggest that codecs has any meaning on a/o. Regarding codecs= in particular, it's an implementation reality that user agents that support it are likely to support it regardless of the type, so there's really no point trying to maintain an artificial boundary of which types it has semantics for and which it doesn't. David Singer pointed out in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202#c11 that this is the wrong thing to do. Do you have any evidence that UAs already use codecs on types on which they aren't defined, *and*, if this is the case, they can't be changed anymore? Best regards, Julian
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
I’m not sure, but I think it’s at your end that character encodings get garbled. Ian Hickson: On Tue, 24 Aug 2010, Christoph Päper wrote: - Input two-digit year, transmit four-digit year. Do sites really want to support two-digit years? Not sites, year input widgets! - Input year name or number in a different system (including “AD”/“BC”/“CE”, emperor eras etc.), transmit proleptic Gregorian year number. Non-contemporary dates aren't in the most common 80% of use cases, “2010 AD” is contemporary (although too verbose for most use cases). It’s just about what the user enters and sees, not about what gets to the server. My sole point was that “year” is not always conceptually a 4-digit number for the users, but it should always be when it arrives at the server. This includes the Japanese use case. Are any browsers interested in implementing such a feature? The OS I’m using at home supports 12 kinds of calendars, other popular OSes probably have similar i18n support. Why shouldn’t browsers?
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
Am 31.08.10 03:36, schrieb Ian Hickson: On Tue, 24 Aug 2010, Martin Janecke wrote: Future browser could offer a calendar tool to fill input fields that have a date semantic. While this would be appropriate, it would not be appropriate to offer a calendar tool for other integer data e.g. an input field that asks the user for his monthly income in USD. Why would you want a calendar tool for a year? Actually, I'd be fine with typing a whole -MM-DDThh:mm:ssTZD date/time into an ordinary text input field. But as it seems HTML will have date and time input fields. Taking this into account I'd be confused to experience different behavior for different date fields in the same form, i.e. sometimes being able to use a calendar tool and sometimes not being able to use it. (Just as Andrew Hayward stated: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028097.html) ... I'd also be interested in browser developers' opinion on this? Are you likely to implement a date selection tool in the coming years? Or accept dates dropped from another application? I assume this becomes more and more useful with the growing importance of web applications. My online banking account implements such a feature with JavaScript, so does my webmail account. But the tools are different, as they are made by different people and will be different again on the next website, although doing the same. Then my e-mail box autoresponder configuration uses selects to do the same as the JavaScript calendar tools mentioned above. Having all of these implemented by a common browser's date selection tool would make such standard input elements more accessible (and work with JavaScript turned off).
Re: [whatwg] Video with MIME type application/octet-stream
On 8/31/10 3:36 AM, Ian Hickson wrote: You might say Hey, but aren't you content sniffing then to find the codecs and you'd be right. But in this case we're respecting the MIME type sent by the server - it tells the browser to whatever level of detail it wants (including codecs if needed) what type it is sending. If the server sends 'text/plain' or 'video/x-matroska' I wouldn't expect a browsers to sniff it for Ogg content. The Microsoft guys responded to my suggestion that they might want to implement something like this with what's the benefit of doing that?. One obvious benefit is that videos with the wrong type will not work, and hence videos will be sent with the right type. If the question is what the benefits of that are, one is that the view video in new window context menu option actually works. Another benefit is that you can send someone the link to the video, instead of the embedding page, and it will work. Another is that when you save the video to disk the browser will fix up the extension correctly, if needed. Basically, getting the types right means that use of the video outside the video tag won't be broken. Inside the video tag there's probably no difference. It seems that sniffing is context-sensitive. Yes, but one issue is that we really do want resources to be usable outside the context the page happens to want to put them in. The ship has sailed on img, clearly, and is working on sailing on video, but I feel that the behavior IE and Chrome are implementing here is highly detrimental to the web. Not that they care much. Sadly, the boat has sailed for text/html and XML at this point, but for binary types, and for contexts where text/plain isn't a contender, why bother doing anything but sniff? See above. As long as some contexts are sniffing and some are not, we have a problem. If it were all-sniff (with the same algorithm across the board!) or all-not-sniff, we might be ok. -Boris
Re: [whatwg] Video with MIME type application/octet-stream
Devil's advocate. On Tue, 31 Aug 2010 15:40:18 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 8/31/10 3:36 AM, Ian Hickson wrote: The Microsoft guys responded to my suggestion that they might want to implement something like this with what's the benefit of doing that?. One obvious benefit is that videos with the wrong type will not work, and hence videos will be sent with the right type. If the question is what the benefits of that are, one is that the view video in new window context menu option actually works. If you sniff you can sniff there too. Another benefit is that you can send someone the link to the video, instead of the embedding page, and it will work. If you sniff you can sniff there too. (Unless that user uses a competitor's browser, but that would be an incentive to encourage that user to use the sniffing browser.) Another is that when you save the video to disk the browser will fix up the extension correctly, if needed. If you sniff you can fix it up correctly too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, Aug 31, 2010 at 12:48 AM, Simon Pieters sim...@opera.com wrote: On Mon, 30 Aug 2010 19:06:43 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters sim...@opera.com wrote: This change clashes with data-*. How? Are you missing the fact that *two* consecutive hyphens are needed? If a vendor is called data, then data--feature becomes a data-* attribute and is included in .dataset. Right. So a vendor shouldn't choose data as their prefix. ~TJ
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 31 Aug 2010 16:02:02 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: Right. So a vendor shouldn't choose data as their prefix. I could imagine we get ariaset in the future and maybe others. But it is unlikely to be a big problem since there are so many prefixes to chose from. And experimental attributes should really be avoided and only be around for limited amount of time... -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Video with MIME type application/octet-stream
On 31.08.2010 15:57, Anne van Kesteren wrote: ... Another is that when you save the video to disk the browser will fix up the extension correctly, if needed. If you sniff you can fix it up correctly too. ... Then let's hope that sniffing doesn't recognize Windows binaries. Best regards, Julian
Re: [whatwg] @srcdoc and default @sandbox
On Mon, Aug 30, 2010 at 6:08 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 30, 2010, at 4:11 PM, Tab Atkins Jr. wrote: On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth w...@adambarth.com wrote: On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote: Should @seamless imply @sandbox too, then? I think there lots of use cases for seamless that don't require sandbox. For example, suppose a site wants to show a login form on many pages by only wants to implement the login logic once. It's entirely reasonable to wish to place the login form in a seamless iframe. If we required @sandbox for seamless, that would interfere with the login form working properly with password managers. Precisely; @seamless was *not* designed with the intention of always being used with @sandbox. It's just a nice feature to have for iframes in general. So there's no real connection between @seamless and @sandbox like there is between @srcdoc and @sandbox. @seamless was in fact designed to help @sandbox meet more use cases (in particular ones where embedding untrusted content in a fixed rect is not sufficient). But it can be used without @sandbox, and has some plausible uses along those lines, though they were not the initial use cases considered. LIkewise for @srcdoc. Indeed, many use cases are well-served by using all three in tandem. But @seamless has a general utility that isn't served in any other capacity. That's not the case for @srcdoc. My point being, don't mix up orthogonal features in arbitrary ways. If @srcdoc implies @sandbox, but @seamless does not, someone reviewing for security has to remember exactly which set of similar-sounding attributes cause sandboxing, instead of following the simple rule just look for @sandbox. Things are clearer when security policy is explicit, and not implied by non-security behaviors. As someone who spends the majority of his time doing security assessments and code audits, I disagree. I'd happily accept an easily reducible false positive over a feature that simply fails open with no security whatsoever. My reasoning here is that the vast majority of software doesn't get security reviews, which is why secure defaults are generally far more effective. This is particularly true when you consider that misuse of @seamless or @srcdoc will fail obviously and quickly in nearly all applications. However, a missing @sandbox is just the kind of thing that's very likely to go undetected. Regards, -j
Re: [whatwg] time element feedback
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke whatwg@kaor.in wrote: Besides, time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though.
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, Aug 31, 2010 at 3:48 AM, Simon Pieters sim...@opera.com wrote: If a vendor is called data, then data--feature becomes a data-* attribute and is included in .dataset. I missed the fact that data--foo is actually a valid data attribute. I guess I assumed that the name part couldn't start with a hyphen. data--foo would be accessed via JS as .dataset.Foo rather than .dataset.foo because of a degenerate application of the camel-casing rules, but it's allowed. Anyway, I preferred the initial-underscore convention -- it's easier to spot, and would be more understandable to people who know CSS.
Re: [whatwg] time element feedback
On Tue, 2010-08-31 at 15:40 -0400, Aryeh Gregor wrote: On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke whatwg@kaor.in wrote: Besides, time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though. I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Video with MIME type application/octet-stream
On Tue, Aug 31, 2010 at 3:36 AM, Ian Hickson i...@hixie.ch wrote: The Microsoft guys responded to my suggestion that they might want to implement something like this with what's the benefit of doing that?. It's a tough question, in this context, given that there's no possibilty of script execution or other privilege escalation with the types we're talking about (currently, anyway). If you can't come up with any actual problems with what IE is doing, then why is anything else even being considered? There's a very clear-cut problem with relying on MIME types: MIME types are often wrong and hard for authors to configure, and this is not going to change anytime soon. Sadly, the boat has sailed for text/html and XML at this point, but for binary types, and for contexts where text/plain isn't a contender, why bother doing anything but sniff? If this is your position, why doesn't the spec match it? On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky bzbar...@mit.edu wrote: You can't sniff in a toplevel browser window. Not the same way that people are sniffing in video. It would break the web. How so? For the sake of argument, suppose you sniff only for known binary video/audio types, and fall back to existing behavior if the type isn't one of those (e.g., not video or audio). Do people do things like link to MP3 files with incorrect MIME types and no Content-Disposition, and expect them to download? If so, don't people also link to MP3 files with correct MIME types and expect the same? I don't see how sniffing vs. using MIME type makes a compatibility difference here, since media support in browsers is so new -- surely whatever bad thing happens, sniffing will make it happen more often, at worst. What do Chrome and IE do here?
Re: [whatwg] time element feedback
On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. What do expect the browser to do in this case? Flip it to 12/01/2010 if appropriate, or rephrase it like January 12, 2010 (or December 1, 2010)? The former would make things much worse, because now rather than having to guess whether the *page* is using American or British convention (usually not too hard), you have to guess what convention your *browser* thinks is right (and it might be someone else's computer, a public computer, . . .). If the author wants the latter effect, on the other hand, why don't they just write out the date that way to begin with, since they aren't actually looking for it to vary between viewers?
[whatwg] default audio upload format (was Fwd: The Media Capture API Working Draft)
Does anyone object to form input type=file accept=audio/*;capture=microphone using Speex as a default, as if it were specified accept=audio/x-speex;quality=7;bitrate=16000;capture=microphone or to allowing the requesting of different speex qualities and bitrates using those mime type parameters? Speex at quality=7 is a reasonable open source default audio vocoder. Runner-up alternatives would include audio/ogg, which is a higher bandwidth format appropriate for multiple speakers or polyphonic music; audio/mpeg, a popular but encumbered format; audio/wav, a union of several different sound file formats, some of which are encumbered; etc. -- Forwarded message -- From: James Salsman jsals...@gmail.com Date: Tue, Aug 31, 2010 at 10:08 AM Subject: Re: The Media Capture API Working Draft To: Ilkka Oksanen ilkka.oksa...@nokia.com, Frederick Hirsch frederick.hir...@nokia.com, Robin Berjon ro...@berjon.com Cc: public-device-a...@w3.org public-device-a...@w3.org, Ian Hickson i...@hixie.ch, Tran, Dzung D dzung.d.t...@intel.com On Tue, Aug 31, 2010 at 2:49 AM, Ilkka Oksanen ilkka.oksa...@nokia.com wrote: 31/08/2010 03:43, ext James Salsman kirjoitti: On Mon, Aug 30, 2010 at 6:58 AM, Ilkka Oksanen ilkka.oksa...@nokia.com wrote: After the Media Capture split the HTML Media Capture spec has been released as a Working Draft. I would like now to propose the same for the second specification. That is the Media Capture API http://dev.w3.org/2009/dap/camera/Overview-API.html please let us know if there any changes that you would see implemented before the publification. What is the default audio capture format? Speex? If so, at what bit rate and quality level, and how can those be adjusted? Can you please go ahead and add the format [attribute] with a specific default such as format=audio/x-speex;quality=7;bitrate=16000 so that implementors can have some guidance here? Thank you. There is no defined default value for capture format and I'm hesitant to propose such thing. In a similar situation HTML WG and WHATWG were not able to agree on the default video codec. That would be the likely outcome also in here I think. My understanding is that Speex default value has already been approved in changes to the System Information draft which were promised by today from the new editor of that draft. If I'm mistaken about that, please let me know. If there is any contention on this question, I would ask that the chairs resolve it by polling
Re: [whatwg] Video with MIME type application/octet-stream
On 8/31/10 3:59 PM, Aryeh Gregor wrote: On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarskybzbar...@mit.edu wrote: You can't sniff in a toplevel browser window. Not the same way that people are sniffing invideo. It would break the web. How so? For the sake of argument, suppose you sniff only for known binary video/audio types, and fall back to existing behavior if the type isn't one of those (e.g., not video or audio). Do people do things like link to MP3 files with incorrect MIME types and no Content-Disposition, and expect them to download? The issue would be someone linking to text or HTML or a binary blob that happens to have some bits at the beginning that look like an audio/video types and expecting them to be rendered respectivel as text or HTML or be downloaded. I don't see how sniffing vs. using MIME type makes a compatibility difference here, since media support in browsers is so new -- surely whatever bad thing happens, sniffing will make it happen more often, at worst. The big danger with sniffing, as always, is that the server will think one thing will happen and suddenly the browser will do something totally different. What do Chrome and IE do here? Good question. -Boris
Re: [whatwg] @srcdoc and default @sandbox
On Mon, 30 Aug 2010 23:13:04 +0100, Justin Schuh jsc...@chromium.org wrote: At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Data URLs already provide this. What about existing UAs that implement data: URIs, but not sandbox? -- regards, Kornel
Re: [whatwg] time element feedback
Am 31.08.10 21:40, schrieb Aryeh Gregor: On Tue, Aug 31, 2010 at 5:25 AM, Martin Janeckewhatwg@kaor.in wrote: Besides,time2010/time in a British news article would allow users e.g. in Japan to have these dates displayed as 平22年. That's clearly an advantage over the number 2010 alone. I would say the opposite. If they can read the English news article, they'll necessarily know what 2010 means. But they might not be able to read Japanese. Maybe they're borrowing a Japanese person's computer, for example, or maybe the browser's idea of the user language is otherwise wrong. Also, content that behaves differently based on the browser settings of the viewer is confusing and can cause hard-to-debug problems. Users will think that the author of that British article actually wrote out a Japanese date, and be completely at a loss to explain why. Even if they can actually understand the date, the incongruity will look like a bug. It could be outright misleading if there are two year display formats that look the same but actually have different meaning. A plain year number in Arabic numerals like 2010 could refer to any number of totally different year-numbering conventions, and the only way to tell them apart currently is the page's context. Having the browser change the number to some convention that doesn't match its surroundings makes it impossible to guess the convention. And finally, it just looks weird. I would find it extremely strange to have all dates on pages I'm reading replaced with Hebrew dates, even though I understand those just fine. I wouldn't want that at all, and I find it hard to believe that many actual users do in real life. Basically, any kind of attempt to have browsers localize dates that are actually displayed in content is a terrible idea, and the spec should remove all mention of any such thing. I'm pretty sure I've said all this before, though. I understand your point, the situation you describe would be unfavorable indeed. However, there's no need to make this unfavorable. The localized display of times and dates can be realized via tooltips for example, as it is often seen with abbreviations in texts. The localized date doesn't have to be a replacement for the original date string but can be a helpful, explaining addition. Furthermore, browsers should not force a localized version upon their users. Users should be able to configure their prefered format, just as they can set a preferred language or a default charset.
Re: [whatwg] time element feedback
On Tue, 2010-08-31 at 16:09 -0400, Aryeh Gregor wrote: On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think localisation does have a valid use though. Consider a page written in English with the date 01/12/2010. Is that date the 1st December, or the 12th January? The only clue might be the spelling of certain words in the document, but even then, the most popular office software in use at the moment defaults to American spelling for its spell-check feature, even if bought in England, which leads to words being spelt wrong and giving the reader no good clue as to what the date might be. Localisation in this case would mean that I could read the document and easily figure out what the date was. What do expect the browser to do in this case? Flip it to 12/01/2010 if appropriate, or rephrase it like January 12, 2010 (or December 1, 2010)? The former would make things much worse, because now rather than having to guess whether the *page* is using American or British convention (usually not too hard), you have to guess what convention your *browser* thinks is right (and it might be someone else's computer, a public computer, . . .). If the author wants the latter effect, on the other hand, why don't they just write out the date that way to begin with, since they aren't actually looking for it to vary between viewers? Because as I mentioned, content authors tend to be quite lazy, and leave default settings on. So lots of English people end up using American spelling, and American date formatting, because that's what their software does by default. I could find you 10 people who didn't know how to change this setting in MSWord for every one you found who did. However, I think readers should be given the choice still with this. If the content authors don't want their precious dates to be read as dates, then don't mark them up as such. A date should be something that can be understood by a variety of media, including search engines, screen readers, even as part of a web snippet that seems to be a popular thing at the moment. If it's in an ambiguous format then there's no point it even being marked up as a date at all. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] @srcdoc and default @sandbox
2010/8/31 Kornel Lesiński kor...@geekhood.net: On Mon, 30 Aug 2010 23:13:04 +0100, Justin Schuh jsc...@chromium.org wrote: At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Data URLs already provide this. What about existing UAs that implement data: URIs, but not sandbox? What about them? (Remember, the context of the use data urls suggestion was to solve the minority use-case of wanting to fill an iframe without a network request, without triggering sandboxing.) ~TJ
Re: [whatwg] @srcdoc and default @sandbox
On 31.08.2010, at 23:39, Tab Atkins Jr. wrote: At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Data URLs already provide this. What about existing UAs that implement data: URIs, but not sandbox? What about them? (Remember, the context of the use data urls suggestion was to solve the minority use-case of wanting to fill an iframe without a network request, without triggering sandboxing.) Yes, it's OK for data without sandboxing. However, inline data without sandboxing does not cover all use cases of srcdoc. There's another use case of inline data _with_ sandboxing and fallback for HTML4 UAs, for which data: URI currently cannot provide. My point is that data: URIs provide only half of srcdoc functionality, and if srcdoc is supposed to be dropped in favor of data: URI, then the other use case needs to be taken into account as well. -- regards, Kornel
Re: [whatwg] @srcdoc and default @sandbox
On Aug 31, 2010, at 4:16 PM, Kornel Lesiński wrote: On 31.08.2010, at 23:39, Tab Atkins Jr. wrote: At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Data URLs already provide this. What about existing UAs that implement data: URIs, but not sandbox? What about them? (Remember, the context of the use data urls suggestion was to solve the minority use-case of wanting to fill an iframe without a network request, without triggering sandboxing.) Yes, it's OK for data without sandboxing. However, inline data without sandboxing does not cover all use cases of srcdoc. There's another use case of inline data _with_ sandboxing and fallback for HTML4 UAs, for which data: URI currently cannot provide. My point is that data: URIs provide only half of srcdoc functionality, and if srcdoc is supposed to be dropped in favor of data: URI, then the other use case needs to be taken into account as well. You can use sandboxing with a data: URI by also specifying the sandbox attribute. As currently specified, srcdoc is almost entirely syntactic sugar. Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
2010/8/31 Kornel Lesiński kor...@geekhood.net: On 31.08.2010, at 23:39, Tab Atkins Jr. wrote: At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Data URLs already provide this. What about existing UAs that implement data: URIs, but not sandbox? What about them? (Remember, the context of the use data urls suggestion was to solve the minority use-case of wanting to fill an iframe without a network request, without triggering sandboxing.) Yes, it's OK for data without sandboxing. Ok. However, inline data without sandboxing does not cover all use cases of srcdoc. It covers very few use-cases, actually. @srcdoc is meant to address the case of inline data *with* sandboxing. There's another use case of inline data _with_ sandboxing and fallback for HTML4 UAs, for which data: URI currently cannot provide. Indeed; that's what @srcdoc is for. Could you be clearer about what point you're trying to make? What use-case are you trying to address that you think the suggestion in this thread (make @srcdoc imply @sandbox) is incompatible with? At the moment it appears that you're confused about the goal of the change I'm suggesting, but I could just be missing something. ~TJ
Re: [whatwg] Video with MIME type application/octet-stream
On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky bzbar...@mit.edu wrote: You can't sniff in a toplevel browser window. Not the same way that people are sniffing in video. It would break the web. How so? For the sake of argument, suppose you sniff only for known binary video/audio types, and fall back to existing behavior if the type isn't one of those (e.g., not video or audio). Do people do things like link to MP3 files with incorrect MIME types and no Content-Disposition, and expect them to download? If so, don't people also link to MP3 files with correct MIME types and expect the same? I don't see how sniffing vs. using MIME type makes a compatibility difference here, since media support in browsers is so new -- surely whatever bad thing happens, sniffing will make it happen more often, at worst. What do Chrome and IE do here? We use the incoming MIME type to determine whether we render the audio/video in the browser versus download. We would never want to execute multimedia sniffing code in the trusted/browser process so implementing sniffing for a top level browser window would involve sending the bytes to a sandboxed process for inspection first. This does have a side effect where a video may play fine on a page with a bogus MIME type (due to sniffing), but viewing the video URL in the browser itself would prompt a download. Andrew
Re: [whatwg] Video with MIME type application/octet-stream
On 8/31/10, Aryeh Gregor simetrical+...@gmail.com wrote: If you can't come up with any actual problems with what IE is doing, then why is anything else even being considered? There's a very clear-cut problem with relying on MIME types: MIME types are often wrong and hard for authors to configure, and this is not going to change anytime soon. Aggressive sniffing can and has resulted in some pretty nasty security bugs. E.g. an attacker crafts an input that a website identifies as video and permits the upload but which a browser sniffs out to be a java jar which can then access the source URL with the permissions of the user. The sniffing rules, in some contexts and some browsers can also end up causing surprising failures... e.g. I've seen older versions of some sniffing heavy browsers automatically switch into UCS-2LE encoding at wrong and surprising times. Perhaps this is irrelevant in a video specific discussion of sniffing— but it is a hazard with sniffing in general. Moreover, it'll never be consistent from implementation to implementation, which seems to me to be pretty antithetical to standardization in general.
[whatwg] some questions regarding clipboard event / clipboard data API
Hi, I'm trying to put together a small spec and a test suite for the clipboard data API which originates from Internet Explorer and is supported by WebKit as event.clipboardData in copy/cut/paste events. I have a few questions regarding the way the API is implemented at the moment. 1) In paste events, WebKit often points event.target to a text node. As far as I know, you've had (or have) known bugs where events target text nodes when they should target elements. I think no events otherwise target text nodes. Do you consider the current implementation a bug, or do you intend to keep it? 2) WebKit defines event.types but I've never seen it be anything but null. Since it exists (but isn't fully implemented?) and I don't know where this property came from or what the plans are, I've just suggested the following text: The types property returns a DOMStringList of MIME type strings. [RFC2046]. In the paste event, it lists those formats available on the clipboard the implementation supports returning to the script. In the copy and cut events, the types property returns a list of supported formats for the copy operation - for example, if the implementation supports copying plain text and HTML it would return a DOMStringList with the values 'text/plain' and 'text/html'. If you have implemented or plan to implement something else please let me know :) 3) The clipboardData.setData() method's spec is based on what IE does, since the method never appeared to do anything in my WebKit testing. If there is a secret preference to toggle or something, please let me know. 4) Although both IE and WebKit support before* events (beforecut, beforecopy, beforepaste) I've omitted them because I can't see the use case for these events. What distinguishes a before* event from a regular cut/copy/paste event? Why is it useful to have both? Are you aware of legacy content that requires before* events? I will probably share the draft spec and tests when it is developed a bit further, for now thanks for any light anybody can shed on these questions. -- Hallvord R. M. Steen
Re: [whatwg] Video with MIME type application/octet-stream
On Tue, Aug 31, 2010 at 9:27 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On 8/31/10, Aryeh Gregor simetrical+...@gmail.com wrote: If you can't come up with any actual problems with what IE is doing, then why is anything else even being considered? There's a very clear-cut problem with relying on MIME types: MIME types are often wrong and hard for authors to configure, and this is not going to change anytime soon. Aggressive sniffing can and has resulted in some pretty nasty security bugs. E.g. an attacker crafts an input that a website identifies as video and permits the upload but which a browser sniffs out to be a java jar which can then access the source URL with the permissions of the user. Indeed. However, that would be an issue with the browser sniffing for jars, not an issue with the browser sniffing for video. The sniffing rules, in some contexts and some browsers can also end up causing surprising failures... e.g. I've seen older versions of some sniffing heavy browsers automatically switch into UCS-2LE encoding at wrong and surprising times. Perhaps this is irrelevant in a video specific discussion of sniffing— but it is a hazard with sniffing in general. Moreover, it'll never be consistent from implementation to implementation, which seems to me to be pretty antithetical to standardization in general. Why will sniffing never be consistent? We need only step up as a community and spec things that implementors are willing to implement. Inoperability suffers when we insist on specing things that implementors refuse to implement. Adam
