add support for width/height on source tag

[attiks]

I just saw a comment in #49 referring to the lack of width and height on the source tag, for the polyfill the used by Drupal we added it to avoid reflow while the page is loading.

Can we add it to source?

[yoavweiss]

Since picture's dimensions may change between sources, that may make sense,
even though it's probably better to define these dimensions in CSS, for the
picture element itself.
What's the advantage of defining that in HTML? (besides the fact that img
supports it)

On Tue, Jun 11, 2013 at 9:05 PM, attiks [email protected] wrote:

I just saw a comment in #49https://github.com/ResponsiveImagesCG/picture-element/issues/49referring to the lack of width and height on the source tag, for the
polyfill the used by Drupal we added it to avoid reflow while the page is
loading.

Can we add it to source?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50
.

[attiks]

Some benefits:

• Easy to generate using a back end
• No need to depend on CSS, and doing this is CSS forces you to right a lot of it
• It's is part of the source tag so easy to set even while writing code manually

[Wilto]

This would mean a brand new addition to source and some complication in rendering. Near as I can tell, disparate width and height attributes on source elements would cause reflows just the same—if the object is to avoid reflows altogether, wouldn’t you want to specify a width and height on picture?

I’m reluctant to add this to the spec, as it involves altering the behavior of an established element and there really hasn’t been much call for it.

-1 from me.

[attiks]

With the poly fill the right source element is quickly detected, on really slow connections (2g) you might notice it, but not on a faster one. Without width and height you'll have reflow all the time even on WiFi connections and it's a PITA on mobile pages.

Adding width/height on picture isn't an option, because sources probably have different sizes

I know it complicates the current specs, but if we don't add it now it probably will never be added.

[attiks]

Some background info https://developers.google.com/speed/docs/best-practices/rendering#SpecifyImageDimensions which also applies mostly to picture AFAIK

[attiks]

I think once picture is implemented and the MQ are parsed on time, it will solve the reflow/repaint problem

[baamenabar]

I'm with @attiks on this, reflow/repaint of a complex layout is a hit on performance, specially evident on feature phones or with slow connections.
Having used picturefill for more than a year, this is a very common issue that shouldn't be relegated to CSS to solve on it's own. If that would be the case, we could also be relegating the responsive images problem to CSS.

[Wilto]

Reflow/repaint is a performance concern for certain, but represents a significantly smaller performance hit than the inclusion of box-shadow or semi-transparency on multiple elements on a page. This issue is better addressed in the internals of the browser than by extending source elements and height/width attributes in a way that only functions on a single type of media element.

[attiks]

@Wilto it is not only the performance that's a problem, it is - at least for me - annoying when it happens; you start reading the page and all of a sudden the whole text is shifted down, so it means you have to scroll and try to figure out where you were reading before the reflow happened.

Adding w/h remedies this and it is similar to image, so - i hope - most people will be used to adding w/h to 'image' and it will help browsers while rendering the page, since they don't have to wait for the image to download.

[Wilto]

Sorry, I should’ve been more clear about closing this out: while this is something I’d absolutely like to see addressed, it isn’t something we’re comfortable adding to the specification at this time—or able to, where we can’t make changes to the spec for source. It is a completely valid issue, however, and one we’ll be looking to solve in the future. First, let’s see what we can do to work around this within CSS, and the internals of the browser itself.

Closing the issue, but not forgetting it either.

[attiks]

Thanks for clarifying

[attiks]

@Wilto Any change this can be reconsidered, the reflow is bugging a lot of people, or will this be fixed when it is natively implemented?

/cc @yoavweiss

[yoavweiss]

We've discussed resolving the reflows in #85.

[zcorpan]

Yeah this is a dup of #85 AFAICT. For now you have to use CSS (with media queries if necessary) to set the right dimensions on the img before the image has loaded.