Re: [whatwg] script features
They would be great additions, thanks. 2. scriptwillexecute/scriptdidexecute events Notice that Opera has a richer set of eventsof this kind (exsposed to privileged User Scripts, though, AFAIK), allowing for much more control over the executing scripts, no matter if from script elements, event handlers or URLs: http://www.opera.com/docs/userjs/specs/#evlistener Cheers -- G Jonas Sicking wrote, On 17/08/2010 6.15: Hi All, I'd like to propose a couple of simple features to makescript elements more useful: 1. document.currentScript This property returns the currently executingscript, if any. Returns null if noscript is currently executing. In the case of several nested executingscripts, it returns the innermost one. This is useful for being able to pass parameters to the script by setting data- attributes on the script element. I think jQuery already does things that requires knowing which script element linked to jQuery, and it approximates this property by getting the last element in document.getElementsByTagName(script), which won't work reliably. Especially with features likescript async. 2. scriptwillexecute/scriptdidexecute events These events fire right before and right after ascript is executed. This allows a page to override the context a specific script is seeing. For example installing compatibility shims for older browsers. Another possible use for this is to make ads execute asynchronously. Currently this is problematic because a lot of ads use document.write and so the content will be lost (or worse) if an async attribute is added to thescript element used to load the ad. Using these events a page can override document.write while a specific script is executing and insert the written content into the DOM. (I've written an implementation for firefox for these features here: https://bugzilla.mozilla.org/show_bug.cgi?id=587931) / Jonas
[whatwg] Using BugZilla for non-W3C spec issues
Hi there, http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546 is about a bug in the HTML-to-Atom algorithm, which only survived in the WHATWG document. Ian has rejected the bug as Invalid use of the bug tracking system. Of course the bug is still there, and the WHATWG document actually points to the W3C BugZilla instance for feedback. Something is wrong here. Please either accept bugs for non-W3C portions, or change the feedback system on the WHATWG document. Best regards, Julian
Re: [whatwg] Using BugZilla for non-W3C spec issues
Please don't cross-post e-mails to the WHATWG list. It causes thread fragmentation. On Tue, 17 Aug 2010, Julian Reschke wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546 is about a bug in the HTML-to-Atom algorithm, which only survived in the WHATWG document. As far as I can tell, the bug is already resolved. There's already a note pointing out what you are requesting a note to point out. Ian has rejected the bug as Invalid use of the bug tracking system. Of course the bug is still there, and the WHATWG document actually points to the W3C BugZilla instance for feedback. Something is wrong here. That particular bug was not filed using the bug filing tool in the spec, so I assumed it was a W3C HTML WG bug only. In general, the way to report problems with the WHATWG specs is to send an e-mail to this mailing list. The bug system is a convenience, but since it's using another working group's bug reporting system, it shouldn't really be considered to be part of the WHATWG processes. If there is still a problem with the WHATWG spec's Atom conversion section, please send an e-mail to this mailing list. I can't tell from the bug cited above what problem you are concerned about; it seems fixed already. Please either accept bugs for non-W3C portions, or change the feedback system on the WHATWG document. I've updated the system to not send bugs filed on the Atom section to the HTML5 component at the W3C, since that section isn't in HTML5. However, that wouldn't affect the particular bug cited above, since it didn't use that system. (For the record, the bug reporting system's use of the W3C bug database is done in coordination with W3C staff.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Using BugZilla for non-W3C spec issues
On 17.08.2010 08:46, Ian Hickson wrote: Please don't cross-post e-mails to the WHATWG list. It causes thread fragmentation. The issue affects both groups. On Tue, 17 Aug 2010, Julian Reschke wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546 is about a bug in the HTML-to-Atom algorithm, which only survived in the WHATWG document. As far as I can tell, the bug is already resolved. There's already a note pointing out what you are requesting a note to point out. I don't see any note on the requirements on the source for computing a usable atom:updated element. Citing the original bug report: The computation of the atom:updated timestamp for *updated* entries (see http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.15) surprisingly depends on the presence of ins/del markup (see http://dev.w3.org/html5/spec/interactive-elements.html#atom, Step 15/13). There's nothing really *wrong* about that, but I think the specification needs to clarify that if you don't use ins/del (with timestamps) on an updated entry, the generated atom:updated will be incorrect. Furthermore, Step 15/15: If publication date and update date both still have no value, then let them both value a value that is a valid global date and time string representing the global date and time of the moment that this algorithm was invoked. appears to handle the case where no date information is available at all, letting it default to the current date. Again, generating feeds where atom:updated varies with every run of the algorithm seems to be a bad idea to me and supports the argument that producing output for insufficient input data is problematic. Ian has rejected the bug as Invalid use of the bug tracking system. Of course the bug is still there, and the WHATWG document actually points to the W3C BugZilla instance for feedback. Something is wrong here. That particular bug was not filed using the bug filing tool in the spec, so I assumed it was a W3C HTML WG bug only. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546#c4. So filing a new one from within the WHATWG document would have changed anything? Sounds very bureaucratic to me. In general, the way to report problems with the WHATWG specs is to send an e-mail to this mailing list. The bug system is a convenience, but since it's using another working group's bug reporting system, it shouldn't really be considered to be part of the WHATWG processes. That's why I asked not to use it in this case. If there is still a problem with the WHATWG spec's Atom conversion section, please send an e-mail to this mailing list. I can't tell from the bug cited above what problem you are concerned about; it seems fixed already. I disagree that it is fixed. Please either accept bugs for non-W3C portions, or change the feedback system on the WHATWG document. I've updated the system to not send bugs filed on the Atom section to the HTML5 component at the W3C, since that section isn't in HTML5. However, that wouldn't affect the particular bug cited above, since it didn't use that system. (For the record, the bug reporting system's use of the W3C bug database is done in coordination with W3C staff.) Thanks for making that change. For the record, this issue is also in WHATWG email (sent on 2010-06-02). Best regards, Julian
Re: [whatwg] HTML5 Drag-and-Drop Specification: dragenter
Le 17/08/2010 02:04, Jason Gross a écrit : Is it possible to get more specificity than just the type of the object being dragged? For example, if I have red images and blue images, and a red target and a blue target, and I want to be able to drop red images only on the red target, and blue images only on the blue target, is there a good way to do this, other than globally keep track of which thing is being dragged? I think I give a good example in my e-mail : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027948.html (do Ctrl+F (function to find it). In this e-mail I talk about drag and drop and the fact that for the use case where drag and drop operations occur within the same document, the dataTransfer object is pointless in my opinion. David Thanks. -Jason On Mon, Aug 16, 2010 at 7:57 PM, Daniel Cheng dch...@chromium.org mailto:dch...@chromium.org wrote: I don't think anything in the spec should prevent that. dragenter handlers attached to different drop targets can check event.dataTransfer.types and decide if they want to accept the drag or not. That being said, do any operating systems actually support multiple concurrent drags and drops? WebKit has some built-in assumptions about there being no more than one drag-and-drop operation (per page possibly--I can't test, since I don't have access to a machine with multi-touch capabilities) and I would be surprised if many other applications didn't have this limitation as well. Daniel On Thu, Aug 12, 2010 at 16:26, Jason Gross jasongross9+ht...@gmail.com mailto:jasongross9%2bht...@gmail.com wrote: Greetings, The specification says that the dragenter event is used to determine whether or not the drop target is to accept the drop. Do functions bound to this event get any information about the object being dragged? In particular, is there a good way to have N drop targets, and have each of them accept only certain draggables? If not, it seems to me like a good feature to have, especially as multi-touch applications/devices become more prevalent. Thanks. Sincerely, Jason Gross
Re: [whatwg] (deferred) script tags with document.write built in
On 8/13/2010 2:00 AM, Adam Barth wrote: On Thu, Aug 12, 2010 at 3:02 AM, Brett Zamirbret...@yahoo.com wrote: On 8/12/2010 4:19 PM, Ian Hickson wrote: On Sat, 24 Jul 2010, Brett Zamir wrote: Might there be a way thatscript/tags could add an attribute which combined the meaning of both defer and document.write, whereby the last statement was evaluated to a string, but ideally treated, as far as the DOM, with the string being parsed and replacing the containing script node. For example: script write 'span onmouseover=alert(\''+(new Date())+'\')I\'ve got the date/span' /script If E4X were supported (since we otherwise lamentably have no PHP-style HEREDOC syntax in JavaScript to minimize the few warts above), allowing this to be used could be especially convenient: script write span onmouseover=alert(new Date())I've got the date/span /script (Maybe even a newwrite/tag could be made to do this exclusively and more succinctly.) I chose defer as the default behavior so as to be XHTML-friendly, to allow convenient reference by default to other DOM elements without the need for adding a listener, and the more appealing default behavior of not blocking other content from appearing. Since it doesn't seem that XQuery support will be making it into browsers anytime soon, it would be nice to be able to emulate its clean template-friendly declarative style, dropping the need to find and append to elements, etc.. I don't really see what this proposal would solve. Can you elaborate on what this would allow that can't be done today? It would simplify and beautify the addition of dynamic content and encourage separation of business logic from design logic (at least for content displayed on initial load). For example, using proposed shorter formwrite/, one might do this: script // business logic here var localizedMsg = I've got the date: ; var businessLogicDate = new Date(); /script write span+localizedMsg.toUpperCase() + businessLogicDate +/span /write It would simplify for those with a frequent need for template pages. The template(s) expressed bywrite/ could succinctly express the design logic without need for document.write() used everywhere. The semantically named tag would also distinguish such templates from other scripts. For XHTML, it would be especially useful in being able to offer document.write functionality (since such a tag would be defined as deferring execution until the rest of the page had loaded). No need for onload handlers, no need for adding and referencing IDs in order to find the element, and no need for DOM appending methods in order to provide dynamic content. I agree that a client-side templating system would be very useful. However, we should design it with security in mind. The design you propose above is very XSS-prone because you're concatenating strings. What you want is a templating system that operates after parsing (and possibly after tree construction) but before rendering. If the concern is to accommodate people who use blacklists of tags (which they shouldn't), then instead of write/, I also mentioned script write/. The latter, as a derivative of script, would be prone to XSS, but it would most likely be caught by existing blacklists. In order for a templating system to have enough robustness while not unnecessarily adding yet another syntax or making undue restrictions, I think regular JavaScript would work fine, just cutting out the unnecessary cruft of load events and element finding needed by XHTML and cut out the need for document.write calls for both XHTML and HTML. I think E4X would be far more elegant than strings and ideal (e.g., see https://developer.mozilla.org/en/E4X_for_templating ) and a logical choice, but I proposed the string concatenation to hopefully minimize the changes that would be necessary to add such support in browsers that don't support E4X. Brett
Re: [whatwg] Using BugZilla for non-W3C spec issues
On 17.08.2010 10:36, Ian Hickson wrote: ... The note is lower down. It reads: Note: The above algorithm does not guarantee that the output will be a conforming Atom feed. In particular, if insufficient information is provided in the document (e.g. if the document does not have anymeta name=author content=... elements), then the output will not be conforming. ... I saw that note. It doesn't mention date handling at all. I believe the publishing this algorithm the way it is without clearer instructions on what the input needs to contain is a total disservice to the reader. Enough said. Best regards, Julian
[whatwg] scrollIntoView()
Ian has suggested several times so far that I take over editing of the scrollIntoView() method and define it in the CSSOM View Module: http://dev.w3.org/csswg/cssom-view/ I agree that is a more appropriate place. I played around with it a little and it seems that in browsers other than Opera invoking the method affects the scrolling position of ancestor documents. I.e. if you have a document in an iframe where scrollIntoView() is invoked on an element not only will that document scroll, but the document the iframe is in will scroll as well. In addition this will dispatch events to each document object of which the document is scrolled, and any elements that are scrolled in the process (the order is innermost-outermost, and sync in Webkit, async in Gecko, afaict). I was wondering whether this should happen cross-origin as well. That seems like a minor leak of some sorts. And if that should happen, should the sandbox= attribute disable it? Cheers, -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] scrollIntoView()
On Tue, 17 Aug 2010 13:53:59 +0200, Olli Pettay o...@pettay.fi wrote: What is your testcase here? I was looking at the code and seems like scrollToView is sync in Gecko. And a simple testcase showed that window.scrollY was updated right after the method call. (note, scroll events aren't sync). I was talking about the events. They are synchronous in WebKit as far as I can tell. I'm happy to define them as asynchronous though. Being compatible with Gecko seems better. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal for secure key-value data stores
On Tue, Aug 17, 2010 at 4:00 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 17, 2010 at 12:31 AM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Aug 16, 2010 at 3:58 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Mar 2010, Dirk Pranke wrote: Nicholas is almost certainly discussing the case where the service provider requires any data stored on a customer's computer to be encrypted, not the provider's own computers. (e.g., this could be a Yahoo! policy that data stored on Yahoo! users' computers must be encrypted). Hence they cannot enforce anything like use FileVault. If you can't enforce whole disk encryption, but you are concerned that an attacker could have access to your machine, it seems that there is no solution, since an attacker could just install a rootkit and then carry out arbitrary attacks remotely, including simply replacing the browser with one that intercepts all the user's data as it is written. While it is true that it would not defend against all attacks, it will still defend against some classes of attacks (e.g. casual snooping), and may still be valuable. Adding API surface area to defend against casual snooping seems a bit ridiculous/overkill to me. Especially when web apps can do this in JS today if they really wish. I was not intending to suggest that it was a reason for adding an API, simply to point out that not being able to defend against a rootkit is not a good reason *not* to do it. Especially since full disk encryption won't save you if you've been rooted, either :) I continue to think that the best approach to start with would be to implement a library in JS that did crypto on top of the Platform APIs (and having a native crypto API would be nice as well), and if it turned out to be useful we could roll it into the platform. -- Dirk
Re: [whatwg] script features
Really like the idea, though I think the naming of Opera's events (beforescript, afterscript) fit in better with other events on the page (i.e. beforeunload). -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 Giorgio Maone Sent: Monday, August 16, 2010 11:12 PM To: Jonas Sicking Cc: WHAT Working Group Subject: Re: [whatwg] script features They would be great additions, thanks. 2. scriptwillexecute/scriptdidexecute events Notice that Opera has a richer set of eventsof this kind (exsposed to privileged User Scripts, though, AFAIK), allowing for much more control over the executing scripts, no matter if from script elements, event handlers or URLs: http://www.opera.com/docs/userjs/specs/#evlistener Cheers -- G Jonas Sicking wrote, On 17/08/2010 6.15: Hi All, I'd like to propose a couple of simple features to makescript elements more useful: 1. document.currentScript This property returns the currently executingscript, if any. Returns null if noscript is currently executing. In the case of several nested executingscripts, it returns the innermost one. This is useful for being able to pass parameters to the script by setting data- attributes on the script element. I think jQuery already does things that requires knowing which script element linked to jQuery, and it approximates this property by getting the last element in document.getElementsByTagName(script), which won't work reliably. Especially with features likescript async. 2. scriptwillexecute/scriptdidexecute events These events fire right before and right after ascript is executed. This allows a page to override the context a specific script is seeing. For example installing compatibility shims for older browsers. Another possible use for this is to make ads execute asynchronously. Currently this is problematic because a lot of ads use document.write and so the content will be lost (or worse) if an async attribute is added to thescript element used to load the ad. Using these events a page can override document.write while a specific script is executing and insert the written content into the DOM. (I've written an implementation for firefox for these features here: https://bugzilla.mozilla.org/show_bug.cgi?id=587931) / Jonas
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, Aug 16, 2010 at 10:27 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 17 Aug 2010 06:32:33 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Aug 17, 2010 at 4:05 PM, Ian Hickson i...@hixie.ch wrote: Hmm, good point. Any other suggestions? Mozilla has already added a number of extensions using just a moz prefix ... e.g. mozInnerScreenX, mozPaintCount, mozRequestAnimationFrame. Webkit has added extensions using a webkit prefx ... e.g. webkitDisplayingFullscreen. In theory I guess that pattern could conflict with new features. But in practice it doesn't seem likely unless new engines enter the market and choose prefixes poorly. (I.e., don't choose a prefix that matches an English verb or noun.) Note that this is for element attributes, not interface members. Having said that, vendor-name (i.e. a single dash) is probably sufficient. It seems highly unlikely we will ever use webkit-, ms-, o-, gecko- as an attribute name. In fact, iirc we follow the policy that new attribute names will not have hyphens in them, unless it is for some kind of pattern (like data-). Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. ~TJ
[whatwg] Case canonicalization for reflected enumerated attributes limited to known values
Test case: !doctype html script var el = document.createElement(form); el.setAttribute(method, get); alert(el.method); el.setAttribute(method, GET); alert(el.method); /script Spec: If a reflecting IDL attribute is a DOMString whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values, then, on getting, the IDL attribute must return the conforming value associated with the state the attribute is in (in its canonical case) . . . http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflecting-content-attributes-in-idl-attributes This says it should echo GET twice. Four out of the five browsers I tested in (Firefox 4 beta, Chrome dev, Safari 5, Opera 10.60) echo get and then GET. IE8 and IE9PP4 echo get twice. I think the spec and IE are right here -- you should be able to test form.method == GET (or == get, whichever) and have it work whenever it's in the GET state. However, since 4/5 of browsers disagree, I'm asking if anyone thinks the spec should be changed, before I file browser bugs. (I've also filed a bug suggesting that the canonical case for this keyword be lowercase: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10388 )
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On 12.08.2010 10:09, Philip Jägenstedt wrote: ... The core problem is that WebSRT is far too compatible with existing SRT usage. Regardless of the file extension and MIME type used, it's quite improbable that anyone will have different parsers for the same format. Once media players have been forced to handle the extra markup in WebSRT (e.g. by ignoring it, as many already do) the two formats will be the same, and using WebSRT markup in .srt files will just work, so that's what people will do. We may avoid being seen as arrogant format-hijackers, but the end result is two extensions and two different MIME types that mean exactly the same thing. ... (just observing...) So when something that used to be plain text now carries markup, what's the compatibility story for plain text that happens to contain markup characters, such as , or ? Best regards, Julian
Re: [whatwg] Case canonicalization for reflected enumerated attributes limited to known values
Actually, it goes further than that. Everyone but IE seems to just return the value of the content attribute when you do a get on the IDL attribute: !doctype html script var el = document.createElement(form); el.setAttribute(method, invalid value); alert(el.method); /script IE alerts get, everyone else alerts invalid value. Are non-IE implementers interested in changing to match IE here? IE's behavior seems more useful.
Re: [whatwg] script features
whatwg-requ...@lists.whatwg.org wrote:
Date: Mon, 16 Aug 2010 21:15:35 -0700
From: Jonas Sicking jo...@sicking.cc
To: WHAT Working Group wha...@whatwg.org
Subject: [whatwg] script features
Message-ID:
aanlktin3t5zb4druxj8ws_hiusgs3pmozl8wogrtc...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Hi All,
I'd like to propose a couple of simple features to make script
elements more useful:
1. document.currentScript
This property returns the currently executing script, if any.
Returns null if no script is currently executing. In the case of
several nested executing scripts, it returns the innermost one. This
is useful for being able to pass parameters to the script by setting
data- attributes on the script element.
I wonder if you mean: This property returns the script tag defining
the currently executing top-level function?
So for:
script
var foo = function() {
alert(a foo);
}
foo();
window.addEventListener(load, foo, false);
/script
the property will be null until the script tag is parsed and passed to
the compiler. Then the property will point to the script tag during the
execution of the outer or top level function which defines foo, calls
foo, and sets foo as a load handler. Then the property is null again.
When the load event runs, the property is null.
I think jQuery already does things that requires knowing which
script element linked to jQuery, and it approximates this property
by getting the last element in
document.getElementsByTagName(script), which won't work reliably.
Especially with features like script async.
2. scriptwillexecute/scriptdidexecute events
These events fire right before and right after a script is executed.
This allows a page to override the context a specific script is
seeing. For example installing compatibility shims for older browsers.
But by the time the functions execute, the environment of compilation
has already been bound into the functions. I think you want the event
*before* compilation.
If this kind of event were provided for all compilations, Javascript
debugging would make a quantum leap forward in performance and
reliability. Firebug, for example, uses egregious hacks to fake these
events on the mozilla platform.
jjb
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 20:40:20 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. Yeah, see e.g. the various form* attributes, autofocus, item* attributes. The only new attribute I can think of with a dash is data- and that's a special case. Elements have no dashes at all. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] scrollIntoView()
On Tue, Aug 17, 2010 at 11:56 PM, Anne van Kesteren ann...@opera.comwrote: On Tue, 17 Aug 2010 13:53:59 +0200, Olli Pettay o...@pettay.fi wrote: What is your testcase here? I was looking at the code and seems like scrollToView is sync in Gecko. And a simple testcase showed that window.scrollY was updated right after the method call. (note, scroll events aren't sync). I was talking about the events. They are synchronous in WebKit as far as I can tell. I'm happy to define them as asynchronous though. Being compatible with Gecko seems better. Async events are also generally safer to implement and use. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Thu, Aug 12, 2010 at 6:09 PM, Philip Jägenstedt phil...@opera.comwrote: On Thu, 12 Aug 2010 02:11:55 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Thu, Aug 12, 2010 at 1:26 AM, Philip Jägenstedt phil...@opera.com wrote: On Wed, 11 Aug 2010 15:38:32 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Going with HTML in the cues, we either have to drop voices and inner timestamps or invent new markup, as HTML can't express either. I don't think either of those are really good solutions, so right now I'm not convinced that reusing the innerHTML parser is a good way forward. I don't see a need for the voices - they already have markup in HTML, see above. But I do wonder about the timestamps. I'd much rather keep the innerHTML parser if we can, but I don't know enough about how the timestamps could be introduced in a non-breakable manner. Maybe with a data- attribute? Maybe span data-t=00:00:02.100.../span? data- attributes are reserved for use by scripts on the same page, but we *could* of course introduce new elements or attributes for this purpose. However, adding features to HTML only for use in WebSRT seems a bit odd. I'd rather avoid adding features to HTML only for WebSRT. Ian turned the timestamps into ProcessingInstructions http://www.whatwg.org/specs/web-apps/current-work/websrt.html#websrt-cue-text-dom-construction-rules . Could we introduce something like ?t at=00:00:02.100? without breaking the innerHTML parser? It appears that the innerHTML parser in at least Opera and Firefox handles PIs in some manner, see test at http://software.hixie.ch/utilities/js/live-dom-viewer/saved/587 Chrome and Safari don't though. However, it isn't valid HTML, validator.nu says Saw ?. Probable cause: Attempt to use an XML processing instruction in HTML. (XML processing instructions are not supported in HTML.) Yeah, so the only conforming solution is probably to use CSS3 transition-delay property. That may not be the most elegant solution, but it works. OTOH, if you say that it will take a short time for popular software to start ignoring the extra WebSRT stuff, well, in this case they have implemented WebSRT support in its most basic form and then there is no problem any more anyway. They will then accept the new files and their extensions and mime types and there is explicit support rather than the dodgy question of whether these SRT files will provide crap or not. During a transition period, we will make all software that currently supports SRT become unstable and unreliable. I don't think that's the right way to deal with an existing ecosystem. Coming in as the big brother, claiming their underspecified format, throwing in incompatible features, and saying: just deal with it. It's just not the cavalier thing to do. I agree that it seems (and is) quite selfish, but am not sure the alternatives are any better, see below. About unstable and unreliable, I think there are really only two kind of errors we will see: 1. Some cues being ignored due to trailing settings after the timestamp. Some files may decide at this point that the files are not conformant and fail. 2. Markup being interpreted as plain text. Both already can and do happen with existing use of SRT, which is annoying but better than no subtitles at all. It's a bit more than just annoying to users. If there are automated processes involved that print that stuff on tape for example, you can burn through a lot of material and money before realising that your input files are broken and if you cannot get software support for the new files implemented, you may need to implement costly manual checking of the files. The core problem is that WebSRT is far too compatible with existing SRT usage. Regardless of the file extension and MIME type used, it's quite improbable that anyone will have different parsers for the same format. Once media players have been forced to handle the extra markup in WebSRT (e.g. by ignoring it, as many already do) the two formats will be the same, and using WebSRT markup in .srt files will just work, so that's what people will do. We may avoid being seen as arrogant format-hijackers, but the end result is two extensions and two different MIME types that mean exactly the same thing. It actually burns down to the question: do we want the simple SRT format to survive as its own format and be something that people can rely upon as not having weird stuff in it - or do we not. I believe that it's important that it survives. WebSRT can have absolutely anything in it, including code and binary data, even if that stuff would not be interpreted in a browser, but handed on to the JavaScript API for a JavaScript routine to do something with it.
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Wed, Aug 18, 2010 at 5:12 AM, Julian Reschke julian.resc...@gmx.dewrote: On 12.08.2010 10:09, Philip Jägenstedt wrote: ... The core problem is that WebSRT is far too compatible with existing SRT usage. Regardless of the file extension and MIME type used, it's quite improbable that anyone will have different parsers for the same format. Once media players have been forced to handle the extra markup in WebSRT (e.g. by ignoring it, as many already do) the two formats will be the same, and using WebSRT markup in .srt files will just work, so that's what people will do. We may avoid being seen as arrogant format-hijackers, but the end result is two extensions and two different MIME types that mean exactly the same thing. ... (just observing...) So when something that used to be plain text now carries markup, what's the compatibility story for plain text that happens to contain markup characters, such as , or ? Best regards, Julian I assume you mean: what happens to text that contains such characters? In most SRT systems, such stuff will just be displayed verbatim. Cheers, Silvia.
Re: [whatwg] script features
On Tue, Aug 17, 2010 at 2:17 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
whatwg-requ...@lists.whatwg.org wrote:
Date: Mon, 16 Aug 2010 21:15:35 -0700
From: Jonas Sicking jo...@sicking.cc
To: WHAT Working Group wha...@whatwg.org
Subject: [whatwg] script features
Message-ID:
aanlktin3t5zb4druxj8ws_hiusgs3pmozl8wogrtc...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Hi All,
I'd like to propose a couple of simple features to make script
elements more useful:
1. document.currentScript
This property returns the currently executing script, if any.
Returns null if no script is currently executing. In the case of
several nested executing scripts, it returns the innermost one. This
is useful for being able to pass parameters to the script by setting
data- attributes on the script element.
I wonder if you mean: This property returns the script tag defining the
currently executing top-level function?
So for:
script
var foo = function() {
alert(a foo);
}
foo();
window.addEventListener(load, foo, false);
/script
the property will be null until the script tag is parsed and passed to the
compiler. Then the property will point to the script tag during the
execution of the outer or top level function which defines foo, calls foo,
and sets foo as a load handler. Then the property is null again. When the
load event runs, the property is null.
That is correct. Though it's not related to if the script is top-level
or not. It's simply related to *when* the script statements execute.
The definition would likely be integrated in the steps related to
processing of script elements.
I think jQuery already does things that requires knowing which
script element linked to jQuery, and it approximates this property
by getting the last element in
document.getElementsByTagName(script), which won't work reliably.
Especially with features like script async.
2. scriptwillexecute/scriptdidexecute events
These events fire right before and right after a script is executed.
This allows a page to override the context a specific script is
seeing. For example installing compatibility shims for older browsers.
But by the time the functions execute, the environment of compilation has
already been bound into the functions. I think you want the event *before*
compilation.
Sure (though I'm not sure which environment is compiled in other than
the global object, which you can't replace anyway, at least not for
now).
If this kind of event were provided for all compilations, Javascript
debugging would make a quantum leap forward in performance and reliability.
Firebug, for example, uses egregious hacks to fake these events on the
mozilla platform.
This feature is not enough for that. For example this event is not
fired for onXXX event handlers, calls to eval(), calls to the Function
constructor, calls to WorkerGlobalScope.importScripts or loading of
Workers and SharedWorkers.
For debugging APIs I suggest platform specific notification mechanisms
as they are much more performant and easier to implement.
/ Jonas
Re: [whatwg] script features
Jonas Sicking wrote:
On Tue, Aug 17, 2010 at 2:17 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
whatwg-requ...@lists.whatwg.org wrote:
Date: Mon, 16 Aug 2010 21:15:35 -0700
From: Jonas Sicking jo...@sicking.cc
To: WHAT Working Group wha...@whatwg.org
Subject: [whatwg] script features
Message-ID:
aanlktin3t5zb4druxj8ws_hiusgs3pmozl8wogrtc...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Hi All,
I'd like to propose a couple of simple features to make script
elements more useful:
1. document.currentScript
This property returns the currently executing script, if any.
Returns null if no script is currently executing. In the case of
several nested executing scripts, it returns the innermost one. This
is useful for being able to pass parameters to the script by setting
data- attributes on the script element.
I wonder if you mean: "This property returns the script tag defining the
currently executing top-level function"?
So for:
script
var foo = function() {
alert("a foo");
}
foo();
window.addEventListener("load", foo, false);
/script
the property will be null until the script tag is parsed and passed to the
compiler. Then the property will point to the script tag during the
execution of the outer or top level function which defines foo, calls foo,
and sets foo as a load handler. Then the property is null again. When the
load event runs, the property is null.
That is correct.
Well either this is correct *or* you fire the event before compiling
(see below). I think my description is not correct, and that's good.
Though it's not related to if the script is top-level
or not. It's simply related to *when* the script statements execute.
(It's the function that is top-level.)
I guess you mean by "execute the script", "compile the source
in the tag and run the top-level function"?
...
seeing. For example installing compatibility shims for older browsers.
But by the time the functions execute, the environment of compilation has
already been bound into the functions. I think you want the event *before*
compilation.
Sure
Ok, so before compilation and hence my description above is *not*
correct. Good.
(though I'm not sure which environment is compiled in other than
the global object, which you can't replace anyway, at least not for
now).
Well if I intercept the event and change the source to
with(browserShim) {
... script tag contents here
}
Then I compile into another environment. Otherwise how can I achieve
your goal?
If this kind of event were provided for all compilations, _javascript_
debugging would make a quantum leap forward in performance and reliability.
Firebug, for example, uses egregious hacks to fake these events on the
mozilla platform.
This feature is not enough for that. For example this event is not
fired for onXXX event handlers, calls to eval(), calls to the Function
constructor, calls to WorkerGlobalScope.importScripts or loading of
Workers and SharedWorkers.
But if you don't cover these paths then I don't think the feature is
complete, because what ever developers do in top-level functions of
script tag source they do in all those other cases too.
For debugging APIs I suggest platform specific notification mechanisms
as they are much more performant and easier to implement.
Well I was just suggesting another use case for your suggested feature.
You are suggesting an introspection feature that also has potential for
debugging. Web debuggers are mostly based on introspection APIs, a
notable exception being _javascript_ control. Your feature would be good
step in that direction.
jjb
/ Jonas
Re: [whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
I've defined an explicit concept of a media timeline and defined how you use it, which should make a lot of video-related issues better. On Mon, 17 May 2010, Odin Omdal H�rthe wrote: I stream conferences using Ogg Theora+Vorbis using Icecast2. I have built a site that shows the video and then automatically shows the slides (as PNG files) as well. I use orbited (COMET) to have the server PUSH my �next� presses on my keyboard. The problem is that icecast does heavy buffering, and also the client, so that while I switch the slides, the browser will go from slide 3 to 4 WAY too early (from 10 second to 1 minute). If I could get the timestamp OR time-since-started-sending/recording from the ogg file in javascript, I'd be able to sync everything. There are multiple way to sync this, may even an stream with the slide-data INSIDE the ogg file, however, AFAIK there's also no way of getting out such arbitrary streams. In theory the new timed track API should let you do this. However, I don't really understand why you can't do this in the first place. The currentTime shouldn't be changing while things are buffering, so why would you be going out of sync? On Mon, 17 May 2010, David Singer wrote: Buffering should not make any difference to how far into a stream a time means. If the transition from slide 3 to slide 4 happens at 10 minutes in, then as the presentation time ticks from 9:59 to 10:00 you should flip the slide. It doesn't matter how much data is in any buffers, does it? Indeed. On Mon, 17 May 2010, Nikita Eelen wrote: I think he means something similar to what QuickTime broadcaster and quicktime streaming server does with a delay on a live stream or wowza media server with flash media encoder when using h.264, unless I am misunderstanding something. Is that correct Odin? Not sure how ice cast deals with it but I bet it's a similar issue, On Tue, 18 May 2010, Odin Omdal H�rthe wrote: Yes, I initially used Darwin Streaming Server, but found Icecast2 much better for *my use*. So I use it in the same way. I'm having Icecast buffer 1MB worth of data so that it can burst all that to the client (the browser in this case) so that its own buffering can go faster. So even there we're quite far behind. And also, the browsers often stops up a few seconds, and buffers a bit more, and then continue playing (although they have buffered more than a few seconds ahead already!), so then they are drifting even further away from real time. I would understand it if you couldn't quite determine what the start of the stream was, but I don't understand why you wouldn't understand what the current time was relative to the start. That is, I understand a fixed offset, but I don't see why it would get worse over time. Are you using ontimeupdate and currentTime to track the video? Or are you using something like setTimeout()? However, I think that it's rather hard to find out what the spec means. Because *earliest POSSIBLE*. What is meant by possible? With live streaming it is not possible to go further back in the stream. What do you think? What is meant by this? If it does not help me, then adding a field for getting the _real_ time code data from the video would be very usable. The earliest possible position is just the earliest position in the stream or resource that the user agent can ever obtain again. It's talked about in this example: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-starttime For example, if two clips have been concatenated into one video file, but the video format exposes the original times for the two clips, the video data might expose a timeline that goes, say, 00:15..00:29 and then 00:05..00:38. However, the user agent would not expose those times; it would instead expose the times as 00:15..00:29 and 00:29..01:02, as a single video. That's well and good, but it would be nice to get the actual time code data for live streaming and these syncing uses if startTime is not the earliest time that exists. Justin Dolske's idea looks rather nice: This seems like a somewhat unfortunate thing for the spec, I bet everyone's going to get it wrong because it won't be common. :( I can't help but wonder if it would be better to have a startTimeOffset property, so that .currentTime et al are all still have a timeline starting from 0, and if you want the real time you'd use .currentTime + .startTimeOffset. I've added a startTimeOffset attribute that returns a Date representing the time corresponding to zero on the media element's timeline (as used by currentTime and startTime). What should we do with video files that have multiple overlapping times? Just use the first timeline in the file/stream? I've done that for now. I'd also suspect we'll want the default video controls to normalize everything to 0 (.currentTime -
Re: [whatwg] script features
On Tue, Aug 17, 2010 at 6:14 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Jonas Sicking wrote:
On Tue, Aug 17, 2010 at 2:17 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
whatwg-requ...@lists.whatwg.org wrote:
Date: Mon, 16 Aug 2010 21:15:35 -0700
From: Jonas Sicking jo...@sicking.cc
To: WHAT Working Group wha...@whatwg.org
Subject: [whatwg] script features
Message-ID:
aanlktin3t5zb4druxj8ws_hiusgs3pmozl8wogrtc...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Hi All,
I'd like to propose a couple of simple features to make script
elements more useful:
1. document.currentScript
This property returns the currently executing script, if any.
Returns null if no script is currently executing. In the case of
several nested executing scripts, it returns the innermost one. This
is useful for being able to pass parameters to the script by setting
data- attributes on the script element.
I wonder if you mean: This property returns the script tag defining the
currently executing top-level function?
So for:
script
var foo = function() {
alert(a foo);
}
foo();
window.addEventListener(load, foo, false);
/script
the property will be null until the script tag is parsed and passed to the
compiler. Then the property will point to the script tag during the
execution of the outer or top level function which defines foo, calls foo,
and sets foo as a load handler. Then the property is null again. When the
load event runs, the property is null.
That is correct.
Well either this is correct *or* you fire the event before compiling (see
below). I think my description is not correct, and that's good.
I'm not sure which event you are referring to here?
Though it's not related to if the script is top-level
or not. It's simply related to *when* the script statements execute.
(It's the function that is top-level.)
I guess you mean by execute the script, compile the source in the tag
and run the top-level function?
To get to specification level detail, I mean:
In the If the load was successful algorithm at [1], insert a step
before the current step 3 which says:
Set the documents /current-script/ to the script element node.
And insert a step after the current step 3 which says:
Set the documents /current-script/ to the value it had before it was
modified above.
And define a currentScript IDL attribute on Document which returns the
documents /current-script/ property.
[1] http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block
(though I'm not sure which environment is compiled in other than
the global object, which you can't replace anyway, at least not for
now).
Well if I intercept the event and change the source to
with(browserShim) {
... script tag contents here
}
Then I compile into another environment. Otherwise how can I achieve your
goal?
These events in and of themselves doesn't allow you to modify the
script source. This does seem like a neat idea, if you have ideas for
how this would be done please do suggest them here.
What I was thinking was simply allowing the event handler to do things like:
var oldWrite;
myWillExecuteHandler(event) {
oldWrite = document.write;
document.write = myWriteOverride;
}
myDidExecuteHandler(event) {
document.write = oldWrite;
}
If this kind of event were provided for all compilations, Javascript
debugging would make a quantum leap forward in performance and reliability.
Firebug, for example, uses egregious hacks to fake these events on the
mozilla platform.
This feature is not enough for that. For example this event is not
fired for onXXX event handlers, calls to eval(), calls to the Function
constructor, calls to WorkerGlobalScope.importScripts or loading of
Workers and SharedWorkers.
But if you don't cover these paths then I don't think the feature is
complete, because what ever developers do in top-level functions of script
tag source they do in all those other cases too.
It's not intended for implementing debuggers. I suspect a debugging
API would require something significantly more complex in order to
deal with all the features I listed. For one, how would you deal with
the fact that workers can cause scripts to compile and evaluate on
multiple threads?
If you have suggestions I'm all ears.
/ Jonas
Re: [whatwg] script features
On 8/17/2010 6:43 PM, Jonas Sicking wrote:
...
[1] http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block
Ok so I see where executing a script block becomes executing script.
(though I'm not sure which environment is compiled in other than
the global object, which you can't replace anyway, at least not for
now).
Well if I intercept the event and change the source to
with(browserShim) {
... script tag contents here
}
Then I compile into another environment. Otherwise how can I achieve your
goal?
These events in and of themselves doesn't allow you to modify the
script source. This does seem like a neat idea, if you have ideas for
how this would be done please do suggest them here.
For example,
myWillExecuteHandler = function(event)
{
var elt = event.target;
var adulterate = with(shim){\n+elt.innerHTML+}\n;
eval(adulterate);
return false; // need some way to abort the script tag in progress.
}
What I was thinking was simply allowing the event handler to do things like:
var oldWrite;
myWillExecuteHandler(event) {
oldWrite = document.write;
document.write = myWriteOverride;
}
myDidExecuteHandler(event) {
document.write = oldWrite;
}
But I guess you don't need events to modify and restore the environment,
why not just put a script before and after:
script
oldWrite = document.write;
document.write = function(msg) { console.log(msg); }
/script
script
document.write(I command you!);
/script
script
document.write = oldWrite;
/script
If this kind of event were provided for all compilations, Javascript
debugging would make a quantum leap forward in performance and reliability.
Firebug, for example, uses egregious hacks to fake these events on the
mozilla platform.
This feature is not enough for that. For example this event is not
fired for onXXX event handlers, calls to eval(), calls to the Function
constructor, calls to WorkerGlobalScope.importScripts or loading of
Workers and SharedWorkers.
But if you don't cover these paths then I don't think the feature is
complete, because what ever developers do in top-level functions of script
tag source they do in all those other cases too.
It's not intended for implementing debuggers. I suspect a debugging
API would require something significantly more complex in order to
deal with all the features I listed. For one, how would you deal with
the fact that workers can cause scripts to compile and evaluate on
multiple threads?
Again, its not a debugging API, it's just the same API you propose. If
workers cause scripts to compile, and it triggers event handlers they
run on the worker thread (and consequently cannot operate on the UI).
And if you want to talk about complex, let's talk about what developers
have to do now or what debugger have to do to try to help them.
jjb
