search

domenic / html-as-custom-elements

HTML as Custom Elements
https://domenic.github.io/html-as-custom-elements/
Apache License 2.0
259 stars 20 forks source link

<img> new "parser-created flag" not exposed to JS #15

Closed zcorpan closed 8 years ago

zcorpan commented 10 years ago

I introduced a new flag to <img> that is not directly exposed to JS in https://github.com/ResponsiveImagesCG/picture-element/pull/179 to fix https://code.google.com/p/chromium/issues/detail?id=372971

You can get an img with the flag set by doing innerHTML = '<img>' on an element in a document without a browsing context

I'm not sure if this is relevant to the "implement a browser in JS" thing or whatever, just thought I'd give you a heads up. Let me know if the approach taken is super-bad etc

domenic commented 10 years ago

Out of curiousity, what problem does this solve? Following links to https://github.com/ResponsiveImagesCG/picture-element/issues/152#issuecomment-43708583 implies it's for performance, but I am skeptical that doing image loading during-parsing, instead of at the end of the turn in which parsing happens, is really that big of a boost.

That said, I am completely aware that you guys have thought about this and related issues much longer and harder than I have, so I have no problem accepting that it's necessary to start the loading synchronously during parsing. So for the rest of the message I'll assume it's necessary.

In general, flags that are not exposed to JS is fine---weak maps in ES6 give us the capability for truly-private instance variables, so that is explicable.

This one is a bit trickier though, because of it's interaction with the parser. I think it's not a problem, it just is something we would have to keep in mind if/when rationalizing the parser. I.e., the parser would need to call all element constructors (once elements have constructors) with some flag to let them know that it's parser-created; HTMLImageElement can then store that internally and refer to it, whereas all other elements will ignore it.

@dglazkov @arv do you agree, disagree, anything else?

zcorpan commented 10 years ago

Yeah the problem is performance. Not starting the load until the end of the turn caused a performance regression in one of the tests. While it probably isn't going to be noticeable on the vast majority of real-world pages, it seems plausible that there is a real problem for some pages/apps that use many images created with innerHTML or so.

domenic commented 10 years ago

Ah good, actual benchmarks is a much better argument than any theorycrafting I can do :).

zcorpan commented 8 years ago

The flag was removed again