Open romainmenke opened 1 year ago
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.
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?
Moving to mdn/bob, as the feature resides in the editor, and was implemented in https://github.com/mdn/bob/pull/759.
@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.
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 https://github.com/mdn/bob/pull/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.
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 :)
Let me put some things in context here:
If I understand you correctly, you would prefer that we either
Both options aren't great:
hyphens
would seemingly have the same result.Nevertheless we will ask folks on Discord for their feedback before making a final decision.
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 :)
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.
@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.
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 :
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.
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