Polymer: use polymer-css-build --no-inline-includes

Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2718243005
Cr-Original-Commit-Position: refs/heads/master@{#453652}
Committed: https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445c12a0ffc57e2
Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#454170}
Committed: https://chromium.googlesource.com/chromium/src/+/600c6a41851b482f7ae4deb3502b5260e708163e

[Dan Beam, 2017-02-28 03:13:09]

Description was changed from

==========
Polymer: harness the --no-inline-includes flag to polymer-css-build

Chromium updated to polymer-css-build 1.0.9 here:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
==========

to

==========
Polymer: harness the --no-inline-includes flag to polymer-css-build

Chromium updated to polymer-css-build 1.0.9 here:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2017-02-28 03:13:25]

Description was changed from

==========
Polymer: harness the --no-inline-includes flag to polymer-css-build

Chromium updated to polymer-css-build 1.0.9 here:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated to polymer-css-build 1.0.9 here:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2017-02-28 03:13:49]

Description was changed from

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated to polymer-css-build 1.0.9 here:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2017-02-28 03:16:11]

Description was changed from

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to polymer_config.js to add:

  Polymer.preserveStyleIncludes = true;

to change Polymer's internal configuration.

So, given the example DOM:

<dom-module id="css-module">
  <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2017-02-28 03:17:30]

Description was changed from

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being use from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2017-02-28 04:07:32]

The CQ bit was checked by dbeam@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 04:08:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 05:49:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-28 05:49:25]

Dry run: This issue passed the CQ dry run.

[dpapad, 2017-02-28 18:30:26]

lgtm

[Dan Beam, 2017-02-28 18:47:59]

The CQ bit was checked by dbeam@chromium.org

[commit-bot: I haz the power, 2017-02-28 18:48:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 18:52:50]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1488307679374710, "parent_rev":
"3eba057d5ac5c97715df1cb89a9ad4d146f7e007", "commit_rev":
"b64500afce5b9342dba43f53f445c12a0ffc57e2"}

[commit-bot: I haz the power, 2017-02-28 18:53:29]

Description was changed from

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#453652}
Committed:
https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445...
==========

[commit-bot: I haz the power, 2017-02-28 18:53:30]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445...

[Dan Beam, 2017-03-01 04:18:03]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/2729483002/ by dbeam@chromium.org.

The reason for reverting is: Broke Linux ChromeOS version of MD Settings.

[Dan Beam, 2017-03-02 00:07:54]

Description was changed from

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#453652}
Committed:
https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445...
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#453652}
Committed:
https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445...
==========

[Dan Beam, 2017-03-02 00:08:05]

The CQ bit was checked by dbeam@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-02 00:08:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Dan Beam, 2017-03-02 01:36:30]

The CQ bit was unchecked by dbeam@chromium.org

[Dan Beam, 2017-03-02 01:40:02]

so the issue ended up being that

  <dom-module id="...">
  <dom-module name="...">
  <dom-module is="...">

are all valid ways to declare modules for Polymer's /runtime/.  BUT
`polymer-css-build` only finds

  <dom-module id="...">

I sent a PR to fix the tool[1] and changed all of Chrome's code to use
<dom-module id="..."> in the mean time[2].  So it's safe to land this now
(dpapad@ and I both verified locally that ChromiumOS + use_vulcanize=true works
now).

[1] https://github.com/PolymerLabs/polymer-css-build/pull/8
[2] https://codereview.chromium.org/2723873003/

[Dan Beam, 2017-03-02 01:40:10]

The CQ bit was checked by dbeam@chromium.org

[commit-bot: I haz the power, 2017-03-02 01:41:20]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-02 03:46:24]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1488418810890610, "parent_rev":
"01d7ab5878d8c24c94669de640cf0d43aaa8d6f9", "commit_rev":
"600c6a41851b482f7ae4deb3502b5260e708163e"}

[commit-bot: I haz the power, 2017-03-02 03:47:20]

Description was changed from

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#453652}
Committed:
https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445...
==========

to

==========
Polymer: use polymer-css-build --no-inline-includes

Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003

This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003

And finally requires a change to Polymer's internal config via:

  Polymer.preserveStyleIncludes = true;


Given the example DOM:

  <dom-module id="css-module">
    <template>
      <style>
        /* module styles */
      </style>
    </template>
  </dom-module>

  <dom-module id="my-element">
    <template>
      <style include="css-module">
        /* template styles */
      </style>
    </template>
  </dom-module>

before this patch is combined both at compile time and at runtime into:

  <my-element>
    #shadow
      <style>
        /* module styles */
        /* template styles */
      </style>
  </my-element>

This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).

With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().

The end results (in the DOM) are basically:

  <my-element>
    #shadow
      <style>
        /* module styles */
      </style>
      <style>
        /* template style */
      </style>
  </my-element>

I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.

R=dpapad@chromium.org
BUG=597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2718243005
Cr-Original-Commit-Position: refs/heads/master@{#453652}
Committed:
https://chromium.googlesource.com/chromium/src/+/b64500afce5b9342dba43f53f445...
Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#454170}
Committed:
https://chromium.googlesource.com/chromium/src/+/600c6a41851b482f7ae4deb3502b...
==========

[commit-bot: I haz the power, 2017-03-02 03:47:21]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/600c6a41851b482f7ae4deb3502b...