MD Settings: Update Protected Content for redesign

chrome/browser/resources/settings/privacy_page/privacy_page.html

Index: chrome/browser/resources/settings/privacy_page/privacy_page.html
diff --git a/chrome/browser/resources/settings/privacy_page/privacy_page.html b/chrome/browser/resources/settings/privacy_page/privacy_page.html
index 4bf462434a60e6f650baab76ea9c82b6e52718f2..c33cf3a09e9e15b0f43859d7983bee1661e67965 100644
--- a/chrome/browser/resources/settings/privacy_page/privacy_page.html
+++ b/chrome/browser/resources/settings/privacy_page/privacy_page.html
@@ -418,8 +418,19 @@
       </template>
       <template is="dom-if" route-path="/content/protectedContent" no-search>
         <settings-subpage page-title="$i18n{siteSettingsProtectedContent}">
+          <div class="settings-box first">
+            <!-- TODO(dschuyler): change i18n to i18nStr. -->
+            <settings-toggle-button class="start"
+                pref="{{prefs.webkit.webprefs.encrypted_media_enabled}}"
+                label="[[getStringTernary_(
+                    prefs.webkit.webprefs.encrypted_media_enabled.value,
+                    '$i18n{siteSettingsProtectedContentEnable}',
+                    '$i18n{siteSettingsBlocked}')]]">

[stevenjb, 2017/02/10 00:32:31]

Just FMI, any particular reason to do this in the HTML instead of using i18n()
in the JS? I realize it's minutely more efficient this way, but seems a little
less readable than something like:
[[getProtectedContentLabel_(prefs.webkit.webprefs.encrypted_media_enabled.value)]]

[tommycli, 2017/02/10 00:51:37]

Ask dschuyler for details, but the plan is to eventually eliminate all of the
JavaScript i18n. As I understand it, if we remove all JavaScript i18n, the
difference is not minute.

[stevenjb, 2017/02/10 01:12:47]

Hmm, I am unconvinced that is achievable, but if it is a non minute improvement
in general, this is fine.

[tommycli, 2017/02/10 16:58:42]

Hey - I should be more specific... if we can remove all the i18n-content
attributes within the HTML, we will be able to skip the step where we parse the
HTML in JavaScript modifying the DOM. That was the part that was non-minute.

[stevenjb, 2017/02/10 17:21:07]

OK, that makes sense. I was actually suggesting:

label=[[getProtectedContentLabel_(prefs.webkit.webprefs.encrypted_media_enabled.value)]]

Then in JS:

getProtectedContentLabel_: function() {
  return this.prefs.webkit.webprefs.encrypted_media_enabled.value ?
    this.i18n(siteSettingsProtectedContentEnable) :
    this.i18n(siteSettingsBlocked);
}

Only because I find the HTML is kind of hard to read, but I noticed that the
pattern / function you used already exists below, so I guess this is fine.

+            </settings-toggle-button>
+          </div>
+<if expr="chromeos or is_win">
           <div class="settings-box first two-line">
-            $i18n{siteSettingsProtectedContentExplanation}
+            $i18n{siteSettingsProtectedContentIdentifiersExplanation}
           </div>
           <div class="settings-box first">
             <!-- TODO(dschuyler): change i18n to i18nStr. -->
@@ -427,14 +438,18 @@
                 pref="{{prefs.settings.privacy.drm_enabled}}"
                 label="[[getStringTernary_(
                     prefs.settings.privacy.drm_enabled.value,
-                    '$i18n{siteSettingsProtectedContentEnable}',
+                    '$i18n{siteSettingsProtectedContentEnableIdentifiers}',
                     '$i18n{siteSettingsBlocked}')]]">
             </settings-toggle-button>
           </div>
+</if>
 <if expr="chromeos">
-          <category-setting-exceptions
-              category="{{ContentSettingsTypes.PROTECTED_CONTENT}}">
-          </category-setting-exceptions>
+          <template is="dom-if"
+              if="[[prefs.settings.privacy.drm_enabled.value]]">
+            <category-setting-exceptions
+                category="{{ContentSettingsTypes.PROTECTED_CONTENT}}">
+            </category-setting-exceptions>
+          </template>
 </if>
         </settings-subpage>
       </template>