Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-29 Thread Philip Jägenstedt 
LGTM3

On Wed, Nov 29, 2023 at 5:55 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-11-23 10:11, Yoav Weiss wrote:
>
> LGTM1
>
> These all seem like useful improvements! :)
>
>
> On Wed, Nov 22, 2023 at 8:14 PM Jeremy Roman  wrote:
>
>>
>>
>> On Wed, Nov 22, 2023 at 11:10 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman 
>>> wrote:
>>>
 Note: This intent email spans three Chromestatus entries for different
 sub-features that we experimented with together and would like permission
 to ship together in M121.

 Contact emails jbro...@chromium.org, adith...@chromium.org,
 isabo...@google.com, dome...@chromium.org, mc...@chromium.org

 Explainer https://github.com/WICG/nav-speculation/blob/main/triggers.md

 Specification
 https://wicg.github.io/nav-speculation/speculation-rules.html

 Summary

 (1) An extension to speculation rules syntax that lets the browser
 obtain URLs for speculation from link elements in a page. They may include
 criteria which restrict which of these links can be used.

>>>
>>> Any specific parts of the explainer/spec that cover this one?
>>>
>>
>> Sure:
>>
>> https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules
>>
>> https://wicg.github.io/nav-speculation/speculation-rules.html#document-rule-predicate-matching
>>
>> https://wicg.github.io/nav-speculation/speculation-rules.html#find-matching-links
>>
>
> That's very useful, thanks!!
>
>>
>>
>>
 (2) Adding the eagerness field to the speculation rules will let the
 developers control how eagerly the browser preloads links in order to
 balance the performance advantage against resource overhead. This field
 accepts one of "conservative", "moderate", "eager", or "immediate" strings
 as the value, and it is applicable to both "prefetch" and "prerender"
 actions and both "list" or "document" sources. If not explicitly specified,
 list rules default to "immediate" and document rules default to
 "conservative".


 (3) Currently developers can only specify speculation rules using
 inline script tags.  The proposed feature provides an alternative through
 the "Speculation-Rules" header. Its value must be a URL to a text resource
 with "application/speculationrules+json" MIME type. The resource's rules
 will be added to the document's rule set.


 Blink component Internals>Preload
 

 TAG review https://github.com/w3ctag/design-reviews/issues/721

 TAG review status Issues addressed (TAG still has reservations)

 Chromium Trial Name SpeculationRulesPrefetchFuture

 Link to origin trial feedback summary
 https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing

 Origin Trial documentation link
 https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md

 WebFeature UseCounter name SpeculationRulesDocumentRules
 SpeculationRulesSelectorMatches
 SpeculationRulesHeader
 SpeculationRulesExplicitEagerness

 Risks


 Interoperability and Compatibility

 Because authors cannot rely on document rules being evaluated (or
 preloading generally), applications which use them should function
 correctly in other browsers and should continue to function correctly were
 the feature to be deprecated. Of course, ideally other browsers do find it
 compelling to implement this feature.


 Similar reasoning applies to the response header and eagerness field.


 *Gecko*: No signal (
 https://github.com/mozilla/standards-positions/issues/620)

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/54)

 *Web developers*: Positive (
 https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
 positive feedback from Akamai and use within Chrome on web.dev

 *Other signals*:

 Activation

 Some developers might not be immediately aware of which URLs they can
 prefetch or prerender without side effects; this risk is reduced if they
 primarily use the feature for same-origin URL patterns they are familiar
 with.


 Security

 See
 https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
 .


 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such
 that it has potentially high risk for Android WebView-based applications?


 Debuggability

 Speculative loading which occurs is visible in the Network panel and
 the new Preloading panel. Console warnings are logged when several types of
 issues are encountered.

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-29 Thread Daniel Bratell 

LGTM2

/Daniel

On 2023-11-23 10:11, Yoav Weiss wrote:

LGTM1

These all seem like useful improvements! :)


On Wed, Nov 22, 2023 at 8:14 PM Jeremy Roman  wrote:



On Wed, Nov 22, 2023 at 11:10 AM Yoav Weiss
 wrote:



On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman
 wrote:


Note: This intent email spans three Chromestatus
entries for different sub-features that we
experimented with together and would like
permission to ship together in M121.


Contact emails

jbro...@chromium.org, adith...@chromium.org,
isabo...@google.com, dome...@chromium.org, mc...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html


Summary

(1) An extension to speculation rules syntax that lets the
browser obtain URLs for speculation from link elements in
a page. They may include criteria which restrict which of
these links can be used.


Any specific parts of the explainer/spec that cover this one?


Sure:
https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules

