Removed internal/outdated/speculative docs from requirements.md

docs/en/reference/requirements.md

@@ -124,63 +124,5 @@ In your controller's init() function, add:
 	:::php
 	Requirements::set_write_js_to_body(false);
 
-
-## CMS Requirements
-
-The SilverStripe core includes a lot of Requirements by itself. Most of these are collated in `[api:LeftAndMain]` first.
-
-## Motivation
-
-Every page requested is made up of a number of parts, and many of those parts require their own CSS or JavaScript.  
-Rather than force the developer to put all of those requests into the template, or the header function, you can
-reference required files anywhere in your application.
-
-This lets you create very modular units of PHP+JavaScript+CSS, which a powerful concept but must be managed carefully.  
-
-## Managing Generic CSS styling
-
-One of the aims of this is to create units of functionality that can be reasonably easily deployed as-is, while still
-giving developers the option to customise them.  The logical solution to this is to create 'generic' CSS to be applied
-to these things.  However, we must take great care to keep the CSS selectors very nonspecific.  This precludes us from
-adding any CSS that would "override customisations" in the form - for example, resetting the width of a field where 100%
-width isn't appropriate.
-
-Another solution would be to include some "generic CSS" for form elements at the very high level, so that fixed widths
-on forms were applied to the generic form, and could therefore be overridden by a field's generic stylesheet.  Similar
-to this is mandating the use of "form div.field input" to style form input tags, whether it's a generic form or a custom
-one.
-
-Perhaps we could make use of a Requirements::disallowCSS() function, with which we could prevent the standard CSS from
-being included in situations where it caused problems.  But the complexity could potentially balloon, and really, it's a
-bit of an admission of defeat - we shouldn't need to have to do this if our generic CSS was well-designed.
-
-
-## Ideas/Problems
-
-### Ajax
-
-The whole "include it when you need it" thing shows some weaknesses in areas such as the CMS, where Ajax is used to load
-in large pieces of the application, which potentially require more CSS and JavaScript to be included.  At this stage,
-the only workaround is to ensure that everything you might need is included on the first page-load.
-
-One idea is to mention the CSS and JavaScript which should be included in the header of the Ajax response, so that the
-client can load up those scripts and stylesheets upon completion of the Ajax request.  This could be coded quite
-cleanly, but for best results we'd want to extend prototype.js with our own changes to their Ajax system, so that every
-script had consistent support for this.
-
-### Lots of files
-
-Because everything's quite modular, it's easy to end up with a large number of small CSS and JavaScript files.  This has
-problems with download time, and potentially maintainability.
-
-We don't have any easy answers here, but here are some ideas:
-
-*  Merging the required files into a single download on the server.  The flip side of this is that if every page has a
-slightly different JS/CSS requirements, the whole lot will be refetched.
-*  Better: "Tagging" each required file for different use-cases, and creating a small set of common functionalities
-(e.g. everything tagged "base" such as prototype.js would always be included)
-*  Do lazy fetching of scripts within an ajax-call. This seems to be possible, but very tricky due to the asynchronous
-nature of an ajax-request. Needs some more research
-
 ## API Documentation
 `[api:Requirements]`