New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Picturefill 3.0.0 Alpha #492

Closed
Wilto opened this Issue May 4, 2015 · 13 comments

Comments

Projects
None yet
6 participants
@Wilto
Collaborator

Wilto commented May 4, 2015

What do we think?

@yoshuawuyts

This comment has been minimized.

yoshuawuyts commented May 4, 2015

What are the changes?

@Wilto

This comment has been minimized.

Collaborator

Wilto commented May 4, 2015

The short version is: major performance improvements (@aFarkas, you have some test results here, yeah?), way closer to native behavior (use largest image in cache instead of requesting smaller sources with srcset, for example), better parsers, and better test coverage.

@jefflembeck

This comment has been minimized.

Collaborator

jefflembeck commented May 4, 2015

Faster, more accurate, and better tested? Into it.

aFarkas pushed a commit that referenced this issue May 4, 2015

aFarkas pushed a commit that referenced this issue May 4, 2015

@aFarkas

This comment has been minimized.

Collaborator

aFarkas commented May 4, 2015

This would be so awesome. I just re-added the umd pattern and the git ignored compiled files. So everything should be good to go from my view. Should I remove the debug code before we tag/release the alpha?

@aFarkas

This comment has been minimized.

Collaborator

aFarkas commented May 4, 2015

About the performance thing, for runtime: it's mainly about scalability. In case of a website with a few DOM elements and very few respimages, you won't see much impact. In case of either complex CSS/DOM or a lot of responsive images, you will see a big performance improvement, due to reduced layout trashing and some sizes memoization and other things.

There are also some network improvements too.

So I'm +2.

@yoshuawuyts

This comment has been minimized.

yoshuawuyts commented May 4, 2015

Neat! Not sure if this project is following semver, but if it is: are there any breaking changes that warrant a major version bump?

@aFarkas

This comment has been minimized.

@Wilto

This comment has been minimized.

Collaborator

Wilto commented May 5, 2015

Yeah; I figure our semver rules are a little different. If we had a major breaking change in a polyfill, something has gone horribly wrong somewhere.

@Wilto

This comment has been minimized.

Collaborator

Wilto commented May 5, 2015

@aFarkas I’d scratch the debug code first, if we can easily move it to a plugin.

@yoshuawuyts

This comment has been minimized.

yoshuawuyts commented May 5, 2015

@Wilto Ideally that'd be true, however the webcomponent spec has had at least one major change (document.register -> document.registerElement) so it's not unheard of specs pushing breaking changes. When applied properly I find semver to be a pleasant communicator of expectations.

edit: since this package is published through npm, it's worth pointing out that npm installs packages by default using the (^) operator. This means that any minor versions published to 2.x.x will be pulled automatically by anyone who has done npm install -S picturefill since version 2 came out. If the next version is mostly just a speed improvement, it might be worth pushing it out to everyone automatically rather than requiring them to upgrade by hand.

@Wilto

This comment has been minimized.

Collaborator

Wilto commented May 6, 2015

Yeah, but we’ve been keeping up with spec-and-real-implementation changes on the fly so far. I mean, we kinda get to cheat there, where we’re extremely tuned-in to changes in native implementations. I wouldn’t want to hold for a major release process if we’re addressing a bug that keeps Picturefill in sync with reality, y’know?

I do want to keep Picturefill 3 out of the usual upgrade process, though, since it’s a huge code overhaul. The 2.Xes works pretty damn well, so I have no qualms about people staying on there for a while—I think I’d rather have a big change like this be an opt-in.

@wiesys

This comment has been minimized.

wiesys commented Jul 28, 2015

Should we still use IE 9 workaround with tag in 3.0?

@aFarkas

This comment has been minimized.

Collaborator

aFarkas commented Jul 28, 2015

@wiesys
There is no way around to use the <video style="display: none;"> workaround to support IE9.

Fun fact: pf 3.0 now also supports the shorter version <audio> of this workaround.

@mike-engel mike-engel closed this Sep 24, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment