Re: [whatwg] setting .src of a SCRIPT element
On 31/05/07, Jonas Sicking [EMAIL PROTECTED] wrote: I agree this is a problem. I see several non-solutions that simply would close the issue without dealing with valid concerns. The only solution I see that actually handles most concerns is to not execute inline scripts at all without some API call on the script element to tell that it's been set up fully. What if you were building a script body in many text nodes and CDATA nodes and entity reference nodes where you only have a final, executable form once you have set it all up? It makes sense to me to have an API function for triggering evaluation of the script inline contents. What we do is that we don't execute the script until it is inserted into the DOM. This is consistent with how most elements work, i.e. they don't affect the document until they are actually inserted into it. Neither would my suggested behaviour, but executing ONLY when inserting into the document hierarchy would be entirely acceptable in my view. It only makes for script.parentNode.replaceChild(script,script) instead of script.evaluate(true) as the way to evaluate the script after changing it. It relies on being able to execute more than one, but a script.cloneNode(true) should be able to deal with even that. This way you can build a script element containing whatever you want and then insert it into the document. You can even build a script element with both src set and has inline content so that you'll get the fallback behaviour exactly like parsed elements. Which you can in my suggestion too. Any of the actions that mark it as unexecuted will make inserting/reinserting it into the document hierarchy send it to the scripting engine. I have in no way specified any other handling when sending it to the scripting engine than the default with regards to where the code to parse comes from. So, what are these issues I talk about? Well, mostly it's questions about what is appropriate to do in cases like: 1. We have a script element, without inline content, in the document hierarchy. A src attribute is added. 2. We have a script element, with either a src attribute or inline content, in the document hierarchy. A type attribute is added, removed or modified. 3. We have a script element, with inline contents, in the document hierarchy. A src attribute is added. 4. We have a script element, with no inline content but with a src attribute, in the document hierarchy. Inline content is added. 5. We have a script element, with inline content and a src attribute, in the document hierarchy. The src attribute is removed. 6. We have a script element, in the document hierarchy. It is removed from and reinserted into the document hierarchy. 7. We have a script element, with inline content, in the document hierarchy. The inline content is changed. 8. We have a script element, without inline content, not in the document hierarchy. A src attribute is added. 9. We have a script element, with a src attribute, in the document hierarchy. The src attribute is changed. (An similar example cases, on and on...) What we've said is that once a script element can be executed it is, and then it never is again. A script element can be executed once it's in the document and it has either inline content or a src attribute set. As mentioned I don't like the idea of not being able to execute it again. But as long as the execution flag is not preserved through a cloneNode, and the node is guaranteed to be cloneable in all user agents, I don't mind, all the functionality of my suggestion would be replicatable then. I think it would be logical to handle DOM manipulation like so: - Any script element: If a src, type, defer, async, language, charset, for or event attribute is added, removed or changed, the script is flagged as unexecuted. - Any script element: If a src attribute is added or changed, load that resource. - A script element, without src attribute: If inline content is changed, removed or added, the script is flagged as unexecuted. I think it would be logical to handle execution of script like so: - A script element, with an unexecuted flag: If inserted into the document hierarchy, the script is sent to the scripting engine queue and flagged as executed. - A script element, with an unexecuted flag, in the document hierarchy: If an evaluation method on the script element is called or the loading of a resource completes, the script is sent to the scripting engine queue and flagged as executed. - A script element, with an executed flag: If an evaluation method on the script is called with a first argument of true, the script is sent to the scripting engine queue again. That would make doing myScript.src = myScript.src and myScript.textContent = myScript.textContent reevaluate the scripts. It would also make the for-loop in the example I gave above reevaluate the first script part over and over again. The myScript.src example, yes. The
Re: [whatwg] Google Gears and HTML5
On 5/31/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: On May 30, 2007, at 8:32 PM, Robert O'Callahan wrote: On the plus side, JAR files make versioning and and consistency incredibly simple. It's not clear what the Gears ManagedStore does if it gets a 404 or some other error during an update. I believe the update is made atomic to the web app: http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore While an update is in progress, resources from the previous version (if any) will continue to be served locally. After all resources have been downloaded, the currentVersion property will be updated to indicate that the new set of a resources are now being served locally and the previous version has been removed. Yeah, but that doesn't say what happens if one or more of the resources fails to load. Other issues with the Gears API: -- The ManagedStore approach seems to have a problem in the following situation: Suppose an app is updated on the server overnight and I visit the main page in the morning. It starts loading other resources. ManagedStore is going to check the manifest, find that the app needs to be updated, pull down the new resources, and flip to the new version --- more than likely while the app is in the middle of loading. Sure, this could happen normally if I hit the site in the middle of the night at the switchover, but ManagedStore makes this uncommon case common. (This is Dave Camp's example.) We've brought up the same problem. I thought more about this though - the update can only happen while you're online, in which case you could do all loads directly from the net (or at least revalidating per normal cache policy) while at the same time checking for an update. Then if you go offline while the app is running, you're in bad shape. (I think brief periods of connectivity are a common scenario...) Or else the manifest could be checked before serving from the local store and if the version changed in that case let the page load live and cache those copies. That could work. The transparency of the cache from the URI point of view actually helps with solving this, I think. I don't think this problem is fundamental. Neither do I, but it's something to think about. -- I think making ResourceStore writable by clients is unnecessary complexity. It's much simpler to maintain the model that the LocalServer/offline cache is really just a cache of the Web. Then there are no issues with enabling/disablings stores, there is no need to add domain restrictions or requiredCookie ( i.e. potential security holes) so that different apps can't tread on each other's resources. (So apps that want to refer to a canonical source for JS library files or whatever can still work.) For file uploads, I think we should just have a DOM API on form control elements that reads the file data into a binary blob of some sort which can then be stored in Storage or SQL. I don't think requiredCookie feature is there solely for writeability reasons, but rather to make the LocalServer cache work even when in normal use they might get different versions of a resource from the server at different times. For example, suppose you have two different gmail accounts with preferences set to different languages. That could be handled other ways, perhaps by restructuring the app to use URI query parameters. I think requiredCookie is an example of something we don't need in an initial spec. (BTW the Gears docs don't say what happens when a load matches in multiple stores, possibly by having multiple cookies...) There is one related feature that Gears is missing that we thought app writers might need. Web pages can load other pages and pass parameters to them via URI query params or POST. When you're offline that won't work. Our solution to this is that query parameters in JAR URIs are ignored, so jar: http://foo.com/foo.jar!/query.html?bar=baz just loads jar: http://foo.com/foo.jar!/query.html, but script in query.html can access the query parameters via document.location, and dynamically generate content that the server would otherwise have provided. I think an WHATWG solution should cover this case somehow. I am not sure what you mean by the resource store being writeable. It lets you tweak the set of items stored, but you can't construct an item with headers and data and all by hand. You can copy, delete and rename items in the cache. I guess I should have said mutable instead of writable. It does overload file insertion into the local store, which is perhaps needlessly complex, but you do want a way to access a file picked by an HTMLInputElement without having to round-trip it to the server. Perhaps that feature would be better served by API on HTMLInputElement instead. Agreed. That would be very useful for regular Web apps as well. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay
Re: [whatwg] setting .src of a SCRIPT element
The script in question is already as bad as it can be: it needs time 10 *
(5 + content length) and 20 context switches to run. I would not mind
making it even worse by reexecuting the script each time. There is a chance
the script developer would learn how to write better code (that is, a DOM
property value should be built incrementally, if so desired, on the script
side) if he noticed that effect.
Cheers
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking
Sent: Thursday, May 31, 2007 3:27 AM
To: Hallvord R M Steen; whatwg
Subject: Re: [whatwg] setting .src of a SCRIPT element
Another thing that would be weird would be inline scripts. How would the
following behave:
s = document.createElement('script');
document.head.appendChild(s);
for (i = 0; i 10; i++) {
s.textContent += a + i + += 5;;
}
Would you reexecute the entire script every time data was appended to
the script? Would you try to just execute the new parts? Would you do
nothing? IE gets around this problem by not supporting dynamically
created inline scripts at all, which I think is a really bad solution.
Re: [whatwg] Style sheet loading and parsing (over HTTP)
You should rather begin with (plain text) CR LF to subvert document type sniffing. It is meant to be plain text, after all. You do not use tags in plain text, be they fake or genuine. Cheers Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of gary turner Sent: Wednesday, May 30, 2007 10:21 PM To: Henri Sivonen Cc: WHATWG; Ian Hickson; Gervase Markham Subject: Re: [whatwg] Style sheet loading and parsing (over HTTP) Henri Sivonen wrote: snip I was serious. If you want to display plain text in the browser content area, it seems that prepending plaintext and sending it as text/html is more likely not to invoke sniffing than sending it as text/plain. This use case doesn't require an end tag. Ah. That, prepending, gives me a better idea of your meaning. Eg., a file, source.html, containing plaintext html ... /html would not be sniffed by IE, and would be rendered as plain text. Where normally, the file, as source.txt, with its text/plain content type, and without the plaintext tag, would be sniffed by IE and rendered as an html document. If a UAs were to simply honor the server response header, it would obviate the need for such an inelegant work-around. Thanks for the clarification. cheers, gary -- Anyone can make a usable web site. It takes a graphic designer to make it slow, confusing and painful to use.
Re: [whatwg] setting .src of a SCRIPT element
I don't see that being able to reuse elements adds any value. Could you give an example where it does? The global eval equivalent is an example. It's not much of an improvement over the cloneNode example but I'd like the performance to be as close to a plain eval as possible. Ability to switch type, charset, language attributes in chosen user agents may be useful for things like testing E4X support or ES4 support, or correct broken encodings. Ability to execute an external resource again may be useful. All of these are already possible however, so I don't think they are strong use cases. If there aren't any strong use cases I think we should go with what's simple. / Jonas
Re: [whatwg] More comments and questions on Web Apps 1.0
On Mon, 20 Mar 2006, Henri Sivonen wrote: 1.14.1. The style and script elements in XHTML have a potentially anything goes content model. Would it be appropriate for a conformance checker to only pass style and script types it knows about (with the proper content model for each type)? I would expect a conformance checker to have a could not validate mode which was between no and yes, though presented more like no, for the state where there was no actual error, but something that normally can be checked couldn't be verified for whatever reason. 2.14.1.1. The spec should probably mention http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-03.txt or its successor around here. I have no idea which section that was, nor which RFC that is (the URI is now dead). Is there an updated link? 2.17. 2.18. Are calendars and cards expected to be unstylable replaced elements in rendering? Those sections are gone now. 2.20.1. When I read this, I had trouble organizing (in my mind) what I was reading because I had no prior understanding of where the spec was going. Up to this point, I had had prior hypotheses that were confirmed or disconfirmed by the spec. This section would be a lot easier to read if it had an introductionary paragraph stating the relationship of rendering, the DOM, the data model object and data submission. (Is the DOM being rendered or is a replaced widget element being rendered? Is it stylable? Is the data model reflected back to the DOM? What's the expected way of serializing the data model and sending it back to the server?) I don't know which section this is talking about. Is it better now? Since last year I've made several attempts at making the spec flow better. 2.20.1. Also, I wondered whether this functionality is best specced as part of the UA or whether it would be better to ship it as a MIT/expat-licensed pure-JS library for running on top of the lower-level JS/DOM APIs. (Note: Considering what I wrote above, I don't really understand what the aims are, so I may be totally missing the point.) Not sure what you mean. 2.20.1.3. I had trouble trying to extract markup-level conformance requirements for stuff that can occur inside the datagrid. It's just any block-level content. Why was it unclear? Do you think it should be further restricted? I've made it explicit. 2.20.1.3. Is select allowed to occur in the block context only here or anywhere? Oops. Allowed select now. (datalist too.) 2.20.2. Is command in head conforming in the XHTML serialization only? (It is a phasing element in the tree construction section.) At some point I'll put command in the head in the parser, I think. Otherwise, it'll be allowed in the head in XHTML only (or not at all). 2.20.3. It why not use type=context for declaring a context menu? Yeah, I guess that's fine. Changed. 3.1. We could make this into a string value that acts as a Hint for why the command is disabled. I suspect that to be trouble, because general purpose code for dealing with boolean attributes would need to take that special case into account. Using another attribute for a hint would be fine, though. The reason to have the boolean be the string would be to force authors to provide the hint. You could easily provide the hint using title, the key is to find a way to force authors into writing good code. 4.4.1. Since all HTML elements can thus be focused and unfocusd unfocused Apparently this went away. 4.5. Is onerror only a DOM attribute or is it a markup attribute as well? Whose attribute is it? Is this defined to your satisfaction now? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More comments and questions on Web Apps 1.0
* Ian Hickson wrote: 2.14.1.1. The spec should probably mention http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-03.txt or its successor around here. I have no idea which section that was, nor which RFC that is (the URI is now dead). Is there an updated link? That would be RFC 4329. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[whatwg] HTMLCollections: embeds, plugins, applets
I note that document.embeds, document.plugins and document.applets are all supported HTMLCollections in browsers. They might need to be specced. Test cases/demos: http://simon.html5.org/test/html/dom/htmlcollections/ In IE7, an embed is not part of the embeds or plugins collections if it is inside an object. In Opera, document.plugins matches both object and embed elements. In WebKit and IE7, document.applets matches both object and applet elements. Suggested spec text: The embeds attribute must return an HTMLCollection rooted at the Document node, whose filter matches only embed elements. The plugins attribute must return an HTMLCollection rooted at the Document node, whose filter matches only embed elements. The applets attribute must return an HTMLCollection rooted at the Document node, whose filter matches only applet elements. This happens to be what Firefox does. -- Simon Pieters
Re: [whatwg] Return values of on* event handlers
On Mon, 24 Jul 2006, Stewart Brodie wrote: Dean Edwards [EMAIL PROTECTED] wrote: Boris Zbarsky wrote: Consider the following testcase: !DOCTYPE html a href=http://www.example.com; onclick=return 0Click me/a Should clicking the link load www.example.com? Yes. You should explicitly return false to cancel an event. I've had to deal with customer fault reports saying that return 0 should cancel the event, so have to allow for numbers here too. I'm assuming that means that one or more of the major desktop browsers permits this. In my testing, IE doesn't do that; they require 'false' exactly. Without more support for this, I'd be reluctant to change it. Could you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
