diff --git a/docs/community/funding.md b/docs/community/funding.md
index 951833682..10e09bf71 100644
--- a/docs/community/funding.md
+++ b/docs/community/funding.md
@@ -1,398 +1,398 @@
-
-
-
-
-# Funding
-
-If you use REST framework commercially we strongly encourage you to invest in its continued development by signing up for a paid plan.
-
-**We believe that collaboratively funded software can offer outstanding returns on investment, by encouraging our users to collectively share the cost of development.**
-
-Signing up for a paid plan will:
-
-* Directly contribute to faster releases, more features, and higher quality software.
-* Allow more time to be invested in documentation, issue triage, and community support.
-* Safeguard the future development of REST framework.
-
-REST framework continues to be open-source and permissively licensed, but we firmly believe it is in the commercial best-interest for users of the project to invest in its ongoing development.
-
----
-
-## What funding has enabled so far
-
-* The [3.4](https://www.django-rest-framework.org/community/3.4-announcement/) and [3.5](https://www.django-rest-framework.org/community/3.5-announcement/) releases, including schema generation for both Swagger and RAML, a Python client library, a Command Line client, and addressing of a large number of outstanding issues.
-* The [3.6](https://www.django-rest-framework.org/community/3.6-announcement/) release, including JavaScript client library, and API documentation, complete with auto-generated code samples.
-* The [3.7 release](https://www.django-rest-framework.org/community/3.7-announcement/), made possible due to our collaborative funding model, focuses on improvements to schema generation and the interactive API documentation.
-* The recent [3.8 release](https://www.django-rest-framework.org/community/3.8-announcement/).
-* Tom Christie, the creator of Django REST framework, working on the project full-time.
-* Around 80-90 issues and pull requests closed per month since Tom Christie started working on the project full-time.
-* A community & operations manager position part-time for 4 months, helping mature the business and grow sponsorship.
-* Contracting development time for the work on the JavaScript client library and API documentation tooling.
-
----
-
-## What future funding will enable
-
-* Realtime API support, using WebSockets. This will consist of documentation and support for using REST framework together with Django Channels, plus integrating WebSocket support into the client libraries.
-* Better authentication defaults, possibly bringing JWT & CORS support into the core package.
-* Securing the community & operations manager position long-term.
-* Opening up and securing a part-time position to focus on ticket triage and resolution.
-* Paying for development time on building API client libraries in a range of programming languages. These would be integrated directly into the upcoming API documentation.
-
-Sign up for a paid plan today, and help ensure that REST framework becomes a sustainable, full-time funded project.
-
----
-
-## What our sponsors and users say
-
-> As a developer, Django REST framework feels like an obvious and natural extension to all the great things that make up Django and it's community. Getting started is easy while providing simple abstractions which makes it flexible and customizable. Contributing and supporting Django REST framework helps ensure its future and one way or another it also helps Django, and the Python ecosystem.
->
-> — José Padilla, Django REST framework contributor
-
-
-
-> The number one feature of the Python programming language is its community. Such a community is only possible because of the Open Source nature of the language and all the culture that comes from it. Building great Open Source projects require great minds. Given that, we at Vinta are not only proud to sponsor the team behind DRF but we also recognize the ROI that comes from it.
->
-> — Filipe Ximenes, Vinta Software
-
-
-
-> It's really awesome that this project continues to endure. The code base is top notch and the maintainers are committed to the highest level of quality.
-DRF is one of the core reasons why Django is top choice among web frameworks today. In my opinion, it sets the standard for rest frameworks for the development community at large.
->
-> — Andrew Conti, Django REST framework user
-
----
-
-## Individual plan
-
-This subscription is recommended for individuals with an interest in seeing REST framework continue to improve.
-
-If you are using REST framework as a full-time employee, consider recommending that your company takes out a [corporate plan](#corporate-plans).
-
-
-
-
-
- {{ symbol }}
- {{ rates.personal1 }}
- /month{% if vat %} +VAT{% endif %}
-
-
Individual
-
-
- Support ongoing development
-
-
- Credited on the site
-
-
-
-
-
-
-
-
-*Billing is monthly and you can cancel at any time.*
-
----
-
-## Corporate plans
-
-These subscriptions are recommended for companies and organizations using REST framework either publicly or privately.
-
-In exchange for funding you'll also receive advertising space on our site, allowing you to **promote your company or product to many tens of thousands of developers worldwide**.
-
-Our professional and premium plans also include **priority support**. At any time your engineers can escalate an issue or discussion group thread, and we'll ensure it gets a guaranteed response within the next working day.
-
-
-
-
-
- {{ symbol }}
- {{ rates.corporate1 }}
- /month{% if vat %} +VAT{% endif %}
-
-
Basic
-
-
- Support ongoing development
-
-
- Funding page ad placement
-
-
-
-
-
-
-
-
- {{ symbol }}
- {{ rates.corporate2 }}
- /month{% if vat %} +VAT{% endif %}
-
-
Professional
-
-
- Support ongoing development
-
-
- Sidebar ad placement
-
-
- Priority support for your engineers
-
-
-
-
-
-
-
-
- {{ symbol }}
- {{ rates.corporate3 }}
- /month{% if vat %} +VAT{% endif %}
-
-
Premium
-
-
- Support ongoing development
-
-
- Homepage ad placement
-
-
- Sidebar ad placement
-
-
- Priority support for your engineers
-
-
-
-
-
-
-
-
-
-*Billing is monthly and you can cancel at any time.*
-
-Once you've signed up, we will contact you via email and arrange your ad placements on the site.
-
-For further enquires please contact funding@django-rest-framework.org.
-
----
-
-## Accountability
-
-In an effort to keep the project as transparent as possible, we are releasing [monthly progress reports](https://www.encode.io/reports/march-2018/) and regularly include financial reports and cost breakdowns.
-
-
-
-
-
-
-
-
-
-
----
-
-## Frequently asked questions
-
-**Q: Can you issue monthly invoices?**
-A: Yes, we are happy to issue monthly invoices. Please just email us and let us know who to issue the invoice to (name and address) and which email address to send it to each month.
-
-**Q: Does sponsorship include VAT?**
-A: Sponsorship is VAT exempt.
-
-**Q: Do I have to sign up for a certain time period?**
-A: No, we appreciate your support for any time period that is convenient for you. Also, you can cancel your sponsorship anytime.
-
-**Q: Can I pay yearly? Can I pay upfront fox X amount of months at a time?**
-A: We are currently only set up to accept monthly payments. However, if you'd like to support Django REST framework and you can only do yearly/upfront payments, we are happy to work with you and figure out a convenient solution.
-
-**Q: Are you only looking for corporate sponsors?**
-A: No, we value individual sponsors just as much as corporate sponsors and appreciate any kind of support.
-
----
-
-## Our sponsors
-
-
-
-
+
+
+
+
+# Funding
+
+If you use REST framework commercially we strongly encourage you to invest in its continued development by signing up for a paid plan.
+
+**We believe that collaboratively funded software can offer outstanding returns on investment, by encouraging our users to collectively share the cost of development.**
+
+Signing up for a paid plan will:
+
+* Directly contribute to faster releases, more features, and higher quality software.
+* Allow more time to be invested in documentation, issue triage, and community support.
+* Safeguard the future development of REST framework.
+
+REST framework continues to be open-source and permissively licensed, but we firmly believe it is in the commercial best-interest for users of the project to invest in its ongoing development.
+
+---
+
+## What funding has enabled so far
+
+* The [3.4](https://www.django-rest-framework.org/community/3.4-announcement/) and [3.5](https://www.django-rest-framework.org/community/3.5-announcement/) releases, including schema generation for both Swagger and RAML, a Python client library, a Command Line client, and addressing of a large number of outstanding issues.
+* The [3.6](https://www.django-rest-framework.org/community/3.6-announcement/) release, including JavaScript client library, and API documentation, complete with auto-generated code samples.
+* The [3.7 release](https://www.django-rest-framework.org/community/3.7-announcement/), made possible due to our collaborative funding model, focuses on improvements to schema generation and the interactive API documentation.
+* The recent [3.8 release](https://www.django-rest-framework.org/community/3.8-announcement/).
+* Tom Christie, the creator of Django REST framework, working on the project full-time.
+* Around 80-90 issues and pull requests closed per month since Tom Christie started working on the project full-time.
+* A community & operations manager position part-time for 4 months, helping mature the business and grow sponsorship.
+* Contracting development time for the work on the JavaScript client library and API documentation tooling.
+
+---
+
+## What future funding will enable
+
+* Realtime API support, using WebSockets. This will consist of documentation and support for using REST framework together with Django Channels, plus integrating WebSocket support into the client libraries.
+* Better authentication defaults, possibly bringing JWT & CORS support into the core package.
+* Securing the community & operations manager position long-term.
+* Opening up and securing a part-time position to focus on ticket triage and resolution.
+* Paying for development time on building API client libraries in a range of programming languages. These would be integrated directly into the upcoming API documentation.
+
+Sign up for a paid plan today, and help ensure that REST framework becomes a sustainable, full-time funded project.
+
+---
+
+## What our sponsors and users say
+
+> As a developer, Django REST framework feels like an obvious and natural extension to all the great things that make up Django and it's community. Getting started is easy while providing simple abstractions which makes it flexible and customizable. Contributing and supporting Django REST framework helps ensure its future and one way or another it also helps Django, and the Python ecosystem.
+>
+> — José Padilla, Django REST framework contributor
+
+
+
+> The number one feature of the Python programming language is its community. Such a community is only possible because of the Open Source nature of the language and all the culture that comes from it. Building great Open Source projects require great minds. Given that, we at Vinta are not only proud to sponsor the team behind DRF but we also recognize the ROI that comes from it.
+>
+> — Filipe Ximenes, Vinta Software
+
+
+
+> It's really awesome that this project continues to endure. The code base is top notch and the maintainers are committed to the highest level of quality.
+DRF is one of the core reasons why Django is top choice among web frameworks today. In my opinion, it sets the standard for rest frameworks for the development community at large.
+>
+> — Andrew Conti, Django REST framework user
+
+---
+
+## Individual plan
+
+This subscription is recommended for individuals with an interest in seeing REST framework continue to improve.
+
+If you are using REST framework as a full-time employee, consider recommending that your company takes out a [corporate plan](#corporate-plans).
+
+
+
+
+
+ {{ symbol }}
+ {{ rates.personal1 }}
+ /month{% if vat %} +VAT{% endif %}
+
+
Individual
+
+
+ Support ongoing development
+
+
+ Credited on the site
+
+
+
+
+
+
+
+
+*Billing is monthly and you can cancel at any time.*
+
+---
+
+## Corporate plans
+
+These subscriptions are recommended for companies and organizations using REST framework either publicly or privately.
+
+In exchange for funding you'll also receive advertising space on our site, allowing you to **promote your company or product to many tens of thousands of developers worldwide**.
+
+Our professional and premium plans also include **priority support**. At any time your engineers can escalate an issue or discussion group thread, and we'll ensure it gets a guaranteed response within the next working day.
+
+
+
+
+
+ {{ symbol }}
+ {{ rates.corporate1 }}
+ /month{% if vat %} +VAT{% endif %}
+
+
Basic
+
+
+ Support ongoing development
+
+
+ Funding page ad placement
+
+
+
+
+
+
+
+
+ {{ symbol }}
+ {{ rates.corporate2 }}
+ /month{% if vat %} +VAT{% endif %}
+
+
Professional
+
+
+ Support ongoing development
+
+
+ Sidebar ad placement
+
+
+ Priority support for your engineers
+
+
+
+
+
+
+
+
+ {{ symbol }}
+ {{ rates.corporate3 }}
+ /month{% if vat %} +VAT{% endif %}
+
+
Premium
+
+
+ Support ongoing development
+
+
+ Homepage ad placement
+
+
+ Sidebar ad placement
+
+
+ Priority support for your engineers
+
+
+
+
+
+
+
+
+
+*Billing is monthly and you can cancel at any time.*
+
+Once you've signed up, we will contact you via email and arrange your ad placements on the site.
+
+For further enquires please contact funding@django-rest-framework.org.
+
+---
+
+## Accountability
+
+In an effort to keep the project as transparent as possible, we are releasing [monthly progress reports](https://www.encode.io/reports/march-2018/) and regularly include financial reports and cost breakdowns.
+
+
+
+
+
+
+
+
+
+
+---
+
+## Frequently asked questions
+
+**Q: Can you issue monthly invoices?**
+A: Yes, we are happy to issue monthly invoices. Please just email us and let us know who to issue the invoice to (name and address) and which email address to send it to each month.
+
+**Q: Does sponsorship include VAT?**
+A: Sponsorship is VAT exempt.
+
+**Q: Do I have to sign up for a certain time period?**
+A: No, we appreciate your support for any time period that is convenient for you. Also, you can cancel your sponsorship anytime.
+
+**Q: Can I pay yearly? Can I pay upfront fox X amount of months at a time?**
+A: We are currently only set up to accept monthly payments. However, if you'd like to support Django REST framework and you can only do yearly/upfront payments, we are happy to work with you and figure out a convenient solution.
+
+**Q: Are you only looking for corporate sponsors?**
+A: No, we value individual sponsors just as much as corporate sponsors and appreciate any kind of support.
+
+---
+
+## Our sponsors
+
+
+
+
diff --git a/docs/topics/html-and-forms.md b/docs/topics/html-and-forms.md
index 17c9e3314..c7e51c152 100644
--- a/docs/topics/html-and-forms.md
+++ b/docs/topics/html-and-forms.md
@@ -1,220 +1,220 @@
-# HTML & Forms
-
-REST framework is suitable for returning both API style responses, and regular HTML pages. Additionally, serializers can be used as HTML forms and rendered in templates.
-
-## Rendering HTML
-
-In order to return HTML responses you'll need to use either `TemplateHTMLRenderer`, or `StaticHTMLRenderer`.
-
-The `TemplateHTMLRenderer` class expects the response to contain a dictionary of context data, and renders an HTML page based on a template that must be specified either in the view or on the response.
-
-The `StaticHTMLRender` class expects the response to contain a string of the pre-rendered HTML content.
-
-Because static HTML pages typically have different behavior from API responses you'll probably need to write any HTML views explicitly, rather than relying on the built-in generic views.
-
-Here's an example of a view that returns a list of "Profile" instances, rendered in an HTML template:
-
-**views.py**:
-
- from my_project.example.models import Profile
- from rest_framework.renderers import TemplateHTMLRenderer
- from rest_framework.response import Response
- from rest_framework.views import APIView
-
-
- class ProfileList(APIView):
- renderer_classes = [TemplateHTMLRenderer]
- template_name = 'profile_list.html'
-
- def get(self, request):
- queryset = Profile.objects.all()
- return Response({'profiles': queryset})
-
-**profile_list.html**:
-
-
-
Profiles
-
- {% for profile in profiles %}
-
{{ profile.name }}
- {% endfor %}
-
-
-
-## Rendering Forms
-
-Serializers may be rendered as forms by using the `render_form` template tag, and including the serializer instance as context to the template.
-
-The following view demonstrates an example of using a serializer in a template for viewing and updating a model instance:
-
-**views.py**:
-
- from django.shortcuts import get_object_or_404
- from my_project.example.models import Profile
- from rest_framework.renderers import TemplateHTMLRenderer
- from rest_framework.views import APIView
-
-
- class ProfileDetail(APIView):
- renderer_classes = [TemplateHTMLRenderer]
- template_name = 'profile_detail.html'
-
- def get(self, request, pk):
- profile = get_object_or_404(Profile, pk=pk)
- serializer = ProfileSerializer(profile)
- return Response({'serializer': serializer, 'profile': profile})
-
- def post(self, request, pk):
- profile = get_object_or_404(Profile, pk=pk)
- serializer = ProfileSerializer(profile, data=request.data)
- if not serializer.is_valid():
- return Response({'serializer': serializer, 'profile': profile})
- serializer.save()
- return redirect('profile-list')
-
-**profile_detail.html**:
-
- {% load rest_framework %}
-
-
-
-
Profile - {{ profile.name }}
-
-
-
-
-
-### Using template packs
-
-The `render_form` tag takes an optional `template_pack` argument, that specifies which template directory should be used for rendering the form and form fields.
-
-REST framework includes three built-in template packs, all based on Bootstrap 3. The built-in styles are `horizontal`, `vertical`, and `inline`. The default style is `horizontal`. To use any of these template packs you'll want to also include the Bootstrap 3 CSS.
-
-The following HTML will link to a CDN hosted version of the Bootstrap 3 CSS:
-
-
- …
-
-
-
-Third party packages may include alternate template packs, by bundling a template directory containing the necessary form and field templates.
-
-Let's take a look at how to render each of the three available template packs. For these examples we'll use a single serializer class to present a "Login" form.
-
- class LoginSerializer(serializers.Serializer):
- email = serializers.EmailField(
- max_length=100,
- style={'placeholder': 'Email', 'autofocus': True}
- )
- password = serializers.CharField(
- max_length=100,
- style={'input_type': 'password', 'placeholder': 'Password'}
- )
- remember_me = serializers.BooleanField()
-
----
-
-#### `rest_framework/vertical`
-
-Presents form labels above their corresponding control inputs, using the standard Bootstrap layout.
-
-*This is the default template pack.*
-
- {% load rest_framework %}
-
- ...
-
-
-
-
-
----
-
-#### `rest_framework/horizontal`
-
-Presents labels and controls alongside each other, using a 2/10 column split.
-
-*This is the form style used in the browsable API and admin renderers.*
-
- {% load rest_framework %}
-
- ...
-
-
-
-
-
----
-
-#### `rest_framework/inline`
-
-A compact form style that presents all the controls inline.
-
- {% load rest_framework %}
-
- ...
-
-
-
-
-
-## Field styles
-
-Serializer fields can have their rendering style customized by using the `style` keyword argument. This argument is a dictionary of options that control the template and layout used.
-
-The most common way to customize the field style is to use the `base_template` style keyword argument to select which template in the template pack should be use.
-
-For example, to render a `CharField` as an HTML textarea rather than the default HTML input, you would use something like this:
-
- details = serializers.CharField(
- max_length=1000,
- style={'base_template': 'textarea.html'}
- )
-
-If you instead want a field to be rendered using a custom template that is *not part of an included template pack*, you can instead use the `template` style option, to fully specify a template name:
-
- details = serializers.CharField(
- max_length=1000,
- style={'template': 'my-field-templates/custom-input.html'}
- )
-
-Field templates can also use additional style properties, depending on their type. For example, the `textarea.html` template also accepts a `rows` property that can be used to affect the sizing of the control.
-
- details = serializers.CharField(
- max_length=1000,
- style={'base_template': 'textarea.html', 'rows': 10}
- )
-
-The complete list of `base_template` options and their associated style options is listed below.
-
-base_template | Valid field types | Additional style options
------------------------|-------------------------------------------------------------|-----------------------------------------------
-input.html | Any string, numeric or date/time field | input_type, placeholder, hide_label, autofocus
-textarea.html | `CharField` | rows, placeholder, hide_label
-select.html | `ChoiceField` or relational field types | hide_label
-radio.html | `ChoiceField` or relational field types | inline, hide_label
-select_multiple.html | `MultipleChoiceField` or relational fields with `many=True` | hide_label
-checkbox_multiple.html | `MultipleChoiceField` or relational fields with `many=True` | inline, hide_label
-checkbox.html | `BooleanField` | hide_label
-fieldset.html | Nested serializer | hide_label
-list_fieldset.html | `ListField` or nested serializer with `many=True` | hide_label
+# HTML & Forms
+
+REST framework is suitable for returning both API style responses, and regular HTML pages. Additionally, serializers can be used as HTML forms and rendered in templates.
+
+## Rendering HTML
+
+In order to return HTML responses you'll need to use either `TemplateHTMLRenderer`, or `StaticHTMLRenderer`.
+
+The `TemplateHTMLRenderer` class expects the response to contain a dictionary of context data, and renders an HTML page based on a template that must be specified either in the view or on the response.
+
+The `StaticHTMLRender` class expects the response to contain a string of the pre-rendered HTML content.
+
+Because static HTML pages typically have different behavior from API responses you'll probably need to write any HTML views explicitly, rather than relying on the built-in generic views.
+
+Here's an example of a view that returns a list of "Profile" instances, rendered in an HTML template:
+
+**views.py**:
+
+ from my_project.example.models import Profile
+ from rest_framework.renderers import TemplateHTMLRenderer
+ from rest_framework.response import Response
+ from rest_framework.views import APIView
+
+
+ class ProfileList(APIView):
+ renderer_classes = [TemplateHTMLRenderer]
+ template_name = 'profile_list.html'
+
+ def get(self, request):
+ queryset = Profile.objects.all()
+ return Response({'profiles': queryset})
+
+**profile_list.html**:
+
+
+
Profiles
+
+ {% for profile in profiles %}
+
{{ profile.name }}
+ {% endfor %}
+
+
+
+## Rendering Forms
+
+Serializers may be rendered as forms by using the `render_form` template tag, and including the serializer instance as context to the template.
+
+The following view demonstrates an example of using a serializer in a template for viewing and updating a model instance:
+
+**views.py**:
+
+ from django.shortcuts import get_object_or_404
+ from my_project.example.models import Profile
+ from rest_framework.renderers import TemplateHTMLRenderer
+ from rest_framework.views import APIView
+
+
+ class ProfileDetail(APIView):
+ renderer_classes = [TemplateHTMLRenderer]
+ template_name = 'profile_detail.html'
+
+ def get(self, request, pk):
+ profile = get_object_or_404(Profile, pk=pk)
+ serializer = ProfileSerializer(profile)
+ return Response({'serializer': serializer, 'profile': profile})
+
+ def post(self, request, pk):
+ profile = get_object_or_404(Profile, pk=pk)
+ serializer = ProfileSerializer(profile, data=request.data)
+ if not serializer.is_valid():
+ return Response({'serializer': serializer, 'profile': profile})
+ serializer.save()
+ return redirect('profile-list')
+
+**profile_detail.html**:
+
+ {% load rest_framework %}
+
+
+
+
Profile - {{ profile.name }}
+
+
+
+
+
+### Using template packs
+
+The `render_form` tag takes an optional `template_pack` argument, that specifies which template directory should be used for rendering the form and form fields.
+
+REST framework includes three built-in template packs, all based on Bootstrap 3. The built-in styles are `horizontal`, `vertical`, and `inline`. The default style is `horizontal`. To use any of these template packs you'll want to also include the Bootstrap 3 CSS.
+
+The following HTML will link to a CDN hosted version of the Bootstrap 3 CSS:
+
+
+ …
+
+
+
+Third party packages may include alternate template packs, by bundling a template directory containing the necessary form and field templates.
+
+Let's take a look at how to render each of the three available template packs. For these examples we'll use a single serializer class to present a "Login" form.
+
+ class LoginSerializer(serializers.Serializer):
+ email = serializers.EmailField(
+ max_length=100,
+ style={'placeholder': 'Email', 'autofocus': True}
+ )
+ password = serializers.CharField(
+ max_length=100,
+ style={'input_type': 'password', 'placeholder': 'Password'}
+ )
+ remember_me = serializers.BooleanField()
+
+---
+
+#### `rest_framework/vertical`
+
+Presents form labels above their corresponding control inputs, using the standard Bootstrap layout.
+
+*This is the default template pack.*
+
+ {% load rest_framework %}
+
+ ...
+
+
+
+
+
+---
+
+#### `rest_framework/horizontal`
+
+Presents labels and controls alongside each other, using a 2/10 column split.
+
+*This is the form style used in the browsable API and admin renderers.*
+
+ {% load rest_framework %}
+
+ ...
+
+
+
+
+
+---
+
+#### `rest_framework/inline`
+
+A compact form style that presents all the controls inline.
+
+ {% load rest_framework %}
+
+ ...
+
+
+
+
+
+## Field styles
+
+Serializer fields can have their rendering style customized by using the `style` keyword argument. This argument is a dictionary of options that control the template and layout used.
+
+The most common way to customize the field style is to use the `base_template` style keyword argument to select which template in the template pack should be use.
+
+For example, to render a `CharField` as an HTML textarea rather than the default HTML input, you would use something like this:
+
+ details = serializers.CharField(
+ max_length=1000,
+ style={'base_template': 'textarea.html'}
+ )
+
+If you instead want a field to be rendered using a custom template that is *not part of an included template pack*, you can instead use the `template` style option, to fully specify a template name:
+
+ details = serializers.CharField(
+ max_length=1000,
+ style={'template': 'my-field-templates/custom-input.html'}
+ )
+
+Field templates can also use additional style properties, depending on their type. For example, the `textarea.html` template also accepts a `rows` property that can be used to affect the sizing of the control.
+
+ details = serializers.CharField(
+ max_length=1000,
+ style={'base_template': 'textarea.html', 'rows': 10}
+ )
+
+The complete list of `base_template` options and their associated style options is listed below.
+
+base_template | Valid field types | Additional style options
+-----------------------|-------------------------------------------------------------|-----------------------------------------------
+input.html | Any string, numeric or date/time field | input_type, placeholder, hide_label, autofocus
+textarea.html | `CharField` | rows, placeholder, hide_label
+select.html | `ChoiceField` or relational field types | hide_label
+radio.html | `ChoiceField` or relational field types | inline, hide_label
+select_multiple.html | `MultipleChoiceField` or relational fields with `many=True` | hide_label
+checkbox_multiple.html | `MultipleChoiceField` or relational fields with `many=True` | inline, hide_label
+checkbox.html | `BooleanField` | hide_label
+fieldset.html | Nested serializer | hide_label
+list_fieldset.html | `ListField` or nested serializer with `many=True` | hide_label
diff --git a/tests/test_description.py b/tests/test_description.py
index 93539a838..7fb93ed4e 100644
--- a/tests/test_description.py
+++ b/tests/test_description.py
@@ -1,155 +1,155 @@
-import pytest
-from django.test import TestCase
-
-from rest_framework.compat import apply_markdown
-from rest_framework.utils.formatting import dedent
-from rest_framework.views import APIView
-
-# We check that docstrings get nicely un-indented.
-DESCRIPTION = """an example docstring
-====================
-
-* list
-* list
-
-another header
---------------
-
- code block
-
-indented
-
-# hash style header #
-
-```json
-[{
- "alpha": 1,
- "beta": "this is a string"
-}]
-```"""
-
-
-# If markdown is installed we also test it's working
-# (and that our wrapped forces '=' to h2 and '-' to h3)
-MARKDOWN_DOCSTRING = """
an example docstring
-
-
list
-
list
-
-
another header
-
code block
-
-
indented
-
hash style header
-
[{ "alpha":1, "beta":"this is a string" }]
-
"""
-
-
-class TestViewNamesAndDescriptions(TestCase):
- def test_view_name_uses_class_name(self):
- """
- Ensure view names are based on the class name.
- """
- class MockView(APIView):
- pass
- assert MockView().get_view_name() == 'Mock'
-
- def test_view_name_uses_name_attribute(self):
- class MockView(APIView):
- name = 'Foo'
- assert MockView().get_view_name() == 'Foo'
-
- def test_view_name_uses_suffix_attribute(self):
- class MockView(APIView):
- suffix = 'List'
- assert MockView().get_view_name() == 'Mock List'
-
- def test_view_name_preferences_name_over_suffix(self):
- class MockView(APIView):
- name = 'Foo'
- suffix = 'List'
- assert MockView().get_view_name() == 'Foo'
-
- def test_view_description_uses_docstring(self):
- """Ensure view descriptions are based on the docstring."""
- class MockView(APIView):
- """an example docstring
- ====================
-
- * list
- * list
-
- another header
- --------------
-
- code block
-
- indented
-
- # hash style header #
-
- ```json
- [{
- "alpha": 1,
- "beta": "this is a string"
- }]
- ```"""
-
- assert MockView().get_view_description() == DESCRIPTION
-
- def test_view_description_uses_description_attribute(self):
- class MockView(APIView):
- description = 'Foo'
- assert MockView().get_view_description() == 'Foo'
-
- def test_view_description_allows_empty_description(self):
- class MockView(APIView):
- """Description."""
- description = ''
- assert MockView().get_view_description() == ''
-
- def test_view_description_can_be_empty(self):
- """
- Ensure that if a view has no docstring,
- then it's description is the empty string.
- """
- class MockView(APIView):
- pass
- assert MockView().get_view_description() == ''
-
- def test_view_description_can_be_promise(self):
- """
- Ensure a view may have a docstring that is actually a lazily evaluated
- class that can be converted to a string.
-
- See: https://github.com/encode/django-rest-framework/issues/1708
- """
- # use a mock object instead of gettext_lazy to ensure that we can't end
- # up with a test case string in our l10n catalog
-
- class MockLazyStr:
- def __init__(self, string):
- self.s = string
-
- def __str__(self):
- return self.s
-
- class MockView(APIView):
- __doc__ = MockLazyStr("a gettext string")
-
- assert MockView().get_view_description() == 'a gettext string'
-
- @pytest.mark.skipif(not apply_markdown, reason="Markdown is not installed")
- def test_markdown(self):
- """
- Ensure markdown to HTML works as expected.
- """
- assert apply_markdown(DESCRIPTION) == MARKDOWN_DOCSTRING
-
-
-def test_dedent_tabs():
- result = 'first string\n\nsecond string'
- assert dedent(" first string\n\n second string") == result
- assert dedent("first string\n\n second string") == result
- assert dedent("\tfirst string\n\n\tsecond string") == result
- assert dedent("first string\n\n\tsecond string") == result
+import pytest
+from django.test import TestCase
+
+from rest_framework.compat import apply_markdown
+from rest_framework.utils.formatting import dedent
+from rest_framework.views import APIView
+
+# We check that docstrings get nicely un-indented.
+DESCRIPTION = """an example docstring
+====================
+
+* list
+* list
+
+another header
+--------------
+
+ code block
+
+indented
+
+# hash style header #
+
+```json
+[{
+ "alpha": 1,
+ "beta": "this is a string"
+}]
+```"""
+
+
+# If markdown is installed we also test it's working
+# (and that our wrapped forces '=' to h2 and '-' to h3)
+MARKDOWN_DOCSTRING = """
an example docstring
+
+
list
+
list
+
+
another header
+
code block
+
+
indented
+
hash style header
+
[{ "alpha":1, "beta":"this is a string" }]
+
"""
+
+
+class TestViewNamesAndDescriptions(TestCase):
+ def test_view_name_uses_class_name(self):
+ """
+ Ensure view names are based on the class name.
+ """
+ class MockView(APIView):
+ pass
+ assert MockView().get_view_name() == 'Mock'
+
+ def test_view_name_uses_name_attribute(self):
+ class MockView(APIView):
+ name = 'Foo'
+ assert MockView().get_view_name() == 'Foo'
+
+ def test_view_name_uses_suffix_attribute(self):
+ class MockView(APIView):
+ suffix = 'List'
+ assert MockView().get_view_name() == 'Mock List'
+
+ def test_view_name_preferences_name_over_suffix(self):
+ class MockView(APIView):
+ name = 'Foo'
+ suffix = 'List'
+ assert MockView().get_view_name() == 'Foo'
+
+ def test_view_description_uses_docstring(self):
+ """Ensure view descriptions are based on the docstring."""
+ class MockView(APIView):
+ """an example docstring
+ ====================
+
+ * list
+ * list
+
+ another header
+ --------------
+
+ code block
+
+ indented
+
+ # hash style header #
+
+ ```json
+ [{
+ "alpha": 1,
+ "beta": "this is a string"
+ }]
+ ```"""
+
+ assert MockView().get_view_description() == DESCRIPTION
+
+ def test_view_description_uses_description_attribute(self):
+ class MockView(APIView):
+ description = 'Foo'
+ assert MockView().get_view_description() == 'Foo'
+
+ def test_view_description_allows_empty_description(self):
+ class MockView(APIView):
+ """Description."""
+ description = ''
+ assert MockView().get_view_description() == ''
+
+ def test_view_description_can_be_empty(self):
+ """
+ Ensure that if a view has no docstring,
+ then it's description is the empty string.
+ """
+ class MockView(APIView):
+ pass
+ assert MockView().get_view_description() == ''
+
+ def test_view_description_can_be_promise(self):
+ """
+ Ensure a view may have a docstring that is actually a lazily evaluated
+ class that can be converted to a string.
+
+ See: https://github.com/encode/django-rest-framework/issues/1708
+ """
+ # use a mock object instead of gettext_lazy to ensure that we can't end
+ # up with a test case string in our l10n catalog
+
+ class MockLazyStr:
+ def __init__(self, string):
+ self.s = string
+
+ def __str__(self):
+ return self.s
+
+ class MockView(APIView):
+ __doc__ = MockLazyStr("a gettext string")
+
+ assert MockView().get_view_description() == 'a gettext string'
+
+ @pytest.mark.skipif(not apply_markdown, reason="Markdown is not installed")
+ def test_markdown(self):
+ """
+ Ensure markdown to HTML works as expected.
+ """
+ assert apply_markdown(DESCRIPTION) == MARKDOWN_DOCSTRING
+
+
+def test_dedent_tabs():
+ result = 'first string\n\nsecond string'
+ assert dedent(" first string\n\n second string") == result
+ assert dedent("first string\n\n second string") == result
+ assert dedent("\tfirst string\n\n\tsecond string") == result
+ assert dedent("first string\n\n\tsecond string") == result