Support for W3C-valid data- attributes in Finsweet Components (CMS Slider)

Finsweet Components
1

Description

We’re using Finsweet Components (CMS Slider) on a client site in Webflow. When we run the site through the W3C Markup Validator (https://validator.w3.org/), the only errors left come from Finsweet:

  1. Slider attributes: fs-slider-type, fs-slider-instance and fs-slider-element on div and button elements return “Attribute fs-slider-element not allowed on element div at this point.” (8 errors)
  2. Script injected by the Webflow app (componentsconfig-1.0.5.js): siteId="..." and finsweet="components" return “Attribute siteid not allowed on element script at this point.” (2 errors)

Under the HTML spec, custom attributes need the data- prefix to be valid. We’d like to use W3C-valid attributes like data-fs-slider-element, and ideally have the injected script use data-site-id and data-finsweet. Is this already supported? If not, could you consider adding it?

Site URL

Steps to Reproduce

  1. Open https://validator.w3.org/
  2. Choose “Validate by URI” and enter https://nue-gmbh.webflow.io/
  3. Click “Check”
  4. See the errors for the fs-slider-* attributes and for the siteId/finsweet attributes on the components script

Expected Behavior

Finsweet Components work with W3C-valid markup (data- prefixed attributes), so the page validates without errors from Finsweet.

Actual Behavior

The validator returns 10 errors. All of them come from the Finsweet slider attributes and the script injected by the Finsweet Components app. Every other error on the site has been fixed.

Video/Screenshots

  • Video link: [Loom-Link einfügen]
  • Screenshots: [Screenshot vom Validator-Report]

Additional Context

  • Browser: Not browser-specific (markup validation)
  • Device: Not device-specific
  • Finsweet Components config version: 1.0.5
2

Hi @admin10,

We checked the website and can see you’ve implemented a workaround for the fs-slider-* attributes
You have them initially in Webflow as data-fs-slider-* so as to pass the W3C Markup Validator checks
Then there’s custom code in there to rework them back to the required fs-slider-* attributes that Finsweet Components expects

The only issue now, as per the W3C Markup Validator checks, is the remaining two attributes on the actual CDN script itself that Finsweet Components adds to the site
These are the siteId="..." and finsweet="components" attributes

First & foremost we need to emphasize that these W3C Markup Validator errors are conformance warnings about custom attribute names
Browsers generally ignore any unknown attributes and so the Finsweet Component attributes will in no way affect the site rendering, or its accessibility, or site SEO
You could consider documenting them as known third-party exceptions

That being said, you’ve at least sorted out 8 of the validator errors with the smart workaround

However, you should try test it thoroughly for potential nuances

For instance, the Finsweet CDN loads async & so if for some reason your attribute-correction script runs while Finsweet CDN is also starting up, the slider may never be initialized & your code’s restart may also fail on the if check, hence no slider

The restart() is also undocumented API & so a future release of Finsweet Components might potentially break it
You would’ve to keep tabs on it perpetually

A routine edit on the Slider settings could potentially re-add the fs-slider-* attributes without notice

The docs advice against removing the attributes
Do not remove the attributes. They are required for the Slider component to work.
We can confirm that Finsweet Attributes are fs- prefixed
There are no data-fs-* aliases in the works

We would suggest working with the current fs-slider-* attributes as is, considering they don’t affect function, accessibility or SEO

Thanks

3

Hi Jesse,

Thanks for taking the time to look at the site in such detail. I really appreciate it.

I understand that browsers ignore unknown attributes and that this doesn’t affect rendering, accessibility or SEO. Still, for us and our clients, valid markup is part of delivering clean, professional work. Clients run these checks, and “known third-party exceptions” are hard to explain when the HTML spec already defines a standard way to add custom attributes: the data- prefix.

Your reply actually makes the case for native support. Every risk you pointed out comes from the workaround:

  • the race condition with the async CDN script
  • relying on the undocumented restart() API
  • slider settings that could quietly re-add the fs-slider-* attributes

If Finsweet supported data- attributes natively, none of these would apply. There’d be no workaround, the validator would pass, and everything would run stable.

So I’d like to ask you to consider:

  1. Accepting data-fs-* as an alias for the existing fs-* attributes (e.g. data-fs-slider-element). That’s fully backward compatible, so existing projects keep working.
  2. Using data- attributes on the injected script as well (e.g. data-site-id and data-finsweet instead of siteId and finsweet).

Could you pass this on to the team as a feature request? I’m sure we’re not the only ones who care about valid markup.

Thanks again for your help!

Best regards

4

Hi admin,

Sure, I’ll definitely pass it on to the devs as a feature request

Thanks once again for suggesting improvements to the product & the Finsweet ecosystem in general