Re: [webkit-dev] Request for position on AudioContext.outputLatency

[Yoav Weiss via webkit-dev]

 WG think about this?
>>>
>>>
>>> Please note that Web Audio API is currently a W3C Recommendation.
>>> - The WG went through several PING reviews in 2020, for example:
>>> https://github.com/WebAudio/web-audio-api/issues/2061
>>> - One of device-related PING threads:
>>> https://github.com/w3cping/tracking-issues/issues/50
>>>
>>> As a result of the privacy discussion, the spec has a dedicated section
>>> on security and privacy:
>>> https://webaudio.github.io/web-audio-api/#priv-sec
>>>
>>> The relevant excerpt:
>>> "Fingerprinting via latency is also possible; it might be possible to
>>> deduce this from baseLatency and outputLatency. Mitigation strategies
>>> include adding jitter (dithering) and quantization so that the exact skew
>>> is incorrectly reported. Note however that most audio systems aim for low
>>> latency, to synchronise the audio generated by WebAudio to other audio or
>>> video sources or to visual cues (for example in a game, or an audio
>>> recording or music making environment). Excessive latency decreases
>>> usability and may be an accessibility issue."
>>>
>>> Cheers,
>>> Hongchan
>>>
>>>
>>> On Mon, Dec 13, 2021 at 1:15 AM youenn fablet  wrote:
>>>
>>>> Looking at
>>>> https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency, it
>>>> states that:
>>>> > If the audio output device is changed the outputLatency
>>>> <https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency> attribute
>>>> value will be updated accordingly.
>>>>
>>>> The use case seems ok, but I worry about fingerprinting if it means
>>>> this allows a web page to passively identify user speakers.
>>>> Say I switch from builtin speakers to Bluetooth headset using MacOS
>>>> system menu.
>>>>
>>>> If so, the spec should identify this as potential fingerprinting and
>>>> should provide mitigations.
>>>> And we should evaluate fingerprinting-free alternatives.
>>>> What does PING WG think about this?
>>>>
>>>> Le lun. 13 déc. 2021 à 09:39, Yoav Weiss via webkit-dev <
>>>> webkit-dev@lists.webkit.org> a écrit :
>>>>
>>>>> (Sent on behalf of Hongchan Choi, who failed to subscribe to this
>>>>> mailing list)
>>>>>
>>>>> Hey folks!
>>>>>
>>>>> AudioContext.outputLatency is to inform the time at which the first
>>>>> sample in the buffer is actually processed by the audio output device. 
>>>>> This
>>>>> is useful when synchronizing the audio generated by Web Audio to other
>>>>> audio or video sources or to visual cues [1].
>>>>>
>>>>> This is already implemented in FireFox and we're looking to ship it in
>>>>> Chrome soon [2][3]. Would you all be interested in this feature?
>>>>>
>>>>> Thanks,
>>>>> Hongchan
>>>>>
>>>>> [1] https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency
>>>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1324552
>>>>> [3]
>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dTQniJNVVMY/m/hPFwY1fbBQAJ
>>>>>
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>>
>>>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on AudioContext.outputLatency

[Yoav Weiss via webkit-dev]

Copying Hongchan's reply to the list..

On Mon, Dec 13, 2021 at 8:00 PM Hongchan Choi  wrote:

> Hi Youenn,
>
> Thanks for your response.
>
> Say I switch from builtin speakers to Bluetooth headset using MacOS system
>> menu.
>>
>
> If changing a device doesn't reflect the current status correctly, the
> feature is not useful. That said, the accuracy/precision of a value being
> served is up to the user agent's discretion.
>
> If so, the spec should identify this as potential fingerprinting and
>> should provide mitigations.
>> And we should evaluate fingerprinting-free alternatives.
>
>
> We are aware of the issue and it is being discussed in the blink-dev I2S
> thread.
>
> What does PING WG think about this?
>
>
> Please note that Web Audio API is currently a W3C Recommendation.
> - The WG went through several PING reviews in 2020, for example:
> https://github.com/WebAudio/web-audio-api/issues/2061
> - One of device-related PING threads:
> https://github.com/w3cping/tracking-issues/issues/50
>
> As a result of the privacy discussion, the spec has a dedicated section on
> security and privacy:
> https://webaudio.github.io/web-audio-api/#priv-sec
>
> The relevant excerpt:
> "Fingerprinting via latency is also possible; it might be possible to
> deduce this from baseLatency and outputLatency. Mitigation strategies
> include adding jitter (dithering) and quantization so that the exact skew
> is incorrectly reported. Note however that most audio systems aim for low
> latency, to synchronise the audio generated by WebAudio to other audio or
> video sources or to visual cues (for example in a game, or an audio
> recording or music making environment). Excessive latency decreases
> usability and may be an accessibility issue."
>
> Cheers,
> Hongchan
>
>
> On Mon, Dec 13, 2021 at 1:15 AM youenn fablet  wrote:
>
>> Looking at https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency,
>> it states that:
>> > If the audio output device is changed the outputLatency
>> <https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency> attribute
>> value will be updated accordingly.
>>
>> The use case seems ok, but I worry about fingerprinting if it means this
>> allows a web page to passively identify user speakers.
>> Say I switch from builtin speakers to Bluetooth headset using MacOS
>> system menu.
>>
>> If so, the spec should identify this as potential fingerprinting and
>> should provide mitigations.
>> And we should evaluate fingerprinting-free alternatives.
>> What does PING WG think about this?
>>
>> Le lun. 13 déc. 2021 à 09:39, Yoav Weiss via webkit-dev <
>> webkit-dev@lists.webkit.org> a écrit :
>>
>>> (Sent on behalf of Hongchan Choi, who failed to subscribe to this
>>> mailing list)
>>>
>>> Hey folks!
>>>
>>> AudioContext.outputLatency is to inform the time at which the first
>>> sample in the buffer is actually processed by the audio output device. This
>>> is useful when synchronizing the audio generated by Web Audio to other
>>> audio or video sources or to visual cues [1].
>>>
>>> This is already implemented in FireFox and we're looking to ship it in
>>> Chrome soon [2][3]. Would you all be interested in this feature?
>>>
>>> Thanks,
>>> Hongchan
>>>
>>> [1] https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency
>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1324552
>>> [3]
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dTQniJNVVMY/m/hPFwY1fbBQAJ
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position on AudioContext.outputLatency

[Yoav Weiss via webkit-dev]

(Sent on behalf of Hongchan Choi, who failed to subscribe to this mailing
list)

Hey folks!

AudioContext.outputLatency is to inform the time at which the first sample
in the buffer is actually processed by the audio output device. This is
useful when synchronizing the audio generated by Web Audio to other audio
or video sources or to visual cues [1].

This is already implemented in FireFox and we're looking to ship it in
Chrome soon [2][3]. Would you all be interested in this feature?

Thanks,
Hongchan

[1] https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1324552
[3]
https://groups.google.com/a/chromium.org/g/blink-dev/c/dTQniJNVVMY/m/hPFwY1fbBQAJ
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

[Yoav Weiss via webkit-dev]

On Wed, Mar 17, 2021 at 5:51 PM Geoff Garen  wrote:

> For the 100 microsecond value — our research suggests that you need a much
> higher value in vulnerable contexts.
>
> For the guaranteed isolated case — have you considered the use of high
> precision time to carry out non-Spectre timing attacks?
>

Could you elaborate on those 2 points?


>
> Thanks,
> Geoff
>
> On Mar 17, 2021, at 3:38 AM, Yoav Weiss via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
> Hey folks,
>
> We recently changed <https://github.com/w3c/hr-time/pull/93> the HR-time
> spec <https://w3c.github.io/hr-time/> to better align its resolution
> clamping with cross-origin isolated capability
> <https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability>,
> and now I'm interested in shipping this change in Chromium.
> In practice that means that Chromium would be reducing its resolution in
> non-isolated contexts (regardless of the platform's site-isolation status)
> to 100 microseconds, and increasing it in cross-origin isolated contexts
> (even in platforms without site-isolation, e.g. Android) to 5 microseconds.
>
> As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your
> position on the latter. Would y'all be interested in increasing timer
> granularity in contexts which have guarantees against pulling in
> cross-origin resources without their opt-in?
>
> I'd appreciate your thoughts on the matter.
>
> Cheers :)
> Yoav
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

[Yoav Weiss via webkit-dev]

Hey folks,

We recently changed  the HR-time
spec  to better align its resolution
clamping with cross-origin isolated capability
,
and now I'm interested in shipping this change in Chromium.
In practice that means that Chromium would be reducing its resolution in
non-isolated contexts (regardless of the platform's site-isolation status)
to 100 microseconds, and increasing it in cross-origin isolated contexts
(even in platforms without site-isolation, e.g. Android) to 5 microseconds.

As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your
position on the latter. Would y'all be interested in increasing timer
granularity in contexts which have guarantees against pulling in
cross-origin resources without their opt-in?

I'd appreciate your thoughts on the matter.

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

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen 
wrote:

> If I understand this correctly, the state of having received an Accept-CH
> header field in a response to a previous request is used to determine
> whether these new Sec-CH-* header fields will be sent.  Not only does this
> add a new place to store bits on the client (as acknowledged by
> https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition
>  )
> but it also seems to not provide a method for a server to receive client
> hint header fields on the first request from a client.  Would both of these
> concerns be resolved if we used something like ALPN instead of needing to
> store state on the client?
>

+David Benjamin 's Client Hints reliability proposal
and its ALPS part
<https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#application-layer-protocol-settings>
are
planned to tackle something very similar to your ALPN proposal.

FWIW, the Accept-CH cache can only be set by HTTP response headers on the
top-level document, and are cleared whenever client state (e.g. cookies)
are cleared. So while it is another place to store state, it doesn't
outlive current same-origin client-side storage.

 Am I understanding the Client Hints Infrastructure correctly?
>
> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak  wrote:
>
>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
>
> Thanks for re-reviewing, Maciej!
>
> Adding Mike Taylor, who's likely to take a closer look at this.
>
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:
>
>>
>> I just did a fresh review of that spec and explainer. Thanks for
>> addressing many of the previous issues. This addresses many of the
>> potential objections.
>>
>> Here’s the new issues I filed:
>>
>> https://github.com/WICG/ua-client-hints/issues/141
>> https://github.com/WICG/ua-client-hints/issues/142
>> https://github.com/WICG/ua-client-hints/issues/143
>> https://github.com/WICG/ua-client-hints/issues/144
>> https://github.com/WICG/ua-client-hints/issues/145
>> https://github.com/WICG/ua-client-hints/issues/146
>> https://github.com/WICG/ua-client-hints/issues/147
>> https://github.com/WICG/ua-client-hints/issues/148
>> https://github.com/WICG/ua-client-hints/issues/149
>> https://github.com/WICG/ua-client-hints/issues/150
>> https://github.com/WICG/ua-client-hints/issues/151
>>
>>
> Thanks for filing those! We'll take a look and respond shortly.
>
>
>> Most of these are minor/editorial, but I think 151 is potentially a
>> deal-breaker. I may be misreading the spec, but as written
>> getHighEntropyValues seems to give access to all of the high entropy client
>> hints to third-party scripts in the first party context, and scripts
>> running in third-party iframes, regardless of which ones the site has opted
>> into via the relevant HTTP header.
>>
>
> That's indeed the case, as we didn't consider the Client Hints opt-in to
> be something that impacts the availability of the JS API. (as it doesn't do
> that for other hints)
>
>
> We’re currently deeply skeptical of implementing any of the other client
> hints due to their expansion of fingerprinting surface, so I don’t feel
> particularly compelled by that precedent. That said, it’s likely the other
> client hints have this same problem, where they expose fingerprinting
> surface way more widely than they may be intending to.
>
> That would be a huge problem, as it would grant a lot of active
>> fingerprinting surface unnecessarily
>>
>
> We did discuss
> <https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548> 
> adding
> a Feature Policy (now Permission Policy) to that effect. Would that help
> with your concerns?
>
>
> My understanding is that feature policy applies at the frame level, and
> therefore could not be used to control what happens when a third-party
> script in a first party context calls the API. Even for third-party
> iframes, it seems like Feature Policy could only default-deny this JS API
> entirely, and would not be able to filter the results down to the set
> delegated via HTTP headers (or otherwise). Maybe you intend a feature
> policy per individual high entropy hint, but first of all that seems like
> overkill, and second, the spec is clearly not written to support such
> filtering.
>
> So no, it would not address the concerns.
>
> I think the best approach is to limit the hints to those opted into (or,
> in case of a third-party frame, delegated). That or remove the script API
> entirely. The origin-based delegation model that works well at the HTTP
> level is not well aligned with the widespread

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Thanks for the background. Let's continue to discuss on the issue.

On Tue, Nov 3, 2020 at 12:32 AM Maciej Stachowiak  wrote:

>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
>
> Thanks for re-reviewing, Maciej!
>
> Adding Mike Taylor, who's likely to take a closer look at this.
>
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:
>
>>
>> I just did a fresh review of that spec and explainer. Thanks for
>> addressing many of the previous issues. This addresses many of the
>> potential objections.
>>
>> Here’s the new issues I filed:
>>
>> https://github.com/WICG/ua-client-hints/issues/141
>> https://github.com/WICG/ua-client-hints/issues/142
>> https://github.com/WICG/ua-client-hints/issues/143
>> https://github.com/WICG/ua-client-hints/issues/144
>> https://github.com/WICG/ua-client-hints/issues/145
>> https://github.com/WICG/ua-client-hints/issues/146
>> https://github.com/WICG/ua-client-hints/issues/147
>> https://github.com/WICG/ua-client-hints/issues/148
>> https://github.com/WICG/ua-client-hints/issues/149
>> https://github.com/WICG/ua-client-hints/issues/150
>> https://github.com/WICG/ua-client-hints/issues/151
>>
>>
> Thanks for filing those! We'll take a look and respond shortly.
>
>
>> Most of these are minor/editorial, but I think 151 is potentially a
>> deal-breaker. I may be misreading the spec, but as written
>> getHighEntropyValues seems to give access to all of the high entropy client
>> hints to third-party scripts in the first party context, and scripts
>> running in third-party iframes, regardless of which ones the site has opted
>> into via the relevant HTTP header.
>>
>
> That's indeed the case, as we didn't consider the Client Hints opt-in to
> be something that impacts the availability of the JS API. (as it doesn't do
> that for other hints)
>
>
> We’re currently deeply skeptical of implementing any of the other client
> hints due to their expansion of fingerprinting surface, so I don’t feel
> particularly compelled by that precedent. That said, it’s likely the other
> client hints have this same problem, where they expose fingerprinting
> surface way more widely than they may be intending to.
>
> That would be a huge problem, as it would grant a lot of active
>> fingerprinting surface unnecessarily
>>
>
> We did discuss
> <https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548> 
> adding
> a Feature Policy (now Permission Policy) to that effect. Would that help
> with your concerns?
>
>
> My understanding is that feature policy applies at the frame level, and
> therefore could not be used to control what happens when a third-party
> script in a first party context calls the API. Even for third-party
> iframes, it seems like Feature Policy could only default-deny this JS API
> entirely, and would not be able to filter the results down to the set
> delegated via HTTP headers (or otherwise). Maybe you intend a feature
> policy per individual high entropy hint, but first of all that seems like
> overkill, and second, the spec is clearly not written to support such
> filtering.
>
> So no, it would not address the concerns.
>
> I think the best approach is to limit the hints to those opted into (or,
> in case of a third-party frame, delegated). That or remove the script API
> entirely. The origin-based delegation model that works well at the HTTP
> level is not well aligned with the widespread practice of including
> third-party scripts in the top frame.
>
> The spec does not eve allow denying the request entirely as written. A
> non-normative Note suggests that is allowed, but I can’t find any step in
> the algorithm that would ever reject the promise.
>
>
>
>> (perhaps even expanding beyond what is currently possible with the UA
>> string).
>>
>
> Can you expand on that last point?
>
>
> I mean that the client hints might include info that is not in the UA
> sting (possibly not at all, or possibly frozen in UA string but could be
> unfrozen in the client hints).
>
>
>
>>
>> Regards,
>> Maciej
>>
>>
>> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
>>
>> Yet-another ping! :)
>>
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:
>>
>>> Friendly ping! :)
>>>
>>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>>>
>>>> Hi WebKit folks,
>>>>
>>>> Circling back on the previous discussion
>>>> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html> about
>>>> User-Agen

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Thanks for re-reviewing, Maciej!

Adding Mike Taylor, who's likely to take a closer look at this.

On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:

>
> I just did a fresh review of that spec and explainer. Thanks for
> addressing many of the previous issues. This addresses many of the
> potential objections.
>
> Here’s the new issues I filed:
>
> https://github.com/WICG/ua-client-hints/issues/141
> https://github.com/WICG/ua-client-hints/issues/142
> https://github.com/WICG/ua-client-hints/issues/143
> https://github.com/WICG/ua-client-hints/issues/144
> https://github.com/WICG/ua-client-hints/issues/145
> https://github.com/WICG/ua-client-hints/issues/146
> https://github.com/WICG/ua-client-hints/issues/147
> https://github.com/WICG/ua-client-hints/issues/148
> https://github.com/WICG/ua-client-hints/issues/149
> https://github.com/WICG/ua-client-hints/issues/150
> https://github.com/WICG/ua-client-hints/issues/151
>
>
Thanks for filing those! We'll take a look and respond shortly.


> Most of these are minor/editorial, but I think 151 is potentially a
> deal-breaker. I may be misreading the spec, but as written
> getHighEntropyValues seems to give access to all of the high entropy client
> hints to third-party scripts in the first party context, and scripts
> running in third-party iframes, regardless of which ones the site has opted
> into via the relevant HTTP header.
>

That's indeed the case, as we didn't consider the Client Hints opt-in to be
something that impacts the availability of the JS API. (as it doesn't do
that for other hints)

That would be a huge problem, as it would grant a lot of active
> fingerprinting surface unnecessarily
>

We did discuss
<https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548>
adding
a Feature Policy (now Permission Policy) to that effect. Would that help
with your concerns?


> (perhaps even expanding beyond what is currently possible with the UA
> string).
>

Can you expand on that last point?


>
> Regards,
> Maciej
>
>
> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
>
> Yet-another ping! :)
>
> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:
>
>> Friendly ping! :)
>>
>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>>
>>> Hi WebKit folks,
>>>
>>> Circling back on the previous discussion
>>> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html>
>>> about User-Agent ClientHint. The feature was implemented in Chromium and is
>>> being rolled out in Chrome.
>>>
>>> There were some concerns mentioned in the previous thread, that we
>>> believe were since addressed. Would the feature be something that WebKit
>>> would consider shipping?
>>>
>>> Cheers :)
>>> Yoav
>>>
>> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Yet-another ping! :)

On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:

> Friendly ping! :)
>
> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>
>> Hi WebKit folks,
>>
>> Circling back on the previous discussion
>> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html>
>> about User-Agent ClientHint. The feature was implemented in Chromium and is
>> being rolled out in Chrome.
>>
>> There were some concerns mentioned in the previous thread, that we
>> believe were since addressed. Would the feature be something that WebKit
>> would consider shipping?
>>
>> Cheers :)
>> Yoav
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Friendly ping! :)

On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:

> Hi WebKit folks,
>
> Circling back on the previous discussion
> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html>
> about User-Agent ClientHint. The feature was implemented in Chromium and is
> being rolled out in Chrome.
>
> There were some concerns mentioned in the previous thread, that we believe
> were since addressed. Would the feature be something that WebKit would
> consider shipping?
>
> Cheers :)
> Yoav
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] User Agent Client Hints

[Yoav Weiss]

Hi WebKit folks,

Circling back on the previous discussion
 about
User-Agent ClientHint. The feature was implemented in Chromium and is being
rolled out in Chrome.

There were some concerns mentioned in the previous thread, that we believe
were since addressed. Would the feature be something that WebKit would
consider shipping?

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

Re: [webkit-dev] Request for position on Event Timing

[Yoav Weiss]

+Nicolás Peña 

On Sun, Aug 9, 2020 at 5:40 AM Ryosuke Niwa  wrote:

> On Fri, Aug 7, 2020 at 2:09 PM Rob Buis  wrote:
> >
> > I was not aware of Long Tasks API. However it seems to have a slightly
> > different focus (task vs. input events). Also I am mostly interested in
> > First Input Delay, and it was decided some time ago to not put it in
> > Long Tasks API (see
> >
> https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#
> ).
>
> The concern still withstands. We don't have dozens of slightly
> different APIs that websites need to track for junks & delays during
> user interactions.
>
> It's also unclear how this first input delay works with a single page
> app which may have multiple transitions after a single page load from
> the browser engine's perspective. There had been some discussions
> about this in the past in Web Perf WG but I don't think we've come to
> any conclusion about it.
>
> In general, I'm hesitant to have any of these APIs implemented in
> WebKit without figuring out more coherent picture of how they'd all
> fit together to address underlying use cases.
>
> - R. Niwa
>
> > On 06.08.20 20:07, Simon Fraser wrote:
> > > Our feedback is that this API seems reasonable, but that there's
> overlap with the "long tasks" API,
> > > and it's not clear if we need both.
> > >
> > > Simon
> > >
> > >> On Aug 6, 2020, at 10:43 AM, Rob Buis  wrote:
> > >>
> > >> Hi Webkit-Dev,
> > >>
> > >> I would like to get an official position from Webkit on the Event
> Timing Web Perf API.
> > >> Besides providing information about input event latency it can be
> used to obtain
> > >> First Input Timing metrics. This specification builds on the
> Performance Timeline
> > >> specification, which is implemented in Webkit. Chrome has implemented
> the Event
> > >> Timing API, see the chrome status entry below.
> > >>
> > >> - Specification: https://wicg.github.io/event-timing/
> > >> - Explainer: https://github.com/WICG/event-timing
> > >> - MDN:
> https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming
> > >> - ChromeStatus: https://chromestatus.com/feature/5167290693713920
> > >> - Caniuse.com URL:
> https://caniuse.com/#feat=mdn-api_performanceeventtiming
> > >>
> > >> Regards,
> > >>
> > >> Rob.
> > >> ___
> > >> webkit-dev mailing list
> > >> webkit-dev@lists.webkit.org
> > >> https://lists.webkit.org/mailman/listinfo/webkit-dev
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Suggesting to enable paint timing by default

[Yoav Weiss]

+Ryosuke Niwa  +Alex Christensen  who
were involved in the spec discussions.

On Wed, May 27, 2020 at 10:29 AM Noam Rosenthal  wrote:

