- From: Garret Rieger via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Aug 2022 23:32:37 +0000
- To: public-css-archive@w3.org
> So this is purely to avoid sending the `Patch` headers in the initial request for the font? Given the obvious benefits, and your very good example of intermediate CDN networks or other proxies that may add support for this, it feels a _little_ odd to make it an author decision to rule out patch-subset at all. But I have plenty of other hills to die on so I'm happy to take your word for it. When incremental-auto is used the first request has to be a GET request with the request message added as a custom header (in case the server can use them). An unfortunate side affect is that this prevents the request from being considered a simple request for CORS and thus a CORS preflight request may need to get made. So explicitly specifying incremental-patch allows the first request to be made over POST instead and avoid triggering the preflight request. This is a pretty significant performance improvement as it avoids a full round trip. Another benefit of using POST is more compact encoding of the request message (no base64 is needed). For a more detailed discussion on how we arrived at the decision to split the keyword see this writeup: https://docs.google.com/document/d/1IcPg4o5k4OOmfLCfa1z2wQl6MD-kPBrahtcb4r-97ZU/edit?resourcekey=0-9WtXKj_y4uihiB7K740xMQ > So these values would be both checking for browser support and also determining how the browser would start talking to the font server. What happens if you have a src that says `incremental-patch` but the server actually does not support it? This is covered by the incxfer spec: https://w3c.github.io/IFT/Overview.html#fallback. If the server responds with something that doesn't look like a patch response then the client will just perform a normal non-incremental load on that URL. An alternative behaviour we could consider specifying instead would be to have the client skip that url and try the next URL in the @font-face (if present). -- GitHub Notification of comment by garretrieger Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7665#issuecomment-1233552245 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 August 2022 23:32:39 UTC