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
Re: [whatwg] Content-Disposition property for a tags
On 5/26/11, Michal Zalewski lcam...@coredump.cx 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] Content-Disposition property for a 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 a 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 a 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 a tags
On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski lcam...@coredump.cx 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 a tags
Am 02.06.2011, 21:58 Uhr, schrieb Glenn Maynard gl...@zewt.org: On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski lcam...@coredump.cx 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] 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 rn...@webkit.org 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 o...@chromium.org wrote: On Tue, May 10, 2011 at 9:51 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai o...@chromium.org wrote: On Tue, May 10, 2011 at 8:55 AM, Tim Down timd...@gmail.com 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] Generalized execCommand() alternatives, or standardized selection and range handling
On 31 May 2011 18:39, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 31, 2011 at 4:15 AM, Markus Ernst derer...@gmx.ch 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 IE9, 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] Video feedback
On Thu, Jun 2, 2011 at 7:28 PM, Ian Hickson i...@hixie.ch wrote:
We can add comments pretty easily (e.g. we could say that ! starts a
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 br 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 nbsp; escape? Inserting
nbsp literally into files is somewhat annoying for authoring, since
they're indistinguishable from regular spaces.
How common would nbsp; be?
I guess the main cases I've used nbsp for don't apply so much to
captions, eg. ©nbsp;2011 (likely to come at the start of a caption,
so not likely to be wrapped anyway).
We
