Re: [webkit-dev] WebKit position on Wake Lock API

2019-12-11 Thread Ryosuke Niwa 
On Wed, Dec 11, 2019 at 11:42 AM Maciej Stachowiak  wrote:

>
> Is there a Blink Intent thread currently running on this or about to
> start?  And do you happen to know if there is a Mozilla standards-positions
> issue on this? (We like to take into consideration whet the other browser
> engines are thinking.)
>

https://github.com/mozilla/standards-positions/issues/210 is Mozilla's
standards position issue.

> On Dec 10, 2019, at 11:46 PM, Thomas Steiner  wrote:
>
> Hello WebKit Dev,
>
> Following Maciej's invitation to send requests for positions on API
> proposals to this very mailing list, I would like to gauge WebKit's
> position on the Wake Lock API:
> https://bugs.webkit.org/show_bug.cgi?id=205104. Nota bene, this is an API
> that is potentially useful for a "document web" even, not just an
> "application web".
>
> Thanks,
> Tom
>
> ___
> 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] Feedback on Blink's text fragment directive proposal

2019-12-11 Thread Nick Burris 
Hi Maciej,

Thanks for the reply! David's away this week, my responses are inline:

(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?


There is a feature detection mechanism that we have
[specified](https://wicg.github.io/ScrollToTextFragment/#feature-detectability)
and implemented, see
[#19](https://github.com/WICG/ScrollToTextFragment/issues/19). Feature
detection can be done by checking
`typeof(window.location.fragmentDirective) == 'object'`. Indeed, there
is still a compat concern as described in the intent to ship, since
these links will exist in the wild. Since WebMD is the only broken
site we've come across, I agree it would be good to make sure they're
aware of this. I'll reach out.

(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.


Agreed - we're wrapping up on some smaller remaining issues and our
next step is to turn this into PRs.

> (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 wanted to keep this simple to ensure links are robust (generally
they will be generated algorithmically, where one can ensure the text
directive is unique in the page). If we add the dimension of relying
on starting at a fragment, that fragment or the text could move in the
page and break the link, even if the desired text is still present on
the page. Feel free to open a Github issue if you think this is worth
discussing more!

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

Re: [webkit-dev] WebKit position on Wake Lock API

2019-12-11 Thread Maciej Stachowiak 

Is there a Blink Intent thread currently running on this or about to start?  
And do you happen to know if there is a Mozilla standards-positions issue on 
this? (We like to take into consideration whet the other browser engines are 
thinking.)


> On Dec 10, 2019, at 11:46 PM, Thomas Steiner  wrote:
> 
> Hello WebKit Dev,
> 
> Following Maciej's invitation to send requests for positions on API proposals 
> to this very mailing list, I would like to gauge WebKit's position on the 
> Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104 
> . Nota bene, this is an API 
> that is potentially useful for a "document web" even, not just an 
> "application web".
> 
> Thanks,
> Tom
> 
> ___
> 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] Feedback on Blink's text fragment directive proposal

2019-12-11 Thread Maciej Stachowiak 

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