I want to assure everyone that we haven’t forgotten about this, and we’ll provide an update soon. I have updated the category to “Improvements” and removed the “NO BUG” status.
4 Likes
I’m not cynical. The pace and output of new features and fixes encourage me plenty. Charaf’s response here is proof.
=)
1 Like
Hey everyone,
Just a quick update on this task. For the past year, we’ve been going back and forth on this topic. We’ve had reports from users that their sites break on older browsers—like smart TVs, whiteboards, and older iPads—because of properties like :where. This has made us hesitant to roll out these changes across the board. But we realized it’s more consistent to break uniformly than to break unpredictably.
We’ve decided that the best time to address this is with the 2.0 release. Our decision is guided by the Baseline concept, which we’re adopting to determine which CSS features to support. Baseline provides a framework for balancing the adoption of new web features with maintaining stability for users.
For us, this means we’ll prioritize supporting properties that are considered “Widely Available” by Baseline. Baseline defines two main stages:
- Newly Available: A feature reaches this stage when it’s interoperable across all major browsers—Chrome, Edge, Firefox, and Safari, including their mobile versions.
- Widely Available: This stage occurs approximately 30 months after a feature becomes Newly Available. It indicates that the feature is safe to use broadly, as it’s available to about 95% of users globally.
Currently, :where is already widely available, which means it’s safe for us to use it broadly. We’re also looking forward to incorporating @layer, which is Baseline 2022 “newly available” and is expected to become widely available later this year.
By aligning with the “Widely Available” stage of Baseline, we ensure a stable and consistent experience for all users. This approach allows us to take advantage of new CSS capabilities as they become viable, staying current with best practices and advancements while avoiding premature implementations that could disrupt user experience.
We’d love to hear your thoughts and feedback. Are there any other CSS properties or features you think we should consider incorporating?
12 Likes
Thanks for the update @charaf release for 2.0 makes the most sense.
I would argue against not supporting Newly Available.
Waiting 30 months for widely available is a long time in CSS land and do you want Bricks to be known in a similar vein to as Elementor was being the last to support grid etc for the sake of niche devices such as whiteboards and TV’s etc. Does Bricks want to be a modern, up to date, current builder or one that is slow, behind and waits for the perfect time to introduce a feature.
As per the Baseline docs, “Newly Available work in at least the latest stable version of each of the Baseline browsers” Most browsers nowadays are updated very regularly so whilst I understand that people might complain about viewing on TV’s, Whiteboards etc but they are such niche devices that you could argue that these devs should be building the site to suit those devices specifically anyhow so there shouldn’t be many issues, especially with new features.
You could be holding off on a lot of new CSS features because of a self-imposed rule about whiteboards. What is the ratio of users wanting new features once they are stable (Newly Available) compared to users who want features at a later date to support everyone
I would suggest that 6 months after Newly Available would be a good point. It will take time to build the features in anyhow, plus after 6 months the vast majority of users will be up to date on the latest browser version that would support said feature.
Just my 2c - I see this as a half step forward with bug fixing and new features but also 1 step back in future updates and supporting new features. To know a new feature is out now and i have to wait almost 3 years for compatibility and inclusion, might make me question using Bricks.
5 Likes
Can’t you use @supports during the newly available stage and then remove that when it reaches widely available?
2 Likes
Thanks for the detailed reply about the path moving forward. I appreciate it. I am glad to see “where” coming to 2.0 and looking forward to layers being supported.
I was also wondering about css containers and when/if a UI is coming for that?
I would like to echo @dan argument though. I would rather see Newly Available be the target baseline instead of Widely Available. TV Browsers, White Boards, and other similar type devices makes up such a small small small percentage of visitors. Heck the percentage of visitors using old devices that do not receive updates any more is a higher percentage but we all agree that they get left behind as the percentage of visitors is still really small.
1 Like
I don’t see the point in supporting “:where” with a 94.69% adoption across major browsers latest release but not supporting “@layer” with 93.83% adoption.
What’s the threshold? An arbitrary 2.5 years cycle because or how fast major browsers can adopt the tech and release?
I’m probably missing something obvious. In any case, a great improvement.
3 Likes
The status is already “Baseline Widely available”. Could you make the update earlier instead of waiting for Bricks 2.0?
1 Like
Hi guys,
These types of issues should be solved in Bricks 2.0 alpha, now available as a manual download in your account (see changelog).
Please let us know in the bugs category if you are still experiencing issues.
As with any pre-stable release, please do not use it on a production/live website. It is only meant for testing in a local or staging environment.
1 Like