Re: [whatwg] Video feedback
On Fri, 03 Jun 2011 01:28:45 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 22 Oct 2010, Simon Pieters wrote: Actually it was me, but that's OK :) There was also some discussion about metadata. Language is sometimes necessary for the font engine to pick the right glyph. Could you elaborate on this? My assumption was that we'd just use CSS, which doesn't rely on language for this. It's not in any spec that I'm aware of, but some browsers (including Opera) pick different glyphs depending on the language of the text, which really helps when rendering CJK when you have several CJK fonts on the system. Browsers will already know the language from track srclang, so this would be for external players. How is this problem solved in SRT players today? Not at all, it seems. Both VLC and Totem allow setting the character encoding and font used for subtitles in the (global) preferences menu, so presumably you would change that if the default doesn't work. Font switching seems to mainly be an issue when your system has other default fonts than the text you're reading, and it appears that is rare enough that very little software does anything about it, browsers perhaps being an exception. On Mon, 3 Jan 2011, Philip Jägenstedt wrote: * The bad cue handling is stricter than it should be. After collecting an id, the next line must be a timestamp line. Otherwise, we skip everything until a blank line, so in the following the parser would jump to bad cue on line 2 and skip the whole cue. 1 2 00:00:00.000 -- 00:00:01.000 Bla This doesn't match what most existing SRT parsers do, as they simply look for timing lines and ignore everything else. If we really need to collect the id instead of ignoring it like everyone else, this should be more robust, so that a valid timing line always begins a new cue. Personally, I'd prefer if it is simply ignored and that we use some form of in-cue markup for styling hooks. The IDs are useful for referencing cues from script, so I haven't removed them. I've also left the parsing as is for when neither the first nor second line is a timing line, since that gives us a lot of headroom for future extensions (we can do anything so long as the second line doesn't start with a timestamp and -- and another timestamp). In the case of feeding future extensions to current parsers, it's way better fallback behavior to simply ignore the unrecognized second line than to discard the entire cue. The current behavior seems unnecessarily strict and makes the parser more complicated than it needs to be. My preference is just ignore anything preceding the timing line, but even if we must have IDs it can still be made simpler and more robust than what is currently spec'ed. If we just ignore content until we hit a line that happens to look like a timing line, then we are much more constrained in what we can do in the future. For example, we couldn't introduce a comment block syntax, since any comment containing a timing line wouldn't be ignored. On the other hand if we keep the syntax as it is now, we can introduce a comment block just by having its first line include a -- but not have it match the timestamp syntax, e.g. by having it be -- COMMENT or some such. One of us must be confused, do you mean something like this? 1 -- COMMENT 00:00.000 -- 00:01.000 Cue text Adding this syntax would break the *current* parser, as it would fail in step 39 (Collect WebVTT cue timings and settings) and then skip the rest of the cue. If we want any room for extensions along these lines, then multiple lines preceding the timing line must be handled gracefully. Looking at the parser more closely, I don't really see how doing anything more complex than skipping the block entirely would be simpler than what we have now, anyway. I suggest: * Step 31: Try to collect WebVTT cue timings and settings instead of checking for the substring --. If it succeeds, jump to what is now step 40. If it fails, continue at what is now step 32. (This allows adding any syntax as long as it doesn't exactly match a timing line, including -- COMMENT. As a bonus, one can fail faster when trying to parse an entire timing line rather than doing a substring search for --.) * Step 32: Only set the id line if it's not already set. (Assuming we want the first line to be the id line in future extensions.) * Step 39: Jump to the new step 31. In case not every detail is correct, the idea is to first try to match a timing line and to take the first line that is not a timing line (if any) as the id, leaving everything in between open for future syntax changes, even if they use --. I think it's fairly important that we handle this. Double id lines is an easy mistake to make when copying things around. Silently dropping those cues would be worse than what many existing (line-based, id-ignoring) SRT parsers do. On Sat, 22 Jan 2011,
Re: [whatwg] Content-Disposition property for a tags
Am 03.06.2011, 10:23 Uhr, schrieb Eduard Pascual herenva...@gmail.com: On Thu, Jun 2, 2011 at 10:09 PM, Dennis Joachimsthaler den...@efjot.de wrote: By the way, another point that we have to discuss: Which tag should a browser favor. The one in HTTP or the other one in HTML? Is that really worth discussing? HTTP HTML: whomever provides the file should have the last say about how the file needs to be served, regardless of what a site referencing to it may suggest. Furthermore, when links point to URIs with any scheme other than http:, whatever the scheme defines about how to deliver the file takes precedence. Thus, only in the lack of an actual Content-Disposition header, or its equivalent on some other scheme, would the attribute given by the link be used, just like an additional fallback step before whatever the UA's default behaviour would be. I agree that I shouldn't even have asked since this is actually a no- brainer. I can't think of any good reason to overwrite the http header with the html attribute. Alright, so, moving on... This grants the ability for any content provider to use an explicit Content-Disposition: inline HTTP header to effectively block download links from arbitrary sources. True. Is it still so that some browsers ignore the filename part of a content-disposition if an inline disposition is used? Personally, on the case I'm most concerned about (data: URIs used for Save log and similar functionalities), there is never a true disposition header; so my use cases do not push towards any of the options. What I have just written is what I feel is the most reasonable approach (the provider of a resource should have some control over it above an arbitrary third party). Data URIs would very well benefit from this attribute, in my opinion. This would also cater to the canvas lovers. Downloading something drawn on a canvas instantly? No problem! a href=data: disposition=attachment filename=canvas.pngDownload me!/a This is still one thing that has to be settled though. a) How do we call the attribute? b) Do we include the filename part directly into the attribute or do we create a SECOND attribute just for this? People have been posting several formats now. But I don't think we actually have *agreed* upon one of those. - Dennis Joachimsthaler
Re: [whatwg] Content-Disposition property for a tags
On 2011-06-03 14:23, Dennis Joachimsthaler wrote: Am 03.06.2011, 10:23 Uhr, schrieb Eduard Pascual herenva...@gmail.com: On Thu, Jun 2, 2011 at 10:09 PM, Dennis Joachimsthaler den...@efjot.de wrote: By the way, another point that we have to discuss: Which tag should a browser favor. The one in HTTP or the other one in HTML? Is that really worth discussing? HTTP HTML: whomever provides the file should have the last say about how the file needs to be served, regardless of what a site referencing to it may suggest. Furthermore, when links point to URIs with any scheme other than http:, whatever the scheme defines about how to deliver the file takes precedence. Thus, only in the lack of an actual Content-Disposition header, or its equivalent on some other scheme, would the attribute given by the link be used, just like an additional fallback step before whatever the UA's default behaviour would be. I agree that I shouldn't even have asked since this is actually a no- brainer. I can't think of any good reason to overwrite the http header with the html attribute. Alright, so, moving on... This grants the ability for any content provider to use an explicit Content-Disposition: inline HTTP header to effectively block download links from arbitrary sources. True. Is it still so that some browsers ignore the filename part of a content-disposition if an inline disposition is used? Yes, see http://greenbytes.de/tech/tc2231/#inlwithasciifilename. Apparently only Firefox gets this right. ... Best regards, Julian
Re: [whatwg] Content-Disposition property for a tags
On Fri, Jun 3, 2011 at 2:23 PM, Dennis Joachimsthaler den...@efjot.de wrote: This grants the ability for any content provider to use an explicit Content-Disposition: inline HTTP header to effectively block download links from arbitrary sources. True. Is it still so that some browsers ignore the filename part of a content-disposition if an inline disposition is used? Ok, I have never even thought about using the filename argument with an explicit inline disposition. When I am in control of the headers, I find it easier to fix the filename with 301/302 redirects, and also have the bonus of some control about how that should be cached... In short, I think that responding with a 2xx code _and_ attempting to change what's essentially part of the URI through other means is a contradiction, and thus a mistake on the best case, or some attempt to fool the browser into doing something it shouldn't do on the worst case. Because of that, I'm ok with whatever way the browser decides to handle the contradiction. You can read my position about error-handling on my earlier post some minutes ago. Personally, on the case I'm most concerned about (data: URIs used for Save log and similar functionalities), there is never a true disposition header; so my use cases do not push towards any of the options. What I have just written is what I feel is the most reasonable approach (the provider of a resource should have some control over it above an arbitrary third party). Data URIs would very well benefit from this attribute, in my opinion. This would also cater to the canvas lovers. Downloading something drawn on a canvas instantly? No problem! a href=data: disposition=attachment filename=canvas.pngDownload me!/a Yep, these are the cases I am actually concerned about. But on these scenarios there is no HTTP header involved, so it doesn't matter (for them) what takes precedence. This is still one thing that has to be settled though. a) How do we call the attribute? Is there any reason to _not_ call it 'content-disposition'? Ok, there is one: verbosity. But, personally, I have no issue with some verbosity if it helps making things blatantly explicit. So many years of browser vendors reverse-engineering the error handling in competing products have convinced me that being explicit is a good thing. b) Do we include the filename part directly into the attribute or do we create a SECOND attribute just for this? People have been posting several formats now. But I don't think we actually have *agreed* upon one of those. What's wrong with using the same format as HTTP? I am not too strongly attached to that format, but I see no point in making things different from what we already have. As a minor advantage, implementors can reuse (or copy-paste) some few lines of parsing code instead of writting them again, since they already parse the header when they get it on an HTTP response. Regards, Eduard Pascual
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11 9:16 AM, Eduard Pascual wrote: Ok, I have never even thought about using the filename argument with an explicit inline disposition. When I am in control of the headers, I find it easier to fix the filename with 301/302 redirects That doesn't work if the data is dynamically generated. In short, I think that responding with a 2xx code _and_ attempting to change what's essentially part of the URI through other means is a contradiction The filename to save the data as is not part of the URI. Think a URI like this: http://mysite.org/generate_progress_report.php?quarter=Q12010 When saving, it would be good to use something like Progress report of Q1 2010 as the filename. But that's not part of the URI in any sense. Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. and thus a mistake on the best case, or some attempt to fool the browser into doing something it shouldn't do on the worst case. I strongly disagree. I think browsers that use the Content-Disposition filename for attachment but not inline are just buggy and should be fixed. Of course it sounds like your position is that they should not use the filename for attachment either... (in which case you disagree not only with me, but with most of the web). -Boris
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11 8:09 AM, Nils Dagsson Moskopp wrote: Eduard Pascualherenva...@gmail.com schrieb am Fri, 3 Jun 2011 10:23:25 +0200: This grants the ability for any content provider to use an explicit Content-Disposition: inline HTTP header to effectively block download links from arbitrary sources. … thus placing a burden on content providers. If browser makers think content providers cannot even get their MIME types right (see image / video sniffing discussion), what makes you think anyone would configure headers for no immediate benefit? There are two ways to get correct things to happen in a setup where the HTTP header is authoritative but optional and other sources can provide the information when the header is absent. 1) Send the right header. 2) Not send the header at all, and let other sources of information work. In the content-type case, some popular web servers have historically defaulted to a third option: Send a bogus header and to hell with it. As a result, almost no one uses option 2 above (since it involves at best reconfiguring the HTTP server and at worst switching to a different HTTP server), and doing option 1 is hard, so the situation ends up bad. For content-disposition, on the other hand, the vast majority of content is already using option 2 above. That's the path of least resistance for content providers, so only providers who are trying to go out of their way to change the behavior will do something else. That significantly reduces the chances of them sending bogus headers. -Boris
Re: [whatwg] [html5] r6178 - [e] (0) More notes about video.readyState.
On Fri, 03 Jun 2011 01:59:25 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2011-06-02 16:59:24 -0700 (Thu, 02 Jun 2011) New Revision: 6178 Modified: complete.html index source Log: [e] (0) More notes about video.readyState. Modified: source === --- source 2011-06-02 23:53:44 UTC (rev 6177) +++ source 2011-06-02 23:59:24 UTC (rev 6178) @@ -30283,7 +30283,7 @@ tr tddfn title=attr-media-preload-metadatacodemetadata/code/dfn tddfn title=attr-media-preload-metadata-stateMetadata/dfn - tdHints to the user agent that the author does not expect the user to need the media resource, but that fetching the resource metadata (dimensions, first frame, track list, duration, etc) is reasonable. + tdHints to the user agent that the author does not expect the user to need the media resource, but that fetching the resource metadata (dimensions, first frame, track list, duration, etc) is reasonable. If the user agent precisely fetches no more than the metadata, then the spanmedia element/span will end up with its code title=dom-media-readyStatereadyState/code attribute set to code title=dom-media-HAVE_METADATAHAVE_METADATA/code; This is wrong if we say that the first frame is metadata as written a few lines above. When you have the first frame, readyState is HAVE_CURRENT_DATA. -- Simon Pieters Opera Software
Re: [whatwg] Content-Disposition property for a tags
On Fri, Jun 3, 2011 at 3:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/3/11 9:16 AM, Eduard Pascual wrote: Ok, I have never even thought about using the filename argument with an explicit inline disposition. When I am in control of the headers, I find it easier to fix the filename with 301/302 redirects That doesn't work if the data is dynamically generated. As a matter of fact, it does. It takes some work, and quite a bit of creativity with ModRewrite or similar tools, but is perfectly achievable. The key is to do the redirection _before_ starting to generate the data, and to keep enough information on the final URI to recover the parameters once the script actually gets into data-generation. In short, I think that responding with a 2xx code _and_ attempting to change what's essentially part of the URI through other means is a contradiction The filename to save the data as is not part of the URI. Think a URI like this: http://mysite.org/generate_progress_report.php?quarter=Q12010 Wouldn't that default (in the absence of a Content-disposition) to generate_progress_report.php as the filename? That's what I meant by part of the URI. When saving, it would be good to use something like Progress report of Q1 2010 as the filename. But that's not part of the URI in any sense. It would, if the author wanted it to be. Turning that URI into something like http://mysite.org/ProgressReport_Q1_2010;, for example (that's what I'd probably do in that scenario) is quite simple to achieve. A literal URI like http://mysite.org/Progress report of Q1 2010 would take some extra work to get working right, but is still doable. After all, if the author cares about having a reasonable filename, why wouldn't they care about having a descriptive URI? The filename option on Content-Disposition headers is just a partial solution to a problem for which a more powerful solution already exists. Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. Not on my sites :P My URIs are a useful filename by themselves. and thus a mistake on the best case, or some attempt to fool the browser into doing something it shouldn't do on the worst case. I strongly disagree. I think browsers that use the Content-Disposition filename for attachment but not inline are just buggy and should be fixed. Ok, maybe I used a too harsh wording for that, but for all the situations I can think of where a filename argument would make sense I can achieve a better result through URI beautification. I still think it's a mistake to try to fix a filename but not fix the URI. The attempt to fool the browser part was more about evil sites serving files with names like hotnudepic.jpg.exe (I have seen real sites in the past doing thinks like that, and even worse). In any case, note that my comment was about what *authors* should do. Browsers will attempt to do whatever is good for the users, and I'm ok with that. Of course it sounds like your position is that they should not use the filename for attachment either... (in which case you disagree not only with me, but with most of the web). Actually, my position is more like I don't care what the browser does with this because I have no need to use it. Honestly, I hadn't looked into the filename option of that header until the discussions about adding this feature to links and/or data: URIs started. data: URIs, by their very own nature, are not suited for beautification. And even if this feature gets implemented, the filename part doesn't concern me too much, since it's just a mere convenience, and the user always has the final say on what the file name will be (even if a browser didn't allow changing that, the user could rename the file afterwards). Regards, Eduard Pascual
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11 10:39 AM, Eduard Pascual wrote: http://mysite.org/generate_progress_report.php?quarter=Q12010 Wouldn't that default (in the absence of a Content-disposition) to generate_progress_report.php as the filename? Depends on the browser. But yes. And that's a crappy filename for the Q12010 report! When saving, it would be good to use something like Progress report of Q1 2010 as the filename. But that's not part of the URI in any sense. It would, if the author wanted it to be. Turning that URI into something like http://mysite.org/ProgressReport_Q1_2010;, for example (that's what I'd probably do in that scenario) is quite simple to achieve. Is it now? You have to do a redirect on the server side, increase latency for the user, etc. For what purpose, given that you just want to specify the filename and there is already a mechanism for that? After all, if the author cares about having a reasonable filename, why wouldn't they care about having a descriptive URI? Because the URI is generated based on a form the user fills out, and no one ever sees the actual URI? I strongly disagree. I think browsers that use the Content-Disposition filename for attachment but not inline are just buggy and should be fixed. Ok, maybe I used a too harsh wording for that, but for all the situations I can think of where a filename argument would make sense I can achieve a better result through URI beautification. better byt what metric? Of course it sounds like your position is that they should not use the filename for attachment either... (in which case you disagree not only with me, but with most of the web). Actually, my position is more like I don't care what the browser does with this because I have no need to use it. That's great, and I'm happy you're willing to impose costs on your users so you don't have to use it. But others may wish to make different tradeoffs here. -Boris
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11, Boris Zbarsky bzbar...@mit.edu wrote: http://mysite.org/generate_progress_report.php?quarter=Q12010 When saving, it would be good to use something like Progress report of Q1 2010 as the filename. But that's not part of the URI in any sense. So you're suggesting using the title as the filename. In that case, the a element has a @title attribute already. a href=http://mysite.org/generate_progress_report.php?quarter=Q12010; title=Progress report of Q1 2010progress report/a Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. That's slightly better than just using the last non-empty path component, though. But yes, in the general case, the filename should be extracted from the title. Note that filenames being verbose by default is a good thing (to avoid accidental collisions). The user can provide short, easy-to-type filenames that he can remember himself. I strongly disagree. I think browsers that use the Content-Disposition filename for attachment but not inline are just buggy and should be fixed. FWIW MSIE9 seems to honor the filename hint with inline (contrary to the test results mentioned earlier in the thread). Of course it sounds like your position is that they should not use the filename for attachment either... (in which case you disagree not only with me, but with most of the web). ... but agree with me. The filename hint is useful for providing filename extensions. Honoring these irrespective of the Content-Type is dangerous. I recommend browsers strip the first dot and all following characters from filename hints - but then they could just as well ignore it.
Re: [whatwg] Selection events in editable content
On Thu, Jun 2, 2011 at 7:27 PM, Ojan Vafai o...@chromium.org wrote: TL;DR version: Having Selections update as the DOM is modified seems to me like considerable added complexity without a good use-case. If it's a Selection object, it will have an associated Range object, and all Range objects update as the DOM is modified anyway. How is it any different from if the user creates a Range object and stores it someplace as a global? That will update as the DOM is modified too. Updating it will be O(N) in the number of such objects floating around, but authors can already create an array of a thousand Ranges if they feel like it, and those all have to be updated too. As far as use-cases, if the range isn't updated, it might wind up pointing to someplace that has no relationship to the original selection. For instance, the node it points to might have been removed from the document, and then the author will have no way to tell where it originally was. Or children might have been added or removed, or replaceData() or something called on a text node, so that the offsets are wrong (or even beyond the end of the node). I strongly believe we should not do this. I don't like adding new things that need to be updated every time a node is added/removed from the DOM. I don't see any problem with the Selection objects getting stale. The author can easily write code to verify that the Selection object is in a valid state if they need to. How can they do that? As long as the boundary points it's pointing at are still in the document and the offset isn't greater than the node's length, the author has no way to tell if they're meaningfully the same boundary points as when the event occurred. E.g., if there's some Text node and the users selects foo[bar]baz, but then before the script handles the event the user cancels that selection and modifies the Text node to quuzfoobarbaz, if the offsets weren't updated, the old Selection object will look like quu[zfo]obarbaz, which has nothing to do with what the user ever selected.
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On Thu, Jun 2, 2011 at 8:07 PM, Tim Down timd...@gmail.com wrote: My version passes an array of ranges to be preserved to the command's various internal methods. Works with multiple selected ranges in Firefox. I've considered doing that too. But it doesn't work with Range objects you don't have a reference to, so it's not the same as what the browser can do. (Although I'm not sure if browsers actually do anything special for ranges not in the selection, for execCommand(). I haven't tested, but I suspect not.)
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11 11:46 AM, Bjartur Thorlacius wrote: Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. That's slightly better than just using the last non-empty path component, though. It's not, because they're not consistent about it... -Boris
Re: [whatwg] Content-Disposition property for a tags
On Fri, Jun 3, 2011 at 5:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/3/11 10:39 AM, Eduard Pascual wrote: http://mysite.org/generate_progress_report.php?quarter=Q12010 Wouldn't that default (in the absence of a Content-disposition) to generate_progress_report.php as the filename? Depends on the browser. But yes. And that's a crappy filename for the Q12010 report! Well, that's a point we agree on: it's indeed a crappy filename. IMO, this is a direct consequence of a crappy URI. Is it now? You have to do a redirect on the server side, increase latency for the user, etc. For what purpose, given that you just want to specify the filename and there is already a mechanism for that? The better filename is just the smallest of the benefits provided by the beautification. A semantic URI is an additional aid to navigation and a noticeable boost to search engine visibility. After all, if the author cares about having a reasonable filename, why wouldn't they care about having a descriptive URI? Because the URI is generated based on a form the user fills out, and no one ever sees the actual URI? For a typical snippet of client-side form validation, one or two extra lines of JS can beautify in advance for a GET form. In the case of POST, I would always use the PRG pattern, so the redirection comes for free. For a GET form with JS disabled, the actual redirection happens, but this is now a fallback case that should only triggered on a minority of the scenarios. I'm not sure what do you mean by no one ever sees the actual URI: I work on a daily basis with half a dozen different browsers, and they all display the URI wherever I navigate. In the case of FF, it won't even let me open a window without a location bar unless the user explicitly enables that through the about:config options. So I'd rather say that most users actually see the URI. Another question could be whether they _care_ about the URI. On one of the sites I have worked in, we implemented a beautification system for SEO purposes: the flow of 10-12 daily mails asking for help about the site's structure dropped to 10-12 monthly (the navigation was not perfect, but it wasn't horrible: it just was a rather complex site), a few users mailing us thanking the change, and the visitor - customer conversion ratio for the site was doubled within a week. From that and some other cases (not so extreme, but in a similar direction) I have reached the conclusion that users are more likely to pay attention to the URI if it looks simple and clean. better byt what metric? By the amount of things it achieves: besides setting the filename (which I consider only a minor benefit), it improves navigation and helps SEO (see comments above). Actually, my position is more like I don't care what the browser does with this because I have no need to use it. That's great, and I'm happy you're willing to impose costs on your users so you don't have to use it. But others may wish to make different tradeoffs here. Honestly, if this were coming from someone else, I'd take it as trolling. But coming from you, I know that's extremely unlikely, so I'll assume that there has been a misunderstanding at some point, because that last statement is already taking things too far from their context. So, please, let me summarize the whole thing, in a (hopefully) clear way: 1) Most of my sites use some URI beautification techniques to aid both user's and spider's navigation (with a significant effort to minimize the impact on the users). 2) Because of (1), I haven't had any need to ever use the filename argument on a Content-Disposition header: my beautified URIs already serve as good enough filenames. 3) Because of (2), I do not hold a strong opinion about how that argument should be handled on the many different scenarios. Please accept my apologies if my earlier posts yielded a different idea; the three points above are what I have been trying to express. I think my English is rather good, but is not native and I may fail to express my views and/or ideas from time to time. I wouldn't ever mentioned this if Dennis Joachimsthaler hand't asked about it on his reply to my initial post on this discussion, since I don't think saying that I stay neutral on something contributes too much to the discussion. I just stepped into the thread to share my view about how to handle conflicts between HTTP headers and parameters given on the markup; and this has turned into a nearly pointless side discussion that doesn't contribute to the main topic. Feel free to contact me privately or (if you think the discussion will be of interest to other people here) to branch into a new thread if you want to go on; but I'd prefer not to derail this thread any further. Regards, Eduard Pascual
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11 2:48 PM, Eduard Pascual wrote: For a typical snippet of client-side form validation, one or two extra lines of JS can beautify in advance for a GET form. Why are you assuming there's any client-side validation code involved? I'm not sure what do you mean by no one ever sees the actual URI: I work on a daily basis with half a dozen different browsers, and they all display the URI wherever I navigate. The URI is not displayed in the url bar unless the new page is shown. If the URI results in a file download, it won't be shown in the URL bar. Another question could be whether they _care_ about the URI. They don't, of course. But that's not even relevant in the generate a download based on form input case. By the amount of things it achieves: besides setting the filename (which I consider only a minor benefit), it improves navigation and helps SEO (see comments above). I think you're assuming people care about SEO for the file to be downloaded In many cases they don't. That's great, and I'm happy you're willing to impose costs on your users so you don't have to use it. But others may wish to make different tradeoffs here. Honestly, if this were coming from someone else, I'd take it as trolling. But coming from you, I know that's extremely unlikely, so I'll assume that there has been a misunderstanding at some point, because that last statement is already taking things too far from their context. So, please, let me summarize the whole thing, in a (hopefully) clear way: 1) Most of my sites use some URI beautification techniques to aid both user's and spider's navigation (with a significant effort to minimize the impact on the users). My point was that these techniques, as far as I can tell, impose a cost on the user, unless I'm completely misunderstanding how they work... I agree that if you fix up URIs on form submit on client side that cost is pretty small in the common case. 2) Because of (1), I haven't had any need to ever use the filename argument on a Content-Disposition header: my beautified URIs already serve as good enough filenames. 3) Because of (2), I do not hold a strong opinion about how that argument should be handled on the many different scenarios. These two were clear, yes. -Boris
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11, Boris Zbarsky bzbar...@mit.edu wrote: On 6/3/11 11:46 AM, Bjartur Thorlacius wrote: Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. That's slightly better than just using the last non-empty path component, though. It's not, because they're not consistent about it... Why need they be? This isn't Bittorrent. Use the last non-empty path component for a short name prone to accidental clashes, or the title for a verbose, unportable and descriptive name. It's purely a hint for user convenience (so they don't have to invent their own names or retype the title). What a file is named on a client's machine is purely the client's matter.
Re: [whatwg] Form controls inside a label but not labelled by it
On Thu, 17 Feb 2011, Mounir Lamouri wrote: Mozilla has an old Gecko bug [1] lying around about form controls not focusable when they are inside a label that is not labelling them: when the user clicks the form control, because it's part of the label, the activation behaviour is done on the labelled element. Thus, the form control isn't focused. Recently, this bug appeared on GMail [2]: if you try to set a signature with Firefox and the HTML5 parser enabled, you will not be able to focus the textarea but you will focus the radio button instead. You can see a minimized test case here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/839 According to a comment of Hixie in [1], this case has been handled by the specs in 2004 but it doesn't seem to be any more and UA's have a very different behaviour here: - Firefox: focus and activate the labelled element ; - Webkit: focus the form control and activate the labelled element ; - Presto and IE9 RC: focus the form control (doesn't activate the labelled element). I think Webkit's behaviour makes the more sense here and it would be nice to have it specified. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270 Oops, not sure why the text was lost in the WF2 merge. I've added equivalent text back. It describes the Opera/IE behaviour; could you elaborate on why the WebKit behaviour is better? Authors can emulate the WebKit behaviour if they really want it by just calling .click() on the element they want to have activated when the target is focused. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video feedback
I'll be replying to WebVTT related stuff in a separate thread. Here just feedback on the other stuff. (Incidentally: why is there details element feedback in here with video? I don't really understand the connection.) On Fri, Jun 3, 2011 at 9:28 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 16 Dec 2010, Silvia Pfeiffer wrote: I do not know how technically the change of stream composition works in MPEG, but in Ogg we have to end a current stream and start a new one to switch compositions. This has been called sequential multiplexing or chaining. In this case, stream setup information is repeated, which would probably lead to creating a new steam handler and possibly a new firing of loadedmetadata. I am not sure how chaining is implemented in browsers. Per spec, chaining isn't currently supported. The closest thing I can find in the spec to this situation is handling a non-fatal error, which causes the unexpected content to be ignored. On Fri, 17 Dec 2010, Eric Winkelman wrote: The short answer for changing stream composition is that there is a Program Map Table (PMT) that is repeated every 100 milliseconds and describes the content of the stream. Depending on the programming, the stream's composition could change entering/exiting every advertisement. If this is something that browser vendors want to support, I can specify how to handle it. Anyone? Icecast streams have chained files, so streaming Ogg to an audio element would hit this problem. There is a bug in FF for this: https://bugzilla.mozilla.org/show_bug.cgi?id=455165 (and a duplicate bug at https://bugzilla.mozilla.org/show_bug.cgi?id=611519). There's also a webkit bug for icecast streaming, which is probably related https://bugs.webkit.org/show_bug.cgi?id=42750 . I'm not sure how Opera is able to deal with icecast streams, but it seems to deal with it. The thing is: you can implement playback and seeking without any further changes to the spec. But then the browser-internal metadata states will change depending on the chunk you're on. Should that also update the exposed metadata in the API then? Probably yes, because otherwise the JS developer may deal with contradictory information. Maybe we need a metadatachange event for this? On Tue, 24 May 2011, Silvia Pfeiffer wrote: Ian and I had a brief conversation recently where I mentioned a problem with extended text descriptions with screen readers (and worse still with braille devices) and the suggestion was that the paused for user interaction state of a media element may be the solution. I would like to pick this up and discuss in detail how that would work to confirm my sketchy understanding. *The use case:* In the specification for media elements we have a track kind of descriptions, which are: Textual descriptions of the video component of the media resource, intended for audio synthesis when the visual component is unavailable (e.g. because the user is interacting with the application without a screen while driving, or because the user is blind). Synthesized as a separate audio track. I'm for now assuming that the synthesis will be done through a screen reader and not through the browser itself, thus making the descriptions available to users as synthesized audio or as braille if the screen reader is set up for a braille device. The textual descriptions are provided as chunks of text with a start and a end time (so-called cues). The cues are processed during video playback as the video's playback time starts to fall within the time frame of the cue. Thus, it is expected the that cues are consumed during the cue's time frame and are not present any more when the end time of the cue is reached, so they don't conflict with the video's normal audio. However, on many occasions, it is not possible to consume the cue text in the given time frame. In particular not in the following situations: 1. The screen reader takes longer to read out the cue text than the cue's time frame provides for. This is particularly the case with long cue text, but also when the screen reader's reading rate is slower than what the author of the cue text expected. 2. The braille device is used for reading. Since reading braille is much slower than listening to read-out text, the cue time frame will invariably be too short. 3. The user seeked right into the middle of a cue and thus the time frame that is available for reading out the cue text is shorter than the cue author calculated with. Correct me if I'm wrong, but it seems that what we need is a way for the screen reader to pause the video element from continuing to play while the screen reader is still busy delivering the cue text. (In a11y talk: what is required is a means to deal with extended descriptions, which extend the timeline of the video.) Once it's finished presenting, it can resume the video element's playback. Is it a requirement that the user be able to use the regular
