symfony · javiereguiluz · Apr 8, 2019 · Apr 8, 2019
diff --git a/form/bootstrap4.rst b/form/bootstrap4.rst
@@ -66,7 +66,7 @@ configuration:
 If you prefer to apply the Bootstrap styles on a form to form basis, include the
 ``form_theme`` tag in the templates where those forms are used:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     {# ... #}
     {# this tag only applies to the forms defined in this template #}

diff --git a/frontend/encore/server-data.rst b/frontend/encore/server-data.rst
@@ -6,7 +6,7 @@ In Symfony applications, you may find that you need to pass some dynamic data
 dynamic configuration is by storing information in ``data`` attributes and reading
 them later in JavaScript. For example:
 
-.. code-block:: twig
+.. code-block:: html-twig
 
     <div class="js-user-rating" data-is-authenticated="{{ app.user ? 'true' : 'false' }}">
         <!-- ... -->
@@ -36,7 +36,7 @@ store any content. In Twig, use the ``html_attr`` escaping strategy to avoid mes
 with HTML attributes. For example, if your ``User`` object has some ``getProfileData()``
 method that returns an array, you could do the following:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <div data-user-profile="{{ app.user ? app.user.profileData|json_encode|e('html_attr') }}">
         <!-- ... -->

diff --git a/frontend/encore/simple-example.rst b/frontend/encore/simple-example.rst
@@ -83,7 +83,7 @@ Congrats! You now have three new files:
 Next, include these in your base layout file. Two Twig helpers from WebpackEncoreBundle
 can do most of the work for you:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     {# app/Resources/views/base.html.twig #}
     <!DOCTYPE html>

diff --git a/frontend/encore/split-chunks.rst b/frontend/encore/split-chunks.rst
@@ -33,7 +33,7 @@ Twig functions from WebpackEncoreBundle, you don't need to do anything else! The
 functions automatically read this file and render as many ``script`` or ``link``
 tags as needed:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     {#
         May now render multiple script tags:

diff --git a/frontend/encore/versioning.rst b/frontend/encore/versioning.rst
@@ -65,7 +65,7 @@ an ``img`` tag) to certain assets. If you're using Symfony, just activate the
 That's it! Just be sure to wrap each path in the Twig ``asset()`` function
 like normal:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <img src="{{ asset('build/images/logo.png') }}">
 

diff --git a/quick_tour/the_view.rst b/quick_tour/the_view.rst
@@ -146,7 +146,7 @@ One of the best features of Twig is its extensibility via tags, filters
 and functions. Take a look at the following sample template that uses filters
 extensively to modify the information before displaying it to the user:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <h1>{{ article.title|capitalize }}</h1>
 
@@ -170,7 +170,7 @@ create a new template fragment that can then be included from other templates.
 Imagine that we want to display ads on some pages of our application. First,
 create a ``banner.html.twig`` template:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     {# app/Resources/views/ads/banner.html.twig #}
     <div id="ad-banner">
@@ -256,7 +256,7 @@ Including Assets: Images, JavaScripts and Stylesheets
 What would the Internet be without images, JavaScripts and stylesheets?
 Symfony provides the ``asset()`` function to deal with them easily:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <link href="{{ asset('css/blog.css') }}" rel="stylesheet" type="text/css"/>
 

diff --git a/reference/dic_tags.rst b/reference/dic_tags.rst
@@ -178,7 +178,7 @@ Second, define a service:
 
 Finally, apply the filter:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     {% javascripts
         '@AcmeBaseBundle/Resources/public/js/global.js'

@@ -195,7 +195,7 @@ This test will check if the current choice is equal to the ``selected_value``
 or if the current choice is in the array (when ``selected_value`` is an
 array).
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <option {% if choice is selectedchoice(value) %} selected="selected"{% endif %} ...>
 
@@ -247,7 +247,7 @@ of variables. By default, these blocks live inside `form_div_layout.html.twig`_.
 
 Look at the ``form_label`` as an example:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     {% block form_label %}
         {% if not compound %}

diff --git a/templating.rst b/templating.rst
@@ -763,11 +763,11 @@ Suppose ``description`` equals ``I <3 this product``:
 
 .. code-block:: twig
 
-    <!-- output escaping is on automatically -->
-    {{ description }} <!-- I &lt;3 this product -->
+    {# output escaping is on automatically #}
+    {{ description }} {# I &lt;3 this product #}
 
-    <!-- disable output escaping with the raw filter -->
-    {{ description|raw }} <!-- I <3 this product -->
+    {# disable output escaping with the raw filter #}
+    {{ description|raw }} {# I <3 this product #}
 
 .. caution::
 

diff --git a/translation.rst b/translation.rst
@@ -286,7 +286,7 @@ texts* and complex expressions:
     that your translated message is *not* output escaped, you must apply
     the ``raw`` filter after the translation filter:
 
-    .. code-block:: twig
+    .. code-block:: html+twig
 
             {# text translated between tags is never escaped #}
             {% trans %}

diff --git a/web_link.rst b/web_link.rst
@@ -27,9 +27,8 @@ Preloading Assets
 
 Imagine that your application includes a web page like this:
 
-.. code-block:: twig
+.. code-block:: html
 
-    {# templates/homepage.html.twig #}
     <!DOCTYPE html>
     <html>
     <head>
@@ -39,7 +38,7 @@ Imagine that your application includes a web page like this:
     </head>
     <body>
         <main role="main" class="container">
-            {# ... some content here ... #}
+            <!-- ... -->
         </main>
     </body>
     </html>
@@ -58,10 +57,10 @@ To do that, first install the WebLink component:
 Now, update the template to use the ``preload()`` Twig function provided by
 WebLink:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <head>
-       {# ... #}
+        <!-- ... -->
         <link rel="stylesheet" href="{{ preload('/app.css') }}">
     </head>
 
@@ -72,10 +71,10 @@ requested the HTML page.
 Additionally, according to `the Priority Hints specification`_, you can signal
 the priority of the resource to download using the ``importance`` attribute:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <head>
-       {# ... #}
+        <!-- ... -->
         <link rel="stylesheet" href="{{ preload('/app.css', { importance: 'low' }) }}">
     </head>
 
@@ -102,10 +101,10 @@ improve performance of your applications in production right now.
 If you want to prevent the push but let the browser preload the resource by
 issuing an early separate HTTP request, use the ``nopush`` option:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <head>
-       {# ... #}
+        <!-- ... -->
         <link rel="stylesheet" href="{{ preload('/app.css', { nopush: true }) }}">
     </head>
 
@@ -135,12 +134,12 @@ The component also supports sending HTTP links not related to performance and
 any link implementing the `PSR-13`_ standard. For instance, any
 `link defined in the HTML specification`_:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <head>
-       {# ... #}
+        <!-- ... -->
         <link rel="alternate" href="{{ link('/index.jsonld', 'alternate') }}">
-        <link rel="stylesheet" href="{{ preload('/app.css', {nopush: true}) }}">
+        <link rel="stylesheet" href="{{ preload('/app.css', { nopush: true }) }}">
     </head>
 
 The previous snippet will result in this HTTP header being sent to the client: