-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Add support for Content-DPR response header #5112
Conversation
Note that having this PR does not constitute an implementation interest in WebKit. It’s simply a prerequisite. |
source
Outdated
<p>Wait until the result of fetching is either a <span data-x="concept-response">response</span> | ||
or an error. If it is a <span data-x="concept-response">response</span>, and the | ||
<span data-x="concept-response">response</span> has an | ||
<span data-x="concept-response-image-density">image density</span> that is not null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not parse for the response header here? Are you trying to avoid having service workers set it or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, just wasn't aware that parsing for headers before a Response exists was an option. Any pointers to another section of the spec that does this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before a response exists? You're holding a response here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that's my confusion. Is a Response object available as soon as step 21 completes, before we get to the networking task source stuff? How do I wait for the image density property I tried to define here whatwg/fetch#971 to be populated, and is it guaranteed to be populated before the first chunks of image data are ready to paint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it would be better to make this part of the next step yeah, once the first task is queued. You'll then have a response (and potentially some initial bytes as well, but definitely all the headers).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved it, per this and our conversation on IRC
I guess another problem here is that image fetching isn't properly abstracted yet and used by all things that fetch images. So technically this would only work for |
…loads ...and point to an issue about unifying image loading, generally.
@eeeps I thought I'd state it again for clarity, I don't think we need any changes to Fetch here. HTML can be in charge of parsing the header and forwarding the information to the image decoder. |
- add reference to Fetch's `get a structured header` algorithm - add reference to the Structured Headers spec, and its definitions of Integers and Decimals - get the Content-DPR header and check that it's valid ourselves, right here in HTML, before setting the image density
@annevk Ok, closed the Fetch PR, called out to Fetch's get a strucructured header, and am validating the result against the Structured Headers definitions of Integer/Decimal. That seemed like the cleanest way to parse, but am I off base? |
I don't know what's causing the PR Preview error. Maybe it's some intermittent failure. I'll try to figure out if there's a way to trigger it to rebuild. |
|
@annevk great. I agree on №2; we have tests for CSS
Not sure if Update:
|
@annevk added the IANA section. The other headers had their @noamr also added a bunch of tests web-platform-tests/wpt#21962 |
Ok, added the expectation that |
Hm, I think I need to specify that |
I believe Content-DPR should be ignored for <= 0 |
CSS has a large number of properties that take images in one form or another. And yeah, this can only be tested on a per-endpoint basis unfortunately. Looks pretty good otherwise. I guess the main things remaining are implementer interest and someone verifying the test coverage. (Happy to help with the latter once the former is sorted.) |
Abandoned this approach; switched to using EXIF information for these use cases, rather than an HTTP header. #5574 |
This WIP PR adds support for the
Content-DPR
response header on image responses (see explainer here).Bonus: here's Chrome's usage tracking.
💥 Error: Wattsi server error 💥
PR Preview failed to build. (Last tried on Jan 15, 2021, 8:00 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.