Not sure how to feel about this. On the one hand, the information does seem more accessible. On the other, all the personality of MDN has been completely wiped out and it feels like an autogenerated github page.
> In the coming months, we’ll be expanding MDN to include a premium subscription service based on the feedback we received from web developers who want to customize their MDN experience. Stay tuned for more information on MDN Plus.
If anything it's the least harmful way of generating a profit. Better than restricting parts of the site. Besides, a subscription service like this is something employers will most likely be paying for, not developers – unless you're a freelancer, in which case it still would count as a business expense.
Hey Mozilla, just writing to thank you for your excellent documentation. The only real problem I have is how free it is. Is there any way I can send you money every month in perpetuity. Thanks.
Mozilla's given me a lot of reasons to be skeptical of much of their last few years but I think this is relatively safe. I don't think they can mess this one up. Web Docs, the bit most people here care about is open source and has many contributions from MS/Google also, so they can't really paywall it or make it too expensive or they'd just go back to hosting that content themselves on msdn or web.dev
If they want to launch a paid newsletter/tutorials site with the same name, it doesn't really affect me much
Love the update. The color-coded pages are also very useful. Though I wish they had an option to hide deprecated methods and properties, or at least put them in a different group.
> In mid-2021 we started to think about modernizing MDN’s design [..] with an emphasis on improved navigability and a universal look and feel across all our pages.
>
> A new logo, chosen by our community [..] We worked closely with branding specialist Luc Doucedame
Wait, this sounds like redesign for redesign's sake?
> Coming soon: MDN Plus [..] In the coming months, we’ll be expanding MDN to include a premium subscription service based on the feedback we received from web developers
> Support MDN and make it your own. For just $5 a month.
Ah, this makes sense now. It looks like MDN is trying to rebrand and reposition itself as a subscription service going forward.
I remain optimistic, it's been a great resource over the years.
You seem to be implying that MDN is no longer the best resource for reading documentation about web technologies. Outside of reading the W3C RFCs, is there something better out there?
One thing w3schools has going for it are the elaborate examples. That really helps when it's a new concept you are trying to learn. Mdn is better for looking up syntax
No there is not, it’s a situation where everyone is burying their head in the sands. No matter how many downvotes I receive it simply does not change the fact that firing a majority of your documentation content team will undeniably have a huge impact on your documentation content.
No, darkmode is not redesign for redesigns sake - it brings benefit for its users.
But redesign for "modernisation" sounds like doing it for the sake of it, unless people would benefit somehow from improved UX. Modernisation alone does not tell this however, I would expect slick awesome buttons, but some ugly, but important buttons gone.
You do know that MDN is considered to be the official documentation of the web and is backed by Google, MicroSoft, Apple, etc? Why in the world would you think it is okay to pay for something that is less than pocket change to maintain for these multi billion dollar behemoths?
Documentation should be free if you want people to use your platform in a coherent way. MDN has always been refreshing and to the point as compared to other sites.
I don't really care about what Google, Microsoft, or Apple do, it's useful to me so I'm happy to pay a small recurring fee for it. I pay for things that provide value to me.
I don't expect you to care, but wow I'm tired of car analogies. They're usually worse than simply talking about the subject at hand.
It's not at all like that. I pay a one-time fee to BMW to get a seat warmer feature, they're not constantly improving or updating them in my car. They're in my car and they're on or off. If they break and I value them, I pay to have them fixed.
MDN is updated often and I it makes my job easier. It makes constantly evolving spec much more digestible. I'd sorely miss it if it were gone tomorrow. It's a service, not a one-off feature.
I don't think that what to all practicality amounts to a tax on basic documentation for web technology would be a great thing or even a good idea. This would finally put an end to the Web as it was conceived.
(Yes, I walk every day, but this doesn't mean that I would welcome feet as a subscription service with the poor damned to crawling.)
> Wait, this sounds like redesign for redesign's sake?
Is it "redesign for redesign's sake" if even your quoted text states the reasons behind it? ("improved navigability and a universal look and feel across all our pages")
I worked on a site that was redesigned every few years. As soon as one redesign finished another one would start. We, the development team, didn’t understand why the business people kept redesigning the site. We finally found out when we were chatting with one of the business people who was leaving for a new position. She admitted to us that the purpose of redesigning was 1. They could point to it as work they were doing to justify their jobs to higher ups, 2. Allowed them to expense meals and travel while meeting with design consultants and doing field research to see how to meet the needs of our users, 3. Allowed them to avoid the harder business work that they should have been working on instead of fun redesign work.
I've often gotten lost at MDN when trying to learn some topic that is new to me. I see on the sidebar of the pages covering aspects of that topic more on the same topic, and within the page links to other related things. I'll have followed some sequence of links through the directed graphs that the pages and links form, and then remember that somewhere on an earlier page there was a link to part of the topic I haven't yet read and then flail around in my history trying to find where I saw that link.
I'd like such sites to have available predefined sequences through the site designed to teach you particular topics. Have context sensitive next and previous and contents links on the page for moving back and forth in the sequence. Context sensitive so that if a page occurs in more than one sequence people get the appropriate navigation for the sequence they are on.
It does, indeed. It does also remind me of GitLab and their quest for finding the best navigation [1]. It was every few versions that the nav kept changing... from horizontal to vertical to fly out to top/side, etc. Looked like bikeshedding on the outside as it seemed to be easier to iterate over the design of the product rather than the actual product. Ultimately what their UX team settled on has been pretty stable for a while.
Looking at the MD source files is enlightening. Every markdown documentation system eventually approaches an underspecced, less powerful, and domain-specific version of reStructuredText/Sphinx.
I thought I was on a different website for a moment haha.
First impression is good though! Looks clean.
One minor annoyance: The sidebar scroll behaves weird. I'm also not a huge fan of the big in your face custom scrollbars. I usually have them hidden, and the custom ones do not respect that, but that's preference.
Dark mode is absolutely great!
Much respect for taking on a big redesign like this. Especially considering the target audience, that takes guts haha.
Finally! A way to directly support MDN and the great things Mozilla does. I remember emailing them over a year ago about their broken previous $5 subscription and getting 0 response back which was perfectly Mozilla.
I'm not optimistic at all about a subscription service for "web developers who want to customize their MDN experience" as an actual value add, as this seems negligible, but I am overall as 1. it's a step in the right direction for new ways to monetize Mozilla and 2. it sounds like they're listening to feedback and willing to iterate on it.
MDN is the single most useful and impactful site in my webdev/design career. Above all things, I want this site to stick around and exist.
Some comments seem to be critical of any change. And while I don't like some of the visual changes, overall I think it's going in the right direction.
Most importantly, I want MDN to stay online and whatever they need to do (within reason of course) to keep it free, open, searchable and existing, I am on board with.
What's up with the huge amount of whitespace? This is supposed to be an information dense website, most of the screen is empty white. Not liking this, who designs this stuff? How to revert back, or I just need to add custom styles?
Update: I added custom styles to remove 95% of the extra margins, padding, spacing, line-height, updated h1/h2/h3/h4 header styling, code highlight styling, and it looks 10 times better, I can actually read the information. Unfortunately I still prefer the previous version
Question: Why do these important sites never get actual user feedback before forcing out a major update as a big "surprise" ?
I'm still working on it. There is a large amount of things to fix. This is the #1 source of web dev information, and from what I can tell they completely screwed it up with this "design update"
Also interested in the custom styles. Although I like the redesign, it's all over the place typographically – 300 only for h1, 400 for h2 with a slight increase in letter spacing (?!) – but can't be bothered to apply a fix myself.
> Why do these important sites never get actual user feedback before forcing out a major update as a big "surprise" ?
The people behind the redesign do so for career, resume & portfolio reasons - they are very unlikely to ever use MDN themselves so they don't care and don't see the problem. You can't rely on user feedback because there's a very high risk users will tell you everything is fine and there's no need for you to mess with anything.
Too much white that's made too many of the visual cues I'd use to navigate blend in with the rest of the page. In the past, I could immediately scroll to polyfills, browser compat charts, etc without having to pay attention while scrolling because those sections were so distinct. I've missed them three times already today and had to start over, scrolling slowly. For me, this update decreases usability.
If anyone from MDN is reading these replies, could you make the old stylesheets open so that we can use extensions like Stylus to put things back?
This one really hurts scanability, which was exceptionally good with the old design. I don't care what they do to the stuff around the content, but this redesign has made the content itself harder to use, which makes it a bad redesign, considering how content-focused the site is.
I don't understand how a company like Mozilla doesn't have the UX talent to call this out immediately when the redesign was proposed. This seems more like a change for the sake of change thing we see out of Google.
I actually dislike the change to the Compatibility Chart. The checkmark serves the same purpose as green vs red boxes did (and is frankly less readable at a glance, not more) and being able to quickly see relative times features were added at a glance made it easy to evaluate whether to use a feature or not. Guess I'll have to revert to using Can I Use? for this again. I had mostly replaced that with MDN.
As a person with red-green colorblindness, I doubt it. The previous version was fine as had an impossible to miss shape-based indication (the X across the cell).
I wouldn't be surprised if you told me that this was done with colorblind people in mind, I've seen many designers blur the line between accessibility and aspects of their design preferences they tell themselves are about accessibility.
Not being able to see browser version numbers at a glance in the Compatibility Chart really reduces the usefulness. I know I can click on a box to see which version a feature was added, but for certain APIs like MediaRecorder (https://developer.mozilla.org/en-US/docs/Web/API/MediaRecord...) this is a lot of clicking! There are subtleties like `pause` being implemented in Safari 14.1 where the rest of the API was implemented in 14.0 I've been bitten by this.
The explanation in the article is: « So you don’t have to keep version numbers in your head, we’ve put more emphasis on yes and no iconography for browser capabilities »
But as far as I can tell all they've done is put a tick there if any version of the browser supports the feature.
That means I could have learned the same information from the old table just by looking at whether the cell had anything in it, with no version numbers "in my head" at all. So I'm feeling patronised rather than helped.
If they'd done a bit more work and made the ticks indicate something like "available in the oldest supported version of the browser" (which is a recent version for Firefox and Chrome but not for Safari), that might have justified what they wrote.
It’s a bit surprising that the linked article isn’t more carefully written to explain choices, given the audience. As you say, the reason given doesn’t hold up to any scrutiny.
Change is hard, naturally there will be some inherent backlash, but one thing I think is a step backwards is the Browser Compatibility table at the bottom. Previously, it had the browser version inline for the cell, now it is just a check mark. To see what version, you need to click on the cell to expand some "more info" section at the bottom.
Knowing if a feature was very recently supported or has been supported for a while is useful; now I'll need to drill down to see the information, and comparing that info across the browsers will be more difficult.
Also, caniuse.com's way of displaying the browser versions is much more helpful. It also communicates which browser versions are current, what's coming up in the next version, and so on.
I fully agree that the browser compatibility information used to be better. That shortened compatibility table is next to useless right now. It even shows a checkmark for features that are only going to be supported by a future (!) version of a browser. For instance, the dialog element [1] is only going to be supported in the upcoming Firefox 98 but already shows a checkmark.
There's some bullshit software on my work machine that is supposed to make it so that we don't need local admin. As if that has ever worked in the past.
Upshot is that Firefox would upgrade, but forget my profile every time. That took months to sort out. Chrome simply won't update at all. Neither will Jetbrains tools, Docker desktop, you name it.
You can try to make everyone upgrade to the latest browser all you want, you're still going to have people running old versions. If you're running a free website, you are at your liberty to ignore those people. But somewhere between 5 and 7 figures a year there's a cutoff where you're going to do backward compatibility because the customer says so.
Not just this, but mozilla also supports ESR versions, where you basically get all the security patches but your browser can be almost 10 versions behind the newest release, so even with regular updates, with ESR, you'll be behind on newest features.
I run a free website, and I consider it my duty to support whatever device the visitor happens to be using. Just like if I had a restaurant or a library, I would build ramps for the less than 1% who need them.
> Change is hard, naturally there will be some inherent backlash
This is the chant of people who've set about forcing regressions on others. Usually it would just be more honest to say, "we don't care about what you want."
Why advertise a service without any details about what it actually is ?
On one hand 5$ is a nominal monthly amount to support MDN. But seriously, just ask for money. I'd be more inclined to help if they just wrote a post saying ' servers ain't free, give us money before this turns into w3schools '.
A few years ago Google, Microsoft, Apple, etc. sent out a press release saying they were abandoning their own documentation efforts and were going to support MDN going forward, which they now considered to be the official documentation of the web.
The servers certainly should be free. AWS, google cloud, Azure should be hosting MDN for free as part of their commitment they laid forth to support MDN.
Yes, but we are talking about a who’s who of the largest tech companies in the world, each of which has their own cloud service systems. One of them could host the content and the others could each pay for a full time person and it would be a few magnitudes less than my paying a single penny towards it a year.
I would love for that to be the case, but at the same time Mozilla is notorious with money mismanagement.
I wouldn't hold my breath here for any big company to step up and feel more Mozilla's coffers. That said, I'm open to buying some merch. As in I'll pay $50 for a sweatshirt
The new site has readability issues, devs you can use the css to fix the font size and line height issues.
.homepage .article-tile p { font-size: 1em; line-height: 1.4; }
Does nobody remember these announcements from the past 5 years? Why would MDN need a subscription service? Why are Google, MicroSoft, Amazon, Apple, etc. not hosting MDN for free on their cloud platforms? Heck, why are they not fighting over the privilege to host it and put a big “Hosted on Azure” link at the bottom of every page? Why are these multi billion dollar companies not funding MDN when they claim in press releases to be sponsors? Funding MDN would be less than pocket change to any of these companies, much less all of them that claim to be sponsors.
We're long past that way of thinking. At all those companies, they are optimizing for operations not building goodwill. Honestly, this is probably more up openshift's direction right now.
Yeah if you dig up the HN conversations on these announcements people have discussed this at length.
Again though, you bring up very good points. With Microsoft and Apple specifically EXPLICITLY throwing in the towel on maintaining documentation for this stuff and pointing people to MDN it boggles the mind how MDN needs money for hosting and subscriptions to fund special content.
I'll miss the old MDN and never had any issues browsing the docs there. The content is what matters at the end of the day, and kudos to the team for the redesign. I do have a couple of complaints though.
1. Font weight (especially with headings) feels far too thin.
2. Seems like there are some color contrast issues when running in dark mode (my system theme)
> Warning: The tabindex attribute must not be used on the <dialog> element.
... Why? I don't use MDN often, mostly just as reference material. I have enjoyed their documentation before, it's always been short and to the point with a few examples and it felt very complete. With this the first article I click on raises an odd question which I feel is either too much detail for reference or too little details for experts.
The spec itself says the same thing with basically no additional detail. I don't exactly see why this is the case but I suppose it does interact with focus as is and tabindex would conflict with that?
> Last year we surveyed users and asked them what they wanted out of their MDN experience… The overall theme we saw was that users wanted to be able to organize MDN’s vast library in a way that worked for them.
Really? I just wanna google for what I need and find it. I guess I'm not representative?
- Reduced contrast (eg. code blocks have lighter gray background, compatibility table is no longer color coded)
- Increased the amount of things that don't render if you disable javascript
I'd reverse all three of those if I could.
On the good side they added a dark mode (which I don't care about but lots of people love dark mode), and they seem to have avoided the common aesthetics-over-effectiveness pitfall of adding tons of vertical whitespace.
(As an aside, I find it weird that they mention the home page in the article. In fact it's the first thing they mention. I would expect the home page to be effectively irrelevant? I only ever land on MDN via google searches and direct links to articles via stackoverflow answers. It's random-access reference material. How would someone end up on the homepage? Maybe they have analytics justifying that.)
> Reduced contrast (eg. code blocks have lighter gray background
Not an expert but this doesn’t seem like a bad thing to me as the contrast of the text with the background within the code blocks is increased, which I’d expect to be a good thing from an accessibility standpoint as I’d say it’s more important than code block contrast vs non-code blocks.
Personally, I really miss the menu background contrast - if something is a floating sidebar please give it a modestly different background content so that it looks like the box-o-stuff it acts like.
Thank you, I wasn't certain if they added the right-hand sidebar with this redesign. I remember consciously thinking that MDN was better than other sites because it lacked said sidebar.
I generally agree on all those points, there's a bunch of things I could critique, like shrinking the search bar behind an icon, or things I like such as the more concise breadcrumbs which make the hierarchy a bit clearer.
But overall I guess after thinking about what I did and didn't like about the design, nothing really stood out as a showstopper for me. I like the old design a lot more, but MDN has always been a reference and I dip into dozens of different references every week, getting used to design differences is par for the course. As long as they don't mess with the overall content hierarchy which is great as-is I'm not too impacted.
So my takeaway was if they invest the same energy into the content hierarchy on a page, I think that would add some value. Keep what they have, don't overstuff it, but just making it easier to see "you are here" and "here be dragons". Like on that example you linked there's a "warning" about tabindex that doesn't explain why you should never add one to a dialog - seems obvious to experienced frontend developers but it would leave juniors and people who might benefit most from such a warning scratching their heads or developing a cargo-cult mentality to certain things. I can envisage a content sweep of their warning / gotcha boxes would add more value than a design refresh.
Also generally since their content is constantly expanding, something that makes it easier to get your bearings in the existing content, adding more context cues etc, and quicker navigation between adjacent paradigms or some "maybe you meant this" suggestions that would be neat. I think that's what they were going for by elevating the "related content" on the left - but that's just showing a list of stuff on the same level as the current item. Why would I care about <summary> on a <dialog> page? If you use their search for "proxy" you might end up on a page talking about web proxies, or javascript proxy objects - disambiguation would be awesome for people who are trying to get their bearings.
(then again I usually just hit back, go to my google results, and pick the next page if it's not what I was looking for...)
The reduced contrast is not great, but I find the more compact layout pleasing.
The old one is very busy with color, borders and backgrounds occupying that white space, this is more in line with what you expect a reference book should look like, and will not tire you out after looking at it for hours.
It used to have a very unique custom look and now it looks a lot like a standard readthedocs type documentation for other projects. The reduced contrast of code blocks in particular is a step back.
the landing page is mostly useless to me, I need an extra click to get to reference and guides. It's like a status page used for home page, the search can be on the top-right corner of each reference|guide page instead. Yes just go directly to reference|guide, why not?
on reference and guide pages, I hope there is a left and right arrow at both sides of each content page so I don't need scroll all the way down to the bottom then click on that small prev and next button to turn pages.
158 comments
[ 6.0 ms ] story [ 248 ms ] threadSadly par for the course with modern web design.
It’s hard not to feel pessimistic about this one.
If they want to launch a paid newsletter/tutorials site with the same name, it doesn't really affect me much
Wait, this sounds like redesign for redesign's sake?
> Coming soon: MDN Plus [..] In the coming months, we’ll be expanding MDN to include a premium subscription service based on the feedback we received from web developers > Support MDN and make it your own. For just $5 a month.
Ah, this makes sense now. It looks like MDN is trying to rebrand and reposition itself as a subscription service going forward.
I remain optimistic, it's been a great resource over the years.
But redesign for "modernisation" sounds like doing it for the sake of it, unless people would benefit somehow from improved UX. Modernisation alone does not tell this however, I would expect slick awesome buttons, but some ugly, but important buttons gone.
It's not at all like that. I pay a one-time fee to BMW to get a seat warmer feature, they're not constantly improving or updating them in my car. They're in my car and they're on or off. If they break and I value them, I pay to have them fixed.
MDN is updated often and I it makes my job easier. It makes constantly evolving spec much more digestible. I'd sorely miss it if it were gone tomorrow. It's a service, not a one-off feature.
No, the idea was to have all the cars equipped with seat warmers, but the software in the car would only allow you to turn them on if you paid a subscription: https://www.businessinsider.com/bmw-subscription-model-for-f...
I haven't heard anything about it since, so I assume BMW eventually realized just how retarded the idea was.
(Yes, I walk every day, but this doesn't mean that I would welcome feet as a subscription service with the poor damned to crawling.)
Is it "redesign for redesign's sake" if even your quoted text states the reasons behind it? ("improved navigability and a universal look and feel across all our pages")
I've often gotten lost at MDN when trying to learn some topic that is new to me. I see on the sidebar of the pages covering aspects of that topic more on the same topic, and within the page links to other related things. I'll have followed some sequence of links through the directed graphs that the pages and links form, and then remember that somewhere on an earlier page there was a link to part of the topic I haven't yet read and then flail around in my history trying to find where I saw that link.
I'd like such sites to have available predefined sequences through the site designed to teach you particular topics. Have context sensitive next and previous and contents links on the page for moving back and forth in the sequence. Context sensitive so that if a page occurs in more than one sequence people get the appropriate navigation for the sequence they are on.
It does, indeed. It does also remind me of GitLab and their quest for finding the best navigation [1]. It was every few versions that the nav kept changing... from horizontal to vertical to fly out to top/side, etc. Looked like bikeshedding on the outside as it seemed to be easier to iterate over the design of the product rather than the actual product. Ultimately what their UX team settled on has been pretty stable for a while.
[1] https://about.gitlab.com/blog/2019/07/31/navigation-state-of...
First impression is good though! Looks clean.
One minor annoyance: The sidebar scroll behaves weird. I'm also not a huge fan of the big in your face custom scrollbars. I usually have them hidden, and the custom ones do not respect that, but that's preference.
Dark mode is absolutely great!
Much respect for taking on a big redesign like this. Especially considering the target audience, that takes guts haha.
I'm not optimistic at all about a subscription service for "web developers who want to customize their MDN experience" as an actual value add, as this seems negligible, but I am overall as 1. it's a step in the right direction for new ways to monetize Mozilla and 2. it sounds like they're listening to feedback and willing to iterate on it.
Some comments seem to be critical of any change. And while I don't like some of the visual changes, overall I think it's going in the right direction.
Most importantly, I want MDN to stay online and whatever they need to do (within reason of course) to keep it free, open, searchable and existing, I am on board with.
Update: I added custom styles to remove 95% of the extra margins, padding, spacing, line-height, updated h1/h2/h3/h4 header styling, code highlight styling, and it looks 10 times better, I can actually read the information. Unfortunately I still prefer the previous version
Question: Why do these important sites never get actual user feedback before forcing out a major update as a big "surprise" ?
The people behind the redesign do so for career, resume & portfolio reasons - they are very unlikely to ever use MDN themselves so they don't care and don't see the problem. You can't rely on user feedback because there's a very high risk users will tell you everything is fine and there's no need for you to mess with anything.
If anyone from MDN is reading these replies, could you make the old stylesheets open so that we can use extensions like Stylus to put things back?
I wouldn't be surprised if you told me that this was done with colorblind people in mind, I've seen many designers blur the line between accessibility and aspects of their design preferences they tell themselves are about accessibility.
But as far as I can tell all they've done is put a tick there if any version of the browser supports the feature.
That means I could have learned the same information from the old table just by looking at whether the cell had anything in it, with no version numbers "in my head" at all. So I'm feeling patronised rather than helped.
If they'd done a bit more work and made the ticks indicate something like "available in the oldest supported version of the browser" (which is a recent version for Firefox and Chrome but not for Safari), that might have justified what they wrote.
But.. THAT'S WHY I'M LOOKING AT THE FRACKING CHART!
Knowing if a feature was very recently supported or has been supported for a while is useful; now I'll need to drill down to see the information, and comparing that info across the browsers will be more difficult.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
* Randomly remove features from MDN
* See which ones people complain about most
* Reintroduce these as part of the new paid subscription
* Profit!
Upshot is that Firefox would upgrade, but forget my profile every time. That took months to sort out. Chrome simply won't update at all. Neither will Jetbrains tools, Docker desktop, you name it.
You can try to make everyone upgrade to the latest browser all you want, you're still going to have people running old versions. If you're running a free website, you are at your liberty to ignore those people. But somewhere between 5 and 7 figures a year there's a cutoff where you're going to do backward compatibility because the customer says so.
https://support.mozilla.org/en-US/kb/firefox-esr-release-cyc...
This is the chant of people who've set about forcing regressions on others. Usually it would just be more honest to say, "we don't care about what you want."
Why advertise a service without any details about what it actually is ?
On one hand 5$ is a nominal monthly amount to support MDN. But seriously, just ask for money. I'd be more inclined to help if they just wrote a post saying ' servers ain't free, give us money before this turns into w3schools '.
The servers certainly should be free. AWS, google cloud, Azure should be hosting MDN for free as part of their commitment they laid forth to support MDN.
Vague promises are one thing, donating enough to support full time employees at MDN is completely different.
Even if the servers are free, they’ll have other costs.
I wouldn't hold my breath here for any big company to step up and feel more Mozilla's coffers. That said, I'm open to buying some merch. As in I'll pay $50 for a sweatshirt
.recent-contributions .request-title { font-size: 1em; line-height: 1.4; }
https://blog.mozilla.org/en/mozilla/mozilla-brings-microsoft...
https://www.zdnet.com/article/developers-rejoice-microsoft-g...
https://opencollective.com/open-web-docs/updates/introducing...
Can't say for others, but Google has web.dev whose implied purpose is to be the sole source of truth for the web (even if a lot of it Chrome-only)
Again though, you bring up very good points. With Microsoft and Apple specifically EXPLICITLY throwing in the towel on maintaining documentation for this stuff and pointing people to MDN it boggles the mind how MDN needs money for hosting and subscriptions to fund special content.
Edit: https://news.ycombinator.com/item?id=27307059
1. Font weight (especially with headings) feels far too thin. 2. Seems like there are some color contrast issues when running in dark mode (my system theme)
... Why? I don't use MDN often, mostly just as reference material. I have enjoyed their documentation before, it's always been short and to the point with a few examples and it felt very complete. With this the first article I click on raises an odd question which I feel is either too much detail for reference or too little details for experts.
https://html.spec.whatwg.org/multipage/interactive-elements....
Really? I just wanna google for what I need and find it. I guess I'm not representative?
https://web.archive.org/web/20210302090607/https://developer...
to the new version:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
I notice that they:
- Reduced horizontal space allocated to content
- Reduced contrast (eg. code blocks have lighter gray background, compatibility table is no longer color coded)
- Increased the amount of things that don't render if you disable javascript
I'd reverse all three of those if I could.
On the good side they added a dark mode (which I don't care about but lots of people love dark mode), and they seem to have avoided the common aesthetics-over-effectiveness pitfall of adding tons of vertical whitespace.
(As an aside, I find it weird that they mention the home page in the article. In fact it's the first thing they mention. I would expect the home page to be effectively irrelevant? I only ever land on MDN via google searches and direct links to articles via stackoverflow answers. It's random-access reference material. How would someone end up on the homepage? Maybe they have analytics justifying that.)
Not an expert but this doesn’t seem like a bad thing to me as the contrast of the text with the background within the code blocks is increased, which I’d expect to be a good thing from an accessibility standpoint as I’d say it’s more important than code block contrast vs non-code blocks.
But overall I guess after thinking about what I did and didn't like about the design, nothing really stood out as a showstopper for me. I like the old design a lot more, but MDN has always been a reference and I dip into dozens of different references every week, getting used to design differences is par for the course. As long as they don't mess with the overall content hierarchy which is great as-is I'm not too impacted.
So my takeaway was if they invest the same energy into the content hierarchy on a page, I think that would add some value. Keep what they have, don't overstuff it, but just making it easier to see "you are here" and "here be dragons". Like on that example you linked there's a "warning" about tabindex that doesn't explain why you should never add one to a dialog - seems obvious to experienced frontend developers but it would leave juniors and people who might benefit most from such a warning scratching their heads or developing a cargo-cult mentality to certain things. I can envisage a content sweep of their warning / gotcha boxes would add more value than a design refresh.
Also generally since their content is constantly expanding, something that makes it easier to get your bearings in the existing content, adding more context cues etc, and quicker navigation between adjacent paradigms or some "maybe you meant this" suggestions that would be neat. I think that's what they were going for by elevating the "related content" on the left - but that's just showing a list of stuff on the same level as the current item. Why would I care about <summary> on a <dialog> page? If you use their search for "proxy" you might end up on a page talking about web proxies, or javascript proxy objects - disambiguation would be awesome for people who are trying to get their bearings.
(then again I usually just hit back, go to my google results, and pick the next page if it's not what I was looking for...)
The old one is very busy with color, borders and backgrounds occupying that white space, this is more in line with what you expect a reference book should look like, and will not tire you out after looking at it for hours.
the landing page is mostly useless to me, I need an extra click to get to reference and guides. It's like a status page used for home page, the search can be on the top-right corner of each reference|guide page instead. Yes just go directly to reference|guide, why not?
on reference and guide pages, I hope there is a left and right arrow at both sides of each content page so I don't need scroll all the way down to the bottom then click on that small prev and next button to turn pages.