GFE getElementsByStyle Problem #208
Conversation
|
@codex review |
1 similar comment
|
@codex review |
|
Claude finished @pertrai1's task in 1m 35s —— View job Code Review: getElementsByStyle ✅Great work implementing this DOM manipulation problem! The solution is correct and demonstrates solid understanding of DOM traversal and the Computed Style API. Here's my detailed review: 1. Correctness ✅Verdict: The solution correctly implements the requirements.
Mental trace with example: // Given DOM: <div><span style="font-size: 12px">Span</span><p style="font-size: 12px">Paragraph</p></div>
getElementsByStyle(doc.body, 'font-size', '12px')
// 1. Iterates through body.children (the div)
// 2. Recursively checks div's children (span, p)
// 3. getComputedStyle returns "12px" for both
// 4. Both match and are added to results
// Returns: [span, p] ✅2. Browser API Usage 🌐getComputedStyle() - Correct Choice
DOM Traversal Pattern
3. Time & Space ComplexityTime Complexity: O(n)
Space Complexity: O(h + m)
4. Code QualityStrengths:
Minor Improvement:
5. Learning Summary 📚Key ConceptsPattern: Depth-First Search (DFS) Tree Traversal
Browser API Insight: Computed Styles vs. Inline Styles
Why This Approach Works:
Alternative ApproachesApproach 1: Iterative DFS with Stack function getElementsByStyle(element: Element, property: string, value: string): Element[] {
const elements: Element[] = [];
const stack = [...element.children];
while (stack.length > 0) {
const el = stack.pop()!;
if (getComputedStyle(el).getPropertyValue(property) === value) {
elements.push(el);
}
stack.push(...Array.from(el.children).reverse());
}
return elements;
}Trade-offs:
Approach 2: BFS with Queue function getElementsByStyle(element: Element, property: string, value: string): Element[] {
const elements: Element[] = [];
const queue = [...element.children];
while (queue.length > 0) {
const el = queue.shift()!;
if (getComputedStyle(el).getPropertyValue(property) === value) {
elements.push(el);
}
queue.push(...el.children);
}
return elements;
}Trade-offs:
Related Problems for Practice
Key Takeaways
Final ThoughtsThis is a solid, production-ready solution for a coding interview. The recursive DFS approach is clean and correct. The minor improvements suggested (removing unnecessary null check, being aware of performance) are nice-to-haves, not critical issues. Rating: ⭐⭐⭐⭐⭐ (5/5)
Keep up the great work! 🚀 |
|
To use Codex here, create a Codex account and connect to github. |
1 similar comment
|
To use Codex here, create a Codex account and connect to github. |
🧮 Solution AnalysisPR: GFE getElementsByStyle Problem 📊 Code Quality ResultsESLint Analysis
Issues by file:
🔍 Complexity AnalysisgetElementsByStyle📋 Analysis Results: 🔍 Automated Complexity Analysis
File: greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/getElementsByStyle.ts Time ComplexityEstimated: O(1)
Space ComplexityEstimated: O(1) Data Structures Used
Code Metrics
Recommendations
💡 Analysis Tips
📁 Analysis Files CreatedDetailed analysis files have been automatically generated and committed to 🎯 Next Steps
Analysis generated for PR files only |
✅ Test ResultsTests have been executed for this pull request. 📊 Coverage Summary
Check the workflow logs for detailed test output. |
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdded a new DOM utility Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🤖 Gemini Code Review (Model: ## Code Review: `getElementsByStyle`
This review focuses on the `getElementsByStyle` function, which is a GreatFrontEnd problem solution.
### 1. Pattern Identification
This solution primarily uses the **Tree Traversal** pattern, specifically a **Depth-First Search (DFS)**. The DOM (Document Object Model) is inherently a tree structure, and the problem requires visiting all descendant nodes to check a condition. DFS is a natural fit for exploring all paths deeply before backtracking.
### 2. Complexity Verification
* **Time Complexity**: **O(N)**, where `N` is the total number of descendant elements in the DOM subtree rooted at `element`.
* The `traverseDOM` function visits each descendant element exactly once.
* For each element, `getComputedStyle(el)` and `getPropertyValue(property)` are called. In most practical scenarios and for DSA problem analysis, these DOM API calls are considered to take effectively constant time (amortized O(1)) for a single property lookup, especially after the browser has computed styles.
* Therefore, the total time complexity is proportional to the number of elements visited.
* **Space Complexity**: **O(N + D)**, where `N` is the number of matching elements stored in the `elements` array, and `D` is the maximum depth of the DOM tree (due to the recursion call stack).
* The `elements` array stores all matching `Element` references. In the worst case, all `N` descendant elements might match, leading to `O(N)` space.
* The recursive `traverseDOM` calls consume space on the call stack. The maximum depth of the recursion corresponds to the deepest path in the DOM tree, leading to `O(D)` stack space.
### 3. Key Insight
The key insight for this problem is twofold:
1. **DOM as a Tree**: Recognizing that the DOM is a tree structure and that finding elements satisfying a condition requires a systematic **tree traversal** (like DFS or BFS).
2. **`getComputedStyle` for Rendered Styles**: The problem specifies finding elements "rendered by the browser using the specified style." This immediately points to using the `window.getComputedStyle()` API. Unlike `element.style` (which only reflects inline styles), `getComputedStyle` provides the final, computed values of all CSS properties for an element as they are actually rendered by the browser, taking into account stylesheets, inheritance, and browser defaults.
### 4. Edge Case Analysis
The solution handles several edge cases correctly:
* **Empty `element` (no children)**: If the initial `element` has no children, the `for (const child of element.children)` loop will not execute, and an empty array `[]` will be returned, which is correct.
* **`element` with no matching descendants**: The `elements` array will remain empty throughout the traversal, correctly returning `[]`.
* **Deeply nested matching descendants**: The DFS approach correctly explores the entire subtree and finds elements at any depth.
* **`property` or `value` not found**: If `getComputedStyle.getPropertyValue(property)` returns a different value (e.g., an empty string for an invalid property, or a default value), the comparison `=== value` will correctly fail.
* **Excluding the root `element`**: The problem statement "only descendants of the element argument are searched, not the element itself" is correctly handled by starting the traversal from `element.children` rather than `element` itself.
* **Case sensitivity**: The solution correctly uses kebab-case for property names (e.g., `'font-size'`) which is standard for `getPropertyValue`. Values are matched exactly, which is usually the expectation.
### 5. Learning Points
* **Similar Problems**:
* Any problem involving traversing a tree-like data structure (e.g., finding the maximum depth of a binary tree, counting nodes, searching for a specific node).
* Implementing custom versions of `document.getElementsByTagName`, `getElementsByClassName`, or `querySelector` without relying on the built-in browser APIs.
* Graph traversal problems where the graph can be represented as an adjacency list/matrix (DFS/BFS are fundamental).
* **Common Mistakes with this Pattern**:
* **Incorrectly handling the root**: Forgetting to exclude or include the root node based on problem requirements.
* **Performance with DOM APIs**: Misunderstanding the cost of DOM operations, especially `getComputedStyle`. While often treated as O(1) for DSA, in real-world performance-critical applications, it can trigger layout recalculations, which are expensive.
* **Confusing `element.style` with `getComputedStyle`**: `element.style` only reflects inline `style` attributes, not styles from stylesheets or inherited styles. `getComputedStyle` is essential for rendered styles.
* **Stack Overflow**: For extremely deep trees, recursive DFS can lead to a stack overflow. Using an iterative DFS with an explicit stack is a common way to mitigate this.
* **Variations of this Problem**:
* Implement `getElementsByStyle` using a **Breadth-First Search (BFS)**, which would return elements level by level.
* Find the *first* element that matches the style, instead of all of them.
* Support multiple style properties/values (e.g., `getElementsByStyle(el, { 'font-size': '12px', 'color': 'red' })`).
* Implement `getElementsByStyle` with a custom filtering function instead of a direct property/value match.
### 6. Code Quality
The code is generally clean and readable.
* **Redundant `null` check**: Inside `traverseDOM`, the check `if (el === null)` is unnecessary. `el` will always be an `Element` because it's passed from `el.children`, which only contains `Element` instances. You can safely remove this line.
* **Variable Naming**: `element`, `property`, `value`, `elements`, `el`, `computedStyle`, `child` are all descriptive and appropriate.
* **Code Structure**: The use of a nested helper function `traverseDOM` is a good pattern for recursive traversals, keeping the main function clean and managing the `elements` array in the outer scope.
**Proposed Improvement:**
```typescript
export function getElementsByStyle(
element: Element,
property: string,
value: string
): Element[] {
const elements: Element[] = [];
// Helper function for recursive DFS traversal
function traverseDOM(el: Element) {
// No need for null check here, as `el` will always be an Element from `el.children`.
const computedStyle = getComputedStyle(el);
// Check if the computed style property matches the target value
if (computedStyle.getPropertyValue(property) === value) {
elements.push(el);
}
// Recursively traverse children
for (const child of el.children) {
traverseDOM(child);
}
}
// Start traversal from the children of the given element,
// as per the problem statement "only descendants...not the element itself."
for (const child of element.children) {
traverseDOM(child);
}
return elements;
}7. Alternative Approaches
The current recursive DFS approach is a perfectly valid and common way to solve this problem, demonstrating a fundamental tree traversal algorithm. |
|
🤖 Gemini Code Review (Model: Here's a detailed review of your 1. Pattern IdentificationThis solution primarily uses a Depth-First Search (DFS) traversal pattern. It recursively explores the DOM tree by visiting a node, then recursively visiting all its children before backtracking. This is a common pattern for traversing tree-like data structures such as the DOM. 2. Complexity Verification
3. Key InsightThe key insight for this problem is the understanding that to find elements rendered by the browser with a specific style, you must use 4. Edge Case AnalysisThe current solution handles several implicit edge cases correctly, but here are some explicit ones to consider:
5. Learning Points
6. Code Quality
// Current:
function traverseDOM(el: Element) {
if (el === null) { // This check is unnecessary because 'el' is typed as Element
return;
}
// ... rest of the code
}
// Improved:
function traverseDOM(el: Element) {
const computedStyle = getComputedStyle(el);
// ... rest of the code
}7. Alternative Approaches
Overall, your solution is correct, clean, and effectively solves the problem using a standard DFS traversal. The feedback primarily aims to deepen your understanding of complexity, edge cases, and alternative patterns in a frontend context. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| const elements: Element[] = []; | ||
|
|
||
| function traverseDOM(el: Element) { | ||
| if (el === null) { |
There was a problem hiding this comment.
Unnecessary null check: The el === null check is redundant here. The function is always called with valid Element objects from element.children, which cannot be null. TypeScript's type system already guarantees el: Element will never be null.
| if (el === null) { | |
| function traverseDOM(el: Element) { |
This simplifies the code without affecting correctness.
| return; | ||
| } | ||
|
|
||
| const computedStyle = getComputedStyle(el); |
There was a problem hiding this comment.
Performance consideration: getComputedStyle() is called for every element in the tree, even if the property doesn't match. While this is correct, be aware that getComputedStyle() triggers browser reflow and is relatively expensive.
For large DOM trees, consider:
- Caching computed styles if querying multiple properties
- Using
element.style.getPropertyValue()first for inline styles (though this changes behavior)
For this problem's requirements (matching computed styles), the current approach is correct but worth noting the performance implications in real-world scenarios.
|
|
||
| const computedStyle = getComputedStyle(el); | ||
|
|
||
| if (computedStyle.getPropertyValue(property) === value) { |
There was a problem hiding this comment.
Normalization consideration: Different browsers may return property values in different formats (e.g., "12px" vs "12.0px", or color values as "rgb(255, 0, 0)" vs "#ff0000"). The current strict equality check assumes the value parameter matches the browser's exact format.
For production code, you might want to normalize values, especially for:
- Colors (rgb/hex/hsl conversions)
- Dimensions (handling of units)
- Whitespace differences
However, for this coding challenge, the strict equality is appropriate as the problem likely assumes normalized inputs.
There was a problem hiding this comment.
Pull request overview
This PR adds a new GreatFrontEnd problem solution for "getElementsByStyle", implementing a function that finds DOM elements matching a specified CSS property-value pair. The implementation uses a depth-first traversal approach to search through element descendants.
Changes:
- Implements the getElementsByStyle function using computed styles and recursive DOM traversal
- Adds problem documentation with description, examples, and constraints
- Updates progress trackers showing 7/75 GFE problems and 13 total GreatFrontEnd problems completed
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| getElementsByStyle.ts | New TypeScript implementation using recursive DFS to find elements with matching computed styles |
| getElementsByStyle/README.md | Problem description explaining the API requirements and providing usage examples |
| gfe-75/README.md | Updates GFE 75 progress from 6 to 7 problems, adds getElementsByStyle to DOM Manipulation section |
| README.md | Updates GreatFrontEnd total count from 12 to 13 problems |
| Implement a method `getElementsByStyle()` that finds DOM elements that are rendered by the browser using the specified style. It is similar to `Element.getElementsByClassName()` but with some differences: | ||
|
|
||
| - It is a pure function which takes in an element, a property string, and a value string representing the style's property/value pair to be matched on the elements descendants. E.g. `getElementsByStyle(document.body, 'font-size', '12px')`. | ||
| - Similar to `Element.getElementsByClassName()``, only descendants of the element argument are searched, not the element itself. |
There was a problem hiding this comment.
There's a double backtick here. It should be a single backtick to properly format "Element.getElementsByClassName()".
| - Similar to `Element.getElementsByClassName()``, only descendants of the element argument are searched, not the element itself. | |
| - Similar to `Element.getElementsByClassName()`, only descendants of the element argument are searched, not the element itself. |
| if (el === null) { | ||
| return; | ||
| } | ||
|
|
There was a problem hiding this comment.
This null check is unnecessary because the Element type doesn't include null, and the function is only called with elements from el.children which are always valid Element objects. This check can be removed to simplify the code.
| if (el === null) { | |
| return; | |
| } |
| export function getElementsByStyle( | ||
| element: Element, | ||
| property: string, | ||
| value: string | ||
| ): Element[] { | ||
| const elements: Element[] = []; | ||
|
|
||
| function traverseDOM(el: Element) { | ||
| if (el === null) { | ||
| return; | ||
| } | ||
|
|
||
| const computedStyle = getComputedStyle(el); | ||
|
|
||
| if (computedStyle.getPropertyValue(property) === value) { | ||
| elements.push(el); | ||
| } | ||
|
|
||
| for (const child of el.children) { | ||
| traverseDOM(child); | ||
| } | ||
| } | ||
| for (const child of element.children) { | ||
| traverseDOM(child); | ||
| } | ||
| return elements; | ||
| } |
There was a problem hiding this comment.
This DOM manipulation function lacks test coverage. The repository pattern shows that GreatFrontEnd problems typically include comprehensive test files (e.g., debounce.test.ts, event-emitter.test.ts, flatten.test.ts). Consider adding a getElementsByStyle.test.ts file with test cases that cover various scenarios like matching elements, nested structures, and edge cases such as no matches or elements with inherited styles.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
`@greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/getElementsByStyle.ts`:
- Around line 1-5: The file getElementsByStyle uses DOM types like Element and
APIs like getComputedStyle but the TypeScript project lib only contains ES2020;
update the project's TypeScript configuration to include the DOM lib by adding
"dom" to the "lib" array in tsconfig.json (e.g., "lib": ["ES2020", "dom"]) so
the symbols used in getElementsByStyle are defined, or alternatively add a
triple-slash directive at the top of this file to reference the DOM lib if you
prefer a file-scoped fix.
🧹 Nitpick comments (2)
greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/README.md (1)
1-7: Add difficulty badge and link to GreatFrontEnd problem.As per coding guidelines, problem READMEs should include a difficulty badge and link to the problem on the respective platform. Other problems in this repository follow this convention.
📝 Suggested addition
# getElementsByStyle + + + +[View on GreatFrontEnd](https://www.greatfrontend.com/questions/javascript/get-elements-by-style) Implement a method `getElementsByStyle()` that finds DOM elements that are rendered by the browser using the specified style. It is similar to `Element.getElementsByClassName()` but with some differences:greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/getElementsByStyle.ts (1)
8-11: Unnecessary null check.The parameter
elis typed asElement, and the function is only called with children fromel.children, which yieldsElementobjects (nevernull). This null check is unreachable.♻️ Proposed simplification
function traverseDOM(el: Element) { - if (el === null) { - return; - } - const computedStyle = getComputedStyle(el);
greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/getElementsByStyle.ts
Show resolved
Hide resolved
|
@codex review |
|
Claude finished @pertrai1's task in 1m 38s —— View job Code Review: getElementsByStyle ✅Great work on this GreatFrontEnd solution! The implementation is correct and demonstrates solid understanding of DOM traversal and the Computed Style API. Here's my detailed educational review: ✅ 1. CorrectnessVerdict: The solution correctly implements all requirements.
Mental trace with the example: // Given DOM: <div><span style="font-size: 12px">Span</span><p style="font-size: 12px">P</p></div>
getElementsByStyle(doc.body, 'font-size', '12px')
// Execution flow:
// 1. Start with body.children (the div)
// 2. traverseDOM(div): getComputedStyle(div).getPropertyValue('font-size') !== '12px' → skip
// 3. Recurse into div.children: [span, p]
// 4. traverseDOM(span): getComputedStyle(span).getPropertyValue('font-size') === '12px' → push span
// 5. traverseDOM(p): getComputedStyle(p).getPropertyValue('font-size') === '12px' → push p
// Returns: [span, p] ✅🌐 2. Browser API UsagegetComputedStyle() - The Right Choice
Important distinction: // ❌ Wrong approach - only checks inline styles:
if (el.style.fontSize === '12px') { ... }
// ✅ Correct approach - checks computed (rendered) styles:
if (getComputedStyle(el).getPropertyValue('font-size') === '12px') { ... }DOM Traversal Pattern
📊 3. Time & Space ComplexityTime Complexity: O(n)
*Note: In reality, Space Complexity: O(h + m)
Example complexity scenarios: 💻 4. Code QualityStrengths:
Minor Note on Original Code:
Additional Quality Points:
📚 5. Learning SummaryKey Concepts & PatternPattern: Depth-First Search (DFS) Tree Traversal
Why DFS Works Here:
Browser API Insight: Computed Styles vs. Inline Styles The key insight for this problem is understanding the difference:
Example: <style>.box { font-size: 16px; }</style>
<div class="box" id="myBox"></div>
<script>
const box = document.getElementById('myBox');
// ❌ Returns empty string (no inline style):
console.log(box.style.fontSize); // ""
// ✅ Returns computed value from stylesheet:
console.log(getComputedStyle(box).getPropertyValue('font-size')); // "16px"
</script>Why This Matters: Always use Alternative ApproachesApproach 1: Iterative DFS with Stackfunction getElementsByStyle(element: Element, property: string, value: string): Element[] {
const elements: Element[] = [];
const stack: Element[] = [...element.children];
while (stack.length > 0) {
const el = stack.pop()!;
if (getComputedStyle(el).getPropertyValue(property) === value) {
elements.push(el);
}
// Push children in reverse order to maintain document order
for (let i = el.children.length - 1; i >= 0; i--) {
stack.push(el.children[i] as Element);
}
}
return elements;
}Trade-offs:
Approach 2: BFS with Queuefunction getElementsByStyle(element: Element, property: string, value: string): Element[] {
const elements: Element[] = [];
const queue: Element[] = [...element.children];
let index = 0;
while (index < queue.length) {
const el = queue[index++];
if (getComputedStyle(el).getPropertyValue(property) === value) {
elements.push(el);
}
queue.push(...Array.from(el.children));
}
return elements;
}Trade-offs:
Which to choose?
Related Problems for Practice
Common Mistakes to Avoid❌ Mistake 1: Using // Wrong - only checks inline styles:
if (el.style.fontSize === '12px') { ... }❌ Mistake 2: Including the root element // Wrong - checks element itself:
traverseDOM(element); // Should start with element.children❌ Mistake 3: Returning HTMLCollection instead of Array // Wrong return type:
return document.getElementsByClassName('...'); // HTMLCollection
// Correct:
return [...document.getElementsByClassName('...')]; // Array❌ Mistake 4: Not handling property name formats // CSS properties use kebab-case in getPropertyValue:
getPropertyValue('font-size') // ✅ Correct
getPropertyValue('fontSize') // ❌ Wrong🎯 Key Takeaways
Final RatingOverall: ⭐⭐⭐⭐⭐ (5/5)
This is a production-ready solution that would pass any coding interview. Excellent work! 🚀 |
|
To use Codex here, create a Codex account and connect to github. |
|
🤖 Gemini Code Review (Model: Here's a detailed review of your 1. Pattern IdentificationThis solution primarily uses a Tree Traversal pattern, specifically Depth-First Search (DFS). The DOM (Document Object Model) is a tree structure, and the problem requires visiting all descendant nodes to check a condition. The recursive 2. Complexity Verification
3. Key InsightThe key insight for this problem has two main components:
4. Edge Case AnalysisThe current solution handles several common edge cases correctly:
Potential Edge Cases to Consider (and how the solution handles them):
The solution seems robust for the specified problem constraints. 5. Learning Points
6. Code QualityThe code quality is good:
Minor Improvement (Optional): You could make // No change needed, but just for illustration of a minor alternative structure:
// export function _traverseDOM(el: Element, property: string, value: string, elements: Element[]) {
// const computedStyle = getComputedStyle(el);
// if (computedStyle.getPropertyValue(property) === value) {
// elements.push(el);
// }
// for (const child of el.children) {
// _traverseDOM(child, property, value, elements);
// }
// }
// export function getElementsByStyle(...) {
// const elements: Element[] = [];
// for (const child of element.children) {
// _traverseDOM(child, property, value, elements);
// }
// return elements;
// }The current nested function is perfectly fine and often preferred for encapsulation. 7. Alternative Approaches
Both iterative approaches offer similar time and space complexity to the recursive DFS for this problem, mainly differing in their traversal order and memory usage patterns (stack vs. queue). Your current recursive DFS is a perfectly valid and idiomatic solution. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/README.md`:
- Around line 1-8: The README for getElementsByStyle is missing metadata and
complexity details; update
greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/README.md to include
the difficulty badge, a link to the original problem, constraints/expected
behavior summary, and a Big-O complexity section (time and space) for the
getElementsByStyle(element, property, value) function so it matches the repo
README guidelines and other problem READMEs; ensure you reference the function
name getElementsByStyle and describe that it searches only descendants (not the
element itself) when explaining constraints.
♻️ Duplicate comments (1)
greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/getElementsByStyle.ts (1)
1-11: Add browser environment configuration for DOM API usage.The ESLint configuration has
"node": truebut not"browser": true, causingno-undeferrors for browser globals likeElementandgetComputedStyle(). Add an override in.eslintrc.jsonforgreatfrontend/**files to enable the browser environment, rather than adding in-file comments. This aligns with the repo's existing pattern of directory-based overrides:{ "files": ["greatfrontend/**/*.{js,ts}"], "env": { "browser": true } }This should be added to the
overridesarray in.eslintrc.jsonalongside the existingleetcode/**andscripts/**overrides.
| # getElementsByStyle | ||
|
|
||
| Implement a method `getElementsByStyle()` that finds DOM elements that are rendered by the browser using the specified style. It is similar to `Element.getElementsByClassName()` but with some differences: | ||
|
|
||
| - It is a pure function which takes in an element, a property string, and a value string representing the style's property/value pair to be matched on the elements descendants. E.g. `getElementsByStyle(document.body, 'font-size', '12px')`. | ||
| - Similar to `Element.getElementsByClassName()`, only descendants of the element argument are searched, not the element itself. | ||
| - Return an array of `Elements`, instead of an `HTMLCollection` of `Elements`. | ||
|
|
There was a problem hiding this comment.
Add problem metadata + complexity section.
This README is missing the difficulty badge, problem link, constraints, and Big‑O complexity note. Please add them to align with the repo’s README guidelines. As per coding guidelines, ...
🤖 Prompt for AI Agents
In `@greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/README.md` around
lines 1 - 8, The README for getElementsByStyle is missing metadata and
complexity details; update
greatfrontend/gfe-75/dom-manipulation/getElementsByStyle/README.md to include
the difficulty badge, a link to the original problem, constraints/expected
behavior summary, and a Big-O complexity section (time and space) for the
getElementsByStyle(element, property, value) function so it matches the repo
README guidelines and other problem READMEs; ensure you reference the function
name getElementsByStyle and describe that it searches only descendants (not the
element itself) when explaining constraints.
📅 Spaced Repetition Reviews Scheduled!Great job solving #GFE-697b - GetElementsByStyle! 🎉 To help you retain this knowledge long-term, I've scheduled 5 review sessions using spaced repetition:
What to expect:
🧠 Why Spaced Repetition?Research shows that reviewing material at increasing intervals dramatically improves retention. This adaptive scheduling ensures optimal spacing based on when you actually complete each review! Check |
Problem: #GFE-697b - GetElementsByStyle PR: #208 First review scheduled (subsequent reviews auto-scheduled on completion) [skip ci]
Summary by CodeRabbit
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.