Skip to content
This repository has been archived by the owner on Jan 9, 2020. It is now read-only.

naturalWidth / naturalHeight, raster #11

Open
chrishtr opened this issue Nov 23, 2018 · 6 comments
Open

naturalWidth / naturalHeight, raster #11

chrishtr opened this issue Nov 23, 2018 · 6 comments

Comments

@chrishtr
Copy link

I'm filing an issue to ask questions.

The explainer says "Specifically, the image would raster at these dimensions and naturalWidth/naturalHeight on images would return the values specified in this attribute."

Two questions:

  1. Why do the natural* properties need to be reflected by the intrinsicsize attribute? Could those just
    remain connected to the actual size of the resource? Or does this make the algorithm unreasonably
    hard to explain?

  2. What does "raster at these dimensions" mean in this context?

@chrishtr
Copy link
Author

The use-cases mentioned in #10 do sound legitimate to me. It does seem useful to query the
backing size of the resource, independent of the sizing algorithm inputs. e.g. to measure estimated
memory or network bandwidth impacts of assets.

@loonybear
Copy link
Collaborator

  1. The definition of intrinsicSize is to override the intrinsic size of the media elements. The intrinsic size of a media element is used in the following ways:
    a) is used to render the element if no sizing info is otherwise specified;
    b) density corrected value of intrinsic size is used to calculate naturalWidth/naturalHeight/videoWidth/videoHeight
    Implementation wise, I think it is possible to separate a) and b). But I think it might make things more complex and confusing?

  2. "raster at these dimensions" means, given intrinsicSize="300x400", the image will be rendered as: 300px in width and 400px in height.

Agree that #10 seems legit. So I am thinking maybe we should support another set of attributes to return the backing size of the resource?

@chrishtr
Copy link
Author

It will layout at some size, which may not be 300x400 (as you mentioned in comment 1(a), but the intrinsic sizing input to layout will be 300x400.

The actual bitmap raster will depend on more factors, such as final layout size, transforms, whether the image is directly composited, ...

Not sure if making naturalWidth/Height not depend on the intrinsic sizing attribute, but instead on
the actual image, is confusing or not. Adding yet more parameters would be unfortunate, all things
being equal.

@loonybear
Copy link
Collaborator

Re: It will layout at some size, which may not be 300x400 (as you mentioned in comment 1(a), but the intrinsic sizing input to layout will be 300x400.
Do you mean this:

<img width="500" intrinsicSize="300x150" >p

The image will layout at 500px by 250px, but the intrinsic width and height will be 300px and 150px. Or did I misunderstand it?

intrinsicSize is only used when there's lacking information to compute final layout size before fully loading the image. And in addition, it will overrides the value of what naturalWidth/naturalHeight return.

@chrishtr
Copy link
Author

chrishtr commented Dec 4, 2018

The image will layout at 500px by 250px, but the intrinsic width and height will be 300px and 150px. Or did I misunderstand it?

Yes, that's what I meant.

intrinsicSize is only used when there's lacking information to compute final layout size before fully loading the image. And in addition, it will overrides the value of what naturalWidth/naturalHeight return.

I agree. Just saying that "resolution of raster" is another question entirely. It's safe for you to ignore this and just say "layout" in your spec.

@loonybear
Copy link
Collaborator

Sounds good. Thanks.

I think the only question we have left is is it a good idea to override naturalWidth / videoHeight

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants