Charts.css
Charts.css: Modern CSS framework for data visualization; uses utility classes for chart styling. Features various chart types, customizable styling, responsive design, no external dependencies, and open-source. GitHub repo available.
CSS
Web Components Demystified
Web Components Overview:
Scott Jehl's course “Web Components Demystified” clarifies concepts around custom elements in web development. Web components consist of custom elements, HTML templates, and shadow DOM. Custom elements are user-defined HTML tags with specific functionalities, while templates facilitate reusable markup hidden from direct rendering. Shadow DOM encapsulates an element's internal structure, isolating it from external styles and scripts.
Key Concepts:
1. Custom Elements: User-defined tags behaving per specifications (e.g.,
2. HTML Templates: Hidden markup for reuse (e.g., ).
3. Shadow DOM: Isolated DOM for styles and scripts (e.g., encapsulated styles).
Development Details:
– Activity in custom elements includes lifecycle management (constructed, connected, and more), utilizing JavaScript for behavior customization.
– Shadow DOM encapsulation requires understanding and techniques to cross-interact with external elements.
– Care should be taken when building web components for forms to ensure accessibility and functionality.
Styling and Attributes: Styling web components can be achieved using regular CSS, while maintaining proper encapsulation and avoiding standard attribute conflicts. Various examples illustrate the practical implementation end-to-end across components.
Overall, the course equips developers with an understanding of creating and managing web components within modern web applications, highlighting both the simplicity and complexity of component architecture.
A CSS-Only Star Rating Component And More! (Part 1)
CSS-only star rating component created with an input range element, styled with CSS to represent stars. The design uses masking techniques to display the star shape based on the input value. The component can be adjusted for star quantity via the max attribute and supports half-star ratings by modifying step values. Accessibility features include outlines for keyboard focus. Code examples show how to implement variations using gradients or SVGs for different shapes, maintaining a clean, single-element structure.
https://css-tricks.com/a-css-only-star-rating-component-and-more-part-1/
A “section” Without an Accessible Name Is Nothing but a “div”
TLDR: https://www.stefanjudis.com/today-i-learned/section-accessible-name/ elements require an accessible name (via aria-label or aria-labelledby) to function as landmarks for assistive technology; otherwise, they act as generic s, losing their intended semantic value.
A New Proposal for Masonry Layouts in CSS
The debate around implementing masonry layouts on the web has been ongoing, with various proposals being put forward. Recently, the WebKit team proposed adding masonry as part of the CSS Grid Layout specification. However, the Chrome team has expressed concerns about this approach and instead suggested defining masonry outside the grid specification.
The Case for a Separate Masonry Specification
The Chrome team argues that adding masonry to the grid specification is problematic for several reasons beyond whether masonry is a grid. By defining masonry outside of the grid specification, it would still be possible to achieve the same flexibility and functionality as the WebKit proposal without the drawbacks of bundling it with the grid.
Here are some key points in favor of a separate masonry specification:
- Simpler syntax: Defining masonry using a separate
display: masonryproperty would require less code than the equivalent grid-bundled version. For example, a classic masonry layout with equal-sized columns could be achieved with just a few lines of CSS:
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
gap: 1rem;
}
- Flexibility in track sizing: A separate masonry specification would still allow for different column widths using grid-type track sizing, just like the WebKit proposal. This means that developers would have the same level of control over the layout as a grid-based solution.
-
Support for spanning columns: There's no reason why a separate masonry specification couldn't support content spanning multiple columns. This could be achieved using properties like
masonry-track-startandmasonry-track-end, similar to how grid items span multiple tracks. -
Compatibility with other layout features: Defining masonry outside of the grid specification doesn't prevent it from being used with other layout features like alignment or gaps. Developers would still have access to the same set of tools they're used to when working with grid layouts.
The Way Forward
The Chrome team's proposal for a separate masonry specification offers a promising alternative to the WebKit approach. By decoupling masonry from the grid, it would be possible to achieve the same functionality and flexibility while avoiding the potential pitfalls of bundling the two together.
As the debate continues, developers are demanding a way to create masonry layouts on the web. The Chrome team's proposal is a step in the right direction, and hopefully, we'll see progress soon.