Re: [blink-dev] Intent to implement and ship: Allow as=fetch in navigation early hints preload

[Kenichi Ishibashi]

Thank you Yoav for the suggestions! I'll add more words and context next
time.

On Mon, Jan 23, 2023 at 2:18 PM Yoav Weiss  wrote:

> LGTM1
>
> On Mon, Jan 23, 2023 at 2:57 AM Kenichi Ishibashi 
> wrote:
>
>> Contact emailsba...@chromium.org
>>
>> ExplainerNone. This feature is standardized.
>>
>
> It's typically helpful to write a few words that explain the feature and
> the addition to it, even if there's no need for a full fledged explainer
> document for this specific addition.
> For example, you could have linked to the feature's broader explainer
> ,
> and then explain that this adds a new `as` value of "fetch" that would
> enable developers to use Early Hints for resources with that potential
> destination (e.g. `fetch()`ed resources).
>
>
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/semantics.html#attr-link-as
>> https://html.spec.whatwg.org/#early-hints
>>
>> Summary
>>
>> Support  in navigation early hints. This
>> allows web developers to preload resources that are fetched by the fetch()
>> API.
>>
>>
>> Blink componentBlink>Loader>Preload
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>
> I agree that a TAG review is not needed here, but it's typically better to
> outline the reason.
> In this case, we're adding support for an extra type of resource without
> changing the API's shape or its integration with the rest of the platform.
>
>
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low. The feature is already specified in the HTML and the Fetch standard.
>>
>>
>> *Gecko*: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1407355)
>>
>> *WebKit*: No signal Previously asked in
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html
>>
>> *Web developers*: No signals. We got this feature request from one of
>> our partners.
>>
>
> I would count a feature request as a slightly positive signal.
>
>
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> N/A
>>
>>
>>
>> Debuggability
>>
>> We have a tracking bug
>>  to
>> improve debuggability.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?We will submit a Web Platform Test along with the implementation (Ongoing
>> CL ).
>>
>> Flag nameN/A
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1408649
>>
>> Estimated milestones
>>
>> M112
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6195487999262720
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX--M%3DZkTz-ZicOW61C9tUJjKvz4cQU49EsnDK7PUG5puGg%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX-_O7%2Buvu8VbMox69M7f0E7BeEeZ1BC4frEkoXbytaLbdQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Thanks Noam!

I'll add support for the other cases behind the feature flag and we'll ship
it when we are "interoperable enough".

Regards,
Traian


On Wed, Dec 14, 2022 at 6:41 AM Noam Rosenthal 
wrote:

>
>
> On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas 
> wrote:
>
>> If we have plans to fix issues on this feature later, why not fixing
>> them before and then shipping when things look good?
>>
>> If we unprefix it, it'll kind of appear as a new Chromium feature that
>> people can use, and they will expect it follows the spec.
>
>
> I agree, for example people might (wrongfully) rely on
> CSS.supports("background-image", "image-set(url(example.jpg) 1x)")
> to mean that the full set of image-set features is supported.
> I'm not sure people are more granular than that about feature detection
> but we probably have data about that.
>
> It might be wise to support the cases behind the prefix, and unprefix when
> the behavior is close to complete and interoperable enough.
> We don't need to rely on people posting bug reports when we know the
> issues today by looking at the WPT failures.
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvt_2YFwe1rKbC3K-teScR9J8_VvHGEJd2rC_D1wM7p0nA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Hi Rego,

If we have plans to fix issues on this feature later, why not fixing
> them before and then shipping when things look good?

Sounds good. I'll fix the issues first, and then I will update the Intent.

Checking the tests results in wpt.fyi:
>
> https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master=chrome%5Bexperimental%5D=chrome%5Bstable%5D=firefox%5Bexperimental%5D=safari%5Bexperimental%5D=subtest
>
> I'm confused about the first examples there:
> * e.style['background-image'] = "image-set(url(example.png) 1x)"
>   is passing
> But:
> * e.style['background-image'] = "-webkit-image-set(url(example.png) 1x)"
> should set the property value
>   is not passing
>
That is a strange one that I was also confused by initially as well. It is
because the '-webkit-' prefixed 'image-set' is expected to serialize to the
same value as standard 'image-set':
"Implementations must accept -webkit-image-set() as a parse-time alias
of image-set(). (It’s a valid value, with identical arguments to
image-set(), and is turned into image-set() during parsing.)"
https://drafts.csswg.org/css-images-4/#deprecated.
Chrome is returning "*-webkit-*image-set(url(\"example.png\") 1x)" while
the expected is "image-set(url(\"example.png\") 1x)"
I fixed this in:
https://chromium-review.googlesource.com/c/chromium/src/+/4167006