https://wicg.github.io/nav-speculation/speculation-rules.html#document-rule-predicate-matching

https://wicg.github.io/nav-speculation/speculation-rules.html#find-matching-links


That's very useful, thanks!!




(2) Adding the eagerness field to the speculation rules
will let the developers control how eagerly the browser
preloads links in order to balance the performance
advantage against resource overhead. This field accepts
one of "conservative", "moderate", "eager", or "immediate"
strings as the value, and it is applicable to both
"prefetch" and "prerender" actions and both "list" or
"document" sources. If not explicitly specified, list
rules default to "immediate" and document rules default to
"conservative".


(3) Currently developers can only specify speculation
rules using inline script tags. The proposed feature
provides an alternative through the "Speculation-Rules"
header. Its value must be a URL to a text resource with
"application/speculationrules+json" MIME type. The
resource's rules will be added to the document's rule set.



Blink component

Internals>Preload




TAG review

https://github.com/w3ctag/design-reviews/issues/721


TAG review status

Issues addressed (TAG still has reservations)


Chromium Trial Name

SpeculationRulesPrefetchFuture


Link to origin trial feedback summary


https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing


Origin Trial documentation link


https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md


WebFeature UseCounter name

SpeculationRulesDocumentRules
SpeculationRulesSelectorMatches
SpeculationRulesHeader
SpeculationRulesExplicitEagerness


Risks



Interoperability and Compatibility

Because authors cannot rely on document rules being
evaluated (or preloading generally), applications which
use them should function correctly in other browsers and
should continue to function correctly were the feature to
be deprecated. Of course, ideally other browsers do find
it compelling to implement this feature.


Similar reasoning applies to the response header and
eagerness field.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/620)

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/54)

/Web developers/: Positive

(https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
positive feedback from Akamai and use within Chrome on
web.dev 

/Other signals/:


Activation

Some developers might not be immediately aware of which
URLs they can prefetch or prerender without side effects;
this risk is reduced if they primarily use the feature for
same-origin URL patterns they are familiar with.

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-23 Thread Yoav Weiss 
LGTM1

These all seem like useful improvements! :)


On Wed, Nov 22, 2023 at 8:14 PM Jeremy Roman  wrote:

>
>
> On Wed, Nov 22, 2023 at 11:10 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman 
>> wrote:
>>
>>> Note: This intent email spans three Chromestatus entries for different
>>> sub-features that we experimented with together and would like permission
>>> to ship together in M121.
>>>
>>> Contact emailsjbro...@chromium.org, adith...@chromium.org,
>>> isabo...@google.com, dome...@chromium.org, mc...@chromium.org
>>>
>>> Explainerhttps://github.com/WICG/nav-speculation/blob/main/triggers.md
>>>
>>> Specification
>>> https://wicg.github.io/nav-speculation/speculation-rules.html
>>>
>>> Summary
>>>
>>> (1) An extension to speculation rules syntax that lets the browser
>>> obtain URLs for speculation from link elements in a page. They may include
>>> criteria which restrict which of these links can be used.
>>>
>>
>> Any specific parts of the explainer/spec that cover this one?
>>
>
> Sure:
>
> https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules
>
> https://wicg.github.io/nav-speculation/speculation-rules.html#document-rule-predicate-matching
>
> https://wicg.github.io/nav-speculation/speculation-rules.html#find-matching-links
>

That's very useful, thanks!!

