Add extensions additional tutorials links to learnsidebar #41242
Conversation
chrisdavidmills
requested review from
hamishwillee and
dipikabh
and removed request for
a team
github-actions
bot
added
Content:Learn
|
Would this fix #29240? |
| To summarize, when it comes to styling form control widgets, the side effects of styling them with CSS can be unpredictable. So don't. Even if it's still possible to do a few adjustments on text elements (such as sizing or font color), there are always side effects. The best approach remains to not style HTML Form widgets at all. But you can still apply styles to all the surrounding items. And, if you must alter the default styles of your form widgets, define a style guide to ensure consistency among all your form controls so user experience is not destroyed. You can also investigate some hard techniques such as [rebuilding widgets with JavaScript](/en-US/docs/Learn_web_development/Extensions/Forms/How_to_build_custom_form_controls). But in that case, do not hesitate to [charge your client for such foolishness](https://www.smashingmagazine.com/2011/11/but-the-client-wants-ie-6-support/). | ||
| As covered elsewhere, you can declare {{cssxref('appearance', 'appearance: none;')}} to remove the default styles and build your own on top with, but you need to make sure your new styles work in legacy browsers, if you need to support them. It might be better to just leave form controls unstyled in legacy browsers. | ||
|
|
||
| If you must alter the default styles of your form widgets in legacy browsers, define a style guide to ensure consistency among all your form controls so user experience is not destroyed. You could also investigate some hard techniques such as [rebuilding widgets with JavaScript](/en-US/docs/Learn_web_development/Extensions/Forms/How_to_build_custom_form_controls). But in that case, do not hesitate to [charge your client for such foolishness](https://www.smashingmagazine.com/2011/11/but-the-client-wants-ie-6-support/). |
There was a problem hiding this comment.
FWIW I'd be tempted to delete everything but the first sentence. The links are old, and so is the advice.
There was a problem hiding this comment.
Yeah, this article is a bit old and out of date, but rewriting these articles is not the purpose of this PR. Nevertheless, I have cut down this section a bit further to clear out more outdated content and remove the ancient link.
| The error level is an upper bound limit, where changes will have a negative and noticeable impact. | ||
|
|
||
| In order to begin, you need to first measure the devices and connection speeds where your users are coming from (e.g., A \~$_200_ Android device over a 3G connection), using multiple [tools](/en-US/docs/Learn_web_development/Extensions/Performance/Web_Performance_Basics). These time-based metrics will translate into file-size budgets. | ||
| In order to begin, you need to first measure the devices and connection speeds where your users are coming from (e.g., A \~$_200_ Android device over a 3G connection), using multiple [tools](/en-US/docs/Learn_web_development/Extensions/Performance/Resources). These time-based metrics will translate into file-size budgets. |
There was a problem hiding this comment.
| In order to begin, you need to first measure the devices and connection speeds where your users are coming from (e.g., A \~$_200_ Android device over a 3G connection), using multiple [tools](/en-US/docs/Learn_web_development/Extensions/Performance/Resources). These time-based metrics will translate into file-size budgets. | |
| The first step is to measure the devices and connection speeds where your users are coming from (e.g., A \~$_200_ Android device over a 3G connection), using multiple [tools](/en-US/docs/Learn_web_development/Extensions/Performance/Resources). These time-based metrics will translate into file-size budgets. |
files/en-us/web/performance/index.md
Outdated
| - [How do users perceive performance?](/en-US/docs/Learn_web_development/Extensions/Performance/Perceived_performance) | ||
| - : More important than how fast your website is in milliseconds, is how fast your users perceive your site to be. These perceptions are impacted by actual page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings. | ||
| - [Web performance basics](/en-US/docs/Learn_web_development/Extensions/Performance/Web_Performance_Basics) | ||
| - [Web performance basics](/en-US/docs/Learn_web_development/Extensions/Performance/Resources) |
There was a problem hiding this comment.
| - [Web performance basics](/en-US/docs/Learn_web_development/Extensions/Performance/Resources) | |
| - [Web performance resources](/en-US/docs/Learn_web_development/Extensions/Performance/Resources) |
There was a problem hiding this comment.
Updated. I've also replaced all of the beginner's links with the same DL as shown on the Learn web performance module.
| slug: Learn_web_development/Extensions/Performance/Resources | ||
| page-type: learn-module-chapter | ||
| sidebar: learnsidebar | ||
| --- |
There was a problem hiding this comment.
This page needs a thorough look at to check that the information is still correct.
It concerns me that in a page called "resources" there is no top level link to https://developer.mozilla.org/en-US/docs/Web/API/Performance or https://developer.mozilla.org/en-US/docs/Web/Performance
Don't love the intro - seems obvious why you might want performance
There are many reasons why your website should perform as well as possible.
Below is a quick review of best practices, tools, APIs with links to provide more information about each topic.
To
This topic provides a quick review of website performance best practices, tools, APIs with links to provide more information about each topic.
There was a problem hiding this comment.
Suggestion - I really don't feel like resources is the right title.
To me this feels mostly like "Best Practices Summary". So the first question is whether it is useful to have a Best practices summary, and if not delete. If it is useful, maybe rename.
There was a problem hiding this comment.
I don't personally think it is very useful. I am happy to just delete it if you agree.
| - /Learn_web_development/Extensions/Server-side/Apache_Configuration_htaccess | ||
| - /Learn_web_development/Extensions/Server-side/Configuring_server_MIME_types |
There was a problem hiding this comment.
These two could be under "server configuration". I'm OK with as you have done it.
| - /Learn_web_development/Extensions/Forms/UI_pseudo-classes | ||
| - /Learn_web_development/Extensions/Forms/Form_validation | ||
| - /Learn_web_development/Extensions/Forms/Sending_and_retrieving_form_data | ||
| - title: Additional_tutorials |
There was a problem hiding this comment.
I have no strong options other than:
- Have you checked that the docs are worth keeping at all?
- Why aren't they able to be in the main flow?
There was a problem hiding this comment.
Perhaps the other PR: #41196 could help answer these questions to some degree. We seem to agree that the docs have some value to be kept but don't really fit into the flow.
There was a problem hiding this comment.
Yeah, I already decided a long time ago that they don't really fit in the main flow. In terms of whether they are worth keeping, the legacy forms article and the web performance resources article probably aren't. I didn't really want to use this PR to start deleting things.
I think we can most likely get rid of the performance resources one, but I'd like to keep the forms one for now until we've had a chance to look at it in a bit more detail.
I guess 2023 Will didn't think so: #29240 (comment) I suppose the question is, do we think this page properly coheres with the rest of Learn/Performance, and does it have some sort of desirable and comprehensible relationship with https://developer.mozilla.org/en-US/docs/Web/Performance ? It's also a question about IA: why do we have Learn/Performance and Web/Performance, what are the criteria for putting stuff in one or the other, and how do they relate? |
I think you could ask the same for the guides section under HTML/JS/CSS and the language-specific learning docs. The answer seems to be they are just rehashes of the same stuff, with the non-learn docs being slightly more "formal" and in-depth. I usually think of the learning docs as being a separate website (think freeCodeCamp). If we aren't afraid to have duplicate content with W3School or freeCodeCamp, then we shouldn't be afraid to duplicate content between Learn/ and Web/. Of course that's a bit too extreme. |
FWIW I agree with this. They are a more tutorial-like guided path through the same information, with an audience that is more clearly a beginner and a style (IMO) that is annoyingly conversational. I have no problem with the rehash if it useful in the context of Learn module and not duplication within the module. But I don't think this performance doc is "resources", I think it it is "best practices". #41242 (comment) Ultimately though I don't want to answer any of the questions - I want @chrisdavidmills to :-) |
Yes, I do agree with that. The reason the IA is especially relevant here, as I said in the original issue report, is that it was moved from Web/Performance to Learn/Performance, but the nav and and content were not updated so as to integrate it into Learn. It seems like this PR updates the nav but doesn't address the content. Addressing the content means thinking of what sort of thing we want this page to be and what it means as a part of Learn - that is, to think about IA. Not addressing the content in this PR is fine too! But if you ask me, does it fix the issue I raised where I say that the content is part of the issue, I'm going to say no. |
Yeah, fixing a load of content was never in the remit of this PR. |
Gee, thanks ;-) There were very clear reasons for wanting to have beginner's content on MDN when we started it way back in about 2015, and I don't think these have changed. Over time, the Learn content became too bloated and too complex for beginners, which is one reason why I am trying to update the content and bring it back to basics again. I'd personally be happy to get rid of some of the extension modules out of the learn area. But again, that's a conversation for a different PR. |
Description
There are still several Learn articles not linked from the learnsidebar. The ones we want to keep should really be linked in some way. This PR adds an "Additional tutorials" subsection at the end of the extension modules to contain the additional tutorials.
In one case (performance), I didn't add it into "Additional tutorials"; I just moved the article so that the slug made more sense, and then added it into the main flow of that module.
In one case (forms), I edited an article to make it a) more useful and b) actually make sense in the context of earlier forms articles in the same module (we don't want to cover all those CSS techniques only to then say "don't style form elements" in a later article).
Motivation
Additional details
Related issues and pull requests