>
>
> Following up on this.
>
>> FOn Tue, May 12, 2020 at 10:28 AM Maciej Stachowiak 
>> wrote:
>>
>>>
>>>
>>> On May 11, 2020, at 9:53 PM, Noam Rosenthal  wrote:
>>>
>>>
>>>
>>> On Tue, May 12, 2020 at 1:36 AM Maciej Stachowiak  wrote:
>>>

 I noticed from comments in one of the Radars that the patch may result
 in an additional “fake paint”, so it should probably be performance tested.
 Have you done any testing?

>>> I've tested it locally, I haven't noticed any significant side effect,
>>> because in complex situations the fake paint only happens once per page and
>>> bails early once contentfulness is detected. but I can run any additional
>>> test needed.
>>>
>>>
 We’ll likely want to A/B some of Apple’s page load speed benchmarks.

>>> A/B testing load speed sounds sensible. How do we go about doing that?
>>>
>>>
>>> Unfortunately our page load speed benchmarks are not public because they
>>> incorporate captured page content, which we can’t freely redistribute.
>>>
>>> So, can someone else from Apple review that the code is mature enough
> for this? Simon had reviewed the original patch. Maybe Zalan/Darin?
>
> A helpful person from Apple may be able to set up an A/B test for this
>>> patch.
>>>
>> What's required to ask for help from a helpful person at Apple? :)
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Position on User-Agent Client Hints

[Yoav Weiss]

On Fri, May 8, 2020 at 6:01 PM Alex Christensen 
wrote:

> Last I recall talking about this, we did not oppose to client hits header
> fields in general, just some specific ones that expose information we do
> not wish to expose to reduce fingerprinting information.  For example, I
> think we do oppose adding Device-Memory because that currently cannot be
> queried through WebKit any other way, but I don’t think we oppose adding
> Viewport-Width which is trivial to query with 100% accuracy once you have
> JavaScript on the client.  I think Downlink and RTT were in a grey area
> because they can indeed be measured other ways, but we don’t want to
> possibly increase the fingerprinting information by providing values that
> can be used for more effective client fingerprinting, such as if we were to
> send the exact same value to multiple servers.
>
> I don’t think this is an official position, just what I recall from TPAC
> discussions in Lyon.
>

Thanks! Just noting that this request is about User-Agent Client Hints in
particular.


>
> > On May 8, 2020, at 12:14 AM, Maciej Stachowiak  wrote:
> >
> > Accidentally removed Yoav from Cc and I’m not sure if he is on this list.
>

I'm still subscribed :D


> >
> >> On May 8, 2020, at 12:04 AM, Maciej Stachowiak  wrote:
> >>
> >>
> >> I would consider myself mildly positive as to the direction, but that’s
> my personal view for the moment, absent consultation with my colleagues. I
> will solicit more viewpoints.
> >>
> >> I particularly appreciate the responsiveness to feedback and that Yoav
> in particular has been willing to iterate.
>

Thank you! :)


> >>
> >> I think there’s a number of things in the spec that should be cleaned
> up before an implementation ships enabled by default, specifically around
> interop, privacy, and protection against UA lockouts. I know there are PRs
> in flight for some of these issues. I think it would be good to get more of
> the open issues to resolution before actually shipping this.
>

Regarding the discussion around `architecture`, my thinking is that we
could either reach a conclusion there before shipping, or ship with that
value currently empty and "fill it" once we reach agreement on what it
should be.

Regarding the GREASE discussion, I don't think it's blocking, as Chromium's
initial implementation will include GREASE: The UA will be a list of
values, will include a non-value that would encourage standard Structured
Header parsing, and will have the list order randomized (but remain stable
for the lifetime of the major version, the avoid caching churn).
With that said, your arguments about making this a MUST make sense, and
I'll send a PR to that effect.

The other issues seem to be either around future enhancement (which we
could add later), or general discussions that don't seem blocking.

>>
> >> Regards,
> >> Maciej
> >>
> >>> On May 7, 2020, at 4:22 PM, Michael Catanzaro 
> wrote:
> >>>
> >>> My personal $0.02: I'm mildly supportive of this spec. It's certainly
> an improvement on existing HTTP user agent headers. I appreciate that you
> worked to incorporate feedback into the spec and considered the concerns of
> small browsers.
> >>>
> >>> Is it going to solve all the problems caused by user agent headers?
> No. If WebKit implements the spec, we're surely going to eventually need a
> quirks list for user agent client hints to decide which websites to lie to,
> just like we already have quirks for the user agent header. And as long as
> Chrome sends a user agent header that includes the string "Chrome", it's
> unlikely we'll be able to get rid of the existing quirks list. But I think
> client hints will probably reduce the amount of websites that
> *accidentally* break WebKit, by replacing wild west UA header parsing with
> well-defined APIs, and adding some GREASE for good measure. The promise of
> freezing Chrome's UA header sounds nice, as it makes quirks easier to
> maintain. And being able to ration entropy by revealing details about the
> platform on an active rather than passive basis is quite appealing.
> >>>
> >>> The spec attracted some misplaced concern about negative impact to
> small browsers, which I've rebutted in [1]. I'm not quite so enthusiastic
> about this spec as I was initially, especially after I was convinced that
> the GREASE is never going to be enough to remove our quirks list, but it's
> certainly not going to *hurt* small browsers.
> >>>
> >>> This spec has received some pretty harsh criticism from the user
> tracking industry (some call it the "ad industry"). Not historically a
> friend of WebKit, so sounds good to me. ;)
> >>>
> >>> One concern I haven't mentioned elsewhere is that frozen UA header
> might encourage deeper levels of fingerprinting than are currently used,
> e.g. for ad fraud prevention. caddy has started blocking WebKitGTK users
> based on TLS handshake fingerprint (yes, really!) [1]. If techniques like
> that take off as a result of this, that could potentially 

[webkit-dev] Position on User-Agent Client Hints

[Yoav Weiss]

Hey WebKit folks,

I'd like to ask for your official position on the User Agent Client Hints
 specification.

+Maciej Stachowiak  has been providing great feedback on the
proposal, as well as to the underlying Client Hints Infrastructure
 (in its former
iterations), which helped shape those proposals, but that obviously doesn't
count as endorsement.

There's an intent to ship for the feature

over at blink-dev, and your position would be appreciated as input into
that process.

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

[webkit-dev] Developer tools when running Safari with a local WebKit build

[Yoav Weiss]

Hey!

I'm trying to run a webkit build using the `run-safari` script, and I
cannot seem to be able to set the Preferences to enable developer tools
(unlike when running regular Safari).

Is there a way to enable it that I'm missing?

Thanks! :)
Yoav
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal for an "intent to" process for web-exposed features

[Yoav Weiss]

On Thu, Feb 27, 2020 at 6:24 PM Maciej Stachowiak  wrote:

>
> I think we should have some structure, not just freeform emails. We can
> start with a simple template, but there’s some info that folks almost
> always want, so it’s easier if it’s included in the first place, rather
> than needing predictable follow-up questions
>
> I also like having a title pattern, because that makes it easier to search
> email to find all things that fit the category.
>

FWIW, at blink-dev, we found a title pattern extremely helpful in enabling
scripts pick up intents that need reviewing, as well as enable more
visibility through twitter bots (e.g. the intenttoship@
 account)


> Basically, since for any given feature email, there’s many potential
> readers and only one sender, so it seems reasonable to ask the sender to do
> a little extra
>
> I had some sample templates (much simpler than the ones used by Chrome)
> which I will dig out and send here.
>
> On Feb 26, 2020, at 11:08 PM, Ryosuke Niwa  wrote:
>
> Thanks for starting this discussion.
>
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang  wrote:
>
>>
>> The idea of an "intent to" process has been raised several times in the
>> past (e.g. in our 2020 goals [1]) and some people already use it
>> informally, but it does not seem that we have any agreement right now. Such
>> a process would help to coordinate changes internally (between port
>> maintainers and contributors) and externally (with standard groups, users
>> and other implementers). For the former point, see [2][3][4] for
>> examples of how coordination is not smooth right now. The latter point
>> will give a better understanding of what's happening in WebKit and help web
>> developer advocacy.
>>
>
> Having some kind of a process to announce a new Web facing API or behavior
> change is a good idea. In fact, we technically still have such a process
> although nobody seems to be using these days:
> https://trac.webkit.org/wiki/AddingFeatures
>
> The Mozilla and Chromium projects have their own process [5] [6]. We can
>> probably start with minimal rules and refine them in the future. We can
>> even make it mandatory only for new web platform features developed
>> under a runtime preference for now (i.e. excluding small features for
>> which it's not worth introducing a flag, behavior changes or
>> deprecation/removal). Below is a proposal based on Mozilla's one.
>>
>
> WebKit tends to err on the side of simpler rules so let's stick with that.
> I don't think we need an email template for example (I hate templates; all
> those intent to X emails on other engines' mailing lists look so silly).
>
> 1. Email webkit-dev with an intent to prototype.
>>
>
> I really dislike the idea of putting features into different stages like
> prototyping, etc... I'd prefer a much simpler approach in which a new
> feature or any behavior chance being worked on is announced on webkit-dev.
>
> In fact, I don't think we should have any rule about how emails are
> titled, etc... Emails just need to contain a certain set of information we
> need to evaluate whether a given feature / behavior change is good or not.
>
> Rather, what we need a guidance on is at which point something becomes a
> feature or a behavior change significant enough that an announcement on
> webkit-dev is necessary. For example, one could argue that any bug fix in
> Web facing API will affect its behavior. However, I don't think we want to
> be tracking every one of those behavior changes in WebKit on webkit-dev.
>
> Similarly, adding a new API has multitude of scales. On one hand, there is
> ResizeObserver and there is adding pointerLockElement on ShadowRoot
> . At which point, should
> we be making webkit-dev announcement. Again, I don't think we want to be
> tracking the addition of every new DOM property, JS API, etc... on
> webkit-dev.
>
>
> I personally think every web platform facing change should be announced,
> but it’s ok if some broader feature announcements cover every property and
> attribute in the spec at the time, even if they don’t land all at once. On
> the other hand, in specs like HTML or DOM, many individual new markup
> attributes or DOM properties are a feature in themselves.
>
>
>
>  2. Implement the feature normally behind a off-by-default preference.
>>
>
> This is not a preference, it's a WebKit policy:
> https://webkit.org/feature-policy/
>
>
> I think he was using “preference” to mean “setting”, not to suggest that
> this is merely a preference and not required.
>
>
> 3. Email webkit-dev with an intent to ship.
>>
>
> I don't think this makes much sense in WebKit since there is no such a
> thing as shipping in WebKit. Each port maintainers decide which set of
> features will be enabled at when.
>
> Or do you mean that we enabling new feature / behavior by default? If so,
> then making such an announcement on webkit-dev requirement for Web facing
> 

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Yoav Weiss]

On Thu, Feb 27, 2020 at 11:47 AM Noam Rosenthal  wrote:

>
>
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>>
>>>
>>> I don't think we should do that. For starters, Chrome's painting
>>> strategy while loading a web page is very different from that of Safari /
>>> WebKit. We would freeze the painting of the previous page at the moment a
>>> new navigation is committed, and we wouldn't update the painting until the
>>> destination page has a meaningful content in it. This is a very much
>>> different from Chrome's model where the moment a new navigation is
>>> committed, Chrome will show a blank page then start incrementally painting
>>> the page throughout the navigation.
>>>
>> Body background color is still painted before any contentful paint... Is
> this a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with
> bgcolors). Would webkit not render that web page at all?
>
>>
>>> Second off, the point of specification is to allow multiple independent
>>> implementations. If we had to reverse-engineer what Chrome is doing and
>>> implement that, it defeats the point of having any standard at all.
>>>
>>
>> With my WebPerfWG hat on, I agree. Would be good to find a model that
>> works well for different implementations (even if not comparable between
>> different implementations), while providing points in time for developers
>> that can: a) provide a user meaningful visual metric and b) enable spotting
>> regressions.
>>
> Note taken. Though this is hypothetical - let's get to the point where the
> spec is lacking, and then we can decide how to go about it.
> What I propose is to go as far as possible with the spec, and when we
> reach an ambiguity tackle it on the spec front.
>
>>
>> Would WebKit folks be interested in helping exploration on that front?
>>
> I would be happy to help coordinate this (e.g. work on the details of pec
> differences and prod Ryosuke and folks for feedback about internals).
>

That sounds great, thank you! :)


>
>
>>
>>> I don't think we don't should that because we don't have an equivalent
>>> of first-paint.
>>>
>>
>> FWIW, I don't think it's a huge problem if WebKit will report FP and FCP
>> as the same timestamp, as they are indeed the same point in time.
>>
> A simple test shows that safari does show the background color
> (body=bgcolor) when a timeout is set to render everything else (e.g. add
> text to the document). According to the spec, the first one should give
> first-paint and the second one would be first-contentful-paint.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Yoav Weiss]

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:

>
> On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal  wrote:
>
>> (resending from correct address)
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  wrote:
>>
>>>
>>> Some quick comments:
>>>
>>
>>> the definition of First Contentful Paint here in the spec: <
>>> https://www.w3.org/TR/paint-timing/#sec-terminology> does not match the
>>> definition stated at . The
>>> Chrome definition on web.dev specifies that iframe content is not
>>> included, the spec does not have this limitation. Would an implementation
>>> that matches the spec match Chrome?
>>>
>> The draft version of the spec specifies that iframe content is not
>> included in FCP:
>> https://w3c.github.io/paint-timing/#sec-reporting-paint-timing, and has
>> a few more comprehensive details about this. I think it's a good place to
>> start.
>>
>> I am also not sure this matches the layout milestones that already exist
>>> in non-Blink browser engines. Has this spec been implemented in Gecko, for
>>> example, to verity that it’s not exposing a concept that only exists in
>>> Blink?
>>>
>> No, this has not been implemented in Gecko, I'm tracking the bug on this:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1518999, there was some
>> movement recently.
>>
>> I suggest to start from "first-paint", and to try to match chrome as much
>> as possible in how FCP is implemented, in the cases where the spec doesn't
>> give enough detail, if such places exist.
>>
>
> I don't think we should do that. For starters, Chrome's painting strategy
> while loading a web page is very different from that of Safari / WebKit. We
> would freeze the painting of the previous page at the moment a new
> navigation is committed, and we wouldn't update the painting until the
> destination page has a meaningful content in it. This is a very much
> different from Chrome's model where the moment a new navigation is
> committed, Chrome will show a blank page then start incrementally painting
> the page throughout the navigation.
>
> Second off, the point of specification is to allow multiple independent
> implementations. If we had to reverse-engineer what Chrome is doing and
> implement that, it defeats the point of having any standard at all.
>

With my WebPerfWG hat on, I agree. Would be good to find a model that works
well for different implementations (even if not comparable between
different implementations), while providing points in time for developers
that can: a) provide a user meaningful visual metric and b) enable spotting
regressions.

Would WebKit folks be interested in helping exploration on that front?


>
> I also suggest to start with "first-paint" as it's perhaps a bit less
>> "internal" than FCP, and can provide a performance-regression metric with a
>> lesser degree of risk regarding exposing internals / privacy.
>>
>
> I don't think we don't should that because we don't have an equivalent of
> first-paint.
>

FWIW, I don't think it's a huge problem if WebKit will report FP and FCP as
the same timestamp, as they are indeed the same point in time.


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

Re: [webkit-dev] "ReflectOnly" IDL equivalent

[Yoav Weiss]

Apologies for not updating this thread sooner.
I already went ahead and implemented
 `as()` to reflect what's
needed, and was planning to refactor that and add a "ReflectEnum" binding
at a later patch.
If that's not needed, I can just leave it as is.

On Fri, Jun 9, 2017 at 8:47 PM Sam Weinig  wrote:

>
>
> > On Jun 2, 2017, at 11:32 AM, Ryosuke Niwa  wrote:
> >
> > On Fri, Jun 2, 2017 at 9:18 AM, Chris Dumez  wrote:
> >> Hi,
> >>
> >> No, I do not believe WebKit supports ReflectOnly and this is not
> standard
> >> IDL either.
> >>
> >> The way to do it in WebKit would be to use a regular DOMString
> attribute, as
> >> in the specification and implement this logic in the c++ getter for this
> >> attribute. See HTMLElement::dir() for an example.
> >>
> >> We could also consider adding support for something like ReflectOnly in
> our
> >> bindings generator considering that this seems to be used quite a bit
> in the
> >> HTML specification and it would decrease code complexity a little.
> >> I’d actually be in favor of that.
> >
> > I'd suggest other names like "ReflectEnum" or even "Reflect"
> > where EnumType is the name of enum that defines the list of values.
> >
> > "ReflectOnly" doesn't tell us on what "only" applies. If I didn't know
> > the context, it sounds like something that does less work than regular
> > "Reflect”.
>
>
> I don’t see a good reason to complicate the bindings until this becomes
> more common place.  For now, I would just implement HTMLLinkElement::as()
> to behave as you want and leave the IDL unannotated, and we can revisit it
> at a later time.
>
> - Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] "ReflectOnly" IDL equivalent

[Yoav Weiss]

I'm working on the link preload feature and as part of that want to align
it to the spec from an IDL perspective.
The `as` attribute is defined 
as an "enumerated attribute", which reflects only a finite set of known
values. That is important for feature detection purposes, so that
developers can know which `as` values are supported by the implementation.

In Blink this is done using `ReflectOnly
`
(pending CL ), and I'm
wondering what is the WebKit equivalent to implement attributes that
are limited
to known values 
.

Thanks! :)
Yoav
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Importing tests from web-platform-tests

[Yoav Weiss]

I'm trying to import tests from web-platform-tests/preload
, but having
trouble getting them to run without requiring expected results and while
using wptserve.

I looked at the WPT import tutorial
 but failed to find a way to
do what I need.

The reason I don't want to rely on expected tests is that I'm trying to add
a warning for unused preloads
, and these warnings can
make expected results flaky. While I can work around it in most cases (by
using the preloads in my layout tests), a way to stop relying on
expected.txt for tests that don't need it would be cleaner.

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

Re: [webkit-dev] CSS Parse error in element.

[Yoav Weiss]

Hi Atul,

I second Alex's suggestion (perhaps followed by HTMLLinkElement::process()
and other places in that file that refer to `hrefAttr`).
If you have a test case online, I could try to take a look and maybe
provide more guidance.

Cheers :)
Yoav

On Fri, Feb 3, 2017 at 9:19 PM Alex Christensen 
wrote:

> I would start looking at HTMLLinkElement::parseAttribute.
> LinkHeader.cpp contains parsers for link headers, which are related.  Yoav
> knows more about those.  Those parsers ought to be united more.
>
> On Feb 3, 2017, at 1:17 AM, Atul Sowani  wrote:
>
> At present I am focusing on CSSParser::findURI() particularly
> and CSSParser::realLex() other related functionality in CSSParser.cpp
> - hope I am on right track. ;-)
>
> Please let me know if I should be looking at some other functionality as
> well to resolve this issue.
>
> Thanks!
> Atul.
>
> On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani  wrote:
>
> Hi,
>
> I came across an issue in qtwebkit CSS parser while working on a PhantomJS
> crash. The issue seems to be with parsing of 
> type elements in an HTML page. What I observed is that the parser is trying
> to interpret the value for href given inside double-quotes. The value
> contains a "-" (e.g. "http://some.domain.com/some-page-etc-etc;). The "-"
> sign is being interpreted as minus and then things go wrong. In another
> case I found that "\g" embedded in the value (e.g. "
> http://some.domain.com/some-page/global/something;) is also creating
> issues. In essence, the parser is trying to interpret the value, which I
> believe, it should not.
>
> I am willing to dive further into it to debug and fix the issue, but
> looking at the complexity and size of WebCore, I think I would benefit a
> lot to expedite a fix, if I could get some tips about which code
> area/functionality I should specifically focus in the WebCore. Looking
> forward to some help in this regard.
>
> Thanks,
> Atul.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Reseting runtime-flag enabled features and IndexedDB

[Yoav Weiss]

After encountering flakiness as a result of runtime flags leaking between
tests, I wrote a patch 
that resets all feature flags to their default values between tests.

The problem I encountered was that IndexedDB was turned off by default in
RuntimeEnabledFeatures, but was (and still is) manually turned on by
WebView (on both mac and win) and by WebKit2. That meant that reseting it
to the default value between tests caused a lot of tests to fail (as they
were relying on it being on). At the same time, I'm not sure that flipping
the default to true won't have an undesired impact on other ports which may
have the feature turned off.

So, I'd love some advice on that front. Do the other ports have that
feature disabled as I suspect? If so, would it be a problem to turn it on
for those ports?

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

[webkit-dev] Using ResourceTiming API for testing

[Yoav Weiss]

Hey,

As part of implementing support for `` more tests are
needed to make sure resources are properly reused. The easiest way to test
that is using the ResourceTiming API, which is currently implemented behind
an off-by-default build-time flag.

Therefore, I'd like to move the implementation of ResourceTiming API to be
behind an off-by-default runtime flag, so I can use it in preload's layout
tests. (By adding an internal API that turns it on when needed)

Would that be OK with the project? Any reasons I shouldn't be doing that?

Thanks! :)
Yoav
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev]

[Yoav Weiss]

Apologies for the long silence on this subject. A patch for initial support
of the feature is at https://bugs.webkit.org/show_bug.cgi?id=156334.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev]

[Yoav Weiss]

Hello Alexey,

On Wed, Nov 18, 2015 at 1:27 AM, Alexey Proskuryakov  wrote:

> Hello Yoav,
>
> Is there any technology on the horizon that would simplify doing this kind
> of optimization? If done manually, this seems:
> - complicated, so only a few sites will do this;
> - very likely to go stale, as the content changes, but preload
> instructions do not get updated;
> - related to the above, the failure mode is opaque, as the website will
> only get a little slower to load, and not break functionally.
>

I believe that the goal for many of the use cases is to automate that
optimization in order to mitigate the issues you raised:
* For static sites, build scripts could easily add these hints as part of
the build process.
* For dynamic site frameworks (e.g. Django), middleware code can be used to
add the hints dynamically.
* CDNs and optimization engines can use site analysis and heuristics in
order to add the hints automatically for their customers.

The framework and CDN use cases can mean that few implementations may
result in many deployments of that optimization.

Regarding the third point (opaque failure mode), we could emit console
errors in case where the preloaded resource is not used.


> Sending the preload requests in HTTP response headers seems like it would
> provide the most benefit, but is also more prone to the above issues.
>

For the CDN/optimization-engine use-case, HTTP headers would be
significantly easier to add automatically.


> Preloading resources as untyped data doesn't seem like a good match to the
> loader implementation mostly dealing with typed resources.
>

The `as` attribute makes it so that the resources will not be downloaded
untyped, but will (most likely) merge with the current HTMLPreloadScanner
loading logic.


> Additionally, fetching depends on the referring document's properties
> (notably the charset is inherited for same origin subresources). This is
> not necessarily a blocker, but the proposal adds a different way to think
> about subresource loading.
>

