Re: [webkit-dev] Raw string literals

[Maciej Stachowiak via webkit-dev]

> On Nov 17, 2021, at 2:58 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Right now, our style checker disapproves of raw string literals, which were 
> introduced in C++11.  It complains with this message:
> 
> Multi-line string ("...") found.  This lint script doesn't do well with such 
> strings, and may give bogus warnings.  They're ugly and unnecessary, and you 
> should use concatenation instead".
> 
> https://webkit.org/code-style-guidelines/ 
>  says nothing on the subject.  I 
> find them quite useful and nice, especially with strings that contain lots of 
> quotation marks that would otherwise need escaping.  Would anyone oppose to 
> my changing our style checker to allow them if I ever get around to it?

Seems like the style checker complains in part because it doesn’t know how to 
properly parse such strings. With that fixed it seems ok to me to use that type 
of string.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Markup based Client Hints delegation for third-party content

[Ari Chivukula via webkit-dev]

I'd like to get WebKit's position on Markup based Client Hints delegation
for third-party content.
https://groups.google.com/a/chromium.org/g/blink-dev/c/FTNrw03Xs9s/m/O74Mp6bmCAAJ
https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit
https://wicg.github.io/client-hints-infrastructure/#accept-ch-state-algo

This is to support content negotiation use cases such as differential
serving of variable fonts, color vector fonts, responsive images, and other
third-party content which requires client information lost by user agent
reduction (an ongoing project). For example: variable fonts allow
significantly less font information to be transferred without loss of
functionality, but only works on specific operating systems.

It’s already possible to set a Permissions Policy in the HTTP response
header, but for sites without the ability to modify HTTP headers a HTML
solution would be ideal. This proposes a meta tag which allows delegation
of client hints to third-party origins. These tags could be included in
code-snippets for embedded third-party content for ease of use.

For example, to specify third party requests to https://foo.bar must
include sec-ch-width you could include:
https://foo.bar')">

You may still omit the permission policy and rely on the default allowlist
as follows:


Note that this is the equivalent of the following today:


~ Ari Chivukula (Their/There/They're)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev