@Chardonneaur opened this Issue on February 27th 2021

When using https://validator.w3.org the Matomo Tag Manager code snippet is flagged as a warning.
Solution: please change

@Findus23 commented on February 27th 2021 Member

This is a fun "issue": In HTML5 javascript is the default for the <script> tag and therefore adding the type is redundand. The [standard]() even says:

Authors should omit the attribute, instead of redundantly giving a JavaScript MIME type.

But Matomo can't know that the website you paste the tracking (or tag manager) code into is a HTML5 page accessed with a modern browser.
It could also be an ancient website only used by IE8 users and in this case I think adding the type is required for the browser to know what scripting language to use for it.

So it might be worth it to add redundand information in 99% of cases to avoid breaking things in very rare cases.

You can of course feel free to remove the type in your website as it isn't needed when you use HTML5.

@tsteur commented on February 28th 2021 Member

Thanks for this @Chardonneaur . @Findus23 @Chardonneaur not sure if we should keep the issue open or close it? We wouldn't remove it for now while we support older browsers so tempted to close the issue and re-open when we drop support for older browsers maybe (which is unlikely to happen in the next 2-3 years).

@oldrup commented on May 15th 2021

My comment from in the matomo forums might actually belong here...

Internet Explorer 8 was released twelve years ago, and had end of life six years ago. Purely an opinion - but is it wise to keep pampering users of an obsolete browser no longer supported by its creator, at the cost of a (slightly, admittedly) less optimal experience for the 99% rest? I don’t think so.

Also, if using IE8, not supporting HTML5 or CSS3 properly, you have way more severe UX problems than missing out on getting your visit recorded by matomo.

Maybe IE browser support could be optional in matomo, just like do-not-track and IP anonymization?

As a site owner, using “modern” web techniques like CSS grid and custom properties, my sites support a vide range of modern browsers on many devices - but not IE - so it’s not that flipping that switch in matomo, serving recommended html, would not be the dealbreaker anyway. I’ve already “lost” my IE visitors.

Regarding "You can of course feel free to remove the type in your website as it isn't needed when you use HTML5." ... As far as I can see, that's not possible if fetching the tracking code via api - like the matomo integration plugin for WordPress, is it?

@tsteur commented on May 16th 2021 Member

@oldrup do you mind letting us know why it's a problem when it's there? If I see this right in the initial issue it triggers a warning in w3c validator (not an error). Is that a problem? why?

FYI it's always possible to write a custom plugin to remove the type if that's absolutely necessary. Most users don't have an issue with the attribute being there so we'd like to prevent having too many options or settings when it works for the majority without issues. In the future this will change for sure and be great to understand why it's a problem.

@oldrup commented on May 17th 2021

@tsteur

Thank you so much for your interest in this. I'll try to explain. It's more like a political issue, than a hard technical error, I'm totally aware of that, so please excuse me if this gets lengthy:

I aim to make sustainable, accessible, solid websites, that lives up to best practices and respects privacy. The latter is where matomo comes into play. Now, project owners, clients, customers, are not always easy to convince, that efforts should be made to live up to certain standards. They are often unaware of the concept of "code quality". They decide on a pretty design and settle with the tools they are used to (GA) and that's it.

Unless you can show them, not tell, that there is a better way, and it's neither hard nor expensive.

Take a look, at these two screenshots, showing the difference in test reports (in this case using wattspeed) before and after removing the redundant JavaScript MIME type:

Before: https://snipboard.io/mYdLTf.jpg
After: https://snipboard.io/xzAelZ.jpg

You and I both know that the redundant JavaScript MIME type, isn't doing any harm whatsoever. Still, there are good reasons that the latter result is preferred:

  • Project owners are much more likely to accept any ethic requirement (like WCAG and GDPR-compliance), when shown a case or prototype, testing green across the board. Having anything but zero errors, is not convincing to non-tech decision makers.
  • Telling clients or co-workers to ignore some "unimportant warnings", is a steep slippery slope, where they immediately decide to ignore every warning or error on the site.

Say what you want about these tests, but in my experience, with the warnings eliminated, I can tell decision makers "Yes - we will respect privacy. Yes - matomo is a viable alternative to GA. Yes - we this site will be accessible. No - you don't just have to take my word for it. It IS a better solution. Looks at these 3rd party test-results.".

And changing peoples habits, like using GA, is not easy. We need every good argument we can get.

We also both know, that there is so much more to creating great websites, than just to pass some synthetic tests. But it is definitely a good starting point.

A constructive afterthought. I appreciate that you want to keep the options in the settings dashboard as simple as possible. And that 99% of the users don't care about HTML validation. But how about making it an option in the matomo config file then? I have no problem setting a flag there, just like I did with the enforce-SSL flag until the official plugin was made.

All the best!
Bjarne

@tsteur commented on May 18th 2021 Member

@Findus23 @oldrup

I have just tested it without the attribute in IE8, IE7, IE6 and FF3 and it worked without any issues without the type attribute.

Note in IE7, IE6 and FF3 the tracking doesn't work because the JSON API is not defined and it needs to be polyfilled but the JS executes otherwise nicely. We removed out of the box tracking support for these.

I cannot think of any issue to remove this attribute right now and I reckon it's ok to go ahead with this. In worst case we could always release a patch release with the type attribute again should there be any specific reason why this is needed. We would ideally not have a config option for this.

We will need to mention this in the developer docs. Removing the attribute itself is easy but more of a task is updating all the test as also some tests in the plugins like A/B testing will break tests and needs to be updated later too. It shouldn't be big issue though.

@oldrup I have scheduled this work now and we're planning to make this change and thanks for explaining the background, very appreciated.

If there are any objections by anyone please comment.

@Findus23 commented on May 18th 2021 Member

If it works without, then I guess there is nothing wrong with removing the attribute.
I also saw that this discussion was already had a long time ago: https://github.com/matomo-org/matomo/pull/214

@tsteur commented on May 20th 2021 Member

FYI already updating this in Matomo for WordPress in next release as the tracking code is generated differently there (and it won't break any other automated tests)

@oldrup commented on May 20th 2021

That's great news. I will give a spin on a test site :) Thank you for the update!

This Issue was closed on June 25th 2021
Powered by GitHub Issue Mirror