Re: [whatwg] Video feedback
On Thu, Jun 2, 2011 at 7:58 PM, Glenn Maynard wrote: > The most straightforward solution would seems to be having @lang be a > CSS property; I don't know the rationale for this being done by HTML > instead. The language of a block of text is a property of the content, not a styling attribute. It must be carried by the content itself. As an interesting aside, the direction of a block of text is a property of the content as well, but CSS has a 'direction' property. We only added that because XML didn't define a generic @dir attribute, so we needed *some* way for generic XML languages to specify the text direction (in this case, by specifying their own direction-specifying attribute and then providing a default stylesheet that sets 'direction' based on that). If XML had specified xml:dir like they did xml:lang, 'direction' wouldn't exist. Similarly, if XML hadn't specified xml:lang, we'd probably have a 'language' property. ~TJ
Re: [whatwg] Video feedback
On Thu, Jun 2, 2011 at 7:28 PM, Ian Hickson wrote: > We can add comments pretty easily (e.g. we could say that " comment and ">" ends it -- that's already being ignored by the current > parser), if people really need them. But are comments really that useful? > Did SRT have problem due to not supporting inline comments? (Or did it > support inline comments?) I've only worked with SSA subtitles (fansubbing), where {text in braces} effectively worked as a comment. We used them a lot to communicate between editors on a phrase-by-phrase basis. But for that use case, using hidden spans makes more sense, since you can toggle them on and off to view them inline, etc. Given that, I'd be fine with a comment format that doesn't allow mid-cue comments, if it makes the format simpler. >> The text on the left is a transcription, the top is a transliteration, >> and the bottom is a translation. > > Aren't these three separate text tracks? They're all in the same track, in practice, since media players don't play multiple subtitle tracks. It's true that having them in separate tracks would be better, so they can be disabled individually. This is probably rare enough that it should just be sorted out with scripts, at least to start. > It's not clear to me that we need language information to apply proper > font selection and word wrapping, since CSS doesn't do it. But it doesn't have to, since HTML does this with @lang. > Mixing one CJK language with one non-CJK language seems fine. That should > always work, assuming you specify good fonts in the CSS. The font is ultimately in the user's control. I tell Firefox to always use Tahoma for Western text and MS Gothic for Japanese text, ignoring the often ugly site-specified fonts. The only control sites have over my fonts is the language they say the text is (or which the whole page is detected as). The same principle seems to apply for captions. (That's not to say that it's important enough to add yet and I'm fine with punting on this, at least for now. I just don't think specifying fonts is the right solution.) The most straightforward solution would seems to be having @lang be a CSS property; I don't know the rationale for this being done by HTML instead. > I don't understand why we can't have good typography for CJK and non-CJK > together. Surely there are fonts that get both right? I've never seen a Japanese font that didn't look terrible for English text. Also, I don't want my font selection to be severely limited due to the need to use a single font for both languages, instead of using the right font for the right text. >> One example of how this can be tricky: at 0:17, a caption on the bottom >> wraps and takes two lines, which then pushes the line at 0:19 upward >> (that part's simple enough). If instead the top part had appeared >> first, the renderer would need to figure out in advance to push it >> upwards, to make space for the two-line caption underneith it. >> Otherwise, the captions would be forced to switch places. > > Right, without lookahead I don't know how you'd solve it. With lookahead > things get pretty dicey pretty quickly. The problem is that, at least here, the whole scene is nearly incomprehensible if the top/bottom arrangement isn't maintained. Lacking anything better, I suspect authors would use similar brittle hacks with WebVTT. Anyway, I don't have a simple solution either. >> I think that, no matter what you do, people will insert line breaks in >> cues. I'd follow the HTML model here: convert newlines to spaces and >> have a separate, explicit line break like if needed, so people >> don't manually line-break unless they actually mean to. > > The line-breaks-are-line-breaks feature is one of the features that > originally made SRT seem like a good idea. It still seems like the neatest > way of having a line break. But does this matter? Line breaks within a cue are relatively uncommon in my experience (perhaps it's different for other languages), compared to how many people will insert line breaks in a text editor simply to break lines while authoring. If you do this while testing on a large monitor, it's likely to look reasonable when rendered; the brokenness won't show up until it's played in a smaller window. Anyone using a non-programmer's text editor that doesn't handle long lines cleanly is likely to do this. Wrapping lines manually in SRTs also appears to be common (even standard) practice, perhaps due to inadequate line wrapping in SRT renderers. Making line breaks explicit should help keep people from translating this habit to WebVTT. >> Related to line breaking, should there be an escape? Inserting >> nbsp literally into files is somewhat annoying for authoring, since >> they're indistinguishable from regular spaces. > > How common would be? I guess the main cases I've used nbsp for don't apply so much to captions, eg. © 2011 (likely to come at the start of a caption, so not likely to be wrapp
Re: [whatwg] Blacklist for regsiterProtocolHandler()
webcal should also be whitelisted. James On Sat, Apr 23, 2011 at 6:41 AM, timeless wrote: > > On Fri, Apr 22, 2011 at 1:07 AM, Michael A. Puls II > wrote: > > Besides mailto, these should be white-listed: > > > > mms > > nntp > > news > > > rtsp
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On 31 May 2011 18:39, Aryeh Gregor wrote: > On Tue, May 31, 2011 at 4:15 AM, Markus Ernst wrote: >> Anyway, everything we need is actually available in the DOM, except a >> standardized and simple handling of selections and ranges. (Well, I might be >> wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, >> they show very different approaches to the range and selection objects, and >> the code of TinyMCE shows lots of browser sniffing.) > > That's because browsers' implementations don't follow the specs, or in > some cases because there weren't specs until the last few months, not > because there's anything wrong with the spec. I've implemented all my > algorithms in pure JavaScript, and there are almost no places where I > have to work around browser bugs -- given that I only target the > latest versions of IE/Firefox/Chrome/Opera. implementation.js is over > 4000 lines, and I estimate I've needed maybe ten browser-specific > workarounds, certainly under twenty. (If you want to support IE<9, of > course, have fun . . .) I'm working on this. There was a perverse pleasure in getting to a workable version of the Range and Selection APIs in IE < 9, and the commands stuff I've recently built on top based on (a slightly outdated version of) Aryeh's code has required relatively little browser-specific code to get bold and italic working. Very rough demo here (works in IE 6 - 8 as well as sensible browsers): http://rangy.googlecode.com/svn/branches/1point2/demos/commands.html. > The only major thing that can't be done in JS is change how ranges > behave when you mutate the DOM. Effectively, I work around it by > using a single Range object to represent the user's selection, and I > only care how that changes. This might actually be the way I'll end > up speccing it too, although it'd be nice if we could preserve ranges > outside the selection too. My version passes an array of ranges to be preserved to the command's various internal methods. Works with multiple selected ranges in Firefox. Tim
Re: [whatwg] Selection events in editable content
TL;DR version: Having Selections update as the DOM is modified seems to me like considerable added complexity without a good use-case. 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. On Tue, May 10, 2011 at 10:49 AM, Ryosuke Niwa wrote: > One implication of adding newSelection property is that this selection may > behave differently against DOM mutations at least in WebKit's > implementation. > > Should newSelection be updated upon DOM mutations by scripts and user > actions in the same way frame's selection will be updated? On one hand, > this will ensure that base and extent nodes offsets are resilient against > DOM mutations but will degrade the performance with O(n) where n is the > number of newSelection objects on the other hand. Any opinions? > > - Ryosuke > > On Tue, May 10, 2011 at 9:57 AM, Ojan Vafai wrote: > > > On Tue, May 10, 2011 at 9:51 AM, Ryosuke Niwa wrote: > > > >> On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai wrote: > >> > >>> On Tue, May 10, 2011 at 8:55 AM, Tim Down wrote: > >>> > newSelectionRanges on its own wouldn't be as useful as possible, since > it tells you nothing about the selection direction. You could cover > this by adding newSelectionFocusNode, newSelectionFocusOffset, > newSelectionAnchorNode and newSelectionAnchorOffset as well. > > >>> > >>> Could we just put a Selection object on the event? That way, if we add > >>> new fields to Selections, we won't need to add new fields to the > selectstart > >>> event. > >>> > >> > >> Should we support methods such as modify, collapse, setPosition? > >> > > > > Yes. > > >
Re: [whatwg] "Content-Disposition" property for tags
Am 02.06.2011, 21:58 Uhr, schrieb Glenn Maynard : On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski wrote: I don't think the issue raised was about getting people to save files, though. If you can get someone to click a link, you can already point them at something that sets the HTTP C-D header. The origin of a download is one of the best / most important indicators people have right now (which, by itself, is a bit of a shame). I just think it would be a substantial regression to make it possible for microsoft.com or google.com to unwittingly serve .exe / .jar / .zip / .rar files based on third-party markup. Firefox and MSIE display the origin fairly prominently, IIRC; Chrome displays it in some views. But deficiencies of current UIs are probably a separate problem. Firefox displays it in a small, unimportant-looking piece of text inside a busy dialog; I never even consciously noticed it until I looked for it. For me, Chrome doesn't say anything; when I click an .EXE it saves it to disk without asking (maybe I changed a preference somewhere--that seems like an unlikely default). When I download a file, I decide whether to trust "dangerous" file types based on who's telling me to download it--that is, based on the site linking the file, not the site hosting it. I'd strongly suspect that more people look at who's linking the file (eg. where they were when they clicked the link), and that very few people examine the "from:" text in the save-as dialog. Either way, again this is something that can be dealt with in UI, for example by displaying the source URL as the source of the download rather than or in addition to the domain hosting the file when this attribute is used. It's a weak argument against this feature. Also it doesn't matter since the content-disposition can be changed in http headers anyway. So almost every case can be applied to this too. If somebody wants to do evil things on your computer, he'd just use the http header. We might only make it easier for them. Less programming skills needed. Security is a) the browser displaying security-relevant info the user and b) the user USING the security relevant info. The user still has to decide if he wants to open the file. Also, the browsers could do primitive guesswork. Example: txt file content-dispositioned as .pl, .php, etc. Browser can give a warning based on this. If it's a php file content-dispositioned as a exe, txt, etc file, it would not raise a warning, since php files from the server are usually server-sided scripts. 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?
Re: [whatwg] "Content-Disposition" property for tags
On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski wrote: >> I don't think the issue raised was about getting people to save files, >> though. If you can get someone to click a link, you can already point >> them at something that sets the HTTP C-D header. > > The origin of a download is one of the best / most important > indicators people have right now (which, by itself, is a bit of a > shame). I just think it would be a substantial regression to make it > possible for microsoft.com or google.com to unwittingly serve .exe / > .jar / .zip / .rar files based on third-party markup. > > Firefox and MSIE display the origin fairly prominently, IIRC; Chrome > displays it in some views. But deficiencies of current UIs are > probably a separate problem. Firefox displays it in a small, unimportant-looking piece of text inside a busy dialog; I never even consciously noticed it until I looked for it. For me, Chrome doesn't say anything; when I click an .EXE it saves it to disk without asking (maybe I changed a preference somewhere--that seems like an unlikely default). When I download a file, I decide whether to trust "dangerous" file types based on who's telling me to download it--that is, based on the site linking the file, not the site hosting it. I'd strongly suspect that more people look at who's linking the file (eg. where they were when they clicked the link), and that very few people examine the "from:" text in the save-as dialog. Either way, again this is something that can be dealt with in UI, for example by displaying the source URL as the source of the download rather than or in addition to the domain hosting the file when this attribute is used. It's a weak argument against this feature. -- Glenn Maynard
Re: [whatwg] "Content-Disposition" property for tags
> I don't think the issue raised was about getting people to save files, > though. If you can get someone to click a link, you can already point > them at something that sets the HTTP C-D header. The origin of a download is one of the best / most important indicators people have right now (which, by itself, is a bit of a shame). I just think it would be a substantial regression to make it possible for microsoft.com or google.com to unwittingly serve .exe / .jar / .zip / .rar files based on third-party markup. Firefox and MSIE display the origin fairly prominently, IIRC; Chrome displays it in some views. But deficiencies of current UIs are probably a separate problem. /mz
Re: [whatwg] "Content-Disposition" property for tags
I don't think the issue raised was about getting people to save files, though. If you can get someone to click a link, you can already point them at something that sets the HTTP C-D header. As I recall, the concern was about getting people to do this on files that appear to be from a trusted domain. That is, evil.com linking to a perl script on trusted.com (or, say, a dual-mode image/ELF file), setting C-D in the link to get it to save-as, perhaps hoping that people will see "from: http://trusted.com"; in the save-as dialog. (I doubt that most users look at that at all; Chrome doesn't even seem to bother displaying it.) At worst, it just seems like a minor UI design issue. -- Glenn Maynard
Re: [whatwg] "Content-Disposition" property for tags
> On Linux you may have comprehensive mailcap lists in /etc, or better > yet the filename extension to MIME type mappings used by httpds. Which still don't necessarily map to the behavior of every single file manager; some of them come with their own rules (heck, even mc does that IIRC), some rely on /usr/bin/file. Plus, the solution needs to be portable. It's really non-trivial, and the the current approach taken by Firefox works only in rudimentary cases. /mz
Re: [whatwg] "Content-Disposition" property for tags
On 5/26/11, Michal Zalewski wrote: > Keep in mind that the mechanism *is* extremely imperfect. It only > works for MIME types and extensions recognized by the browser (which > is a small list). There's a large disconnect between this set, the set > handled by the OS, and the actual logic used to control content > disposition later on (much more messy on Linux than on Windows, > interestingly). > On Linux you may have comprehensive mailcap lists in /etc, or better yet the filename extension to MIME type mappings used by httpds. > Unless it becomes common for file systems to support MIME type > metadata for every file, and for all client applications to honor it, > I really think that giving the markup such control over content > disposition does more harm than good. > Browsers need to recognize the filename extensions to be able to utilize the filename hint securely, and the filename hint's raison d'être is providing filename extensions in case the browser doesn't know it. It's therefore harmful when it's potentially useful.
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
I brought this up a while ago as well: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028868.html Echoing Ilya: this is actually a very important feature because generally you don't want long-lived connections (HTTP streaming) and short-lived connections (web page requests) going through the same hosts. -Nicholas __ Commander Lock: "Dammit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of ilya goberman Sent: Wednesday, June 01, 2011 11:24 AM To: whatwg@lists.whatwg.org Subject: [whatwg] Enhancement request: change EventSource to allow cross-domain access Can EventSource be enhanced to support cross-domain requests via "Access-Control-Allow-Origin" header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862 The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains. Is support for EventSource cross domains planned at all? It is supposedly one of the most requested features, but I do not know how it is tracked. Thanks