>
>
>
>>> (2) Adding the eagerness field to the speculation rules will let the
>>> developers control how eagerly the browser preloads links in order to
>>> balance the performance advantage against resource overhead. This field
>>> accepts one of "conservative", "moderate", "eager", or "immediate" strings
>>> as the value, and it is applicable to both "prefetch" and "prerender"
>>> actions and both "list" or "document" sources. If not explicitly specified,
>>> list rules default to "immediate" and document rules default to
>>> "conservative".
>>>
>>>
>>> (3) Currently developers can only specify speculation rules using inline
>>> script tags.  The proposed feature provides an alternative through the
>>> "Speculation-Rules" header. Its value must be a URL to a text resource with
>>> "application/speculationrules+json" MIME type. The resource's rules will be
>>> added to the document's rule set.
>>>
>>>
>>> Blink componentInternals>Preload
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/721
>>>
>>> TAG review statusIssues addressed (TAG still has reservations)
>>>
>>> Chromium Trial NameSpeculationRulesPrefetchFuture
>>>
>>> Link to origin trial feedback summary
>>> https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing
>>>
>>> Origin Trial documentation link
>>> https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md
>>>
>>> WebFeature UseCounter nameSpeculationRulesDocumentRules
>>> SpeculationRulesSelectorMatches
>>> SpeculationRulesHeader
>>> SpeculationRulesExplicitEagerness
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Because authors cannot rely on document rules being evaluated (or
>>> preloading generally), applications which use them should function
>>> correctly in other browsers and should continue to function correctly were
>>> the feature to be deprecated. Of course, ideally other browsers do find it
>>> compelling to implement this feature.
>>>
>>>
>>> Similar reasoning applies to the response header and eagerness field.
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/620)
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/54)
>>>
>>> *Web developers*: Positive (
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
>>> positive feedback from Akamai and use within Chrome on web.dev
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> Some developers might not be immediately aware of which URLs they can
>>> prefetch or prerender without side effects; this risk is reduced if they
>>> primarily use the feature for same-origin URL patterns they are familiar
>>> with.
>>>
>>>
>>> Security
>>>
>>> See
>>> https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
>>> .
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>>
>>>
>>> Debuggability
>>>
>>> Speculative loading which occurs is visible in the Network panel and the
>>> new Preloading panel. Console warnings are logged when several types of
>>> issues are encountered.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes (though some
>>> capabilities vary per platform)
>>>
>>> Is this feature fully tested by web-platform-tests
>>>

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-22 Thread Jeremy Roman 
On Wed, Nov 22, 2023 at 11:10 AM Yoav Weiss  wrote:

>
>
> On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman 
> wrote:
>
>> Note: This intent email spans three Chromestatus entries for different
>> sub-features that we experimented with together and would like permission
>> to ship together in M121.
>>
>> Contact emailsjbro...@chromium.org, adith...@chromium.org,
>> isabo...@google.com, dome...@chromium.org, mc...@chromium.org
>>
>> Explainerhttps://github.com/WICG/nav-speculation/blob/main/triggers.md
>>
>> Specification
>> https://wicg.github.io/nav-speculation/speculation-rules.html
>>
>> Summary
>>
>> (1) An extension to speculation rules syntax that lets the browser obtain
>> URLs for speculation from link elements in a page. They may include
>> criteria which restrict which of these links can be used.
>>
>
> Any specific parts of the explainer/spec that cover this one?
>

Sure:
https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules
https://wicg.github.io/nav-speculation/speculation-rules.html#document-rule-predicate-matching
https://wicg.github.io/nav-speculation/speculation-rules.html#find-matching-links


>> (2) Adding the eagerness field to the speculation rules will let the
>> developers control how eagerly the browser preloads links in order to
>> balance the performance advantage against resource overhead. This field
>> accepts one of "conservative", "moderate", "eager", or "immediate" strings
>> as the value, and it is applicable to both "prefetch" and "prerender"
>> actions and both "list" or "document" sources. If not explicitly specified,
>> list rules default to "immediate" and document rules default to
>> "conservative".
>>
>>
>> (3) Currently developers can only specify speculation rules using inline
>> script tags.  The proposed feature provides an alternative through the
>> "Speculation-Rules" header. Its value must be a URL to a text resource with
>> "application/speculationrules+json" MIME type. The resource's rules will be
>> added to the document's rule set.
>>
>>
>> Blink componentInternals>Preload
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/721
>>
>> TAG review statusIssues addressed (TAG still has reservations)
>>
>> Chromium Trial NameSpeculationRulesPrefetchFuture
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing
>>
>> Origin Trial documentation link
>> https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md
>>
>> WebFeature UseCounter nameSpeculationRulesDocumentRules
>> SpeculationRulesSelectorMatches
>> SpeculationRulesHeader
>> SpeculationRulesExplicitEagerness
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Because authors cannot rely on document rules being evaluated (or
>> preloading generally), applications which use them should function
>> correctly in other browsers and should continue to function correctly were
>> the feature to be deprecated. Of course, ideally other browsers do find it
>> compelling to implement this feature.
>>
>>
>> Similar reasoning applies to the response header and eagerness field.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/620)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/54)
>>
>> *Web developers*: Positive (
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
>> positive feedback from Akamai and use within Chrome on web.dev
>>
>> *Other signals*:
>>
>> Activation
>>
>> Some developers might not be immediately aware of which URLs they can
>> prefetch or prerender without side effects; this risk is reduced if they
>> primarily use the feature for same-origin URL patterns they are familiar
>> with.
>>
>>
>> Security
>>
>> See
>> https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
>> .
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>>
>> Debuggability
>>
>> Speculative loading which occurs is visible in the Network panel and the
>> new Preloading panel. Console warnings are logged when several types of
>> issues are encountered.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes (though some
>> capabilities vary per platform)
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://wpt.fyi/results/speculation-rules?label=experimental&label=master&aligned
>> Some tests cover behavior which isn't enabled by default (even if
>> experimental web platform features are on).
>>
>>
>> Flag name on chr

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-22 Thread Yoav Weiss 
On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman  wrote:

> Note: This intent email spans three Chromestatus entries for different
> sub-features that we experimented with together and would like permission
> to ship together in M121.
>
> Contact emailsjbro...@chromium.org, adith...@chromium.org,
> isabo...@google.com, dome...@chromium.org, mc...@chromium.org
>
> Explainerhttps://github.com/WICG/nav-speculation/blob/main/triggers.md
>
> Specificationhttps://wicg.github.io/nav-speculation/speculation-rules.html
>
> Summary
>
> (1) An extension to speculation rules syntax that lets the browser obtain
> URLs for speculation from link elements in a page. They may include
> criteria which restrict which of these links can be used.
>

Any specific parts of the explainer/spec that cover this one?


>
> (2) Adding the eagerness field to the speculation rules will let the
> developers control how eagerly the browser preloads links in order to
> balance the performance advantage against resource overhead. This field
> accepts one of "conservative", "moderate", "eager", or "immediate" strings
> as the value, and it is applicable to both "prefetch" and "prerender"
> actions and both "list" or "document" sources. If not explicitly specified,
> list rules default to "immediate" and document rules default to
> "conservative".
>
>
> (3) Currently developers can only specify speculation rules using inline
> script tags.  The proposed feature provides an alternative through the
> "Speculation-Rules" header. Its value must be a URL to a text resource with
> "application/speculationrules+json" MIME type. The resource's rules will be
> added to the document's rule set.
>
>
> Blink componentInternals>Preload
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/721
>
> TAG review statusIssues addressed (TAG still has reservations)
>
> Chromium Trial NameSpeculationRulesPrefetchFuture
>
> Link to origin trial feedback summary
> https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing
>
> Origin Trial documentation link
> https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md
>
> WebFeature UseCounter nameSpeculationRulesDocumentRules
> SpeculationRulesSelectorMatches
> SpeculationRulesHeader
> SpeculationRulesExplicitEagerness
>
> Risks
>
>
> Interoperability and Compatibility
>
> Because authors cannot rely on document rules being evaluated (or
> preloading generally), applications which use them should function
> correctly in other browsers and should continue to function correctly were
> the feature to be deprecated. Of course, ideally other browsers do find it
> compelling to implement this feature.
>
>
> Similar reasoning applies to the response header and eagerness field.
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/620)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/54)
>
> *Web developers*: Positive (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
> positive feedback from Akamai and use within Chrome on web.dev
>
> *Other signals*:
>
> Activation
>
> Some developers might not be immediately aware of which URLs they can
> prefetch or prerender without side effects; this risk is reduced if they
> primarily use the feature for same-origin URL patterns they are familiar
> with.
>
>
> Security
>
> See
> https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
> .
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Debuggability
>
> Speculative loading which occurs is visible in the Network panel and the
> new Preloading panel. Console warnings are logged when several types of
> issues are encountered.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes (though some
> capabilities vary per platform)
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/speculation-rules?label=experimental&label=master&aligned
> Some tests cover behavior which isn't enabled by default (even if
> experimental web platform features are on).
>
>
> Flag name on chrome://flags
>
> Finch feature nameSpeculationRulesPrefetchFuture
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1371522
> https://bugs.chromium.org/p/chromium/issues/detail?id=1406595
> https://bugs.chromium.org/p/chromium/issues/detail?id=1366940
>
> Estimated milestones
> Shipping on desktop 121
> OriginTrial desktop last 120
> OriginTrial desktop first 110
> Shipping on Android 121
> Origin

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-17 Thread Jeremy Roman 
On Fri, Nov 17, 2023 at 11:40 AM Daniel Vogelheim 
wrote:

> Hi Jeremy,
>
> On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman 
> wrote:
>
>> (3) Currently developers can only specify speculation rules using inline
>> script tags.  The proposed feature provides an alternative through the
>> "Speculation-Rules" header. Its value must be a URL to a text resource with
>> "application/speculationrules+json" MIME type. The resource's rules will be
>> added to the document's rule set.
>>
>
> Is the URL from the speculation rules header restricted to same-origin
> resources?
>
> The examples seem to assume so; but I couldn't find any definite
> statement. The header parsing code reads to me like it would allow
> arbitrary URLs (cross-origin; or mixed http/https). Is this the intent?
>

