[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: [webkit-dev] Lazy loading
From: Dominic Farolino <domfarolino () gmail ! com>
Date: 2019-12-04 21:07:19
Message-ID: CA+-N3bpUT=4WpyeZA9DAYNWFfuOmk4ONuLTnac+0avVSPb+zaw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
*Maciej wrote:*
- I couldn't find a spec for a lazy loading feature policy either, and the
Chrome Platform Status page for it gives the status as "removed"[2] so this
too might be a nonstandard thing. Or maybe there is a newer (Doesn't look
like the feature policy aspect is in your patch though.)
I hope I am not being too nitpicky. I do think this is a great feature. I
just want to make sure we're cautious about the line between implementing
standards-track stuff vs copying things from Chromium that are nonstandard
or unspecified (so far).
It's also really worrisome if Chrome implemented semantics for the
"loading" attribute beyond what is in the PR, as that will make interop a
challenge.
Regards, Maciej
Just to circle back to this, the current spec PR does not include the
"auto" attribute, so there is no need for any Feature/Document policies to
control the default image- or frame-loading. The `loading` attribute has
two values "lazy" and "eager", and the missing/invalid-value default is
"eager".
Long-term, Chrome is interested in exploring making the default
"lazy". However, we're thinking a good intermediate step is in the future,
add "auto" back to the spec and introduce a Document or Feature Policy that
allows developers to specify that "auto" == "lazy". Then over time, we may
consider simply making the default "lazy". There has been
discussion/proposals for image- and frame-policies [1] [2]. There has not
been many updates to the proposals, so I am not sure how reliable the
current text is. Furthermore, there is a tracking issue for Chrome [3]
which covers some implementation discussion for these policies, however it
too seems stalled.
FYI Chrome currently ships the "auto" attribute, but it is treated as
"eager" unless the user has opted into Lite mode, as Thomas mentioned.
[1]:
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-image-default-eager.md
[2]:
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-frame-default-eager.md
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=949683
[Attachment #5 (text/html)]
<div dir="ltr"><div><i>Maciej wrote:</i></div><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>- I couldn't find a spec for a lazy loading \
feature policy either, and the Chrome Platform Status page for it gives the status as \
"removed"[2] so this too might be a nonstandard thing. Or maybe there is a newer \
(Doesn't look like the feature policy aspect is in your patch \
though.)</div><div><br></div><div>I hope I am not being too nitpicky. I do think this \
is a great feature. I just want to make sure we're cautious about the line between \
implementing standards-track stuff vs copying things from Chromium that are \
nonstandard or unspecified (so far).</div><div><br></div><div>It's also really \
worrisome if Chrome implemented semantics for the "loading" attribute beyond what is \
in the PR, as that will make interop a \
challenge.</div><div><div><br></div></div><div><div>Regards, \
Maciej</div></div></blockquote><div><br></div><div>Just to circle back to this, the \
current spec PR does not include the "auto" attribute, so there is no need \
for any Feature/Document policies to control the default image- or frame-loading. The \
`loading` attribute has two values "lazy" and "eager", and the \
missing/invalid-value default is \
"eager".</div><div><br></div><div>Long-term, Chrome is interested in \
exploring making the default "lazy". However, we're thinking a good \
intermediate step is in the future, add "auto" back to the spec and \
introduce a Document or Feature Policy that allows developers to specify that \
"auto" == "lazy". Then over time, we may consider simply making \
the default "lazy". There has been discussion/proposals for image- and \
frame-policies [1] [2]. There has not been many updates to the proposals, so I am \
not sure how reliable the current text is. Furthermore, there is a tracking issue for \
Chrome [3] which covers some implementation discussion for these policies, however it \
too seems stalled.</div><div><br></div><div>FYI Chrome currently ships the \
"auto" attribute, but it is treated as "eager" unless the user \
has opted into Lite mode, as Thomas mentioned.</div><div><br></div><div>[1]: <a \
href="https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-ima \
ge-default-eager.md">https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-image-default-eager.md</a><br></div><div>[2]: \
<a href="https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading- \
frame-default-eager.md">https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-frame-default-eager.md</a></div><div>[3]: \
<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=949683">https://bugs.chromium.org/p/chromium/issues/detail?id=949683</a></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic