Re: [whatwg] Timed tracks: feedback compendium
On Sat, 11 Sep 2010 01:27:48 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Sep 10, 2010 at 11:00 PM, Philip Jägenstedt phil...@opera.comwrote: On Thu, 09 Sep 2010 15:08:43 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Jul 2010, Philip Jägenstedt wrote: If we must have both kind=subtitles and kind=captions, then I'd suggest making the default subtitles, as that is without a doubt the most common kind of timed text. Making captions the default only means that most timed text will be mislabeled as being appropriate for the HoH when it is not. Ok, I've changed the default. However, I'm not fighting this battle if it comes up again, and will just change it back if people don't defend having this as the default. (And then change it back again if the browsers pick subtitles in their implementations after all, of course.) Note that captions aren't just for users that are hard-of-hearing. Most of the time when I use timed tracks, I want captions, because the reason I have them enabled is that I have the sound muted. Hmm, you both have good points. Maybe we should choose something as the default that is not visible on screen, such as descriptions? That would avoid the issue and make it explicit for people who provide captions or subtitles that they have to make a choice. If we want people to make an explicit choice, we should make kind a required attribute and make browsers ignore tracks without it. (I think subtitles is a good default though.) I think you misunderstood - my explanation probably wasn't very good. I'm looking at it from the authoring POV. What I meant was: if I author a text track that is supposed to be visible on screen as the video plays back and if we choose either @kind=subtitle or @kind=caption as the default, then I don't have to really think through about what I authored as it will be displayed on screen. This invites people to not distinguish between whether they authored subtitles or captions, which is a bad thing, because a deaf user may then get tracks with the wrong label and expectations. If, however, we choose as a default something that is not visible on screen, e.g. @kind=description or @kind=metadata, then the author who wants their text track to be visible on screen has to give it a label, i.e. make an explicit choice between @kind=subtitle and @kind=caption. I believe this will lead to more correctly labeled content. I am therefore strongly against default labeling with either subtitle or caption. We could make @kind a required attribute instead as you are saying. OK, I think we mostly agree. Any default will sometimes be wrong, so to not have to choose between subtitles and captions, I'd still really prefer if specific HoH-tags like sound can be shown or hidden depending on user preference. I think that would lead to more content actually being written for HoH users, as it doesn't requiring maintaining 2 different files. On Sun, 25 Jul 2010, Silvia Pfeiffer wrote: I think if we have a mixed set of .srt files out there, some of which are old-style srt files (with line numbers, without WebSRT markup) and some are WebSRT files with all the bells and whistles and with additional external CSS files, we create such a mess for that existing ecosystem that we won't find much love. I'm not sure our goal is to find love here, but in general I would agree that it would be better to have one format than two. I don't see why we wouldn't just have one format here though. The idea of WebSRT is to be sufficiently backwards-compatible that that is possible. With finding love I referred to your expressed goals: - Keep implementation costs for standalone players low. - Use existing technologies where appropriate. - Try as much as possible to have things Just Work. With WebSRT, we will have one label for two different types of files: the old-style SRT files and the new WebSRT files. Just putting a single label on them doesn't mean it is one format, in particular when most old files will not be conformant to the new label and Apart from the encoding, what else about old SRT files wouldn't be conformant? font and u Oh, right. It would still render though, and I assume one could style u to actually be underlined if one really wanted to. Does it matter that they aren't conformant if they work anyway? The ones on the wrong charset won't work, at least not without us introducing specific handling for it - which is incidentally specific handling that non-Web applications won't get, so they are still left out in the rain. Think of a new standalone application that was developed just for WebSRT and only deals with UTF-8. It will not deal well with those legacy files. Requiring UTF-8 and not requiring UTF-8 both has its downsides. I think that handling
Re: [whatwg] Video with MIME type application/octet-stream
2010-09-11 01:51 EEST: Roger Hågensen: On 2010-09-09 09:24, Philip Jägenstedt wrote: For at least WAVE, Ogg and WebM it's not possible as they begin with different magic bytes. Then why not define a new magic that is universal, so that if a proper content type is not stated then a sniffing for a standardized universal magic is done? Yep, I'm referring to my BINID proposal. If a content type is missing, sniff the first 265 bytes and see if it is a BINID, if it is a BINID check if it's a supported/expected one, and it is then play away, all is good. From the what could possibly go wrong department of thought: - a web server blindly prefixes files with BINID if it knows the file suffix and as a result, a file ends up with a double BINID (server assumes that no files contain BINID by default) - a file has double BINID with contradicting content ids - some internal API assumes that caller wants BINID in the stream, the caller assumes that the stream has no BINID - as a result, the caller will pass content with BINIDs embedded in the middle of stream. Basically, this sounds like all the issues of BOM for all binary files. And why do we need this? Because web servers are not behaving correctly and are sending incorrect Content-Type headers? What makes you believe that BINID will not be incorrectly used? (If you really believe that you can force content authors to provide correct BINIDs, why you cannot force content authors to provide correct Content-Types? Hopefully the goal is not to sniff if BINIDs seems okay and ignore clearly incorrect ones in the future...) I'd like to specify that the only cases an UA is allowed to sniff the content type are: - Content-Type header is missing (because the server clearly does not know the type), or - Content-Type is literal text/plain, text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 or text/plain; charset=UTF-8 (to deal with historical mess caused by IIS and Apache), or - Content-Type is literal application/octet-stream (In all these cases, the server clearly has no real knowledge. If a file is meant for downloading, the server should use Content-Disposition: attachment header instead of hacks such as using application/x-download for Content-Type.) For any other value of Content-Type, honor the type specified in HTTP level. And provide no overrides of any kind on any level above the HTTP. Levels above HTTP may provide HINTS about the content that can be used to aid or override *sniffing* but nothing should override any *explicitly specified Content-Type*. [This is simplified version of the logic that the Mozilla/Firefox already applies: http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#684] And for heavens sake, do not specify any sniffing as official. Instead, explicitly specify all sniffing as UA specific and possibly suggest that UAs should inform the user that content is broken and the current rendering is best effort if any sniffing is required. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Video with MIME type application/octet-stream
On 2010-09-13 15:03, Mikko Rantalainen wrote: 2010-09-11 01:51 EEST: Roger Hågensen: On 2010-09-09 09:24, Philip Jägenstedt wrote: For at least WAVE, Ogg and WebM it's not possible as they begin with different magic bytes. Then why not define a new magic that is universal, so that if a proper content type is not stated then a sniffing for a standardized universal magic is done? Yep, I'm referring to my BINID proposal. If a content type is missing, sniff the first 265 bytes and see if it is a BINID, if it is a BINID check if it's a supported/expected one, and it is then play away, all is good. From the what could possibly go wrong department of thought: - a web server blindly prefixes files with BINID if it knows the file suffix and as a result, a file ends up with a double BINID (server assumes that no files contain BINID by default) - a file has double BINID with contradicting content ids - some internal API assumes that caller wants BINID in the stream, the caller assumes that the stream has no BINID - as a result, the caller will pass content with BINIDs embedded in the middle of stream. Basically, this sounds like all the issues of BOM for all binary files. And why do we need this? Because web servers are not behaving correctly and are sending incorrect Content-Type headers? What makes you believe that BINID will not be incorrectly used? Because if they add a binary id then they obviously are aware of the standard. Old servers/software would just pass the file through as they are unaware so content type issues still exist there, eventually old servers/software are rotate out until most are binary id aware. This is how rolling out new standards work. A server would only add a binary id if none exist and it's certain (by previous sniffing) that it's guess is correct, though I guess the standard could state that if no binary id exist on a file then none should be added by the server at all (legacy behavior?) And what I meant with the server adding it I meant services like Youtube (if Youtube transcode a video to MP4 then the server knows it's delivering just that), likewise with streaming radio or video or similar, a regular webserver would have no right (or point) in modifying a file served than it does a .zip or .mp3 that a user downloads, we are talking about streaming here mainly right? (where a short max length sniffing would be a huge benefit) (If you really believe that you can force content authors to provide correct BINIDs, why you cannot force content authors to provide correct Content-Types? Hopefully the goal is not to sniff if BINIDs seems okay and ignore clearly incorrect ones in the future...) I do not see why web authors (or users at all) would need to mess with the binary id at all, it's authoring software or transcoding software that would add them. My BINID proposal is just that, a proposal for a binary id, it does not define how servers and browsers should handle it as that is a different scope altogether. Something like a binary id would need a proper RFC writeup or similar. I'd like to specify that the only cases an UA is allowed to sniff the content type are: - Content-Type header is missing (because the server clearly does not know the type), or - Content-Type is literal text/plain, text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 or text/plain; charset=UTF-8 (to deal with historical mess caused by IIS and Apache), or - Content-Type is literal application/octet-stream (In all these cases, the server clearly has no real knowledge. If a file is meant for downloading, the server should use Content-Disposition: attachment header instead of hacks such as using application/x-download for Content-Type.) Yes! But if the UA in those cases also checked for a binary ID (and found such) there would hardly be any ambiguity. For any other value of Content-Type, honor the type specified in HTTP level. And provide no overrides of any kind on any level above the HTTP. Levels above HTTP may provide HINTS about the content that can be used to aid or override *sniffing* but nothing should override any *explicitly specified Content-Type*. [This is simplified version of the logic that the Mozilla/Firefox already applies: http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#684] And for heavens sake, do not specify any sniffing as official. Instead, explicitly specify all sniffing as UA specific and possibly suggest that UAs should inform the user that content is broken and the current rendering is best effort if any sniffing is required. Any sniffing would be as a fallback only if the UA suspects the content type is wrong (i.e. video of type text for example) or similar, and it would not hurt to have some standardized behavior in those cases that sniff for something simple like a short binary id rather than parse potentially several kilobytes of the stream (which was where this discussion took
Re: [whatwg] Timed tracks: feedback compendium
On Mon, Sep 13, 2010 at 5:55 PM, Philip Jägenstedt phil...@opera.comwrote: On Sat, 11 Sep 2010 01:27:48 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Sep 10, 2010 at 11:00 PM, Philip Jägenstedt phil...@opera.com wrote: On Thu, 09 Sep 2010 15:08:43 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Jul 2010, Philip Jägenstedt wrote: If we must have both kind=subtitles and kind=captions, then I'd suggest making the default subtitles, as that is without a doubt the most common kind of timed text. Making captions the default only means that most timed text will be mislabeled as being appropriate for the HoH when it is not. Ok, I've changed the default. However, I'm not fighting this battle if it comes up again, and will just change it back if people don't defend having this as the default. (And then change it back again if the browsers pick subtitles in their implementations after all, of course.) Note that captions aren't just for users that are hard-of-hearing. Most of the time when I use timed tracks, I want captions, because the reason I have them enabled is that I have the sound muted. Hmm, you both have good points. Maybe we should choose something as the default that is not visible on screen, such as descriptions? That would avoid the issue and make it explicit for people who provide captions or subtitles that they have to make a choice. If we want people to make an explicit choice, we should make kind a required attribute and make browsers ignore tracks without it. (I think subtitles is a good default though.) I think you misunderstood - my explanation probably wasn't very good. I'm looking at it from the authoring POV. What I meant was: if I author a text track that is supposed to be visible on screen as the video plays back and if we choose either @kind=subtitle or @kind=caption as the default, then I don't have to really think through about what I authored as it will be displayed on screen. This invites people to not distinguish between whether they authored subtitles or captions, which is a bad thing, because a deaf user may then get tracks with the wrong label and expectations. If, however, we choose as a default something that is not visible on screen, e.g. @kind=description or @kind=metadata, then the author who wants their text track to be visible on screen has to give it a label, i.e. make an explicit choice between @kind=subtitle and @kind=caption. I believe this will lead to more correctly labeled content. I am therefore strongly against default labeling with either subtitle or caption. We could make @kind a required attribute instead as you are saying. OK, I think we mostly agree. Any default will sometimes be wrong, so to not have to choose between subtitles and captions, I'd still really prefer if specific HoH-tags like sound can be shown or hidden depending on user preference. I think that would lead to more content actually being written for HoH users, as it doesn't requiring maintaining 2 different files. Ah, you are talking about some kind of CSS marker for the audio events that are marked up in a caption file and that could just simple be display: none if they are viewed as a subtitle. Interesting idea... not sure that matches with the current spec though. Does it matter that they aren't conformant if they work anyway? The ones on the wrong charset won't work, at least not without us introducing specific handling for it - which is incidentally specific handling that non-Web applications won't get, so they are still left out in the rain. Think of a new standalone application that was developed just for WebSRT and only deals with UTF-8. It will not deal well with those legacy files. Requiring UTF-8 and not requiring UTF-8 both has its downsides. I think that handling charset as an attribute on track isn't very difficult, but if there are SRT-incompatible changes for other reasons (e.g. a header) then I think we should go back to always requiring UTF-8. I'm very happy to always require UTF-8, in fact, I would prefer it. For me it's just another argument to break with history and have WebSRT stand on its own without having to worry about SRT. many new files will not play in the software created for the old spec. As long as we don't add a header, the files will play in most existing software. Apart from parsers that assume that SRT is plain text (and thus would be unsuitable for much existing SRT content), what kind of breakage have you found with WebSRT-specific syntax in existing software? I think we need to add a header - and possibly other things in the future. Will we forever have the SRT restrictions hold back the introduction of new features into WebSRT? Yes, if we extend SRT we can't break compatibility. However, it seems that all the
Re: [whatwg] Video with MIME type application/octet-stream
Mikko Rantalainen mikko.rantalai...@peda.net schrieb am Mon, 13 Sep 2010 16:03:27 +0300: […] Basically, this sounds like all the issues of BOM for all binary files. And why do we need this? Because web servers are not behaving correctly and are sending incorrect Content-Type headers? What makes you believe that BINID will not be incorrectly used? (If you really believe that you can force content authors to provide correct BINIDs, why you cannot force content authors to provide correct Content-Types? Hopefully the goal is not to sniff if BINIDs seems okay and ignore clearly incorrect ones in the future...) This. BINID may be a well-intended idea, but would be an essentially useless additional layer of abstraction that provides no more safeguards against misuse than the Content-Type header. The latter also required no changes to current binary file handling — which for BINID would need to be universally updated in every conceivable device that could ever get a BINID file. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
[whatwg] Interface of the readystatechange event
I could not find information on what DOM Events interface does readystatechange event have. Can someone point me to where it is defined/mentioned? Sergey/
Re: [whatwg] Interface of the readystatechange event
On Mon, 13 Sep 2010 16:33:01 +0200, Sergey Ilinsky casto...@yahoo.co.uk wrote: I could not find information on what DOM Events interface does readystatechange event have. Can someone point me to where it is defined/mentioned? Where the specification defines it to be dispatched it says to fire a simple event named readystatechange. The definition of firing a simple event named e says to use the Event interface. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Which mechanisms does HTML5 have in place to combat XSS attacks?
Q1. I know Mozilla and Microsoft have provided some ways (respectively, CSP, XSS filter) to mitigate or detect XSS attacks. so I wonder whether HTML5 will present an approach to fight this attacks? Q2. I also saw Chrome and Safari have present some ways to fight XSS attacks , however, I always don't find which mechanisms has Opera provided to block the attack. I want to know whether Opera has any solutions for it? if someone know it, please tell me. thanks. kindly, Matt
Re: [whatwg] Improve select required
On Monday 13 Sep 2010 Mounir Lamouri wrote: 2. Introduce a placeholder boolean attribute for option and select elements will suffer from being missing if there are no options selected or selected options all have the placeholder attribute set. I also wonder if that would be more straighforward. I suggested / inquired about that when this was being discussed before, but the discussion petered out and no one said anything about it: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027892.html (See last paragraph.) last solution isn't [backward compatible] (ie. the placeholder text wouldn't be shown). However, a workaround can be found using javascript: In my opinion, something that relies on scripting isn't a viable solution. Solution 3, seems to be the nicest and is consistent with the other part of the specifications (placeholder would be used in input and select). That's not viable now because it's not backward compatible, but if people think that would be the ideal solution in the future, would it feasible to specify and implement the following authoring requirements and user agent behavior? * @placeholder for SELECT (as in your #3) AND * @placeholder as a boolean attribute on OPTION (just as a crutch for backward compatibility) AND * @placeholder on OPTION is only valid when @placeholder is also used on the SELECT (and perhaps only if the OPTION's textContent matches the value of the SELECT's @placeholder attribute?) AND * Although @placeholder on OPTION is valid / tolerated under those circumstances, conforming UAs must ignore those OPTIONs entirely and use the value of @placeholder on the SELECT If that's doable, then implementors could implement the behavior for @placeholder on SELECT now and authors could author documents that use the new mechanism and preserve the status-quo for HTML 4 user agents -- an initial label OPTION. When authors stop caring about HTML 4 UAs, they can just stop including an OPTION with @placeholder. Jesse
Re: [whatwg] Video with MIME type application/octet-stream
On Mon, Sep 13, 2010 at 9:03 AM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: For any other value of Content-Type, honor the type specified in HTTP level. And provide no overrides of any kind on any level above the HTTP. Levels above HTTP may provide HINTS about the content that can be used to aid or override *sniffing* but nothing should override any *explicitly specified Content-Type*. [This is simplified version of the logic that the Mozilla/Firefox already applies: http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#684] This is not feasible at least for some legacy cases, like image MIME types. It's a good strategy to try for new cases, though. If it could be specced for video and audio, maybe we could get everyone to converge sooner rather than later. And for heavens sake, do not specify any sniffing as official. Instead, explicitly specify all sniffing as UA specific and possibly suggest that UAs should inform the user that content is broken and the current rendering is best effort if any sniffing is required. This is totally incompatible with the compelling interoperability and security benefits of all browsers using the exact same sniffing algorithm.
