Short of explicitly putting in the HTML namespace at every occurrence of
this, I don't know how to fix this. Putting in the HTML namespace
everywhere is a non-starter, there's something like ten thousand
occurrences of element names in the spec. (Literally. Ten thousand.)
I don't mean in the
The current url resolution as
describedhttp://www.whatwg.org/specs/web-apps/current-work/#resolving-urlsin
the spec results in some unhelpful behavior when the following
combination of web technologies are used in a client-side web app:
- a combination of path-relative urls (a
On 9 July 2013 20:39, Ian Hickson i...@hixie.ch wrote:
1. Add a dependencies attribute to script that can point to other
scripts to indicate that execution of this script should be delayed
until all other scripts that are (a) earlier in the tree order and (b)
identified by this
On 9 July 2013 21:41, Kyle Simpson get...@gmail.com wrote:
http://wiki.whatwg.org/wiki/Script_Execution_Control
My proposal was to standardize what IE4-10 did, which is to start loading
a script even if it's not in the DOM, but not execute it until it's in the
DOM. Then, you monitor an event
On 9 July 2013 22:31, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 7/9/13, Ian Hickson i...@hixie.ch wrote:script id=jquery
src=jquery.js async/script
script id=shims src=shims.js async/script
script dependencies=shims jquery src=myscript.js
async/script
Why limit depends
On 7/9/13 7:09 PM, Kyle Simpson get...@gmail.com wrote:
I have been wrestling pretty hard with script loading issues lately. I'd
say that having the browser manage script interdependency is probably a
bad and cumbersome way to solve these issues.
What do you mean by having the browser manage
On 10 July 2013 11:31, Bruno Racineux br...@hexanet.net wrote:
Anyway, as per your previous email I think we mostly agree that solution
#1 is not very practical (or infeasible per your word)
Given the suggestions I made to #1 in
The IE4-10 technique is invisible to pre-parsers, if we're chasing
performance here it's not good enough.
...
Also invisible to preloaders.
I personally don't care about scripts being discoverable by pre-parsers. I have
done testing and am not convinced that something appearing earlier (in
**
Summary:
1. `preload` attribute on script tags in markup, `preload` property on
script elements created by code. In either case, its presence tells the
browser not to execute the script once it finishes loading.
2. `onpreload` event fired on any script
On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote:
The IE4-10 technique is invisible to pre-parsers, if we're chasing
performance here it's not good enough.
...
Also invisible to preloaders.
I personally don't care about scripts being discoverable by pre-parsers. I
have done
On Wed, 10 Jul 2013 16:39:42 +0100, Kyle Simpson get...@gmail.com wrote:
I personally don't care about scripts being discoverable by pre-parsers.
[...]
For instance, I've added like link rel=prefetch annotations for my
scripts into the head of my document, and then done my normal
This is a good proposal and I'm hugely excited to see this getting more
attention! Thanks so much for bringing it up again.
There's one state that's not represented here which is download but do not
run, an inactive flag, if you will. I know this is important is some
situations where the overhead
hey Igor,
Was just discussing this with Rafael, and it seems like the core issue
you're flagging is that if a document has a base element, all #anchor
navigations (which would otherwise be document relative) are now full-page
navigations to the URL specified in the base, not the document's
I'm curious: Is it useful to have fragment URL resolve against
anything other than the display url? I.e. when is the current
behavior wrt fragments appropriate.
On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell slightly...@google.com wrote:
hey Igor,
Was just discussing this with Rafael, and it
On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell slightly...@google.comwrote:
hey Igor,
Was just discussing this with Rafael, and it seems like the core issue
you're flagging is that if a document has a base element, all #anchor
navigations (which would otherwise be document relative) are now
Which of your use-cases have not been met? So far I've seen only I want X,
Y, Z but not what you need X, Y, Z to achieve that isn't covered by other
simpler proposals or existing features.
You know, I keep relying on the fact that the body of work on this topic for
almost 3 years ought NOT
Pre-parsers can kick in before a page is actually opened, but script cannot
be executed. Let me dig up some numbers on the benefits of this report
back. But logically, [parse html]-[load script] is always going to be faster
than [parse html]-[parse inline script]-[execute inline
On Wed, 19 Jun 2013, Gregg Tavares wrote:
In order for ImageBitmap to be useful for WebGL we need more options
ImageBitmap is trying to just be a generic HTMLImageElement, that is, a
bitmap image. It's not trying to be anything more than that.
Based on some of these questions, though, maybe
I'm supportive of this proposal, and I think it'd help declarative script
loading.
I've recently contemplated the slightly related issue of adding the media
attribute to script, for declarative loading of scripts that are only
relevant to some viewports [1]
While it may complicate certain things
(Replying on behalf of Gregg, who unfortunately isn't at Google any more)
On Wed, Jul 10, 2013 at 3:17 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 19 Jun 2013, Gregg Tavares wrote:
In order for ImageBitmap to be useful for WebGL we need more options
ImageBitmap is trying to just be a
On Wed, 10 Jul 2013, Kenneth Russell wrote:
Some background: when uploading HTMLImageElements to WebGL it's required
to be able to specify certain options, such as whether to premultiply
the alpha channel, or perform colorspace conversion. Because it seemed
infeasible at the time to
On Wed, Jul 10, 2013 at 4:37 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 10 Jul 2013, Kenneth Russell wrote:
Some background: when uploading HTMLImageElements to WebGL it's required
to be able to specify certain options, such as whether to premultiply
the alpha channel, or perform colorspace
On Wed, 10 Jul 2013, Kenneth Russell wrote:
ImageBitmap can cleanly address all of the desired use cases simply by
adding an optional dictionary of options.
I don't think that's true. The options only make sense for WebGL --
flipping which pixel is the first pixel, for example, doesn't do
On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson i...@hixie.ch wrote:
(The other two options don't make much sense to me even for GL. If you
don't want a color space, don't set one. If you don't want an alpha
channel, don't set one. You control the image, after all.)
I only have a small amount
On Sat, 24 Nov 2012, Adam Barth wrote:
On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 12 Nov 2012, Justin Novosad wrote:
For many types of apps, DOM-based rendering is uncompetitively slow
[so we should make text rendering in canvas more controllable]
This
On 7/10/13 4:20 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 10 July 2013 11:31, Bruno Racineux br...@hexanet.net wrote:
Anyway, as per your previous email I think we mostly agree that solution
#1 is not very practical (or infeasible per your word)
Given the suggestions I made to #1 in
On Wed, Jul 10, 2013 at 5:13 PM, Peter Kasting pkast...@google.com wrote:
On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson i...@hixie.ch wrote:
(The other two options don't make much sense to me even for GL. If you
don't want a color space, don't set one. If you don't want an alpha
channel, don't
On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 10 Jul 2013, Kenneth Russell wrote:
ImageBitmap can cleanly address all of the desired use cases simply by
adding an optional dictionary of options.
I don't think that's true. The options only make sense for WebGL
28 matches
Mail list logo
