Re: [webkit-dev] Request for position on hasDroppedEntry in PerformanceObserverCallback

[Ryosuke Niwa]

This seems fine to me.

On Mon, Aug 31, 2020 at 9:09 AM Nicolás Peña  wrote:
>
> Hi,
>
> We'd like to request an official position on a very small addition to 
> PerformanceTimeline specification. We've added a hasDroppedEntry parameter to 
> PerformanceObserverCallback, which is in 
> https://w3c.github.io/performance-timeline/#the-performanceobserver-interface,
>  and logic for it in 
> https://w3c.github.io/performance-timeline/#queue-the-performanceobserver-task.
>  It lets a developer know when an entry has been dropped from a buffer that 
> the PerformanceObserver cares about. We reached this solution when discussing 
> https://github.com/w3c/performance-timeline/issues/169 in a WebPerf WG call.
> ___
> 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 Storage Buckets API

[Ayu Ishii]

Hi WebKit-dev,

We would like to ask for WebKit's early position on Storage Buckets API.
Storage Buckets API grants sites the ability to create multiple storage
buckets[1], where the user agent may choose to delete each bucket
independently of other buckets. By contrast, today's user agents have a
binary choice of either persisting or deleting all the data stored by a
site. Chrome is preparing to prototype.

Early discussions of Storage Buckets API have been held at TPAC 2019
attended by Youenn from the WebKit team. Notes from this discussion have
been linked below.

Relevant links:

* Explainer:
https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md
* TPAC 2019 Discussion:
https://docs.google.com/document/d/1eBWhY91nUfdT2mys3GaNKX4fKPei79Wk-KlWHYffbAA/edit?usp=sharing
* ChromeStatus: https://chromestatus.com/feature/5739224579964928

[1] Storage Buckets: https://storage.spec.whatwg.org/#buckets

Thank you for your time!

- Ayu I.
___
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]

[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 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
> 

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

[Darin Adler]

> On Aug 31, 2020, at 9:33 AM, David Bokan  wrote:
> 
> We've made lots of improvements to the spec, notably around issues raised in 
> Mozilla's standards-position 
> .

Do you think those improvements address Maciej’s concerns from last December? 
Since you didn’t say that explicitly I was wondering what your take on that was.

— Darin___
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]

[Sending from correct account this time and on root thread]

Hello WebKit-dev,

Bumping this thread to give/get an update.

Text-fragments shipped in Chrome M80. We've made lots of improvements to
the spec, notably around issues raised in Mozilla's standards-position
.

>From Google Search's use (I've seen this being used on Bing as well), we've
seen improvements to user experience metrics and surveys. ajuma@ mentioned
his team might be interested in contributing this to WebKit. I'm wondering
if this is something that WebKit would accept or if there's any updated
concerns?

Thanks,
David

On Wed, Dec 11, 2019 at 2:39 PM Maciej Stachowiak  wrote:

>
> Hi David,
>
> Apple folks have discussed this internally. In general, we think this is
> useful functionality to expose. Some points of feedback (let me know if any
> of these should be filed as an issue against the spec):
>
> (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.
>
> It seems like the spec doesn’t provide a solution for this. We think some
> form of feature detection would slightly improve the situation. Other than
> that, We're not sure how to avoid potential breakage. Maybe evangelize
> WebMD if that’s the only major site that breaks on unexpected fragments?
>
> (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.
>
> (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.
>
> We would frame these more as points of concern than opposition to the
> whole idea, but it seems wise to address them before shipping.
>
> Regards,
> Maciej
>
>
> On Dec 2, 2019, at 12:22 PM, David Bokan  wrote:
>
> Hello webkit-dev,
>
> I'd like to solicit feedback as well as an official position from Webkit
> on our proposal for the text fragment directive:
> https://github.com/WICG/ScrollToTextFragment.
>
> In summary: this is a feature that allows authors and users to craft URLs
> to pages and specify a snippet of text on the page as a subresource
> (visually highlighting it and scrolling it into view). Analogous to
> element-id based fragment anchors but for text.
>
> You can try this out today in Chrome Beta by enabling 
> chrome://flags/#enable-text-fragment-anchor.
> Here's an example link:
>
>
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>
> Relevant Links:
>
> 
> Explainer
> 
> Spec 
> TAG Review 
> (Currently Suspended) Blink Intent Thread
> 
> Issue on Mozilla standards-positions
> 
>
> We've been using the GitHub repo for issue tracking but happy to take
> feedback (official or otherwise) in any form.
>
> Thank you!
> David
> ___
> 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