Remove feature detection and hiding of demo's in unsupported browsers

[romainmenke]

Demo's seem to have browser sniffing and show a red banner when the browser doesn't (fully?) support the demo.

https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens#browser_compatibility

I can not understand why this is needed and who is helped by this?

Also makes me wonder if MDN itself adheres to it's own advice....
https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent

Tasks

Preview Give feedback

1. Get user feedback on Discord

[sivakusayan]

I'm just a random person, but I took a quick look at this out of curiosity and I think this is okay, unless I'm misunderstanding something.

This was added in pull request mdn/yari#759 and seems to use feature detection rather than browser sniffing to display the message.

[romainmenke]

Showing how something fails is valuable to web developers, then they can compare the working feature with the degraded experience.

Maybe it is better to show this message as a warning together with the demo?

[caugner]

Moving to mdn/bob, as the feature resides in the editor, and was implemented in #759.

[caugner]

@romainmenke Can you share what browser and version you saw the red banner with?

PS: In the future, please make sure to always use the issue templates to ensure we have all information upfront.

[romainmenke]

Hi @caugner,

The exact browser nor the version I was on are relevant to this issue.
The issue is not : "I expect this thing to work on my specific browser" :)

I expect all demo's to be shown regardless of the browser and or version.
I don't think hiding content for specific browsers or browser versions is ever ok.

So I think the change in #759 was not a good direction and should be revisited.

It is obviously fine and helpful to indicate that a demo is not fully working in a specific browser, but how a demonstrated web API breaks is useful information for developers. By hiding the demo entirely this information is also hidden.

The example from my original post was hyphens. In a browser without support for the CSS property you would still get some behavior for how text flows over multiple lines and if hyphens are added. Seeing this fallback behavior is information that developers need.

It shows whether a feature is safe or unsafe to use as a progressive enhancement.

[romainmenke]

In the future, please make sure to always use the issue templates to ensure we have all information upfront.

There is only one issue template, which is focussed on capturing bug report information.
This is not a bug report so the questions there were not relevant to this issue.

https://github.com/mdn/yari/issues/new

If there was a template that I could have used which relevant questions, I would have used it. I know how helpful these are and I always try to use them :)

[caugner]

Let me put some things in context here:

• The examples you're referring to here are specifically for CSS features, like this one:
  
• Before Warning on javascript or feature not supported #759, the case that a browser doesn't support a given CSS feature was already detected, and the interactive CSS example was just hidden.
• Warning on javascript or feature not supported #759 simply changed that a note is shown instead indicating that the browser doesn't support the [CSS] feature, to give users a chance to consult the browser compatibility table and possibly try the examples in a browser that supports the feature.
• Interactive CSS examples are shown if at least one of the example choices is supported (the screenshot above has three), and afaik unsupported choices are indicated accordingly.
• We use feature detection, not browser sniffing, so the premise of your report is invalid.
• It is in the nature of our interactive examples that they only work in browsers that support the feature, so your expectation of every interactive examples working in every browser and version cannot be met by our implementation of interactive examples.

If I understand you correctly, you would prefer that we either

1. show examples regardless of whether they work in the browser, or
2. make sure every example works in every browser, even if the browser doesn't support the feature.

Both options aren't great:

1. Showing an example that doesn't work in the browser confuses users, because (to use the example above) all values for hyphens would seemingly have the same result.
2. Making an example work that doesn't actually work misleads users, because they will expect that they can use the feature as showcased, but actually it won't work.

Nevertheless we will ask folks on Discord for their feedback before making a final decision.

[romainmenke]

We use feature detection, not browser sniffing, so the premise of your report is invalid.

I've changed the title to avoid this point of confusion.
The exact technical implementation of how different content is shown to different browser versions is not crucial to this issue.

If MDN uses client side code to detect feature support then that is what this issue is about. It is the end result, the hidden demo that this issue is about.

make sure every example works in every browser, even if the browser doesn't support the feature.

That is impossible and doesn't make sense.
I also don't think I've given any indication that this is what is being asked in this issue 😕

show examples regardless of whether they work in the browser

Yes, that is what I am trying to communicate here.

Showing an example that doesn't work in the browser confuses users, because (to use the example above) all values for hyphens would seemingly have the same result.

That would be confusing when there isn't any context.
But as I said in the previous comment, a warning that a demo is not fully functional together with the broken demo would be very helpful.

The combination is possible :)

• a broken demo
• a message that says the demo is broken

Showcasing how a feature does not work IS relevant information.
Given that the web is not a homogenous environment, it is natural that some features will not work for some end users. Showcasing how things break is an important part of informing developers about features.

---

Hiding the demo can make a feature seem unsafe to use.

A demo with a broken feature that shows the fallback behavior might show to developers that the feature is a harmless progressive enhancement and therefore perfectly safe to use.

[caugner]

@romainmenke Let me try and ask once more if your argument is theoretical at this point, or whether you can provide a real example where a specific CSS feature is currently not supported in a browser and the interactive examples on the corresponding page is showing that message? That might significantly help your case.

[romainmenke]

Initially I filed this issue with hyphens as the example, but Safari shipped it since then, so that demo now works and the warning is gone.

---

Another example : https://developer.mozilla.org/en-US/docs/Web/CSS/ruby-position

A codepen that can be used to see the result in all browsers :

https://codepen.io/romainmenke/pen/ExGMEGw

When the demo is present I can use it to test things out.
For example I can try the -webkit- prefixed versions, right there on the page.

However when the demo is hidden I can no longer see how it breaks and I can't manipulate the code to try things out.

By hidden the (broken) demo I can no longer answer these questions for myself, right there on the page :

• can a user still see the content when the property is not supported?
• is the fallback/initial value something that is acceptable for my use case?
• how does the vendor prefixed property work?

Developers can build their own demo's in codepens and use those to try things out.
But this seems weird given that there already is a demo, it's just being hidden.

---

I think that communicating that a demo will not work as expected in the user's browser is a good thing. However I think this can be done without hiding the demo entirely.

I also think that the broken/unsupported states of features are valuable to illustrate how something breaks.