Fix: typos & remove "BART" about :root vs @Property

Author: podfeet

docs/_pbs/pbs182.md

@@ -5,13 +5,13 @@ creators: [bart, allison]
 date: 2026-04-11
 ---
 
-*Cascading Style Sheets*, or CSS, was among the very first technologies covered in Programming By Stealth. We started our CSS explorations way back in [instalment 6](./pbs6), and by [instalment 10](./pbs10) we'd pretty much finished with the topic. The only other time we covered CSS in any depth was instalment [PBS 28](./pbs28), though we used it regularly throughout the series. We Learned the fundamentals of how CSS's works, and more importantly, why it's important to use CSS to separate the look of web apps and web sites from their semantic structure, which we'd previously learned is expressed in HTML.
+*Cascading Style Sheets*, or CSS, was among the very first technologies covered in Programming By Stealth. We started our CSS explorations way back in [instalment 6](./pbs6), and by [instalment 10](./pbs10) we'd pretty much finished with the topic. The only other time we covered CSS in any depth was instalment [PBS 28](./pbs28), though we used it regularly throughout the series. We learned the fundamentals of how CSS's works, and more importantly, why it's important to use CSS to separate the look of web apps and websites from their semantic structure, which we'd previously learned is expressed in HTML.
 
 Because our exploration of CSS never went beyond the basics, we never covered the more advanced features like so-called *CSS Variables*. Until [Bootstrap 5.3](https://getbootstrap.com/docs/5.3/getting-started/introduction/) made it impossible to achieve certain customisations without CSS variables, I'd never encountered a need to learn about CSS *'variables'*. So, I didn't make time to learn about them myself, let alone include them in this series. But now that we're about to discuss customising Bootstrap, we have a good motivation for adding them to our proverbial programming toolboxes.
 
-While Bootstrap customisation is our reason for exploring the topic, nothing we cover in this instalment is in any way specific to Bootstrap. The features covered here are completely generic, and can be used on any of your web apps or web pages, whether or not they're styled with the help of Bootstrap.
+While Bootstrap customisation is our reason for exploring the topic, nothing we cover in this instalment is in any way specific to Bootstrap. The features covered here are completely generic and can be used on any of your web apps or web pages, whether or not they're styled with the help of Bootstrap.
 
-> **Note on the use of *'colour'* & `color` in this instalment** — as an Irish resident and proud European I make a point of writing these notes in my own voice, using my local spellings and language patterns. Specifically, that these notes are written in [Hiberno-English](https://en.wikipedia.org/wiki/Hiberno-English), or in HTML jargon, `lang="en-IE"`. This is why the descriptive parts of this blog post spell *'colour'* the European way, with a *'u'*. Computer programming languages on the other hand almost universally written in American English (or `en-US`), and that very much includes CSS. Every colour-related identifier in the CSS specification uses the American spelling, without the `u`, for example `background-color`. To avoid confusion, I choose to adopt the same American spelling for all my own identifiers when writing CSS. This is why all code snippets in these notes use `color`.
+> **Note on the use of *'colour'* & `color` in this instalment** — as an Irish resident and proud European, I make a point of writing these notes in my own voice, using my local spellings and language patterns. Specifically, that these notes are written in [Hiberno-English](https://en.wikipedia.org/wiki/Hiberno-English), or in HTML jargon, `lang="en-IE"`. This is why the descriptive parts of this blog post spell *'colour'* the European way, with a *'u'*. Computer programming languages, on the other hand almost universally written in American English (or `en-US`), and that very much includes CSS. Every colour-related identifier in the CSS specification uses the American spelling, without the `u`, for example, `background-color`. To avoid confusion, I choose to adopt the same American spelling for all my own identifiers when writing CSS. This is why all code snippets in these notes use `color`.
 {: .aside}
 
 ## Matching Podcast Episode
@@ -64,7 +64,7 @@ The reason properties are defined as having a *default* inheritance behaviour ra
 
 ## The Problem to be Solved
 
-The feature colloquially referred as *CSS variables* was added to CSS to solve a common problem that we have been side-stepping by using Bootstrap's default styles for all our web apps — consistency without code repetition!
+The feature colloquially referred to as *CSS variables* was added to CSS to solve a common problem that we have been side-stepping by using Bootstrap's default styles for all our web apps — consistency without code repetition!
 
 We've achieved consistency by simply applying the Bootstrap CSS classes to our various elements, and trusting that Bootstrap's style sheet will keep all our spacing, typography, and colours consistent, which of course it does.But had we been developing our own custom styles from scratch, we'd be all to familiar with this problem!
 
@@ -74,15 +74,15 @@ Clearly, we need to be able to define some form of **reusable named values** in
 
 ## How CSS Implements 'Variables' — CSS Custom Properties
 
-CSS is not a programming language in the traditional sense — you don't execute CSS code to achieve tasks! Instead, it's a kind of markup language for defining how HTML content should look. Given this context, it shouldn't be surprising that CSS's approach to *variables* is nothing like what we've seen in traditional programming languages like Javascript and Bash.
+CSS is not a programming language in the traditional sense — you don't execute CSS code to achieve tasks! Instead, it's a kind of markup language for defining how HTML content should look. Given this context, it shouldn't be surprising that CSS's approach to *variables* is nothing like what we've seen in traditional programming languages like JavaScript and Bash.
 
 The way CSS implements the concept of custom named values is by extending its existing concept of style properties. Simply put, we can **invent our own CSS style properties**! The properties we invent behave just like the regular CSS style properties we use all the time like `color`, `font-family`, `border-width`, etc.
 
 However, because we're inventing these properties ourselves, they have no direct visual effect. For them to become somehow visible, we need to reference them from within style declarations for the traditional CSS style properties. In effect, we say *set the background colour to be the same as the local value for this invented property*.
 
 Local value? Like every other CSS style property, every HTML element gets its own internal instances of our invented properties, and, just like with traditional style properties like `font-family`, the values for our invented properties can cascade through our document.
 
-In other words, **CSS *variables* behave like CSS properties**, not like Javascript variables, because they actually **are** CSS style properties!
+In other words, **CSS *variables* behave like CSS properties**, not like JavaScript variables, because they actually **are** CSS style properties!
 
 Finally, **custom CSS properties cascade by default**.
 
@@ -102,13 +102,13 @@ The rules are simply:
 
 In effect that means **case-sensitive dash-delimited names** of the form `--my-variable-name`.
 
-By convention, custom properties are named following the same approach as the standard CSS style properties — full words in all lower case, separated with dashes. You could use upper-case letters if you wished, but your properties would look very unusual and other developers would probably get cranky with you!
+By convention, custom properties are named following the same approach as the standard CSS style properties — full words in all lower case, separated with dashes. You could use upper-case letters if you wished, but your properties would look very unusual, and other developers would probably get cranky with you!
 
 ### Assigning and Using Custom CSS Property Values
 
 Other than their funny names, you assign values to custom properties just like you would for the traditional CSS properties — that is to say, using style declarations.
 
-To set the `color` property to `DarkBlue` for all top-level headings we would use:
+To set the `color` property to `DarkBlue` for all top-level headings, we would use:
 
 ```css
 h1 {
@@ -153,7 +153,7 @@ What does that mean?
 Imagine we have the following HTML code:
 
 ```html
-<p>This is the partent tag, <em>and this is a child tag</em>.</p>
+<p>This is the parent tag, <em>and this is a child tag</em>.</p>
 ```
 
 Then imagine we have the following style sheet:
@@ -366,15 +366,13 @@ The `calc()` function expects to be passed a list of **space-delimited arguments
 
 As an example, let's look at a simple implementation of the concept of using ratios of a base spacing size for all paddings and spacings:
 
-**BART I will probably interrupt you the instant you start this because you use root and not @property. You explained them both, but you didn't tell us why you use one sometimes and another the other time. **
-
 ```css
 /* set a base spacing value */
 :root {
   --space: 1rem; /* the width of one em-dash at the document root's font size (root-em)*/
 }
 
-/* calculate margins and paddings for the the document */
+/* calculate margins and paddings for the document */
 body{
   margin: 0px;
   padding: 0px var(--space) 0px var(--space); /* top left bottom right*/
@@ -579,7 +577,7 @@ blockquote {
 }
 ```
 
-As explained previously, simply updating the value of the custom property has no visible effect, we need to use that value in a style declaration that has a high enough specificity to *'win'* over the less specific declaration that has already set the font family to the default value of the `--body-font` custom property at the `<body>` level.
+As explained previously, simply updating the value of the custom property has no visible effect. We need to use that value in a style declaration that has a high enough specificity to *'win'* over the less specific declaration that has already set the font family to the default value of the `--body-font` custom property at the `<body>` level.
 
 These two things can be done within a single css statement, if, and only if, the custom
 property is updated **before** it's new value is used:
@@ -819,7 +817,7 @@ You'll find the JavaScript powering the widget at the bottom of the file. It imp
 2. Tune the readability of the UI by adjusting the borders, spacings, and font sizes, being sure to use custom CSS properties to make the various relevant values adjustable.
 3. Enhance the usability of the UI by:
    1. Choosing an appropriate font, background colour, and text colour for the display textbox to make it look like what it is — capture each of those three things in custom properties.
-   2. Choosing colours for both the button text and background. It's important that your UI makes a visual distinction between the three types of button (number, operator & action). How you choose to do that is up to you, but you should make the specifics of your choice customisable with custom properties.
+   2. Choosing colours for both the button text and background. It's important that your UI makes a visual distinction between the three types of buttons (number, operator & action). How you choose to do that is up to you, but you should make the specifics of your choice customisable with custom properties.
 
 ## Final Thoughts