Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task
romainmenke opened this issue Jul 26, 2023 · 10 comments
Open
1 task
Labels
effort: medium This task is a medium effort. enhancement Improves an existing feature.

Comments

@romainmenke
Copy link

romainmenke commented Jul 26, 2023

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

Screenshot 2023-07-26 at 10 32 12

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
@github-actions github-actions bot added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Jul 26, 2023
@sivakusayan
Copy link

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
Copy link
Author

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
Copy link
Contributor

caugner commented Oct 11, 2023

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

@caugner caugner transferred this issue from mdn/yari Oct 11, 2023
@caugner
Copy link
Contributor

caugner commented Oct 11, 2023

@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.

@caugner caugner added the needs info Needs more information to review or act on. label Oct 11, 2023
@romainmenke
Copy link
Author

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
Copy link
Author

romainmenke commented Oct 11, 2023

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
Copy link
Contributor

caugner commented Oct 11, 2023

Let me put some things in context here:

  • The examples you're referring to here are specifically for CSS features, like this one:
    image
  • 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 romainmenke changed the title Remove browser sniffing Remove feature detection and hiding of demo's in unsupported browsers Oct 11, 2023
@romainmenke
Copy link
Author

romainmenke commented Oct 11, 2023

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 caugner added enhancement Improves an existing feature. effort: medium This task is a medium effort. needs discussion and removed needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. needs info Needs more information to review or act on. labels Oct 11, 2023
@caugner
Copy link
Contributor

caugner commented Oct 11, 2023

@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
Copy link
Author

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.

Screenshot 2023-10-11 at 22 59 02

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?
Screenshot 2023-10-11 at 23 01 32

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: medium This task is a medium effort. enhancement Improves an existing feature.
Projects
None yet
Development

No branches or pull requests

3 participants