Regards,
Traian

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvvcw%3D9vPauKowJsfpcCB1J9oG_ier-1HvHjPk0iUo1mQg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Mike Taylor]

LGTM1

On 1/23/23 2:26 PM, Khushal Sagar wrote:



On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor  
wrote:


Hi Khushal,

On 1/19/23 3:12 PM, Khushal Sagar wrote:


Contact emails

bo...@chromium.org, hvanops...@chromium.org,
jakearchib...@chromium.org, khushalsa...@chromium.org,
vmp...@chromium.org


Explainer

https://github.com/WICG/view-transitions/blob/main/explainer.md



Specification

https://www.w3.org/TR/css-view-transitions-1



Summary

View Transitions
is
an API that enables the creation of polished transitions. Web
developers only need minimal effort to make transitions look
nice. They can choose to use some default animation properties,
or they can customize their own transition effects to achieve a
desired transition experience.


This is accomplished by leveraging user-agents’ ability to
persist visual representations of rendered output (i.e.
snapshots) and blend them with the live DOM state’s rendered
output. The API also allows these animations to be customized via
standard CSS animation properties.

Note that while this intent is limited to shipping an API for
same-document transitions (i.e. by using
document.startViewTransition, as outlined in the spec), there is
ongoing work to provide this feature for same-origin,
cross-document navigations (MPA). MPA support will be added as a
follow up via a separate intent to ship.


Blink component

Blink>ViewTransitions




TAG review

https://github.com/w3ctag/design-reviews/issues/748



Can you confirm that all the follow-up issues


filed in response to feedback in this review are
backwards-compatible with what you propose to ship now?


Yes, most follow-up issues filed based on TAG feedback are about 
transitions initiated from navigations. This is part of the MPA work 
which we plan to ship as a follow up and it can be shipped 
independently of the same-document transitions covered by this intent.


The only issue on that review which concerns same-document transitions 
is #8319 , a syntax 
which would allow selecting a subset of generated pseudo-elements. 
This syntax addition can be made in a backwards-compatible way.


Thanks, SGTM.



TAG review status

Pending


Risks


Interoperability and Compatibility

Low. As a new feature, the primary risk is that other browsers do
not implement it. But since this is a progressive enhancement,
sites should be able to feature-detect and drop usage of the
feature easily in browsers where it is not supported without
breaking any site functionality.


This feature can be feature-detected by checking the existence of
the document.startViewTransition function:

```js

if (!document.startViewTransition) {

  /* feature is not available */

} else {

  /* start transition */

}

```

Gecko: Under consideration
(https://github.com/mozilla/standards-positions/issues/677
)


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/48
)


Web developers: Strongly positive interest in and developer
experimentation with the API:

 *

Updated developer.chrome article (Twitter)


 *

News about the new SET API (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

I/O Session (Youtube
)

 *

Dev-built demo using SET (Reddit)



 *

Dev-built demo using SET (Twitter)



 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 5  is currently ramping up to 50% of the stable release 
population. 

Thanks.
Victor

On Monday, January 9, 2023 at 2:31:08 PM UTC-5 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 5  is currently ramping up to 10% of the stable release 
> population. We will monitor the change has any impacts. 
>
> Thanks.
> Victor
>
> On Wednesday, December 7, 2022 at 4:56:18 PM UTC-5 Victor Tan wrote:
>
>> Hi blink-dev,
>> UA Reduction Phase 5  is currently ramping up to 5% of the stable release 
>> population. We will monitor the change has any impacts. 
>>
>> Thanks.
>> Victor
>>
>> On Thursday, December 1, 2022 at 3:55:50 PM UTC-5 Mike Taylor wrote:
>>
>>> Thanks Ziling. We're unlikely to make the change just ahead of the 
>>> weekend, but will ping this thread early next week once the move to 5% is 
>>> submitted.
>>>
>>> On 12/1/22 1:36 PM, Ziling Zhao wrote:
>>>
>>> Hey Mike, 
>>>
>>> I think moving to 5% early sounds good for YouTube. The 1% doesn't seem 
>>> to be giving us consistent data and we would want to get more traffic as 
>>> soon as possible. If we were to move forward, would this re-roll the 
>>> experiment or just expand? How soon would we be able to roll this out?
>>>
>>> Thanks!
>>>
>>> On Mon, Nov 28, 2022 at 3:33 PM Mike Taylor  
>>> wrote:
>>>
 Hi Ziling,

 (forgive the delay in replying, I took some time off and managed to not 
 check my email)

 Based on the other feedback we've received both internally and 
 externally (and the lack of any negative impact thus far), I don't think 
 we 
 want to add an additional month to our rollout schedule before hitting 
 100%. Another possible option would be to move to 5% sooner, at least 1 
 month ahead of Jan 9th, ideally with enough time to observe metrics ahead 
 of the Finch freeze on Dec 16th, in case something scary happens that 
 would 
 warrant a rollback.

 Would that work for YouTube?

 thanks,
 Mike

 On 11/17/22 7:12 PM, Ziling Zhao wrote:

 Hello, 

 YouTube -- and various other Google properties -- have been analyzing 
 the results of this 1% experiment. We're concerned that the 1% may not 
 provide enough data especially due to the amount of slicing (modern 
 chrome, 
 non windows vs. legacy windows, etc.). On YT, we are seeing significant 
 metrics impact on, and given the holidays, there's a short amount of time 
 available for us to iterate and debug issues before we rollout to 10%.

 We'd like to propose:

- An intermediate state of 5% on January 9th rather than jumping 
directly to 10%. 
- The 5% should hold for at least a month, enough for us to do a 
few rounds of experimental analysis and debugging. 


 Thanks.

 On Wednesday, November 2, 2022 at 4:32:02 PM UTC-7 mike...@chromium.org 
 wrote:

> Howdy blink-dev,
>
> Phase 5 of UA Reduction is currently ramping up to 1% of the stable 
> release population. No changes will occur between now and January 9th, 
> pending site compatibility feedback.
>
> thanks,
> Mike
>
> On 9/7/22 12:16 PM, Victor Tan wrote:
>
> Thanks all. I just realized there are some date typos for the roll out 
> plan. Update as follows:  
>
> Stage
>
> Time
>
> Date
>
> Stable 1% (M107+)
>
> Canary/Dev/Beta 100%
>
> M107 stable release is shipping to 100% (a best guess)
>
> Nov 1, 2022
>
> Stable 10% (M107/M108/M109)
>
> ~10 weeks after previous stage
>
> Jan 9, *2023*
>
> Stable 50%
>
> (M107/M108/M109)
>
> ~2 weeks
>
> Jan 23, *2023* 
>
> TOT Default (M111)
>
> ~2 weeks after previous stage
>
> Feb 7, *2023*
>
> Stable 100% (M107=>M111)
>
> ~ Same business day as previous stage
>
> Feb 7, *2023*
>
> Bests,
> Victor
>
> On Wed, Sep 7, 2022 at 11:59 AM Yoav Weiss  
> wrote:
>
>> LGTM3
>>
>> On Wed, Sep 7, 2022 at 5:51 PM Daniel Bratell  
>> wrote:
>>
>>> LGTM2
>>>
>>> /Daniel
>>> On 2022-09-07 17:50, Chris Harrelson wrote:
>>>
>>> LGTM1. If any issues come up during this rollout that affect the 
>>> plan, please bring them back to this thread for our consideration.
>>>
>>> On Thu, Sep 1, 2022 at 11:29 AM Victor Tan  
>>> wrote:
>>>
 Contact emails 

 mike...@chromium.org, vict...@chromium.org

 Explainer 


 https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

 Specification 

 https://www.chromium.org/updates/ua-reduction is the closest thing 
 that specifies Chrome’s UA Reduction plans today. As these changes 
 land in 
 Chromium 

Re: [blink-dev] Virtual Method is not being overridden

[Ryan Hamilton]

Sounds like there is a mistake of some sort in the code. Can you post a CL
so we can look at the actual code?

On Mon, Jan 23, 2023 at 11:25 AM Rahul yadav 
wrote:

> Dear all ,
>
> I have created a new module in blink/renderer/modules
> And my class is extending CanvasRenderingContext class.
>
> I have defined my funcitons "virtual" in CanvasRenderingContext . But in
> my class they are not being overridden .
> I am getting error as :
> "member function declared with 'override' does not override a base class
> member"
>
>  I have checked , there is no typos .  i have overridden all the pure
> virtuals .
>
> Could you please help .
>
> Thanks a lot in advance .
>
> Rahul
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ec96f728-075e-4036-883e-86833826609cn%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfTNeJo%3DLRzj541-qPJRUb%3DjkN1NH3RpP_DFdEZMhr-r6Q%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

['Jun Kokatsu' via blink-dev]

Hi All,

I wanted to provide some updates on outreach I've done last week.

I manually went through a list of sample sites in the use counter
, and
contacted ~10 sites which will be impacted. Among those sites, 3 sites
responded so far.

   1. onsetapp.com has successfully migrated away from data: URLs in
   SVGUseElement.
  - Reason for the usage:


*"We used them to import elements from SVG sprites, basically an SVG file
  containing every icons loaded once at page load as an attempt to improve
  performance of the app."*
   2. jobs.nzz.ch are testing the fix in the development pipeline, and hope
   to migrate away from data: URLs in SVGUseElement soon.
   - Reason for the usage is unsure as it was done a long time ago.
   3. We've reached out to Salesforce contact (thanks Rick!) for
   appexchange.salesforce.com. They are trying to find a responsible team
   for that subdomain to understand why it was used, and if it can be migrated
   away.

I've also identified faucet.okp4.network as a false positive, because they
use svgxuse  as a fallback mechanism
.

I will wait for sometime so that UKM will reach Beta or Stable, to further
identify impacted origins with high volume of access.

BTW, thank you Daniel for creating a page
 with easy to read alternatives!
This was very helpful in the outreach process!

Thanks,

Jun


On Thu, Jan 19, 2023 at 3:23 PM Jun Kokatsu  wrote:

> On Thu, Jan 19, 2023 at 2:14 PM Rick Byers  wrote:
>
>> On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu  wrote:
>>
>>> On Thu, Jan 19, 2023 at 9:29 AM Rick Byers  wrote:
>>>
 Thanks Daniel. I also looked at this page
 
  which
 inlines the same 422 kB long sprite sheet 5 separate times, only to select
 a tiny 422 BYTE SVG out of it each time! In that case, simply inlining the
 desired SVG would save both several MB of network and a lot of parse/decode
 time. Perhaps there's an opportunity for a tool at design time which
 unrolls these inlined sprite sheets, like Jun's tool
  does?

 Rick

 On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
 wrote:

> Without saying whether it is appropriate to block data urls, I would
> like to say that doing what the site is doing with icons in data urls is
> far from the best way to do it. Since there are better ways to accomplish
> the same output, it's not in itself a use pattern that must be preserved.
> It is better to either have the icons in a separate file, or if that is
> unsuitable, have them inline in an invisible svg. I put a quick demo at
> https://dbratell.github.io/svg-use-icons/ but in short you could have
>
> ... id="icon2">...
>
> And then refer to the icons in it with  xlink:href="#icon1"> or 
> That would have cut tens of KB from the cz site source. I checked with
> fs and thanks to optimizations Blink would not have created a separate svg
> document for each icon but that was also a risk.
>
> (Also curious to the answer to Alex' question)
>
> /Daniel
>
> On 2023-01-18 17:50, Alex Russell wrote:
>
> Per today's API OWNERs meeting, a dumb question: is the XSS risk here
> largely down to script execution triggered by this pattern? Or non-script
> content in the inline'd SVG?
>
> Sorry, I just noticed that I only replied to Alex yesterday 
>>> The XSS risk here is mostly about script execution triggered by this
>>> pattern. This includes (but not limited to) inline event handlers and links
>>> with Javascript URLs.
>>>
>>
>> So if we find it's too breaking to disallow this pattern completely,
>> could we instead just disable script execution from within the context of
>> documents resulting from data: URLs in SVGUseAttributes?
>>
>
> Is that solution for Trusted Types or XSS through SVGUseElement in general?
>
> If it is for Trusted Types, it does solve the issue in Chromium for short
> term, but we want other rendering engines to implement Trusted Types as
> well. Does that mean we spec this in Trusted Types that inline event
> handlers from SVGUseElement will be disallowed when enforcing Trusted
> Types?
> One thing I'm not sure about this approach is that each rendering engine
> has differences in supported features inside SVGUseElement.
> For example, if the 
> 
> is supported, then iframes inside foreignObject can have srcdoc, and it can
> contain script tags which are considered "stored" XSS (because the payload
> never goes through DOM APIs), and therefore Trusted Types could be bypassed
> (i.e. script tags are 

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Khushal Sagar]

On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor  wrote:

> Hi Khushal,
>
> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>
> Contact emails
> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
> khushalsa...@chromium.org, vmp...@chromium.org
>
> Explainer
>
> https://github.com/WICG/view-transitions/blob/main/explainer.md
> 
>
> Specification
>
> https://www.w3.org/TR/css-view-transitions-1
>
> Summary
>
> View Transitions
>  is an
> API that enables the creation of polished transitions. Web developers only
> need minimal effort to make transitions look nice. They can choose to use
> some default animation properties, or they can customize their own
> transition effects to achieve a desired transition experience.
>
> This is accomplished by leveraging user-agents’ ability to persist visual
> representations of rendered output (i.e. snapshots) and blend them with the
> live DOM state’s rendered output. The API also allows these animations to
> be customized via standard CSS animation properties.
>
> Note that while this intent is limited to shipping an API for
> same-document transitions (i.e. by using document.startViewTransition, as
> outlined in the spec), there is ongoing work to provide this feature for
> same-origin, cross-document navigations (MPA). MPA support will be added as
> a follow up via a separate intent to ship.
>
> Blink component
>
> Blink>ViewTransitions
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/748
>
> Can you confirm that all the follow-up issues
> 
> filed in response to feedback in this review are backwards-compatible with
> what you propose to ship now?
>

Yes, most follow-up issues filed based on TAG feedback are about
transitions initiated from navigations. This is part of the MPA work which
we plan to ship as a follow up and it can be shipped independently of the
same-document transitions covered by this intent.

The only issue on that review which concerns same-document transitions is
#8319 , a syntax which
would allow selecting a subset of generated pseudo-elements. This syntax
addition can be made in a backwards-compatible way.

>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> Low. As a new feature, the primary risk is that other browsers do not
> implement it. But since this is a progressive enhancement, sites should be
> able to feature-detect and drop usage of the feature easily in browsers
> where it is not supported without breaking any site functionality.
>
> This feature can be feature-detected by checking the existence of the
> document.startViewTransition function:
>
> ```js
>
> if (!document.startViewTransition) {
>
>   /* feature is not available */
>
> } else {
>
>   /* start transition */
>
> }
>
> ```
>
> Gecko: Under consideration (
> https://github.com/mozilla/standards-positions/issues/677)
>
> WebKit: No signal (https://github.com/WebKit/standards-positions/issues/48
> )
>
> Web developers: Strongly positive interest in and developer
> experimentation with the API:
>
>-
>
>Updated developer.chrome article (Twitter)
>
>-
>
>News about the new SET API (Twitter)
>
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>I/O Session (Youtube )
>-
>
>Dev-built demo using SET (Reddit)
>
> 
>
>-
>
>Dev-built demo using SET (Twitter)
>
> 
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>https://twitter.com/dannymoerkerke/status/1597187172783693824
>-
>
>The Shared Element Transition API is Flipping Cool | Chris Coyier
>
> 
>-
>
>Every Transition is a Page Transition? | OddBird
>
>-
>
>https://twitter.com/derSchepp/status/1590709783807791104
>-
>
>Astro stands to benefit highly from View Transitions | Chris 

[blink-dev] Virtual Method is not being overridden

[Rahul yadav]

Dear all ,

I have created a new module in blink/renderer/modules
And my class is extending CanvasRenderingContext class.

I have defined my funcitons "virtual" in CanvasRenderingContext . But in my 
class they are not being overridden .  
I am getting error as : 
"member function declared with 'override' does not override a base class 
member"

 I have checked , there is no typos .  i have overridden all the pure 
virtuals .

Could you please help .

Thanks a lot in advance .

Rahul

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ec96f728-075e-4036-883e-86833826609cn%40chromium.org.

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Mike Taylor]

Hi Khushal,

On 1/19/23 3:12 PM, Khushal Sagar wrote:


Contact emails

bo...@chromium.org, hvanops...@chromium.org, 
jakearchib...@chromium.org, khushalsa...@chromium.org, vmp...@chromium.org



Explainer

https://github.com/WICG/view-transitions/blob/main/explainer.md 




Specification

https://www.w3.org/TR/css-view-transitions-1 




Summary

View Transitions 
is 
an API that enables the creation of polished transitions. Web 
developers only need minimal effort to make transitions look nice. 
They can choose to use some default animation properties, or they can 
customize their own transition effects to achieve a desired transition 
experience.



This is accomplished by leveraging user-agents’ ability to persist 
visual representations of rendered output (i.e. snapshots) and blend 
them with the live DOM state’s rendered output. The API also allows 
these animations to be customized via standard CSS animation properties.


Note that while this intent is limited to shipping an API for 
same-document transitions (i.e. by using document.startViewTransition, 
as outlined in the spec), there is ongoing work to provide this 
feature for same-origin, cross-document navigations (MPA). MPA support 
will be added as a follow up via a separate intent to ship.



Blink component

Blink>ViewTransitions 




TAG review

https://github.com/w3ctag/design-reviews/issues/748 



Can you confirm that all the follow-up issues 
 
filed in response to feedback in this review are backwards-compatible 
with what you propose to ship now?



TAG review status

Pending


Risks


Interoperability and Compatibility

Low. As a new feature, the primary risk is that other browsers do not 
implement it. But since this is a progressive enhancement, sites 
should be able to feature-detect and drop usage of the feature easily 
in browsers where it is not supported without breaking any site 
functionality.



This feature can be feature-detected by checking the existence of the 
document.startViewTransition function:


```js

if (!document.startViewTransition) {

  /* feature is not available */

} else {

  /* start transition */

}

```

Gecko: Under consideration 
(https://github.com/mozilla/standards-positions/issues/677 
)



WebKit: No signal 
(https://github.com/WebKit/standards-positions/issues/48 
)



Web developers: Strongly positive interest in and developer 
experimentation with the API:


 *

Updated developer.chrome article (Twitter)


 *

News about the new SET API (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

I/O Session (Youtube )

 *

Dev-built demo using SET (Reddit)



 *

Dev-built demo using SET (Twitter)



 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

https://twitter.com/dannymoerkerke/status/1597187172783693824


 *

The Shared Element Transition API is Flipping Cool | Chris Coyier



 *

Every Transition is a Page Transition? | OddBird


 *

https://twitter.com/derSchepp/status/1590709783807791104


 *

Astro stands to benefit highly from View Transitions | Chris
Coyier



 *

Shared Element Transitions API Part 1 | Smashing Magazine




Ergonomics

None.


Activation

   Low.


As with interop/compat 

Re: [blink-dev] Intent to Ship: CSS Nesting

[Rune Lillesveen]

On Mon, Jan 23, 2023 at 6:21 PM 'Steinar H. Gunderson' via blink-dev <
blink-dev@chromium.org> wrote:

> On Mon, Jan 23, 2023 at 11:37:21AM -0500, Mike Taylor wrote:
> > I spent quite a lot of time trying to understand the issues around
> nesting
> > syntax. It looks like the CSSWG resolved to adopt "Option 3", with
> > representatives from all 3 engines voting in favor - and the WebKit blog
> > survey also resulted in "Option 3" as the top choice.
> >
> > Do we know if the other engines have started work on implementation of
> > Option 3?
>
> As far as I know, WebKit is indeed working an implementation of Option 3.
>

Enabled feature for preview (TP?) here:

https://github.com/WebKit/WebKit/commit/ceafa556d06a475ae4b9362abeb64a42128ce9ee

-- 
Rune Lillesveen

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRb-QZbjEB1wTf9SrH6PUHcBpqjcnswx0Tcv6egtsct2g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Nesting

['Steinar H. Gunderson' via blink-dev]

On Mon, Jan 23, 2023 at 11:37:21AM -0500, Mike Taylor wrote:
> I spent quite a lot of time trying to understand the issues around nesting
> syntax. It looks like the CSSWG resolved to adopt "Option 3", with
> representatives from all 3 engines voting in favor - and the WebKit blog
> survey also resulted in "Option 3" as the top choice.
> 
> Do we know if the other engines have started work on implementation of
> Option 3?

As far as I know, WebKit is indeed working an implementation of Option 3.

/* Steinar */

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/Y87B/PQu7BSOUyLR%40google.com.

Re: [blink-dev] Intent to Ship: CSS Nesting

[Philip Jägenstedt]

I think that we should ship this. It's a high profile and in-demand new
feature ,
so I have a few questions and comments first.

Taking a look at the open spec issues (
https://github.com/w3c/csswg-drafts/labels/css-nesting-1) some are
explicitly ideas for future changes, but are there any where shipping
amounts to a decision that isn't easily changed? I'm thinking especially of
the CSSOM issues.

In https://wpt.fyi/results/css/css-nesting there's a single subtest
failure, related to how a rule serializes. Is that implemented per spec, or
is it tied up with the open CSSOM issues?

Regarding the threat of a formal objection, there doesn't appear to be any
solution that would fully satisfy everyone, but I trust your judgment that
this is the best option. Additionally, we should not pre-commit Blink to
shipping parser changes, and accept the possibility that what we ship now
is the final shape of the feature.

On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails: se...@chromium.org, futh...@chromium.org
> Explainer: None
>
> Specification: https://drafts.csswg.org/css-nesting
>
> Summary: Add the ability to nest CSS style rules inside other style rules,
> combining selectors from the outer with the inner rule for increasing
> modularity and maintainability of style sheets.
>
> Blink component: Blink>CSS
>
> TAG review: https://github.com/w3ctag/design-reviews/issues/791
>
> TAG review status: Pending
>
> Risks: There is a threat of a formal objection in CSSWG.
>
> Interoperability and Compatibility:
>
> Gecko: Positive (https://github.com/mozilla/standards-positions/issues/695
> )
> WebKit: Positive (https://github.com/WebKit/standards-positions/issues/69)
>
> Debuggability
> Nesting style rules will be a big change for editing and displaying style
> rules in the inspector:
>
> - Showing displaying nested rules for matching declarations
> - Editing selectors
> - Inserting nested rules
> - etc...
>
> Tracking issue for devtools support: https://crbug.com/1172985
> Devtools says they're on track for shipping in M111.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux,
> Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests? Yes
>
> Flag name: CSSNesting
>
> Requires code in //chrome? False
>
> Tracking bug: https://crbug.com/1095675
>
> Estimated milestones
> DevTrial on desktop 109
> DevTrial on Android 109
> Shipping112
>
>
> Anticipated spec changes: See above.
>
> Link to entry on the Chrome Platform Status:
> https://chromestatus.com/feature/5800613594529792
>
> Links to previous Intent discussions:
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com
>
> --
> Software Engineer, Google Norway
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/Y8ph9gk50U2D92f3%40google.com
> .
>

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdMTE%3DjWA4AVXeJfGGTZ5WNzQCR4MiHONuZD3gq43PAOg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Nesting

[Yoav Weiss]

On Mon, Jan 23, 2023 at 5:37 PM Mike Taylor  wrote:

> Hi Steiner,
>
> I spent quite a lot of time trying to understand the issues around
> nesting syntax. It looks like the CSSWG resolved to adopt "Option 3",
> with representatives from all 3 engines voting in favor - and the WebKit
> blog survey also resulted in "Option 3" as the top choice.
>
> Do we know if the other engines have started work on implementation of
> Option 3?
>
> thanks,
> Mike
>
> On 1/20/23 4:42 AM, 'Steinar H. Gunderson' via blink-dev wrote:
> > Contact emails: se...@chromium.org, futh...@chromium.org
> > Explainer: None
> >
> > Specification: https://drafts.csswg.org/css-nesting
> >
> > Summary: Add the ability to nest CSS style rules inside other style
> rules,
> > combining selectors from the outer with the inner rule for increasing
> > modularity and maintainability of style sheets.
> >
> > Blink component: Blink>CSS
> >
> > TAG review: https://github.com/w3ctag/design-reviews/issues/791
> >
> > TAG review status: Pending
> >
> > Risks: There is a threat of a formal objection in CSSWG.
>

Can you expand on that?


> >
> > Interoperability and Compatibility:
> >
> > Gecko: Positive (
> https://github.com/mozilla/standards-positions/issues/695)
> > WebKit: Positive (
> https://github.com/WebKit/standards-positions/issues/69)
> >
> > Debuggability
> > Nesting style rules will be a big change for editing and displaying
> style rules in the inspector:
> >
> > - Showing displaying nested rules for matching declarations
> > - Editing selectors
> > - Inserting nested rules
> > - etc...
> >
> > Tracking issue for devtools support: https://crbug.com/1172985
> > Devtools says they're on track for shipping in M111.
> >
> > Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux,
> > Chrome OS, Android, and Android WebView)? Yes
> >
> > Is this feature fully tested by web-platform-tests? Yes
> >
> > Flag name: CSSNesting
> >
> > Requires code in //chrome? False
> >
> > Tracking bug: https://crbug.com/1095675
> >
> > Estimated milestones
> > DevTrial on desktop   109
> > DevTrial on Android   109
> > Shipping112
> >
> >
> > Anticipated spec changes: See above.
> >
> > Link to entry on the Chrome Platform Status:
> > https://chromestatus.com/feature/5800613594529792
> >
> > Links to previous Intent discussions:
> > Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/be91b584-f0ba-cd60-a142-f60c3aa72709%40chromium.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvZBk8XhzJoT%3Dx0EVNEZ3hvtk1EqKKFeGAMH1j_ehYsA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Nesting

[Mike Taylor]

Hi Steiner,

I spent quite a lot of time trying to understand the issues around 
nesting syntax. It looks like the CSSWG resolved to adopt "Option 3", 
with representatives from all 3 engines voting in favor - and the WebKit 
blog survey also resulted in "Option 3" as the top choice.


Do we know if the other engines have started work on implementation of 
Option 3?


thanks,
Mike

On 1/20/23 4:42 AM, 'Steinar H. Gunderson' via blink-dev wrote:

Contact emails: se...@chromium.org, futh...@chromium.org
Explainer: None

Specification: https://drafts.csswg.org/css-nesting

Summary: Add the ability to nest CSS style rules inside other style rules,
combining selectors from the outer with the inner rule for increasing
modularity and maintainability of style sheets.

Blink component: Blink>CSS

TAG review: https://github.com/w3ctag/design-reviews/issues/791

TAG review status: Pending

Risks: There is a threat of a formal objection in CSSWG.

Interoperability and Compatibility:

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/695)
WebKit: Positive (https://github.com/WebKit/standards-positions/issues/69)

Debuggability
Nesting style rules will be a big change for editing and displaying style rules 
in the inspector:

- Showing displaying nested rules for matching declarations
- Editing selectors
- Inserting nested rules
- etc...

Tracking issue for devtools support: https://crbug.com/1172985
Devtools says they're on track for shipping in M111.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? Yes

Is this feature fully tested by web-platform-tests? Yes

Flag name: CSSNesting

Requires code in //chrome? False

Tracking bug: https://crbug.com/1095675

Estimated milestones
DevTrial on desktop 109
DevTrial on Android 109
Shipping112


Anticipated spec changes: See above.

Link to entry on the Chrome Platform Status:
https://chromestatus.com/feature/5800613594529792

Links to previous Intent discussions:
Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com



--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/be91b584-f0ba-cd60-a142-f60c3aa72709%40chromium.org.

[blink-dev] Re: Intent to Ship: Add containerName and containerQuery, update conditionText

[Daniil Sakhapov]

Hi!

So, I haven't found any usage on the websites chromestatus gave me.
But looking at WebArchive results

I
can see that the usage is very small and the update won't change anything.

On Wed, Jan 18, 2023 at 6:04 PM Alex Russell 
wrote:

> Hey Daniil:
>
> Thanks for filing for this change while the feature is still low-use;
> it'll be much more challenging to make this switch later.
>
> Something that wasn't clear from the use counters you linked was the use
> of the IDL properties vs. the CSS names. Given that it seems like we have
> use-counters for the latter but not the former, it seems reasonable to
> consider CSS usage to be a hard cap on potential use of the JS interface.
>
> Would you be willing to manually inspect some content (say 10-20 sites)
> that use the CSS `container-name` and `container-query` attributes to look
> for script access? Presumably it's a fraction that population, but
> verifying would be helpful.
>
> Thanks
>
> On Tuesday, January 17, 2023 at 8:31:42 AM UTC-8 Daniil Sakhapov wrote:
>
>> Contact emailssakha...@chromium.org
>>
>> Specification
>> https://w3c.github.io/csswg-drafts/css-contain-3/#the-csscontainerrule-interface
>>
>> Summary
>>
>> Updates the CSSContainerRule interface to match the specs. Implements
>> containerName and containerQuery, updates conditionText for @container to
>> be up-to-date with specs.
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/592
>>
>> TAG review statusIssues addressed
>>
>> Risks
>>
>> Activation
>>
>> Previous conditionText attribute contained only container-query part, but
>> now it's both container-name and container-query. But it should not break a
>> lot of sites due to low current usage as per:
>> https://chromestatus.com/metrics/css/timeline/popularity/697
>> https://chromestatus.com/metrics/css/timeline/popularity/699 The real
>> breakage is hard to measure, as it's not possible to track the how result
>> of conditionText is used and the usage of container-name is low compared to
>> the container-type usage. Also, conditionText is readonly, so there are no
>> round-trip issues
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> https://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
>>
>> https://wpt.fyi/css/css-contain/container-queries/at-container-serialization.html
>> https://wpt.fyi/css/css-contain/container-queries/idlharness.html
>> https://wpt.fyi/css/cssom/CSSContainerRule.tentative.html
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1393577
>>
>> Estimated milestones
>> DevTrial on desktop 112
>> DevTrial on Android 112
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5159369837117440
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z929YatFWoab%3Dcua%2BMmwb_6omELjiSFQ9cBM5Luyn1Q5VdQ%40mail.gmail.com.