It is not restricted to be same-origin. This is similar to how other
subresources, like scripts, stylesheets, and images, can be loaded
cross-origin. However, if it is cross-origin, the response must be
CORS-readable.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13f9oYJrxnHdsQh5QEtjBY_JjtejBJY%3DgEscffPP49kCgA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-17 Thread 'Daniel Vogelheim' via blink-dev 
Hi Jeremy,

On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman  wrote:

> (3) Currently developers can only specify speculation rules using inline
> script tags.  The proposed feature provides an alternative through the
> "Speculation-Rules" header. Its value must be a URL to a text resource with
> "application/speculationrules+json" MIME type. The resource's rules will be
> added to the document's rule set.
>

Is the URL from the speculation rules header restricted to same-origin
resources?

The examples seem to assume so; but I couldn't find any definite statement.
The header parsing code reads to me like it would allow arbitrary URLs
(cross-origin; or mixed http/https). Is this the intent?

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOmdn2FiQKjHfCahooU_sARXz_gwGdw8-X8LQ%2B2%2BMFzhg%40mail.gmail.com.

[blink-dev] Intent to Ship: Document rules, response header, eagerness

2023-11-15 Thread Jeremy Roman 
Note: This intent email spans three Chromestatus entries for different
sub-features that we experimented with together and would like permission
to ship together in M121.

Contact emailsjbro...@chromium.org, adith...@chromium.org,
isabo...@google.com, dome...@chromium.org, mc...@chromium.org

Explainerhttps://github.com/WICG/nav-speculation/blob/main/triggers.md

Specificationhttps://wicg.github.io/nav-speculation/speculation-rules.html

Summary

(1) An extension to speculation rules syntax that lets the browser obtain
URLs for speculation from link elements in a page. They may include
criteria which restrict which of these links can be used.


(2) Adding the eagerness field to the speculation rules will let the
developers control how eagerly the browser preloads links in order to
balance the performance advantage against resource overhead. This field
accepts one of "conservative", "moderate", "eager", or "immediate" strings
as the value, and it is applicable to both "prefetch" and "prerender"
actions and both "list" or "document" sources. If not explicitly specified,
list rules default to "immediate" and document rules default to
"conservative".


(3) Currently developers can only specify speculation rules using inline
script tags.  The proposed feature provides an alternative through the
"Speculation-Rules" header. Its value must be a URL to a text resource with
"application/speculationrules+json" MIME type. The resource's rules will be
added to the document's rule set.


Blink componentInternals>Preload


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/721

TAG review statusIssues addressed (TAG still has reservations)

Chromium Trial NameSpeculationRulesPrefetchFuture

Link to origin trial feedback summary
https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing

Origin Trial documentation link
https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md

WebFeature UseCounter nameSpeculationRulesDocumentRules
SpeculationRulesSelectorMatches
SpeculationRulesHeader
SpeculationRulesExplicitEagerness

Risks


Interoperability and Compatibility

Because authors cannot rely on document rules being evaluated (or
preloading generally), applications which use them should function
correctly in other browsers and should continue to function correctly were
the feature to be deprecated. Of course, ideally other browsers do find it
compelling to implement this feature.


Similar reasoning applies to the response header and eagerness field.


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/620)

*WebKit*: No signal (https://github.com/WebKit/standards-positions/issues/54
)

*Web developers*: Positive (
https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/VvbMZrcsAQAJ)
positive feedback from Akamai and use within Chrome on web.dev

*Other signals*:

Activation

Some developers might not be immediately aware of which URLs they can
prefetch or prerender without side effects; this risk is reduced if they
primarily use the feature for same-origin URL patterns they are familiar
with.


Security

See
https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
.


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?



Debuggability

Speculative loading which occurs is visible in the Network panel and the
new Preloading panel. Console warnings are logged when several types of
issues are encountered.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes (though some
capabilities vary per platform)

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/speculation-rules?label=experimental&label=master&aligned
Some tests cover behavior which isn't enabled by default (even if
experimental web platform features are on).


Flag name on chrome://flags

Finch feature nameSpeculationRulesPrefetchFuture

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1371522
https://bugs.chromium.org/p/chromium/issues/detail?id=1406595
https://bugs.chromium.org/p/chromium/issues/detail?id=1366940

Estimated milestones
Shipping on desktop 121
OriginTrial desktop last 120
OriginTrial desktop first 110
Shipping on Android 121
OriginTrial Android last 120
OriginTrial Android first 110
OriginTrial webView last 120
OriginTrial webView first 110

Anticipated spec changes

A URLPattern change was made to facilitate this, and document rules will be
affected by upstream changes to URLPattern. Similarly, upstream changes to
CSS selectors will affect document rules which use selectors t