push-based · ozcoder · Nov 2, 2025
diff --git a/Readme.md b/Readme.md
@@ -25,9 +25,9 @@ Different Lab measures to understand the impact.
 
 ## Can I Use
 
-![caniuse-contain](https://user-images.githubusercontent.com/95690470/159102200-d3232902-b71f-413d-a473-36994e26f4e9.PNG)
+[![caniuse-contain](https://user-images.githubusercontent.com/95690470/159102200-d3232902-b71f-413d-a473-36994e26f4e9.PNG)](https://caniuse.com/?search=contain)
 
-![caniuse-content-visibility](https://user-images.githubusercontent.com/95690470/159102242-d328c5c5-d0ba-44ad-a969-02d58a938a5e.PNG)
+[![caniuse-content-visibility](https://user-images.githubusercontent.com/95690470/159102242-d328c5c5-d0ba-44ad-a969-02d58a938a5e.PNG)](https://caniuse.com/?search=content-visibility)
 
 ## Documentation
 
@@ -50,8 +50,8 @@ Different Lab measures to understand the impact.
 - [CSS Containment Module Level 3](https://www.w3.org/TR/css-contain-3/)
 - [The stacking context](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context)
 - [caniuse](https://caniuse.com/mdn-css_properties_contain) - `contain` browser support   
-- [css-tricks - almanac - contain](https://css-tricks.com/almanac/properties/c/contain/) - by far best demos and visuall eplaination
-- [smashingmagazine - browsers-containment-css-contain-property](https://www.smashingmagazine.com/2019/12/browsers-containment-css-contain-property/) - good demo o visual limitations
+- [css-tricks - almanac - contain](https://css-tricks.com/almanac/properties/c/contain/) - by far the best demos and visual explanation
+- [smashingmagazine - browsers-containment-css-contain-property](https://www.smashingmagazine.com/2019/12/browsers-containment-css-contain-property/) - good demo of visual limitations
 - [offscreen improvements](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Containment#paint_containment)
 
 **Content Visibility**
@@ -63,8 +63,10 @@ Different Lab measures to understand the impact.
 - 🔥 [Paul Irish - What forces layout / reflow?](https://gist.github.com/paulirish/5d52fb081b3570c81e3a)
 - [Paul Lewis & Surma - CSS trigger](https://csstriggers.com/)
 - [web page geometry](https://docs.google.com/document/d/1WZKlOSUK4XI0Le0fgCsyUTVw0dTwutZXGWwzlHXewiU)
-- chrome graphics feature set `chrome://gpu/`
-- chrome flags `chrome://flags/`
+- Chrome graphics feature set `chrome://gpu/`
+- Chrome flags `chrome://flags/`
+- Firefox graphics feature set `about:support` - mostly low level information
+- Firefox preferences `about:preferences`
 
 ---
 

diff --git a/index.html b/index.html
@@ -1,18 +1,20 @@
+<!DOCTYPE html>
 <html>
   <head>
     <meta charset="UTF-8" />
     <link rel="stylesheet" type="text/css" href="styles-consolidated.css" />
     <link rel="stylesheet" type="text/css" href="animation.css" />
+    <title>Performance testing</title>
   </head>
 
   <body>
-    <h1>Performance tests for `contain` style proterty</h1>
+    <h1>Performance tests for `contain` style property</h1>
     <ul>
-      <li>Open the devtools with [CTRL] + [SHIFT] + [i]</li>
+      <li>Open the DevTools with [CTRL] + [SHIFT] + [i]</li>
       <li>Open the "Performance" tab</li>
       <li>Select a style value over the radio buttons</li>
       <li>Start recording</li>
-      <li>Hover over the area with the gear ant wait for soe seconds</li>
+      <li>Hover over the area with the gear and wait for some seconds</li>
       <li>Stop recording</li>
     </p>
     <div id="panel"></div>

diff --git a/projects/angular-movies-audit/Readme.md b/projects/angular-movies-audit/Readme.md
@@ -15,32 +15,32 @@ URL
 **Desktop view:**
 ![img-ngm-overview](https://user-images.githubusercontent.com/10064416/159577772-30983977-65b9-40a8-bc1a-293922bb7876.png)
 
-To start I just opened up the application and started browsing. I randomli clicked links and refreshed the page in multiple different stages.
+To start I just opened up the application and started browsing. I randomly clicked links and refreshed the page in multiple different stages.
 
-What I am looking for is interactoins or load cases where one of the following is true:
+What I am looking for is interactions or load cases where one of the following is true:
 - paint heavy on/offscreen content
 - layout heavy parts of the page
 - lot of offscreen content
 - static content
 - a page layout with fixed dimensions in some sections (header, footer, sidebar)
-- animations/effects triggeres on UI interaction or loading spinner
+- animations/effects triggered on UI interaction or loading spinner
 
-I spotted some areas where i immediately could apply changes and test, but before I start I try to get a good understanding of the pages loading behaviour and see if there are any special things to consider.
+I spotted some areas where I immediately could apply changes and test, but before I start, I try to get a good understanding of the pages loading behaviour and see if there are any special things to consider.
 It also helps me to structure the page into their layouting areas.
 
 
 Let's start with the general bootstrapping and page rendering process.
 
 ![img-ngm-before](https://user-images.githubusercontent.com/10064416/159577824-84507a1f-3628-43a7-b287-321000d3cbf2.png)
 
-The bage it self is in a really good state. the total rendering and paint togeather is under 200ms which is really fast, but still we can improve.
-After the initial page render different HTTP requests bounce in and apply visual updates to the page. The sidemenu and the pages content is updating with remote content.
+The page it self is in a really good state. The total rendering and paint together is under 200ms, which is really fast, but still we can improve.
+After the initial page render, different HTTP requests bounce in and apply visual updates to the page. The sidemenu and the pages content is updating with remote content.
 
-Those updates trgger all the paint work after the initial rendering.
+Those updates trigger all the paint work after the initial rendering.
 
-A good first step would be to shield the different areas and their updates form other areas.
+A good first step would be to shield the different areas and their updates from other areas.
 
-Here I identified 3 different main sreas:
+Here I identified 3 different main areas:
 - header
 - sidebar
 - content
@@ -56,7 +56,7 @@ Lets start with the sidebar as it is the easier part.
 ![sidebar-areas](https://user-images.githubusercontent.com/10064416/159578010-439bbd16-fdcf-4b32-8056-1795188f57e1.png)
 
 
-A first step would be to apply `contain: strict` (`contain: layout paint size`) to the sidebar. I pick content as there are no visual overflows needed for userinteraction or so. At the end of this section I realized the whole sidebar is hidden on mobile but all the elements are rendered and layouted, so I added a `content-visibility: auto`  here too.
+A first step would be to apply `contain: strict` (`contain: layout paint size`) to the sidebar. I picked content as there are no visual overflows needed for user interaction. At the end of this section I realized the whole sidebar is hidden on mobile but all the elements are rendered and layed out, so I added a `content-visibility: auto`  here too.
 
 ```css 
 .side-drawer {
@@ -66,7 +66,7 @@ A first step would be to apply `contain: strict` (`contain: layout paint size`)
 ```
 
 Next I could also contain the scroll area and apply `content-visibility:auto` as it could improve potential offscreen menu elements.
-I use a `contain-intrinsic-size` as i konw the item size `20px` and it will never change.
+I use a `contain-intrinsic-size` as I know the item size `20px` and it will never change.
 
 ```css
 .navigation {
@@ -83,7 +83,7 @@ The biggest impact is on mobile for the sidebar, but also on desktop we have sma
 
 ![bootstrap-comparison](https://user-images.githubusercontent.com/10064416/159578036-78c5ec25-8bbd-40bc-b128-2d26db1efed0.png)
 
-The initial rendering of the sidebar if not nearly invisible and updates over all are slightly (but irrelevent) faster.
+The initial rendering of the sidebar if not nearly invisible and updates over all are slightly (but irrelevant) faster.
 ![bootstrap-comparison-mobile](https://user-images.githubusercontent.com/10064416/159578060-a223da95-794e-407c-986c-3b385123276c.png)
 
 ### Toolbar
@@ -92,22 +92,22 @@ The toolbar is the next small area we can focus on.
 
 ![toolbar-areas](https://user-images.githubusercontent.com/10064416/159584191-39a5b8bc-414a-4956-8df1-aad640464b42.png)
 
-The interesting part here is the searchbox that has a animation on `width` focus. The first thing i did to isolate the animation was to set `contain:layout` on the toolbar area (I did not use `contain:content` includes `paint` as we have important visible overflow, the account menu). 
+The interesting part here is the searchbox that has an animation on `width` focus. The first thing I did to isolate the animation was to set `contain:layout` on the toolbar area (I did not use `contain:content` includes `paint` as we have important visible overflow, the account menu). 
 
 ```css
 .ui-toolbar {
   contain: layout;
 }
 
-The form it self can get `contain:strict` to shield the focus style of the input.
+The form its self can get `contain:strict` to shield the focus style of the input.
 
 ```css
 .form {
   contain: strict;
 }
 ```
 
-As this showed only slight improvements I pushed the width animation into the composition layer with translatez and I applied will-chnage:width to optimize the animation furter. 
+As this showed only slight improvements I pushed the width animation into the composition layer with translateZ and I applied `will-change: width` to optimize the animation further. 
 
 
 ```css
@@ -136,15 +136,15 @@ The main list has 2 areas:
 - List
 
 The headline is a good candidate for the `content` value as it can change it's height if the text changes.
-Here we can use `contain:content`.
+Here we can use `contain: content`.
 
 ```css
 header {
   contain: content;
 }
 ```
 
-The list is a good cast for `content-visibility: auto` but also some containent is possible:
+The list is a good case for `content-visibility: auto` but also some containment is possible:
 
 ```css
 ui-grid {
@@ -177,11 +177,11 @@ The main list has 2 areas:
 - Headline
 - Movieinfos
 - Cast list
-- Reccomendaton list
+- Recommendation list
 
 The heading and the list already got improved in the list page.
 
-The cast list is also of fixed height. here we can apply `strict`. As it has a fixed height and is not visible in mobile we can add `content-visibility:auto;` and contain its intrinsic size.
+The cast list is also of fixed height. Here we can apply `strict`. As it has a fixed height and is not visible in mobile we can add `content-visibility:auto;` and contain its intrinsic size.
 
 ```css
 .movie-detail--cast-list {
@@ -191,9 +191,9 @@ The cast list is also of fixed height. here we can apply `strict`. As it has a f
 }
 ```
 
-We also can contain the layout of the reccommendatin section.
+We also can contain the layout of the recommendation section.
 
 
-## Comparisom
+## Comparison
 
 ![img-ngm-after](https://user-images.githubusercontent.com/10064416/159596750-604fb5e7-9e58-4f5b-97eb-360907f65397.png)
diff --git a/projects/bootstrap-v1/Readme.md b/projects/bootstrap-v1/Readme.md
@@ -25,15 +25,15 @@ The target node under test are the card elements.
 As the page can be set up in different way lets quickly clarify the setup.
 
 As we focus on rendering and paint, it makes a difference if we load the images lazy of not.
-The following diagram shows how the artefacts at the end of the flames chage, depending on `loading` attributes value. (`lazy` or nothing)
+The following diagram shows how the artefacts at the end of the flames change, depending on `loading` attributes value. (`lazy` or nothing)
 
 ![img-comparison-bootstrap-doading-lazy](https://user-images.githubusercontent.com/95690470/159002129-d9571db9-13f7-4403-afb6-dadf16514522.PNG)
 
 ```html
   <img loading="lazy" ... />
 ```
 
-We take the version with lazy loaded images as atrefacts at the end, caosed by the the offscreen images provide a nice case to test the improvements in offscreen areas. 
+We take the version with lazy loaded images as artefacts at the end, caused by the the offscreen images. This provides a nice case to test the improvements in offscreen areas. 
 
 ### Bootstrap process
 
@@ -53,7 +53,7 @@ On click we add a set of cards programmatically:
 After that we have styles recalculation, layout, hit test, paint and composite of the added nodes.
 We can see that recalculation and layout take the longest.
 
-After some time we have another badge of tasks caused by the images with `loading="lazy"` as the HTTP request is pushed to the end of the renderpipeline.
+After some time we have another batch of tasks caused by the images with `loading="lazy"` as the HTTP request is pushed to the end of the render pipeline.
 
 Now lets test `contain:content` and `content-visibility`
 
@@ -87,8 +87,8 @@ The measure showed the following outcome:
 _[1] contain-vs-none--alternating_  
 ![img-comparison-bootstrap-none-vs-contain-pattern](https://user-images.githubusercontent.com/95690470/159005929-effa8c33-e77b-47fe-8088-36cbcca1aa4d.PNG)
 
-As there where clear signs for a difference in the assuptions i took another measure with a 25 times higher load [2]. This showed clear differences.
-The miss assumptions with painting of on vs offscreen elements is clear as the initial load will also receive the offscreen benefits of `contain:content`.
+As there were clear signs for a difference in the assumptions, I took another measure with a 25 times higher load [2]. This showed clear differences.
+The miss-assumptions with painting of on vs offscreen elements is clear as the initial load will also receive the offscreen benefits of `contain:content`.
 
 _[2] unoptimized vs contain_  
 | Run | Styles           | Recalculate Styles | Layout | Update Layertree | Paint     | Composite |
@@ -100,7 +100,7 @@ _[2] unoptimized vs contain_
 
 ### `content-visibility:auto`
 
-If we apply **`content-visibility:auto`** to all **`.card`** elements and **initially render the cards** we should be able to improve the full render pipeling as we can literally ignore those nodes from the whole process.
+If we apply **`content-visibility:auto`** to all **`.card`** elements and **initially render the cards** we should be able to improve the full render pipeline as we can literally ignore those nodes from the whole process.
 
 ![img-comparison-bootstrap-content-visibility-diagram](https://user-images.githubusercontent.com/95690470/159006915-695bb687-7edc-45b0-ae2e-8d9261c72047.PNG)
 
@@ -119,7 +119,7 @@ Running a measure gives the following flames:
 The measure showed the following outcome:
 - ✔ drastic improvement in recalculate styles clearly visible (22 times faster)
 - ✔ drastic improvement in layouting clearly visible (120 times faster)
-- 🤷‍👍 drastic improvement in composit and small in paint is measurably faster [3]
+- 🤷‍👍 drastic improvement in composite, and small in paint is measurably faster [3]
 - ✔ drastic improvement in painting items offscreen clearly visible (22 times faster)
 
 _[3] contain:content vs content-visibility_  

diff --git a/projects/contain-impact-properties/Readme.md b/projects/contain-impact-properties/Readme.md
@@ -51,7 +51,7 @@ Improvement in:
 - ❌ painting
 - ❌ composite
 
-[*] no further improvement compated to measure [L,l,On]
+[*] no further improvement compared to measure [L,l,On]
 
 ### [P,p,Off]
 
@@ -91,15 +91,15 @@ Improvement in:
 - ✔  composite ** 
 
 [*] no improvement as different work type
-[**] as we dont paint offscreen nodes 
+[**] as we don't paint offscreen nodes
 
 ### [P,p,Ob]
 - ❌ layouting
 - ❌ hittest
 - ❌ painting
 - ❌ composite
 
-[*] no further improvement compated to measure [L,l,Off]
+[*] no further improvement compared to measure [L,l,Off]
 
 ## Size
 

diff --git a/projects/offscreen/Readme.md b/projects/offscreen/Readme.md
@@ -19,9 +19,9 @@ This measure tests the offscreen benefits of `contain:content` and `content-visi
 
 As the page can be set up in different way lets quickly clarify the setup.
 
-To test onscreen offscreen render performance we specify 2 screen states "default" and "offscreen". default displays all 1tems on screen, the other state display all items offscreen with a `margin-top: 9000px`. By adding items in those 2 states we can measure the offscreen node benefits more accurate.
+To test onscreen/offscreen render performance we specify 2 screen states "default" and "offscreen". Default displays all items on screen, the other state displays all items offscreen with a `margin-top: 9000px`. By adding items in those 2 states we can measure the offscreen node benefits more accurate.
 
-The second test besides adding and removing DOM nodes is trigger recalculation with a animation. In our case it is just a color fade from purple to black.
+The second test, besides adding and removing DOM nodes, triggers recalculation with an animation. In our case it is just a color fade from purple to black.
 
 ![contain-comparison--offscreen-cards-setup](https://user-images.githubusercontent.com/95690470/159068427-e5ea1364-407d-4bd7-a174-1a793af6d3a6.PNG)
 
@@ -35,7 +35,7 @@ The measure consists out of 2 types of settings:
 
 ![img-comparison-onscreen-none](https://user-images.githubusercontent.com/95690470/159072468-37d060fc-d632-4f7d-8548-cf960f93c228.PNG)
 
-This mesure is herre as a reference only.
+This measure is here as a reference only.
 
 ### `contain:content` - onscreen nodes only  
 
@@ -130,7 +130,7 @@ Expected impact at **animation** is:
 
 ![img-comparison-offscreen-none](https://user-images.githubusercontent.com/95690470/159096345-abfbe1f0-8ffa-43dc-8895-72ea883a857e.PNG)
 
-This mesure is herre as a reference only.
+This measure is here as a reference only.
 
 ### `contain:content` - onscreen nodes only  
 

diff --git a/usage-and-debugging/Readme.md b/usage-and-debugging/Readme.md
@@ -10,7 +10,7 @@
 
 ## Description
 
-This measure tests the different contain properties without load. It's should generate a reproducable validation of the theoretical knowledge.
+This measure tests the different contain properties without load. It's should generate a reproducible validation of the theoretical knowledge.
 
 The target node under test is the border box around the loading bar.
 The radio inputs apply the styles visible below the target and color the bar.
@@ -20,7 +20,7 @@ The radio inputs apply the styles visible below the target and color the bar.
 By default the layout root is the document.
 Any changes inside the target node will cause a relayout of the whole page.
 
-This can be check if we a recording of te the animation and click a tasks layout work.
+This can be checked if we have a recording of the animation and click on the tasks layout.
 ![img-contain-and-layout-root--document](https://user-images.githubusercontent.com/95690470/158653604-0754b098-dbcb-4adc-8c0e-8865859d0572.PNG)
 
 We can see the layout root is `#document`.
@@ -33,7 +33,7 @@ We can define the layoutroot by the following settings:
 }
 ```
 
-In some cases it is also possible to get the layoutroot with the following steeting:
+In some cases it is also possible to get the layoutroot with the following setting:
 
 ```css
 .contain-target {
@@ -53,7 +53,7 @@ This can be evaluated over again the performance tab:
 ### Visible overflow
 
 The visible overflow is defined by the `overflow` property and the default value is `visible`.
-We can restric this and use a scroll bar instead (or even hide the scrollbar `auto`). This limits the paint area of the node.
+We can restrict this and use a scroll bar instead (or even hide the scrollbar `auto`). This limits the paint area of the node.
 
 ![img-contain-and-overflow](https://user-images.githubusercontent.com/95690470/158661451-50a9d0de-ee77-444a-b166-23f1a860fe1a.PNG)