Re: [whatwg] script features
On Tue, Aug 17, 2010 at 9:45 PM, John J. Barton
johnjbar...@johnjbarton.com wrote:
(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.
}
This doesn't work for external scripts. I.e. ones with a src attribute.
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
This doesn't work if the script whose evironment you want to modify is
an asynchronous script. It also is significantly more cumbersome,
especially if you want to do this to several script elements in your
page. It also doesn't work if some parts of your markup is generated
by other libraries or components that you don't directly control,
which is exactly the situation when you generally want to use shims.
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.
I'm all for improving debuggers. However I don't see a need to expose
the APIs that debuggers need to web pages. If there are features that
web pages need, and that debuggers happen to be able to use, then
that's great. But features should be added based on if web pages need
them, not if debuggers or implementations need them internally.
/ Jonas
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On 18.08.2010 00:43, Silvia Pfeiffer wrote: On Wed, Aug 18, 2010 at 5:12 AM, Julian Reschke julian.resc...@gmx.de mailto:julian.resc...@gmx.de wrote: 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. Yes, in SRT. But in WebSRT? Isn't there a compatibility problem when the format just switches from plain text to possibly escaped text? (I recall the problems with title handling in RSS, and I want to make sure that people have considered this issue) Best regards, Julian
Re: [whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Wed, Aug 18, 2010 at 11:13 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 24 May 2010, Philip Jägenstedt wrote: I think we both agree but aren't understanding each other very well, or I'm not thinking very clearly. People will write players assuming that currentTime starts at 0 and ends at duration. If this is not the case they will break, so an API which makes this not be the case in very few cases isn't very nice. Agreed. I've made the API clearly say that duration is the time at the end, even in the case where the start is not actually zero, to sidestep this issue somewhat. (The start will almost always be zero, so the slightly misleading name seems like a non-issue.) It's a shame we are using the word duration instead of the more appropriate word endTime for this. Would it be too difficult to change it at this time? Cheers, Silvia.
Re: [whatwg] Video with MIME type application/octet-stream
On 20.05.2010 20:53, Simon Pieters wrote: On Thu, 20 May 2010 20:18:43 +0200, David Singer sin...@apple.com wrote: It's an error to have a parameter that isn't valid for the mime type, so are you suggesting (a) that you throw away the parameter as it's invalid or (b) since it's an error to supply application/octet-stream as the mime type in the first place, we may as well process its invalid parameter in an attempt to recover? I'm just suggesting that it should be defined what to do when you get application/octet-stream with parameters. I don't care which handling that is, or whether it's valid or why the specific handling was chosen. Picking up an old thread because of http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202. From http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.1: Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize. So, as codecs is not defined on application/octet-stream, the parameter simply should be ignored, thus the advice in http://dev.w3.org/html5/spec/Overview.html#rel-archives: The MIME type application/octet-stream with no parameters is never a type that the user agent knows it cannot render. User agents must treat that type as equivalent to the lack of any explicit Content-Type metadata when it is used to label a potential media resource. In the absence of a specification to the contrary, the MIME type application/octet-stream when used with parameters, e.g. application/octet-stream;codecs=theora, is a type that the user agent knows it cannot render. is incorrect, because it requires handling application/octet-stream and application/octet-stream;codecs=theora differently (*). Best regards, Julian (*) It's also not clear whether the note applies to all parameters or just codecs.
[whatwg] Clarifying the use and requirements of Data URL
Currently the specification requires the use of Data URLs for canvas.toDataURL[1] and refers to usage of them a number of times as well[2][3]. While steps describing how to generate a Data URL are defined in the specification[4], they are not being referenced by the other occurrences. These steps seem to be identical to the contents of RFC 2397[5], The data URL scheme by Larry Masinter. Next to that, the specification does not list when Data URLs should be supported by an User Agent. WebKit, Gecko and Presto seem to accept them as any resource, including locations entered via the address bar, while Trident only accepts Data URLs for images and scripts. I believe the use and requirements of Data URLs in the specification could be clarified by: - Referring to RFC 2397 for information about their composition and syntax *or* generalize the steps described in the form submission algorithm[4], so they can be applied on the entire document. - Extend the accepted values of @src, @href, @action et al to include support for data: URLs. Thank you, Peter Beverloo [1] http://www.whatwg.org/specs/web-apps/current-work/#dom-canvas-todataurl [2] http://www.whatwg.org/specs/web-apps/current-work/#submit-data-post [3] http://www.whatwg.org/specs/web-apps/current-work/#sandboxOrigin [4] http://www.whatwg.org/specs/web-apps/current-work/#submit-data-put [5] http://tools.ietf.org/html/rfc2397
Re: [whatwg] script features
On 8/17/2010 11:52 PM, Jonas Sicking wrote:
On Tue, Aug 17, 2010 at 9:45 PM, John J. Barton
johnjbar...@johnjbarton.com wrote:
(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.
}
This doesn't work for external scripts. I.e. ones with a src attribute.
I think is it appropriate for the proposed event to have a property
pointing to the source.
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
This doesn't work if the script whose evironment you want to modify is
an asynchronous script. It also is significantly more cumbersome,
Similarly script tag event approach only works in async cases which
rely on script tags; it won't work if the async is caused by eg window
load event handlers or setTimeouts. The proposal offers only partial
support for intercepting Javascript before compilation, I think it
should offer complete support.
especially if you want to do this to severalscript elements in your
page. It also doesn't work if some parts of your markup is generated
by other libraries or components that you don't directly control,
which is exactly the situation when you generally want to use shims.
I don't understand this. The script tag event fires and runs code
before and after the script tag content is compiled and the top level
function runs. The above example runs code before and after the script
tag content is compiled and the top-level function runs. How can one not
get the same answer? I suppose the body of the target script tag could
prevent the trailing script from running, but it could also prevent the
event handler.
jjb
Re: [whatwg] script features
On Tue, Aug 17, 2010 at 10:39 PM, John J. Barton
johnjbar...@johnjbarton.com wrote:
On 8/17/2010 11:52 PM, Jonas Sicking wrote:
On Tue, Aug 17, 2010 at 9:45 PM, John J. Barton
johnjbar...@johnjbarton.com wrote:
(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.
}
This doesn't work for external scripts. I.e. ones with a src attribute.
I think is it appropriate for the proposed event to have a property pointing
to the source.
I'll have to think about it, might not be a bad idea. Curious to get
input from others 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;
}
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
This doesn't work if the script whose evironment you want to modify is
an asynchronous script. It also is significantly more cumbersome,
Similarly script tag event approach only works in async cases which rely
on script tags; it won't work if the async is caused by eg window load
event handlers or setTimeouts. The proposal offers only partial support for
intercepting Javascript before compilation, I think it should offer complete
support.
It's not a proposal for intercepting all script compilation. It's a
bit unclear to me what the use case for a webpage to intercept all
compilation is? It also seems significantly more complex in the face
of things like workers and language features like eval and setTimeout.
The use case here is being able to intercept the execution when
linking to a particular library. I could also see wanting to intercept
the compilation and initial execution of on* attributes as that would
allow you to intercept all execution that happens in a particular
subtree. This is useful if you get a chunk of HTML, rather than simply
a script url, from an external source.
especially if you want to do this to severalscript elements in your
page. It also doesn't work if some parts of your markup is generated
by other libraries or components that you don't directly control,
which is exactly the situation when you generally want to use shims.
I don't understand this. The script tag event fires and runs code before
and after the script tag content is compiled and the top level function
runs. The above example runs code before and after the script tag content is
compiled and the top-level function runs. How can one not get the same
answer? I suppose the body of the target script tag could prevent the
trailing script from running, but it could also prevent the event handler.
Your solution requires modifying the HTML markup. My solution only
requires attaching an event handler to the document node. The former
isn't always possible, and the latter is almost always significantly
easier.
/ Jonas
[whatwg] Narendra Sisodiya has invited you to use Google Talk
Narendra Sisodiya has invited you to sign up for Google Talk so you can talk to each other for free over your computers. To sign-up, go to: http://www.google.com/accounts/NewAccount?service=talksendvemail=trueskipvpage=truereqemail=wha...@lists.whatwg.orgcontinue=http://www.google.com/talk/service/handleinvite?p%3DFdIQViwBAAA.JwT5o2O1PymXQrEalpo34p7xoNrg2iTt4c0VRJS-r9PEYq7rbZsVoXZgzwA-wl_1ysJlL6sTcqiwZdWKXx7ClA.IG0FJMrso_ZUUypYfc97bgfollowup=http://www.google.com/talk/service/HandleEmailVerified?ee%3DFdIQViwBAAA.wA-fH2ePyy-U4bmPl2DDFGEWCv1-eva-hs5SeNf3NWQ.uAEeifAreJwpzOt9a6xnPQ%26p%3DFdIQViwBAAA.JwT5o2O1PymXQrEalpo34p7xoNrg2iTt4c0VRJS-r9PEYq7rbZsVoXZgzwA-wl_1ysJlL6sTcqiwZdWKXx7ClA.IG0FJMrso_ZUUypYfc97bg Google Talk is a downloadable Windows* application that offers: - Free calls over your computer anytime, from anywhere, and for as long as you want - A simple and intuitive user interface for sending instant messages or making calls--no clutter, pop-ups or ads - Superior voice quality through just a microphone and computer speaker - Fast file transfers with no restrictions on file type After signing-up, download Google Talk and sign in with your new Google Account username and password. You can then begin inviting anyone you want to talk to for free. Google Talk works with any computer speaker and microphone, such as the ones built-in to many PC laptops today, as well as with wired and wireless headsets and USB phones. Google Talk also works across all firewalls. Google Talk is still in beta. Just like with Gmail, we're working hard to add features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making it even better! Thanks, The Google Talk Team To learn more about Google Talk before signing up, visit: http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). * Not a Windows user? No problem. You can also connect to the Google Talk service from any platform using third-party clients (http://www.google.com/talk/otherclients.html).
Re: [whatwg] Narendra Sisodiya has invited you to use Google Talk
On Thu, Aug 19, 2010 at 12:33 AM, Narendra Sisodiya naren...@narendrasisodiya.com wrote: I extremely sorry for this act. I do not know how this happened. Even I have not invited any user on Google Chat. I do manage 10+ online communities and I consider this as a criminal activity. Please forgive me. I will check how this is done. Thanks -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘
