Intent to Deprecate and Remove: <link rel=subresource>
Yoav Weiss
Primary eng email
yo...@yoav.ws / yoav....@akamai.com
Summary
Remove support for the "subresource" rel of HTMLLinkElement
Motivation
The "subresource" rel never really did what it was intended to do, as the resources that it downloaded were downloaded with low priority. On top of that it was never shipped in any browsers other than Chromium based ones, and its Blink implementation is buggy, and results in double downloads. Also, removing it from the code base would enable to lower the complexity of LinkLoader.
Compatibility Risk
The API has been around for a long while, but was only supported by Chrome, and is not critical in nature (i.e. lack of support doesn't break content). I believe removing it poses a very low to non-existent compatibility risk.
Alternative implementation suggestion for web developers
Web developers should use the "preload" rel that now supersedes "subresource".
Usage information from UseCounter
Usage was close to 0 up until a few months back. For some reason usage got bumped to 0.02% between October 15 and 17. From the nature of that jump, it is likely a single fairly large entity that decided to add "subresource" to their markup. Since the current implementation double downloads, this entity is likely to benefit from the removal of "subresource". In any case, content will not break, and 0.02% is still below our threshold for removal.
OWP launch tracking bug
Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
Requesting approval to remove too?
Yes, please!
Dimitri Glazkov
Rick Byers
LGTM2
Note that 0.03% isn't "our threshold for removal' - just a rule of thumb below which considering removal is probably worthwhile. But since there's really no way this removal can break anyone, higher would be fine.
Ilya Grigorik
Chris Harrelson
--
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+...@chromium.org.
Joe Medley
Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
Yoav Weiss
Joe Medley
edeni...@yahoo.com.br
oro.ja...@gmail.com
oro.ja...@gmail.com
oro.ja...@gmail.com
oro.ja...@gmail.com
LGTM1.
Yes, please!
oro.ja...@gmail.com
On Saturday, 30 January 2016 00:36:36 UTC+8, Joe Medley wrote:
On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672Can you please add one
oro.ja...@gmail.com
On Monday, 1 February 2016 19:56:48 UTC+8, Yoav Weiss wrote:
Sure. Added one at https://www.chromestatus.com/features/6596598008119296
On Fri, Jan 29, 2016 at 5:36 PM, Joe Medley <jme...@google.com> wrote:
On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672
Can you please add one.
oro.ja...@gmail.com
oro.ja...@gmail.com
Yes, please!
oro.ja...@gmail.com
On Thursday, 28 January 2016 05:50:24 UTC+8, Yoav Weiss wrote:
oro.ja...@gmail.com
On Thursday, 28 January 2016 05:52:23 UTC+8, Dimitri Glazkov wrote:
oro.ja...@gmail.com
On Thursday, 28 January 2016 06:03:27 UTC+8, Rick Byers wrote:
oro.ja...@gmail.com
On Thursday, 28 January 2016 07:50:04 UTC+8, Ilya Grigorik wrote:
oro.ja...@gmail.com
oro.ja...@gmail.com
oro.ja...@gmail.com
On Saturday, 30 January 2016 00:36:36 UTC+8, Joe Medley wrote:
On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672Can you please add one.
oro.ja...@gmail.com
oro.ja...@gmail.com
On Tuesday, 2 February 2016 00:40:02 UTC+8, Joe Medley wrote:
Thank you.
On Mon, Feb 1, 2016 at 3:56 AM, Yoav Weiss <yo...@yoav.ws> wrote:
Sure. Added one at https://www.chromestatus.com/features/6596598008119296
On Fri, Jan 29, 2016 at 5:36 PM, Joe Medley <jme...@google.com> wrote:
On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672
Can you please add one.
oro.ja...@gmail.com
theot...@gmail.com
Theo Alves
Remover o suporte para o rel "subrecurso" de HTMLLinkElement
Motivação
O rel "subrecurso" nunca realmente fez o que tinha a intenção de
fazer, como os recursos que baixado foram baixadas com baixa
prioridade. Em cima do que ele nunca foi enviado em quaisquer outros
do que aqueles baseados Chromium navegadores, e sua implementação
Blink é buggy e resulta em descargas duplas. Além disso, removendo-o
da base de código permitiria a reduzir a complexidade da LinkLoader.
Risco de compatibilidade
A API tem sido em torno de um longo tempo, mas só foi apoiado pelo
Chrome, e não é de natureza crítica (ou seja, falta de apoio não
quebrar conteúdo). Acredito que removê-lo representa uma muito baixa
ao risco de compatibilidade inexistente.
sugestão alternativa de implementação para os desenvolvedores web
Os desenvolvedores da Web deve usar o rel "pré-carga", que agora
substitui "sub-recurso".
informações de uso de UseCounter
Uso estava perto de 0 até alguns meses atrás. Por alguma razão o uso
got batido para 0,02% entre 15 de outubro e 17. A partir da natureza
desse salto, é provável que uma única entidade bastante grande que
decidiu acrescentar "sub-recurso" para a sua marcação. Desde a
implementação atual de downloads duplas, essa entidade é susceptível
de beneficiar da remoção de "sub-recurso". Em qualquer caso, o
conteúdo não irá quebrar, e 0,02% é ainda inferior a limiar de
remoção.
OWP bug tracking lançamento
crbug.com/581840
Entrada no painel recurso
No entry no painel recurso como eu não tenho certeza se devo
acrescentar um só para fins de remoção. Se eu devo, eu vou :)
O pedido de aprovação para remover também?
Sim por favor!
-
Você recebeu esta mensagem porque se inscreveu para um tópico no grupo
Grupos do Google "blink-dev".
Para cancelar a assinatura deste tópico, visite
https://groups.google.com/a/chromium.org/d/topic/blink-dev/Y_2eFRh9BOs/unsubscribe.
Para sair deste grupo e todos os seus temas, envie um e-mail para
blink-dev+...@chromium.org.
2016-07-29 12:07 GMT-03:00, theot...@gmail.com <theot...@gmail.com>:
>
>
> Em quarta-feira, 27 de janeiro de 2016 19:50:24 UTC-2, Yoav Weiss escreveu:
>>
>> Primary eng email
>>
>> Summary
>>
>> Remove support for the "subresource" rel of HTMLLinkElement
>>
>> Motivation
>>
>> The "subresource" rel never really did what it was intended to do, as the
>>
>> resources that it downloaded were downloaded with low priority. On top of
>>
>> that it was never shipped in any browsers other than Chromium based ones,
>>
>> and its Blink implementation is buggy, and results in double downloads.
>> Also, removing it from the code base would enable to lower the complexity
>>
>> of LinkLoader.
>>
>> Compatibility Risk
>>
>> The API has been around for a long while, but was only supported by
>> Chrome, and is not critical in nature (i.e. lack of support doesn't break
>>
>> content). I believe removing it poses a very low to non-existent
>> compatibility risk.
>>
>> Alternative implementation suggestion for web developers
>>
>>
>> Usage information from UseCounter
>> Usage was close to 0 up until a few months back. For some reason usage
>> jump, it is likely a single fairly large entity that decided to add
>> "subresource" to their markup. Since the current implementation double
>> downloads, this entity is likely to benefit from the removal of
>> "subresource". In any case, content will not break, and 0.02% is still
>> below our threshold for removal.
>>
>>
>> OWP launch tracking bug
>>
>> crbug.com/581840
>>
>> No entry on the feature dashboard as I'm not sure if I should add one just
>>
>> for removal purposes. If I should, I will :)
>>
>> Requesting approval to remove too?
>>
>> Yes, please!
>>
>
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/Y_2eFRh9BOs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> blink-dev+...@chromium.org.
>
girl.ch...@gmail.com
On Wednesday, January 27, 2016 at 11:50:24 PM UTC+2, Yoav Weiss wrote:
Primary eng email
yo...@yoav.ws / yoav....@akamai.com
Summary
Remove support for the "subresource" rel of HTMLLinkElement
Motivation
The "subresource" rel never really did what it was intended to do, as the resources that it downloaded were downloaded with low priority. On top of that it was never shipped in any browsers other than Chromium based ones, and its Blink implementation is buggy, and results in double downloads. Also, removing it from the code base would enable to lower the complexity of LinkLoader.
Compatibility Risk
The API has been around for a long while, but was only supported by Chrome, and is not critical in nature (i.e. lack of support doesn't break content). I believe removing it poses a very low to non-existent compatibility risk.
Alternative implementation suggestion for web developers
Web developers should use the "preload" rel that now supersedes "subresource".
Usage information from UseCounter
Usage was close to 0 up until a few months back. For some reason usage got bumped to 0.02% between October 15 and 17. From the nature of that jump, it is likely a single fairly large entity that decided to add "subresource" to their markup. Since the current implementation double downloads, this entity is likely to benefit from the removal of "subresource". In any case, content will not break, and 0.02% is still below our threshold for removal.
OWP launch tracking bug
Entry on the feature dashboard
No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)
theopa...@gmail.com
gilmaral...@gmail.com
Em quarta-feira, 27 de janeiro de 2016 19:52:23 UTC-2, Dimitri Glazkov escreveu:
LGTM1.
On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:
deven...@gmail.com
sadame...@gmail.com
thali...@hotmail.com
Em quarta-feira, 27 de janeiro de 2016 19:50:24 UTC-2, Yoav Weiss escreveu:
sonid...@yahoo.com.mx
ohen...@gmail.com
On Wednesday, January 27, 2016 at 4:50:24 PM UTC-5, Yoav Weiss wrote:
vrmur...@gmail.com
d.dyoungcal...@gmail.com
El miércoles, 27 de enero de 2016, 16:50:24 (UTC-5), Yoav Weiss escribió:
Primary eng email
Iwan Lesmana Riza
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e48e9d6c-80eb-4bf9-aed6-31adad639cdd%40chromium.org.
