qns/guides: address user feedback (#489)

Author: tahachm

packages/behavioral-interview-guidebook/contents/overview/en-US.mdx

@@ -38,7 +38,7 @@ In addition to these, interviewers can also mark if there wasn't sufficient info
 
 Ratings have to be done with regard to the situation's complexity. A more difficult or complex situation handled well will typically receive a higher rating and leveling recommendation.
 
-At the end of the interview do they reconcile all the ratings and qualitative feedback to decide:
+At the end of the interview they reconcile all the ratings and qualitative feedback to decide:
 
 - Whether to pass or fail the candidate
 - If passed, what level the candidate should receive

packages/front-end-interview-guidebook/contents/overview/en-US.mdx

@@ -132,7 +132,7 @@ Here's a summary of the question types asked by the top US companies.
 - **JavaScript**: Implement a function/class in JavaScript that is related to the front end domain.
 - **UI**: Build a user interface using HTML/CSS/JavaScript. Some companies allow you to use a framework of your choice while some only allow Vanilla JS/certain frameworks.
 - **System design**: Design a system and discuss the architecture and its components.
-- **Behavioral**: Discuss specific your experience working with others and how you handled difficult scenarios.
+- **Behavioral**: Discuss your specific experience working with others and how you handled difficult scenarios.
 
 ## Study and practice
 

packages/front-end-interview-guidebook/contents/quiz/en-US.mdx

@@ -32,7 +32,7 @@ There usually wouldn't be interview rounds just asking you solely quiz questions
 - **System design round**: Like in the coding round, the interviewer can ask further questions on the things you say.
 - **Hiring manager round**: Hiring manager rounds are usually not meant to be technical but they could be going over your resume and asking you related quiz questions on technologies/projects mentioned in your resume.
 
-As you can see, you can be expect to be asked quiz questions in almost every possible round. Be prepared at all times.
+As you can see, you can expect to be asked quiz questions in almost every possible round. Be prepared at all times.
 
 ## Important concepts
 

packages/front-end-interview-guidebook/contents/user-interface-components-api-design-principles/en-US.mdx

@@ -142,7 +142,7 @@ function Slider({ label, value, className, classNameLabel, classNameTrack }) {
         {label}
       </label>
       <input
-        className={clsx('gfe-slider-range', classNameRange)}
+        className={clsx('gfe-slider-range', classNameTrack)}
         id={id}
         type="range"
         value={value}

packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx

@@ -34,7 +34,7 @@ Most UI questions in interviews will require state and designing the state well
 
 - **Determine the minimum state needed in your UI**: The smaller the state, the easier it is to read and understand the code -> lower likelihood for bugs. Identify essential state vs derived state. Derived state is state that can be calculated from essential state. By deriving the state on-the-fly you reduce the possibility of state values going out-of-sync.
 - **Separate rendering code vs data management code**: Make the UI a function of your data and separate your code into two parts (rendering code vs data management code) for better readability. If you use JavaScript frameworks such as React, you will more or less be forced to do so.
-- **Use the state-reducer pattern for complex state interactions**: If the question requires many state fields and certain actions require changing multiple fields at once, use a [reducer to consolidate state update logic](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer). First popularized by Redux, the state-reducer pattern encourages you to determine the state of your UI, actions that can be taken, and how to combine actions with state to derive the next state. If you are using React, you can achieve this pattern via the [`useReducer` React hook](https://reactjs.org/docs/hooks-reference.html#usereducer). Redux is usually overkill for interviews and `useReducer` should be sufficient.
+- **Use the state-reducer pattern for complex state interactions**: If the question requires many state fields and certain actions require changing multiple fields at once, use a [reducer to consolidate state update logic](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer). First popularized by Redux, the state-reducer pattern encourages you to determine the state of your UI, actions that can be taken, and how to combine actions with state to derive the next state. If you are using React, you can achieve this pattern via the [`useReducer` React hook](https://react.dev/reference/react/useReducer). Redux is usually overkill for interviews and `useReducer` should be sufficient.
 
 [React's](https://beta.reactjs.org) docs on ["Managing State"](https://beta.reactjs.org/learn/managing-state) is an excellent resource on how to design and use component state correctly. Some of the ideas mentioned aren't specific to React and can be applied to any UI frameworks.
 
@@ -80,7 +80,7 @@ Does your UI provide a great user experience?
   - Make interactive elements like buttons large enough to be pressed (recommend at least 44 x 44 px) and spaced widely enough.
 - **Error states**: Reflect errors promptly and clearly — form validation errors, network request errors.
 - **Handle rendering images of different dimensions**: Make your UI work for rendering images of all sizes/dimensions yet preserving the original aspect ratios.
-  - Use CSS `background-image` together with `background-position: contain` so that the image fits within your defined area. If it is ok for the image to be cropped off (e.g. for gradient backgrounds), use `background-position: cover`.
+  - Use CSS `background-image` together with `background-size: contain` so that the image fits within your defined area. If it is ok for the image to be cropped off (e.g. for gradient backgrounds), use `background-size: cover`.
   - `<img>` tags have a similar `object-fit` property with `contain` and `cover` values.
 - **Optimistic updates**: Advanced technique where the success state is reflected even though the network request is still pending. If the request fails, revert the UI changes and show an error message.
 
@@ -136,7 +136,7 @@ There's probably not enough time to handle all edge cases scenarios in your code
 - **Too many items in a list**: Showing too many items on a single page can lead to poor UX (user has to scroll a lot) and poor performance in terms of responsiveness and memory consumption.
   - **Pagination**: Break up a long list of items into multiple pages.
   - [**Virtual lists**](https://www.patterns.dev/posts/virtual-lists): Rendering only visible rows of content in a dynamic list instead of the entire list.
-  - Truncate the excess content and show an ellipsis. The `word-break` CSS property will come in handy useful.
+  - Truncate the excess content and show an ellipsis. The `word-break` CSS property will come in handy.
   - Limit the content to the first X characters/words and hide the excess content behind a "Show More" button.
 
 ## Performance
@@ -151,7 +151,7 @@ There's probably not enough time to handle all edge cases scenarios in your code
 
 - **Cross-site Scripting (XSS)**: Avoid assigning to [`Element.innerHTML`](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML) or React's `dangerouslySetInnerHTML` when rendering contents into the DOM if it comes from users to prevent cross-site scripting, assign to [`Node.textContent`](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent) or use the experimental[`Element.setHTML()`](https://webdocs.dev/en-us/docs/web/api/element/sethtml) method instead. Refer to [OWASP's XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
 - **Output encoding for "URL Contexts"**: If user-supplied input can be used in URL query parameters, use `encodeURIComponent` to prevent unintended values from becoming part of the URL (e.g. extra query parameters).
-- **Cross Site Request Forgery**: Refer to [OWASP's XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html).
+- **Cross Site Request Forgery**: Refer to [OWASP's CSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html).
 
 ## Internationalization (i18n)
 

packages/quiz/questions/what-is-css-selector-specificity-and-how-does-it-work/en-US.mdx

@@ -2,15 +2,27 @@
 title: What is CSS selector specificity and how does it work?
 ---
 
-The browser determines what styles to show on an element depending on the specificity of CSS rules. We assume that the browser has already determined the rules that match a particular element. Among the matching rules, the specificity, four comma-separate values, `a, b, c, d` are calculated for each rule based on the following:
+When multiple CSS rules could apply to the same HTML element, the browser needs a way to decide which rule takes precedence. This is determined by the **CSS cascade**, which considers importance, inline styles, selector specificity, and source order. **Selector specificity** is a key part of this process, calculating a weight for each selector.
 
-1. `a` is whether inline styles are being used. If the property declaration is an inline style on the element, `a` is 1, else 0.
-1. `b` is the number of ID selectors.
-1. `c` is the number of classes, attributes and pseudo-classes selectors.
-1. `d` is the number of tags and pseudo-elements selectors.
+The browser determines what styles to show on an element depending on the **specificity** of the CSS rules that match it. Specificity is calculated for each rule to decide which one takes precedence.
 
-The resulting specificity is not a single numerical score, but an array of values that can be compared column by column. When comparing selectors to determine which has the highest specificity, look from left to right, and compare the highest value in each column. So a value in column `b` will override values in columns `c` and `d`, no matter what they might be. As such, specificity of `0, 1, 0, 0` would be greater than one of `0, 0, 10, 10`.
+## How is specificity computed?
 
-In the cases of equal specificity: the latest rule is the one that counts. If you have written the same rule into your stylesheet (regardless of internal or external) twice, then the lower rule in your stylesheet is closer to the element to be styled, it is deemed to be more specific and therefore will be applied.
+The specificity algorithm is basically a three-column value of three categories or weights - ID, CLASS, and TYPE - corresponding to the three types of selectors. The value represents the count of selector components in each weight category and is written as `ID - CLASS - TYPE`. The three columns are created by counting the number of selector components for each selector weight category in the selectors that match the element.
 
-It's a better practice to write CSS rules with low specificity so that they can be easily overridden if necessary. When writing CSS UI component library code, it is important that they have low specificities so that users of the library can override them without using too complicated CSS rules just for the sake of increasing specificity or resorting to `!important`.
+1.  **ID**: This is the count of ID selectors (e.g., `#example`).
+2.  **CLASS**: This is the count of class selectors (e.g., `.my-class`), attribute selectors (e.g., `[type="radio"]`), and pseudo-classes (e.g., `:hover`).
+3.  **TYPE**: This is the count of type selectors (element names, e.g., `h1`, `div`) and pseudo-elements (e.g., `::before`).
+
+When comparing selectors to determine which has the highest specificity, look from left to right (ID, then CLASS, then TYPE), and compare the highest value in each column. A value in the ID column will override values in the CLASS and TYPE columns, no matter how large they are. Similarly, a value in the CLASS column overrides any value in the TYPE column. For example, a specificity of `1,0,0` (one ID) is greater than `0,10,10` (ten classes and ten types).
+
+It's important to remember that specificity is part of the broader **CSS cascade**. Declarations marked `!important` have the highest precedence, followed by inline styles (using the `style` attribute). Selector specificity comes next.
+
+In cases of **equal specificity** among competing rules (that aren't inline or `!important`), the rule that appears **last** in the CSS source order is the one that counts and will be applied.
+
+It's a better practice to write CSS rules with low specificity so that they can be easily overridden if necessary. When writing CSS for UI component libraries, it is important that styles have low specificities so that users of the library can customize them without needing overly complex selectors or resorting to `!important`.
+
+## References
+
+- [Specificity | MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_cascade/Specificity)
+- [Specificity | web.dev](https://web.dev/learn/css/specificity)

packages/react-interview-playbook/contents/react-thinking-declaratively/en-US.mdx

@@ -164,7 +164,7 @@ Actions are triggered in response to two kinds of events:
 
 For the todo list at hand, we only need to care about user events.
 
-However, it is advisable to write a function for each of these actions, and call the state setters within each action function. This is because the same operation can be triggered from many places on the UI, or even in the background. An example is a video player where there to pause the video, users can either press the "Pause" button or press the spacebar.
+However, it is advisable to write a function for each of these actions, and call the state setters within each action function. This is because the same operation can be triggered from many places on the UI, or even in the background. An example is a video player, where, to pause the video, users can either press the "Pause" button or press the spacebar.
 
 Centralizing state update logic within these action functions will help to keep the code maintainable.
 

packages/system-design/contents/introduction/en-US.mdx

@@ -42,7 +42,7 @@ As you can see, the focus of front end system design interviews can be very diff
 
 ## What you will learn in this guide
 
-Our Front End System Design guide is structured into two parts, you will first gain a deeper understanding system design interviews are about, then dive into some front end system design case studies that use the RADIO framework.
+Our Front End System Design guide is structured into two parts, you will first gain a deeper understanding of what system design interviews are about, then dive into some front end system design case studies that use the RADIO framework.
 
 - [Types of questions](/system-design/types-of-questions): Types of Front End System Design interview questions and examples
 - [RADIO framework](/system-design/framework): A framework for answering Front End System Design interview questions

packages/system-design/contents/types-of-questions/en-US.mdx

@@ -12,7 +12,7 @@ There are two main kinds of front end system design questions: (1) Applications
 
 As mentioned above, designing applications for front end system design interviews will feel similar to general Software Engineering system design interviews, and in fact, the questions are highly similar. However, instead of talking about distributed systems, you should focus on the client side of things and talk about application architecture and client-side implementation details.
 
-In this day and age, many websites are interactive and rich applications that can do virtually what many desktop applications can. If you've used Gmail, Facebook, YouTube, ChatGPT, or Google Calender on the web, you'd have used a web app. Web apps tend to be interactive and dynamic (contents on the page change frequently) and page navigations in a web app usually don't require a full page refresh; the app uses JavaScript to fetch remote data for the next page and dynamically change the contents and URL.
+In this day and age, many websites are interactive and rich applications that can do virtually what many desktop applications can. If you've used Gmail, Facebook, YouTube, ChatGPT, or Google Calender on the web, you have used a web app. Web apps tend to be interactive and dynamic (contents on the page change frequently) and page navigations in a web app usually don't require a full page refresh; the app uses JavaScript to fetch remote data for the next page and dynamically change the contents and URL.
 
 Since web apps are complex software involving multiple modules, common application architectures learnt in Software Engineering classes like Model-View-Controller (MVC), Model-View-ViewModel (MVVM) are also applicable when building web apps. React is one of the most popular JavaScript libraries by Facebook to build interactive web applications and many React web apps adopt a unidirectional Flux/Redux-based architecture.