[wp-trac] [WordPress Trac] #30770: Twenty Fifteen: Theme Review: Stylesheets and Scripts

[WordPress Trac]

#30770: Twenty Fifteen: Theme Review: Stylesheets and Scripts
---------------------------+-----------------------
 Reporter:  emiluzelac     |       Owner:
     Type:  defect (bug)   |      Status:  reopened
 Priority:  normal         |   Milestone:  4.2
Component:  Bundled Theme  |     Version:  4.1
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:
---------------------------+-----------------------

Comment (by peterwilsoncc):

 Replying to [comment:39 valendesigns]:
 > Thank you for adding an updated patch. However, I think
 [attachment:30770.diff] is still the correct course of action here. The
 code is being loaded before all other scripts and in the case of child
 themes or modernizr they would still be able to add classes to the `html`
 element by overriding the modification in a separate script, since they
 are called after `wp_head` via the `wp_enqueue_scripts` action. Please
 correct me if I'm wrong, but I don't see a reason to change the JavaScript
 to make it any more compatible. The issue here (IMO) is how this
 particular piece of code is being loaded into `header.php` and not how it
 changes `no-js` to `js` in the `html` element.

 That's correct, any enqueued javascript runs after the code inserted into
 `wp_head`

 My aim is to protect against two things:
 * child themers adding a class to the HTML element directly into a
 header.php override.
 * child themers doing_it_wrong by hard coding modernizr or similar into a
 header.php override.

 The former being more important than the latter.

 In terms of opinionated coding, the purpose is to replace `no-js` with
 `js` so that's what I think it should do.

 ''Anyway, that was my poorly explained logic - I'll bow out now.''

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30770#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform