[webkit-dev] Request for position on isInputPending

[Andrew Comminos]

Hey all,

We're looking to gather a position from WebKit folks on isInputPending, 
an API to query for the presence of pending input events. It allows 
sites to reduce event latency by yielding during longer computational 
tasks, without sacrificing throughput otherwise.


Explainer: https://github.com/WICG/is-input-pending/

Spec: https://wicg.github.io/is-input-pending/

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

[webkit-dev] Request for position on @font-face descriptors ascent/descent/line-gap-override to override font metrics

[Xiaocheng Hu]

Hi webkit-dev,

I'd like to request an official position on @font-face descriptors
`ascent-override`, `descent-override` and `line-gap-override` for
overriding the default font metrics.

Explainer:
https://gist.github.com/xiaochengh/da1fa52648d6184fd8022d7134c168c1
Spec: https://drafts.csswg.org/css-fonts-4/#font-metrics-override-desc
Chromestatus: https://www.chromestatus.com/feature/5651198621253632

Other information:

These descriptors are newly added into CSS Fonts Level [1], following a
recent resolution [2].
Chromium has already implemented them in M86 behind a flag [3].

[1] https://github.com/w3c/csswg-drafts/pull/5521
[2] https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-693528301
[3]
https://chromium-review.googlesource.com/q/hashtag:%22font-metrics-override%22

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

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[David Bokan]

Friendly ping to get an answer here.

Do my answers above address those points or is there anything else I can
clarify?

Thanks,
David

On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:

> [sending (again, sorry) from correct e-mail]
>
> I think Nick's replies
>  
> mostly
> still apply, some updated answers to those questions.
>
> (1) We’re concerned about compatibility issues in a world where some
>> browsers support this but not all. Aware browsers will strip `:~:`, but
>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>> mentioned that at least one site (webmd.com) totally breaks if any
>> fragment ID is exposed to the page. This makes it difficult to create a
>> link that uses this feature but which is safe in all browsers:
>> - Since there is no feature detection mechanism, it’s hard for a webpage
>> to know whether it should issue such a link. It would have to be based on
>> UA string checks, which is regrettable.
>> - A link meant for a supporting browser can end up in a non-supporting
>> browser, at the very least by copy paste from the URL field, and perhaps
>> through other features to share a link.
>>
>
> We do have a feature detection
> 
>  mechanism
> for this.
>
> On the latter point, this is true but we think implementing fragment
> directive stripping (removing the part after and including `:~:`) is
> trivial even if the UA doesn't wish to implement the text-fragment feature.
> FWIW, we haven't seen or heard of another such example since.
>
>
>> (2) The portions of this Community Group report that monkey patch other
>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>> against those specifications. Monkeypatching other specs is not a good way
>> to build specifications for the long term.
>>
>
> We still need support from another vendor to start merging the monkey
> patches into the real standards - if Apple's supportive I'd be happy to
> start on that immediately.
>
>
>> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
>> more natural semantic would be that the text search starts at the fragment,
>> so if there are multiple matches it’s possible to scroll to a more specific
>> one. It’s not clear why the fragment is instead entirely ignored.
>>
>
> This was discussed in more detail in issue#75
> ; I agree with
> Nick's point that the disambiguation syntax is already specific enough that
> starting from a fragment isn't necessary. This also keeps us
> mostly-compatible with the TextQuoteSelector
>  specified
> in WebAnnotations which I think may have benefits for interaction with
> annotation applications.
>
> On Mon, Aug 31, 2020 at 1:31 PM David Bokan  wrote:
>
>> I think Nick's replies
>> 
>> mostly still apply, some updated answers to those questions.
>>
>> (1) We’re concerned about compatibility issues in a world where some
>>> browsers support this but not all. Aware browsers will strip `:~:`, but
>>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>>> mentioned that at least one site (webmd.com) totally breaks if any
>>> fragment ID is exposed to the page. This makes it difficult to create a
>>> link that uses this feature but which is safe in all browsers:
>>> - Since there is no feature detection mechanism, it’s hard for a webpage
>>> to know whether it should issue such a link. It would have to be based on
>>> UA string checks, which is regrettable.
>>> - A link meant for a supporting browser can end up in a non-supporting
>>> browser, at the very least by copy paste from the URL field, and perhaps
>>> through other features to share a link.
>>>
>>
>> We do have a feature detection
>> 
>> mechanism for this.
>>
>> On the latter point, this is true but we think implementing fragment
>> directive stripping (removing the part after and including `:~:`) is
>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>> FWIW, we haven't seen or heard of another such example since.
>>
>>
>>> (2) The portions of this Community Group report that monkey patch other
>>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>>> against those specifications. Monkeypatching other specs is not a good way
>>> to build specifications for the long term.
>>>
>>
>> We still need support from another vendor to start merging the monkey
>> patches into the real standards - if Apple's supportive I'd be happy to
>> start on that immediately.
>>
>>
>>> (3) Text fragment trumping a regular fragment ID seems a bit strange.
>>> The more natural