Good point to consider while implementing! :)


>
> There appears to be some feature duplication with HTTP/2 server push
> functionality, could you please characterize the differences that would
> make it worth having both?
>

Preload has several advantages over HTTP/2 push:
* Preload is not limited to first-party resources.
* Preload will take into consideration the browser's cache.
* Preload doesn't require server side smarts (so can be used to speed up
static sites hosted on e.g. GitHub pages or S3).
* Preload is not limited to secure origins.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev]

[Yoav Weiss]

Hi,

I'm interested in adding support for 
 and the corresponding "Link:" headers and
wanted to gauge interest for supporting the feature.

The preload relationship provides a declarative fetch primitive that
enables developers to initiate a resource fetch and separate fetching from
resource execution. As such, preload is a low-level primitive that enables
applications to build custom resource loading and execution behaviors
without hiding resources from the user agent and incurring delayed resource
fetching penalties.

Use cases include:
* Early fetch of lately discovered critical resources - Sites that contain
critical resources that aren't discoverable by the preload scanner (e.g.
fonts, JS loaded scripts and styles, etc) can use the feature to download
these critical resources early
* Separation of download and execution in a declarative, non-hacky way.

All in all, it would enable Web sites to significantly improve loading
performance in various common scenarios.

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

Re: [webkit-dev] Content-DPR header

[Yoav Weiss]

On Sun, May 31, 2015 at 4:54 AM, Sam Weinig wei...@apple.com wrote:


 Hi Yoav,

 Sorry, but I’m afraid I’m still not really getting it.  Can you get even
 more concrete?  Perhaps provide some a sample page that would need this
 kind of functionality and go through what Content-DPR values would be used?


Sure. Let's take this very simple sample site
http://jsbin.com/rofewawuyo/1/edit.
If you wanted to optimize the image there with Client-Hints, you'd need
some way to tell the browser that it has been modified, and that even
though you provided it with a 400x400 pixel image, it should display it
over a 200x200 CSS pixel box.
A Content-DPR header value of 2 would enable the browser to know that the
server has reacted to the DPR hint request header, and scale the CSS pixels
it displays the image on accordingly.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Content-DPR header

[Yoav Weiss]

On Sat, May 30, 2015 at 12:32 AM, Simon Fraser simon.fra...@apple.com
wrote:


 As others have said, doing this at the transport layer seems wrong.


HTTP is an application layer protocol, and is already used to convey all
kinds of data about the payload that it delivers, such as content-type,
charset and language. Content-DPR is not very different.
Content-DPR can be thought of as part as the regular content-negotiation
flow, where the browsers may indicate this is what I need (e.g. via
Client-Hints request headers) and the server can indicates this is what I
gave you.



 Why not just invent some new metadata that gets put into the image to
 describe some scaling of the intrinsic size?


Well, several reasons:
* The same image resource can be used over multiple scenarios (e.g. a 600px
wide image can be used as a 300px image on a retina screen, as well as a
600px image on a 1x screen). In each scenario, the image would need to have
a different intrinsic size.
* Introducing meta data to do that would require a significant effort on
multiple fronts:
 - We would need that meta data to work the same way across all currently
used Web image formats (GIF, PNG, JPEG, SVG, JPEG-2000, WebP and JPEG-XR).
 - We would need to add support for that to the decoding code of all these
formats.
 - We would need the various utilities that create these images to add
support for editing this meta data. This would require a huge eco-system
wide effort.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Content-DPR header

[Yoav Weiss]

On Fri, May 29, 2015 at 8:34 PM, Sam Weinig wei...@apple.com wrote:

 Hi Yoav,

 Can you give a concrete example of when this will be used?  I’m having
 trouble understanding when an author will want to change an images
 intrinsic size but not have control of the markup.


It's not about control over markup, it's about control over style.

Let's say you're now given the following task: write a script that will go
over all your server's HTML files and make your images responsive by adding
a `srcset` attribute to all img tags. Since some of the images may change
their display dimensions at different viewport sizes (i.e the variable
width use case
https://dev.opera.com/articles/native-responsive-images/#variable-width-images),
you want to add multiple resources with `w` descriptors to each img. Each
one of these resources will be pointed towards your shiny new image server,
which has access to the original high-quality image as well as the
currently displayed one (the src image).

But, since you don't know if all the images have their dimensions defined
in CSS (and you suspect that a large chunk of them don't have CSS based
dimensions), you want to make sure that the intrinsic dimensions of the
displayed images remain the same even when you deliver images of varying
physical dimensions. How can you achieve that?

Well, the answer is, you want to modify the intrinsic size of the delivered
images to be the same as the src image's intrinsic dimensions. With
Content-DPR, that's easy. You simply set it to the value that is the
delivered image width divided by the src image width.
That way, the browser takes the Content-DPR into account, scales the
delivered image and it ends up with the same intrinsic dimensions as the
src image.

If you don't have markup control, the same exercise applies, but would
require the full-fledged Client-Hints in order to actually deliver resized
images.



 On May 29, 2015, at 11:23 AM, Yoav Weiss y...@yoav.ws wrote:

 As a first step towards the Client-Hints implementation, I submitted a
 patch https://bugs.webkit.org/show_bug.cgi?id=145380 for Content-DPR
 support
 http://igrigorik.github.io/http-client-hints/#confirming-selected-dpr.
 A discussion followed on the thread, so I'd like to move it to the list,
 in order for it to get higher exposure.

 Content-DPR is an HTTP response header that enables style-agnostic image
 resizing,


 What exactly does style-agnostic image resizing” mean? I am not familiar
 with that term


It's not an official term. I meant to say that it enables you to perform
image resizing without taking into account the style rules that control the
way in which the resized image will be displayed.


 by enabling the server to adapt the image's intrinsic size so that layout
 will not break, even if the image's dimensions are not defined in style.

 Opinions welcome! :)
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



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

Re: [webkit-dev] Removing the srcset/sizes flag

[Yoav Weiss]

Build flag was removed. Thanks all!

On Fri, May 8, 2015 at 10:51 AM, Yoav Weiss y...@yoav.ws wrote:

 Hi,

 Currently the srcset `w` descriptor and the `sizes` attribute
 implementation is behind an on-by-default flag.
 After a twitter exchange
 https://twitter.com/awfulben/status/595852748375068672 with Ben, I've
 added a bunch https://bugs.webkit.org/show_bug.cgi?id=144766 of tests
 https://bugs.webkit.org/show_bug.cgi?id=144640 and
 https://bugs.webkit.org/show_bug.cgi?id=144674 bug
 https://bugs.webkit.org/show_bug.cgi?id=144739 fixes
 https://bugs.webkit.org/show_bug.cgi?id=144675 and would now like to go
 ahead and remove the build time flag
 https://bugs.webkit.org/show_bug.cgi?id=144679.
 Please let me know of any objections.

 Thanks :)
 Yoav







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

[webkit-dev] Removing the srcset/sizes flag

[Yoav Weiss]

Hi,

Currently the srcset `w` descriptor and the `sizes` attribute
implementation is behind an on-by-default flag.
After a twitter exchange
https://twitter.com/awfulben/status/595852748375068672 with Ben, I've
added a bunch https://bugs.webkit.org/show_bug.cgi?id=144766 of tests
https://bugs.webkit.org/show_bug.cgi?id=144640 and
https://bugs.webkit.org/show_bug.cgi?id=144674 bug
https://bugs.webkit.org/show_bug.cgi?id=144739 fixes
https://bugs.webkit.org/show_bug.cgi?id=144675 and would now like to go
ahead and remove the build time flag
https://bugs.webkit.org/show_bug.cgi?id=144679.
Please let me know of any objections.

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

Re: [webkit-dev] Client Hints

[Yoav Weiss]

On Wed, May 6, 2015 at 9:09 PM, Maciej Stachowiak m...@apple.com wrote:


 Some more questions/comments about RW:

 - Is maybe-image-width-maybe-viewport-width a useful value? Perhaps there
 should be an always-present header for viewport width, and one for resource
 width that is present only when known? Though I’m not sure you can get a
 resource width even in the case where it’s known.


I believe that this value is useful since it represents an upper bound of
the number of CSS pixels in which the image will be displayed.
Along with DPR, it enables the server to send the largest possible useful
image.
With that said, we can try to think of use cases where the server actually
needs to know which one was provided, and try to account for them if there
are any.



 - The “sizes attribute allows units which can’t be calculated down to px
 without doing a full style resolution, such as “em and “ex”. The HTML spec
 even has an example using em units. But RW requires a number in CSS px
 units. How can this be reconciled with preloading happening before style is
 resolved?


Relative units in sizes
https://html.spec.whatwg.org/multipage/embedded-content.html#source-size-2
are resolved similar to relative CSS units in Media Queries - relative to
the root font size. http://dev.w3.org/csswg/mediaqueries-4/#units
so em in this case is identical to rem, and ex would be half that.



 - I don’t think making viewport-size-based decisions on the server side
 makes sense, because what do you do when the viewport is resized? Do you
 reissue the HTTP request for the image?


That's up for the browser (same as srcset). When the viewport change
results in a smaller source-size length, I guess there's no much sense in
downloading a different image, but when it's significantly larger, it might
(and the server can respond with a 304 in case there's no higher quality
version). For WebKit's case it may make sense to implement that along with
srcset's viewport reactivity.



 - The premise of this spec is to allow an image server to provide multiple
 representations when the markup can’t be changed, but sizes=“” is a new
 attribute, so old markup won’t already have it, and it’s normally only
 useful when doing client-size image selection with srcset=“”. In what case
 would it make sense to combine client-side and server side selection?


`DPR` would be useful without any client-side changes.
`RW` would be useful as well, even without `sizes` in markup - limiting the
images to the dimensions of the viewport is something that several
automatic image conversion services are doing today, either by using
(inaccurate) UA sniffing, or by relying on cookies after the first time the
user browses the page.
Adding `sizes` to the mix (in the use cases when it is possible) provides
us with extra optimization on top of that.

We can also leverage the `width` attribute (when in pixels) to provide us
with the display dimensions info when `sizes` is missing in legacy sites.



 - What do you do when sizes=“” is changed on the client side? Do you have
 to issue a fresh HTTP request?


Same as the viewport change case.


 The fact that this is all unclear in the current Internet-Draft is part of
 what makes me think it’s not quite ready for prime time.


Since the spec is destined to be an IETF RFC, it's destination audience is
not restricted to browsers, and therefore, it's skimpy on browser related
details.
It's probably a good idea though to create a related document that would
contain all these browser related details, and what browsers are expected
to do in various scenarios.




 More general questions that remain:

 - Why require the server to opt into receiving these headers at all? Why
 not just always send?


There was some resistance about sending extra headers over all requests
even if they aren't used, which lead to the introduction of the opt-in
signal. With that said, this is up to the UA.

- Why multiple headers instead of one that can contain multiple tokens?
 That would allow a clearer name while maintaining compactness.


Multiple headers are more cache friendly, since you can Vary on each one
of them independently. If Key
https://tools.ietf.org/html/draft-fielding-http-key-02 was complete and
implemented everywhere (including intermediaries) we wouldn't need that
split. Unfortunately, that's not the case, so splitting to multiple headers
has significant caching advantages.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Client Hints

[Yoav Weiss]

On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org wrote:

 I do have the same concern over terse names.  I don't see any point in
 saving 13 bytes by abbrebiating DevicePixelRadio as DPR.

 In the case of ResourceWidth, we can't get this number until we trigger a
 layout.  It doesn't seem desirable to slow down the page load speed by
 eagering triggering layout before loading each image.  How do we plan to
 work around that?


The resource width is planned to be based on the `sizes` attribute when
available, and to fall back to the viewport width when it is not.
There are no plans to delay image loading waiting for layout, nor are there
current plans to use the layout information once we have it, as that would
introduce undesired raciness.



 On Tue, May 5, 2015 at 10:59 PM, Maciej Stachowiak m...@apple.com wrote:


 Does anyone else in the WebKit community have comments on this proposal?


  - Maciej

 On Apr 28, 2015, at 8:42 AM, Yoav Weiss y...@yoav.ws wrote:

 (Re) Posting Ilya's response from April 24th, since his response wasn't
 published on the mailing list archive for some reason.

 On Thu, Apr 23, 2015 at 1:37 PM, Yoav Weiss y...@yoav.ws wrote:

 +Ilya for spec related questions.

 Also, I forgot to mention it, but my intention is to implement the RW
 and DPR hints first, and see about the MD and RQ hints (which are newer to
 the spec) later on.


 Yes, we should scope this discussion to RW and DPR. This is consistent
 with Blink implementation [1], and to keep this thread focused I'll skip
 the comments on MD/RQ/etc. That said, happy to discuss those in a separate
 thread :)


 On Thu, Apr 23, 2015 at 7:02 PM, Maciej Stachowiak m...@apple.com
  wrote:

 Is the Internet-Draft for this planned to become a standards-track RFC?
 Is there an IETF Working Group that has adopted it?

 Yes, and as part of the HTTP WG. /cc mnot

 On the spec contents: I’m wary of the fact that the header names are
 very opaque. That’s not in the HTTP tradition, where header names are
 generally human-readable. I am skeptical that the HTTP WG would be
 satisfied with these header names as-is.

 I believe the intent with the short names was to minimize impact on the
 network, since the headers will be sent with every sub-resource requests
 once the server has opted-in. With that said, you're not the first to make
 that comment, so I'm open to modify that, especially since HTTP/2 makes
 this consideration irrelevant.


 Uncompressed bytes on the wire add up quickly and short names are
 consistent with general policy of keeping those at a minimum. I don't
 believe this is counter to HTTP WG goals or guidance. That said, I'm not
 opposed to renaming them if there is a strong preference one way or another.

 I know spec feedback may be off-topic for an implementation thread, but
 I’m not sure where else to send it since it’s not clear if this
 Internet-Draft is associated with a working group.

 Spec feedback is most welcome. The best place to send it is the GitHub
 repo https://github.com/igrigorik/http-client-hints/issues.


 Big +1 to that. This is all great feedback, thanks Maciej.

 ig

 [1]
 https://groups.google.com/a/chromium.org/d/msg/blink-dev/vOgv-TqefsA/o_fEsy8RFcwJ



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



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

Re: [webkit-dev] Client Hints

[Yoav Weiss]

On Wed, May 6, 2015 at 8:41 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss y...@yoav.ws wrote:

 On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org wrote:

 I do have the same concern over terse names.  I don't see any point in
 saving 13 bytes by abbrebiating DevicePixelRadio as DPR.

 In the case of ResourceWidth, we can't get this number until we trigger
 a layout.  It doesn't seem desirable to slow down the page load speed by
 eagering triggering layout before loading each image.  How do we plan to
 work around that?


 The resource width is planned to be based on the `sizes` attribute when
 available, and to fall back to the viewport width when it is not.
 There are no plans to delay image loading waiting for layout, nor are
 there current plans to use the layout information once we have it, as that
 would introduce undesired raciness.


 Okay, thanks for the clarification. Perhaps the spec should explictily
 state that.


Good idea. I'll file a spec issue.

Can I take the feedback here as a green light to implement (assuming that
the header name concerns will be addressed)? Are there other blocking
issues? Any other feedback?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Client Hints

[Yoav Weiss]

(Re) Posting Ilya's response from April 24th, since his response wasn't
published on the mailing list archive for some reason.

On Thu, Apr 23, 2015 at 1:37 PM, Yoav Weiss y...@yoav.ws wrote:

 +Ilya for spec related questions.

 Also, I forgot to mention it, but my intention is to implement the RW and
 DPR hints first, and see about the MD and RQ hints (which are newer to the
 spec) later on.


Yes, we should scope this discussion to RW and DPR. This is consistent with
Blink implementation [1], and to keep this thread focused I'll skip the
comments on MD/RQ/etc. That said, happy to discuss those in a separate
thread :)


 On Thu, Apr 23, 2015 at 7:02 PM, Maciej Stachowiak m...@apple.com wrote:

 Is the Internet-Draft for this planned to become a standards-track RFC?
 Is there an IETF Working Group that has adopted it?

 Yes, and as part of the HTTP WG. /cc mnot

 On the spec contents: I’m wary of the fact that the header names are very
 opaque. That’s not in the HTTP tradition, where header names are generally
 human-readable. I am skeptical that the HTTP WG would be satisfied with
 these header names as-is.

 I believe the intent with the short names was to minimize impact on the
 network, since the headers will be sent with every sub-resource requests
 once the server has opted-in. With that said, you're not the first to make
 that comment, so I'm open to modify that, especially since HTTP/2 makes
 this consideration irrelevant.


Uncompressed bytes on the wire add up quickly and short names are
consistent with general policy of keeping those at a minimum. I don't
believe this is counter to HTTP WG goals or guidance. That said, I'm not
opposed to renaming them if there is a strong preference one way or another.

 I know spec feedback may be off-topic for an implementation thread, but
 I’m not sure where else to send it since it’s not clear if this
 Internet-Draft is associated with a working group.

 Spec feedback is most welcome. The best place to send it is the GitHub
 repo https://github.com/igrigorik/http-client-hints/issues.


Big +1 to that. This is all great feedback, thanks Maciej.

ig

[1]
https://groups.google.com/a/chromium.org/d/msg/blink-dev/vOgv-TqefsA/o_fEsy8RFcwJ
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Client Hints

[Yoav Weiss]

And (Re) Posting Mark's response from April 25th, for the same reasons.

 On 24 Apr 2015, at 2:32 pm, Ilya Grigorik i...@igvita.com wrote:

 On Thu, Apr 23, 2015 at 7:02 PM, Maciej Stachowiak m...@apple.com wrote:
 Is the Internet-Draft for this planned to become a standards-track RFC?
Is there an IETF Working Group that has adopted it?
 Yes, and as part of the HTTP WG. /cc mnot

To be clear, it hasn't been adopted yet, but we have discussed it, and I
suspect we will at some point in the not-too-distant future.

 On the spec contents: I’m wary of the fact that the header names are
very opaque. That’s not in the HTTP tradition, where header names are
generally human-readable. I am skeptical that the HTTP WG would be
satisfied with these header names as-is.
 I believe the intent with the short names was to minimize impact on the
network, since the headers will be sent with every sub-resource requests
once the server has opted-in. With that said, you're not the first to make
that comment, so I'm open to modify that, especially since HTTP/2 makes
this consideration irrelevant.

Regarding the concern about the WG feeling — actually, there's a strong
preference for shorter names, as long as it really is something that's
going to be on the wire a lot. Roy in particular gets grouchy at long names.

Cheers,


--
Mark Nottingham   https://www.mnot.net/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Client Hints

[Yoav Weiss]

+Ilya for spec related questions.

Also, I forgot to mention it, but my intention is to implement the RW and
DPR hints first, and see about the MD and RQ hints (which are newer to the
spec) later on.

On Thu, Apr 23, 2015 at 7:02 PM, Maciej Stachowiak m...@apple.com wrote:


 Additional spec concerns:

 (1) The RW header is unimplementable because image requests are sent
 before the display width of the image is known.


The intent is not to rely on actual display width for content images, but
to rely on HTML based info (mainly the sizes attribute), similar to srcset.
It might be better to clarify that in the spec.


 (2) The MD header is defined in a way that’s probably not useful to rely
 on; if I’m on 802.11g on a home WiFi network where the next hop is a cable
 modem, the nominal speed of 802.11g is not helpful for knowing how long it
 would take to load a large resource.


While the maximum downlink bandwidth does not provide the author with
accurate bandwidth information, it provides them a cap over the current
bandwidth. In other words, if that value is low, you can be certain that
the network is limited, but the contrary is not necessarily true.
While accurate bandwidth would have been better (both here and as part of
the NetInfo API), I don't think we have consensus on a decent way to expose
(heuristic) bandwidth measurements.



 (3) The MD header references a table of values in the W3C’s Network
 Information API spec, but that is a Working Group Note with no technical
 content and a warning that work has been discontinued because “while
 working on this specification the Device APIs Working Group encountered
 issues related to estimating network bandwidth and with providing useful
 information”. In other words, the WG concluded that there isn’t a sensible
 way to do what the MD header is trying to do.


The spec refers to the recent version of the Network Information API
https://w3c.github.io/netinfo/#downlinkmax-attribute, rather than the
outdated WG note.


 (4) The RQ header seems silly. It’s supposed to be a number 0-100, with
 fractional values allowed, that let the client specify it’s desired
 “resource quality”.  Why would you conceivably need this level of
 fine-grained selection? Will there really be a server with so many
 different versions of a resource that there’s a difference between quality
 55.431 and 55.432? Furthermore, how is a client supposed to set this?
 Without knowing what the server will do or what value thresholds are
 important, is there anything useful WebKit could do other than always send
 100?


I believe fractional values here are not intentional.

snip


 Is the Internet-Draft for this planned to become a standards-track RFC? Is
 there an IETF Working Group that has adopted it?

 Not sure. I'll let Ilya answer that.


 On the use cases: is there really anyone who is able to provide new higher
 resolution versions of their images, but cannot modify the HTML that
 references them?

 For the legacy content use case: It's not about providing new higher
resolution images, but about adapting current images to smaller viewports,
and sending smaller images when the device doesn't need to full
desktop-sized image.

For the automated image conversion use case: The use case is about
optimizing the images at a separate layer, that's not necessarily HTML
aware.


 On the spec contents: I’m wary of the fact that the header names are very
 opaque. That’s not in the HTTP tradition, where header names are generally
 human-readable. I am skeptical that the HTTP WG would be satisfied with
 these header names as-is.

 I believe the intent with the short names was to minimize impact on the
network, since the headers will be sent with every sub-resource requests
once the server has opted-in. With that said, you're not the first to make
that comment, so I'm open to modify that, especially since HTTP/2 makes
this consideration irrelevant.


 The meta requirement is problematic for two reasons:
 - Most meta http-equiv values are not processed as the equivalent http
 header. HTML5 limits it to a whitelist. It doesn’t seem like a good idea to
 extend this legacy facility.

 While true, this won't be the first header to extend that white list.
Looking at Document.cpp::processHttpEquiv I see that
x-dns-prefetch-control, x-frame-options and various variants of
Content-Security-Policy already have support for their meta equivalent.

- Browser engines may issue image requests before actually parsing the
 document (e.g. WebKit’s preloading feature) so it doesn’t seem safe to rely
 on meta being processed before image requests are sent.

 True, but the preloadScanner can parse out these meta tags and add them
to its logic.


 Also, if a content author is able to add a meta header, that contradicts
 the use case assumption that

 True for legacy content, less so for automated image optimizers.
An example use case can be a site which HTML is hosted at a static location
(e.g. GitHub pages) while 

[webkit-dev] Client Hints

[Yoav Weiss]

Hi,

As I've discussed during my session at the contributor's meetup, I'm
interested in implementing Client-Hints
http://igrigorik.github.io/http-client-hints/ in WebKit.

For those unfamiliar with it, Client-Hints is a standard destined to
improve content negotiation, and enable the browser to advertise various
characteristics to the server along with resource requests, so that the
server can adapt its responses to these characteristics in a cache friendly
way.

It was conceived to enable and facilitate server-side based responsive
images solutions. The main use-cases for that are automatic optimization of
legacy Web content, where it's not always easy to go back and modify the
HTML, as well as external image optimization solutions that prefer content
negotiation over HTML modification.

I'd like to emphasize that this effort is orthogonal to the picture
effort. (and the use-cases covered by each are orthogonal as well)

Since I intend to go ahead with implementation soon, I wanted to share my
intentions with the wider WebKit community and gather feedback at this
early stage.

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

Re: [webkit-dev] Picture element implementation

[Yoav Weiss]

On Tue, Jul 1, 2014 at 11:53 PM, Maciej Stachowiak m...@apple.com wrote:


 In fairness I should note that enabling by default in nightlies doesn’t
 necessarily mean anyone will ship it right away. But it’s still a good
 thing to do to get better test coverage.


I fully understand it doesn't mean that any port will ship it. But as you
said, it'd be better for test coverage. It would also prevent the code from
bit rotting, as well as let Web developers play around with the
implementation.

On Jul 1, 2014, at 1:26 PM, Benjamin Poulain benja...@webkit.org wrote:


  The barrier on entry is rather low to enable something in the nightly. It
 is your responsibility to make sure we don't get tons of bug reports,
 crashes, or security issues.


Of course.


 You need to have okay test coverage and make sure the tests work on all
 the ports (if relevant for the given platforms obviously).


This is already in place.


 Then you just make a patch and post the link to the bug on the mailing
 list. :)


I've submitted a patch to turn it on by default at
https://bugs.webkit.org/show_bug.cgi?id=134634

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

Re: [webkit-dev] Picture element implementation

[Yoav Weiss]

I've landed support for the sizes part of the syntax, currently on
HTMLImageElement only, behind an off-by-default compile time flag.
What is the proper procedure to request permission to turn on the flag by
default?


On Sun, Jun 15, 2014 at 11:31 PM, Yoav Weiss y...@yoav.ws wrote:


 On Mon, Mar 31, 2014 at 10:59 PM, Benjamin Poulain benja...@webkit.org
 wrote:

 On 3/31/14, 9:32 AM, Yoav Weiss wrote:

 I'm currently implementing the picture element
 http://picture.responsiveimages.org/ in Blink, to extend the srcset

 implementation and handle more responsive images use-cases
 https://groups.google.com/a/chromium.org/d/msg/blink-dev/
 vuLeAM9fJww/UHnMz7QLRWgJ.


 I'd be interested in working with the WebKit project in order to port
 that work into WebKit, once it's done. Is the project interested in the
 feature?


 I think it is worth experimenting with those. Please use a compile time
 flag for the picture element, it still is unclear how popular/useful this
 feature is going to be.



 A patch for the 'sizes' part of the picture specification is waiting for
 review at https://bugs.webkit.org/show_bug.cgi?id=133620
 Feedback will be highly appreciated :)


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

Re: [webkit-dev] Picture element implementation

[Yoav Weiss]

On Mon, Mar 31, 2014 at 10:59 PM, Benjamin Poulain benja...@webkit.org
wrote:

 On 3/31/14, 9:32 AM, Yoav Weiss wrote:

 I'm currently implementing the picture element
 http://picture.responsiveimages.org/ in Blink, to extend the srcset

 implementation and handle more responsive images use-cases
 https://groups.google.com/a/chromium.org/d/msg/blink-dev/
 vuLeAM9fJww/UHnMz7QLRWgJ.


 I'd be interested in working with the WebKit project in order to port
 that work into WebKit, once it's done. Is the project interested in the
 feature?


 I think it is worth experimenting with those. Please use a compile time
 flag for the picture element, it still is unclear how popular/useful this
 feature is going to be.



A patch for the 'sizes' part of the picture specification is waiting for
review at https://bugs.webkit.org/show_bug.cgi?id=133620
Feedback will be highly appreciated :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Picture element implementation

[Yoav Weiss]

Hi all,

I'm currently implementing the picture
elementhttp://picture.responsiveimages.org/ in
Blink, to extend the srcset implementation and handle more responsive
images 
use-caseshttps://groups.google.com/a/chromium.org/d/msg/blink-dev/vuLeAM9fJww/UHnMz7QLRWgJ
.

I'd be interested in working with the WebKit project in order to port that
work into WebKit, once it's done. Is the project interested in the feature?

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

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

I think this discussion might be more fruitful at a vendor neutral forum,
so I've started a thread out on the WHATWG:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-November/041369.html


On Fri, Nov 8, 2013 at 6:06 PM, John Mellor joh...@chromium.org wrote:

 Most discussion so far seems to be bikeshedding the syntax. To make this
 more productive, can we focus on the core issues?

 srcN brings two things to the table, compared to srcset:
 1. It handles viewport-switching better (easier to author, avoids
 repetition of image urls, allows bandwidth-driven decisions).
 2. It handles art direction.

 Does everyone agree that these are useful and long-overdue problems to
 solve, and that the high-level approach of srcN (with viewport-urls
 syntax to handle viewport switching, and a layer of media queries above
 that) is the best (only) known solution to these?


 On Fri, Nov 8, 2013 at 3:24 PM, Dean Jackson d...@apple.com wrote:

 [And the holy book sayeth cursed is she who participates in standards
 email, doomed forever to receive email in CC and being unable to sleep at
 night. ]

 On 7 Nov 2013, at 17:43, Tab Atkins Jr. jackalm...@gmail.com wrote:

  A proposal for a new paradigm of using multiple attributes deserves
 some resistance, careful consideration and exploration of alternatives. I
 feel my factual example of path d was flippantly tossed aside. So I
 responded in jest.
 
  Apologies if you believed my response was flippant; it was short, but
  serious and to the point.  I explained why the path d example wasn't
  very good - it's a single (albeit way overcomplicated) list of
  commands.  The src-N attributes already contain lists, so they're
  comparable.  I'm objecting to combining the src-N attributes into a
  single attribute because that produces a *list of lists*, which is a
  significant step further in mental complexity.

 one of the things I liked about srcset is that in the most urgent case it
 is simply one extra attribute with one higher resolution image.

 once we get into structure and ordering and multiple options and art
 direction any of these attribute solutions looks horrible. I don't care
 whether it is one attribute or 99, it's a pain to understand. if you want
 structure, use markup. I'm tempted to think the picture element is a
 better solution for these advanced cases.

 fwiw path d is an attribute because we expected thousands of values in
 that and structure would have been too unwieldy.

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



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


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

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Fri, Nov 8, 2013 at 8:44 PM, Maciej Stachowiak m...@apple.com wrote:


 On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

  On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com
 wrote:
  As I replied before, there should only be one attribute — srcset.
 
  I have a serious suggestion - could we rename srcset to src-n
  (literally, src-n), and then just ship it?  This puns in three
  interesting ways:
 
  1. If src-N is never accepted, it's still an attribute that holds N
  src values, so src-n works well.
  2. If src-N is accepted, but as a single attribute, src-n is just
  named perfectly to match the proposal name.
  3. If src-N is accepted fully, the obvious ordering is clearly src-1,
  src-2, src-3, ..., src-n, which matches the fallback we want.
 
  A guaranteed last fallback is legitimately useful for the full src-N
  proposal, so I'm totally okay with integrating that into my proposal.
 
  This'll let us ship now, and then continue to discuss src-N for a
  while, with whatever solution we land on still having a consistent
  name. Win for authors no matter what the result is.

 Further discussion will go to whatwg, which is a better place to discuss
 technical details of the src-N proposal, but I wanted to comment on this:

 (1) In the case that src-N is never adopted, or is adopted in
 single-attribute form, srcset matching the CSS image-set() function will
 be more useful than src-n matching a hypothetical proposal based on
 multiple attributes.

 (2) Neither src-n nor srcset is super-obvious as a final fallback, but
 either is a rule that could plausibly be learned.

 (3) In the absence of considerations about matching anything else, source
 set better conveys the idea of selecting from multiple sources than
 source n, at least to me.

 So I don't think your proposal is super helpful to enable a future
 transition. What might be helpful:

 (A) Change srcset parsing in implementations now to be compatible to
 extension with an additional list level (for instance, drop everything
 after the first ||).
 (B) Remove support for the w and h specifiers from srcset
 implementations since no one loves those and they are apparently not really
 adequate to addressing their use case.


The w and h specifiers are not implemented in neither WebKit nor Blink,
so this is a non-issue.


 (C) Ship srcset with these two changes ASAP.

 This would leave the field open to either extending the microsyntax or
 adding more attributes or both. And authors will at least have a way to
 address the multi-resolution-only case, a case where I believe we have no
 substantial controversy about the right solution.

 Regards,
 Maciej

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

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

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Thu, Nov 7, 2013 at 3:32 AM, Benjamin Poulain benja...@webkit.orgwrote:

 On 11/6/13, 3:24 PM, Yoav Weiss wrote:


 On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain benja...@webkit.org
 mailto:benja...@webkit.org wrote:

 On 11/6/13, 10:53 AM, John Mellor wrote:

 On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak
 m...@apple.com mailto:m...@apple.com
 mailto:m...@apple.com mailto:m...@apple.com wrote:
   
My initial impression is that it seems a bit overengineered.

 I sympathize. The issue of srcN appearing to be a complex
 solution to a
 seemingly simple problem came up again on IRC chatting to rniwa,
 so I
 thought I'd try to explain this briefly.

 Unfortunately, responsive images is a deceptively complex
 problem. There
 are 3 main use cases:
 1. dpr-switching: fixed-width image resolution based on
 devicePixelRatio.
 2. viewport-switching: flexible-width image resolution based on
 viewport
 width and devicePixelRatio.
 3. art direction: same as #1 or #2, except additionally, must
 serve
 completely different images based on viewport width.


 How important and common are each of those use cases?
 Handling every imaginable use case by the Engine is a non-goal.


 There has been a lot of demand for dpr-switching since the first
 iPad Retina. This has caused some very ugly hacks on the Web. It is
 very important to address that issue.

 Viewport switching is usually done to adapt images for mobile device
 VS large/huge display devices. It is a valid concern but it is not
 easily addressed. Srcset can/should likely be improved regarding this.

 I believe (feel free to prove me wrong) dynamic viewport adaptation
 and what you call art direction is not as common.

 On a survey ran at the last Mobilism conference (and on Twitter) 41% of
 respondents said they're already using some hack to get their responsive
 image art-directed.
 A manual responsive site survey
 http://japborst.net/blog/the-current-state-of-art-direction.html
 showed that

 23% of the sites art-direct their images, and 58% do that when
 (subjectively) the design requires it.
 So it might not be as common as viewport switching (which is practically
 everywhere), but it is pretty common.


 The survey you linked (http://japborst.net/blog/the-current-state-of-art-
 direction.html) was targeting specifically responsive websites.


That's true. This is why I called it a responsive site survey.

Those websites represents only an unquantified subset of the web.


Arguably, they also represent the future of Web design, since the multitude
of devices and form factors renders the alternative methods impractical.


 Even with that very targeted subset, only a small percentage was actually
 implementing art-direction.


