WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #21256, comment 53


Ignore:
Timestamp:
04/28/2018 06:07:57 PM (8 weeks ago)
Author:
markcallen
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #21256, comment 53

    initial v1  
    22
    33* Screen size (unknown at the time of generation anyway)
    4 * Post type as inferred by the OP
     4* Post type, as inferred by the OP
    55* Template
    66* Post format
     
    88* Something I haven't thought of
    99
    10 It's inappropriate in my opinion for core to try and make assumptions about any possible layout conditions in a theme and define a list of arguments for theme.
     10It's inappropriate for core to try and make assumptions about any possible layout conditions and provide a pre-determined list of arguments to decide. IT's just creating future back-compat issues IMO.
    1111
    1212This is why a simple filter value makes most sense to me. e.g.
     
    1414`apply_filters( 'content_width', $content_width );`
    1515
    16 Theme devs can then add filters as simple or complicated as necessary to get the right value out. It removes the need for hooking into `template_redirect`, because it can be hooked directly and appropriately.
     16Theme devs can then add filters based on their own requirements to get the right value out. It removes the need for hooking into `template_redirect`, or any other workaround because it can be hooked directly and appropriately.
    1717
    18 The definition in themes then becomes the default value and allows flexibility.
     18The definition in themes then becomes the default value.
    1919
    20 Ultimately, the continued existence of `$content_width` should really be challenged. Anyway you look at it, it shouldn't have a long term future.
     20Ultimately, the continued existence of `$content_width` should really be challenged. Any way you look at it, it shouldn't have a long term future.