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

[Myles C. Maxfield]

I’m on record in that csswg-drafts issue as being positive on these descriptors.

Myles

> On Sep 18, 2020, at 12:55 PM, Xiaocheng Hu  wrote:
> 
> 
> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Requesting a position on Document Policy

[Ian Clelland]

Pinging this thread again, since the TAG has asked about multi-vendor
interest  as well
recently.

Since I sent the original email, there has also been some discussion within
the WebAppSec W3C working group about using Document Policy to deprecate
security-negative features on the web platform; +John Wilander
 who may have additional thoughts on the utility of
this API from that angle.

On Tue, Jul 28, 2020 at 10:02 AM Ian Clelland 
wrote:

> Hi WebKit!
>
> I'm building out the infrastructure in Blink for Document Policy, and
> would like to ship at least part of it in Chrome for developers to take
> advantage of. I'd like to get an official position from WebKit leads on
> this. I'm also interested in getting thoughts from other WebKit folks about
> the design or implementation.
>
> Some details:
>
> Document Policy explainer:
> https://github.com/w3c/webappsec-permissions-policy/blob/master/document-policy-explainer.md
> Document Policy spec:
> https://w3c.github.io/webappsec-permissions-policy/document-policy.html
> GitHub Repository (shared with Permissions Policy (previously Feature
> Policy)): https://github.com/w3c/webappsec-permissions-policy
> Blink intent-to-ship discussion:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Za159T1QOek/m/lewQUFlBCQAJ
> Also previously discussed at the TAG:
> https://github.com/w3ctag/design-reviews/issues/408
>
> I think that the last time I brought this to WebKit engineers would have
> been at TPAC last year, where it was discussed in the WebAppSec meetings as
> a way to provide a general configuration mechanism for documents, splitting
> off of ideas that had been floating around at the time for Feature Policy.
>
> While Document Policy itself doesn't prescribe any actual features, it
> could eventually be used to configure the behaviour of different
> web-platform features, such as:
> - Restricting the use of poorly-performing images
> - Disabling slow synchronous JS APIs
> - Configuring frame, image, or script loading styles
> - Restricting overall document sizes or network usage
> - Restricting patterns which cause page re-layout
>
> The initial intent, though, is to ship part of this in Chrome to support
> an opt-out for the Scroll-to-text-fragment feature.
>
> Document Policy has two different mechanisms which can work in conjunction
> with each other: The first is the Document-Policy (and
> Document-Policy-Report-Only) HTTP header, which just sets the policy on the
> document it ships with. The other is a negotiation mechanism between an
> embedder and its embedded content, which uses an Iframe attribute and an
> additional request header.
>
> I'm currently interested in shipping just the first of these mechanisms in
> Chrome. The second may warrant more discussion and review, and isn't needed
> for the Scroll-to-text-fragment opt-out. The details are in the Chrome
> Platform Status entry:
> https://www.chromestatus.com/feature/5756689661820928
>
> Feel free to ask any questions; I'm happy to discuss this in whatever
> forum works best for folks,
>
> Thanks!
> Ian
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Problems with code review tool

[Saam Barati]

Hi Ken,

I think this is a known problem. Unfortunately, this happens to me a few times 
a year as well.

- Saam

> On Sep 21, 2020, at 2:26 PM, Ken Russell  wrote:
> 
> Hi,
> 
> Often when I publish code reviews on bugs.webkit.org 
> , my browser tab gets stuck waiting for 
> ews.webkit.org . Reloading the bug shows my comments, 
> but because the submission doesn't complete, the review comments are still 
> treated as pending by the tool, so publishing again causes duplicates.
> 
> Has anyone else run into this?
> 
> (My browser is Chrome on macOS.)
> 
> Thanks,
> 
> -Ken
> 
> 
> -- 
> I support flexible work schedules, and I’m sending this email now because it 
> is within the hours I’m working today.  Please do not feel obliged to reply 
> straight away - I understand that you will reply during the hours you work, 
> which may not match mine. (credit: jparent@)
> 
> ___
> 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