I wouldn't consider almost 1 out of 4 a small percentage, given the fact
that art-direction today requires some extra effort over a native solution
(the use of polyfills, etc).


 It looks to me like art-direction should not be imposing all the design
 constraints over the more important use cases.


 Something that is still unclear to me is why srcN would be doing a better
 job than JavaScript for art-direction?


SrcN would enable art-directed image to be picked up by the preloader and
loaded fairly early in the page's life-cycle (like all other images).
Using polyfills, you have to either download the polyfill script
synchronously (which is considered a performance bad practice) and
frequently poll the DOM for discovered images that you'd then add to the
resource download queue, or download it asynchronously and start polling
the DOM for image much later in the page's life-cycle. In short, with srcN,
performance would be better.

There are many complex cases that are handled dynamically (changing images
 on zoom; tiling large images on zoom; changing layout on rotation; creating
 popover style layout when switching portrait/landscape, etc).


That's true, and none of them is considered to be implemented as part of a
responsive images solution. (even though some of them can be handled with
CSS).
These cases are all related to interaction with images once they were
loaded, not to the loading process itself and the decision which images
need to be loaded in the first place.



 Benjamin

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

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Wed, Nov 6, 2013 at 9:00 PM, Maciej Stachowiak m...@apple.com wrote:



 (b) I am dubious of some of the use cases proposed as essential for src-N
 that ratchet up the complexity. For example, your case #2 of
 viewport-switching


Viewport switching is very common in almost any responsive design.


 , in particular its headlining use case of a multi-column view that
 changes number of columns at different viewport widths, was not addressed
 or even meaningfully discussed in the N years that srcset and picture
 were being developed.


This case was brought
uphttp://24ways.org/2012/responsive-images-what-we-thought-we-needed/as
one of the cases previous proposals did not address. Admittedly, it
wasn't discussed enough, even though it breaks one of the assumptions of
previous viewport switching proposals - that a smaller viewport necessarily
means a smaller image.


 This makes me doubt somewhat that addressing this use case is now
 absolutely critical. It seams kinda neat, but is it really a showstopper to
 address this in version 1.0 of the feature?


There are other advantages to the viewport-url syntax over the previous
viewport-switching proposal, srcset's 'w' syntax, that were thoroughly
discussed:
* The fact that it enables to define viewport width using relative units
enables it to match responsive designs that are based on relative units,
without breaking the design or the images for users with an non-typical
default font-size (e.g. Kindle, or users that have set a preference)
* The fact that it enables authors to define either min or max-width as the
breakpoints (or for that matter, any MQ, if the author chooses to do so, at
the expense of verbosity), makes it compatible and easy to author with any
responsive design approach (the classic example is mobile first vs.
desktop first), by defining the image's variable width percentage,
instead of a fixed width. That makes it much easier to author any
responsive design with fluid images where the image dimensions are not
linear (i.e. the image dimensions as percentage of the viewport vary
between breakpoints, which is a common case), when compared to srcset's 'w'
syntax.

So, I'd say that the viewport-url syntax is important for ease of authoring
and making sure images match their layout, as well as the varying column
number as image width case.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain benja...@webkit.orgwrote:

 On 11/6/13, 10:53 AM, John Mellor wrote:

 On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak m...@apple.com
 mailto:m...@apple.com wrote:
  
   My initial impression is that it seems a bit overengineered.

 I sympathize. The issue of srcN appearing to be a complex solution to a
 seemingly simple problem came up again on IRC chatting to rniwa, so I
 thought I'd try to explain this briefly.

 Unfortunately, responsive images is a deceptively complex problem. There
 are 3 main use cases:
 1. dpr-switching: fixed-width image resolution based on devicePixelRatio.
 2. viewport-switching: flexible-width image resolution based on viewport
 width and devicePixelRatio.
 3. art direction: same as #1 or #2, except additionally, must serve
 completely different images based on viewport width.


 How important and common are each of those use cases?
 Handling every imaginable use case by the Engine is a non-goal.


 There has been a lot of demand for dpr-switching since the first iPad
 Retina. This has caused some very ugly hacks on the Web. It is very
 important to address that issue.

 Viewport switching is usually done to adapt images for mobile device VS
 large/huge display devices. It is a valid concern but it is not easily
 addressed. Srcset can/should likely be improved regarding this.

 I believe (feel free to prove me wrong) dynamic viewport adaptation and
 what you call art direction is not as common.


On a survey ran at the last Mobilism conference (and on Twitter) 41% of
respondents said they're already using some hack to get their responsive
image art-directed.
A manual responsive site
surveyhttp://japborst.net/blog/the-current-state-of-art-direction.html
showed
that 23% of the sites art-direct their images, and 58% do that when
(subjectively) the design requires it.
So it might not be as common as viewport switching (which is practically
everywhere), but it is pretty common.

I have the feeling those corner cases may be better addressed with
 JavaScript.


I don't think art-direction qualifies as a corner case.




 In my opinion WebKit should not support srcN in its current form. We are
 here to make the web a better/friendlier platform. The srcN proposal does
 not do that, it is a catch all that makes the important use cases more
 difficult.

 Benjamin

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

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

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.ws wrote:

 On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi
 wrote:
  Ignoring other aspects of this, the idea of making attribute name an
  enumeration is somewhat distasteful. It will require ugly special
 parsing.
  The platform has plenty of attribute values that are lists already.

 The parsing aspect isn't particularly new - parsing data-* attributes
 presents the same problem.  You just need to filter the list of
 attributes on the element to look for things with a src- prefix.  I've
 heard direct feedback from Yoav, implementing in Blink, that it's not
 a big problem.


 Just because it was not a big problem in one engine, it doesn't mean it
 won't be in other engines.
 If we're supporting src-N attributes in WebKit, I'd like to see N to
 have a small upper bound; e.g. 10.
 so that we can enumerate all parsed attributes statically at the
 compilation time.


 Out of curiosity, what would be the benefits of such a restriction?


 We're considering to implement an optimization that takes the advantage of
 parsed attributes being a finite set at the compilation time.

 Having this feature will make it much harder to implement such an
 optimization.  Note that data-* attributes don't need to be parsed since it
 doesn't synchronously update Element's internal states.

 - R. Niwa


Will setting the limit on the number of possible attributes at 99 still
enable that optimization?
Many people (on the RICG's IRC and on Blink-dev) feel that setting the
limit to 9, even if it'd be enough today, leaves fairly little space for
future evolution. Setting it to some random number between 10 and 99 feels
arbitrary to me. So, will 99 be OK with you?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote:
  Ignoring other aspects of this, the idea of making attribute name an
  enumeration is somewhat distasteful. It will require ugly special
 parsing.
  The platform has plenty of attribute values that are lists already.

 The parsing aspect isn't particularly new - parsing data-* attributes
 presents the same problem.  You just need to filter the list of
 attributes on the element to look for things with a src- prefix.  I've
 heard direct feedback from Yoav, implementing in Blink, that it's not
 a big problem.


 Just because it was not a big problem in one engine, it doesn't mean it
 won't be in other engines.
 If we're supporting src-N attributes in WebKit, I'd like to see N to have
 a small upper bound; e.g. 10.
 so that we can enumerate all parsed attributes statically at the
 compilation time.


Out of curiosity, what would be the benefits of such a restriction?

When thinking about the feature's implementation for Blink, I found it
easier to iterate once over the element's attribute, create a vector
containing all the srcN attributes (so all attrs that start with src-),
sort it according to attribute numeric order, and return that vector when
the srcN attributes are requested from the element. For the
HTMLPreloadScanner, I'd probably need to create a similar vector attribute
by attribute, sort it at the tag's end, and send it to the main thread.

Wouldn't a similar approach work for WebKit?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Thu, Oct 24, 2013 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 23, 2013, at 11:24 PM, Yoav Weiss y...@yoav.ws wrote:


 On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi
 wrote:
  Ignoring other aspects of this, the idea of making attribute name an
  enumeration is somewhat distasteful. It will require ugly special
 parsing.
  The platform has plenty of attribute values that are lists already.

 The parsing aspect isn't particularly new - parsing data-* attributes
 presents the same problem.  You just need to filter the list of
 attributes on the element to look for things with a src- prefix.  I've
 heard direct feedback from Yoav, implementing in Blink, that it's not
 a big problem.


 Just because it was not a big problem in one engine, it doesn't mean it
 won't be in other engines.
 If we're supporting src-N attributes in WebKit, I'd like to see N to have
 a small upper bound; e.g. 10.
 so that we can enumerate all parsed attributes statically at the
 compilation time.


 Out of curiosity, what would be the benefits of such a restriction?

 When thinking about the feature's implementation for Blink, I found it
 easier to iterate once over the element's attribute, create a vector
 containing all the srcN attributes (so all attrs that start with src-),
 sort it according to attribute numeric order, and return that vector when
 the srcN attributes are requested from the element.


 Your described strategy is both not quite correct (srcN attributes are not
 all attributes that start with src-)


I left out the followed by an integer part. Obviously, that should be
part of the algorithm.


 and it's O(N^2) for srcN attributes added dynamically with script.


The typical case for dynamically added srcN attributes would be adding them
in order (since otherwise, a wasteful resource download might be
triggered). That is very similar to srcset, which when added dynamically,
must be added before the src attribute.
For that case, adding N dynamic attributes to the end of the vector would
have O(N) complexity.
The case for unordered addition can be optimized to O(NlgN) by replacing
the vector with a linked list and adding each new attribute in its order
using binary search.



 I think the authoring complexity is a more relevant consideration than the
 implementation complexity, though.


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

Re: [webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Oct 20, 2013 11:31 AM, PERIER Romain romain.per...@gmail.com wrote:

 Hi all,
 srcset is not complicated enough for a web developer?  why do you want to
add complexity for the developer ? The srcset specification already convers
DRP switching and viewport

The reasoning behind the new proposal was detailed by John Melloer at
http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/

In short, srcset's viewport syntax doesn't cover the art-direction use-case
and doesn't really cover the viewport based resource selection use case
either.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

Hello WebKiteers,

I'd like to get the project's opinion on a recent responsive image proposal
by Tab Atkins dubbed srcN:
http://tabatkins.github.io/specs/respimg/Overview.html

This proposal covers all the major responsive images use-cases: DPR based
resource selection, viewport dimensions based resource selection and
art-direction.
It does so while avoiding previous implementor concerns regarding the
picture element and its complexity, and while providing better authoring
tools for viewport based resource selection than previous proposals.

The srcN proposal does come to replace the srcset DPR switching syntax
which recently landed in WebKit (an effort I was a part of). OTOH, srcN's
x-based URL syntax replicates srcset's DPR syntax, so I believe large parts
of that code can be reused in srcN's implementation.

Will the project welcome patches implementing the srcN proposal? (Possibly
behind a flag)

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

Re: [webkit-dev] When should I use AtomicString vs String?

[Yoav Weiss]

Are there any advantages to String over AtomicString?


On Fri, May 31, 2013 at 11:14 PM, Daker Pinheiro 
daker.pinhe...@openbossa.org wrote:

 It is faster to compare and hash AtomicString than regular Strings.


 On Fri, May 31, 2013 at 5:57 PM, Brendan Long s...@brendanlong.comwrote:

 I hope this isn't a stupid question, but I can't find any references to
 what the difference between AtomicString and String is. It looks like
 AtomicString is generally preferred, but I don't know why. Can someone
 fill me in on this? Is there any refences for the classes in WTF?


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




 --
 Daker Fernandes Pinheiro
 http://codecereal.blogspot.com


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


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