Changes between Initial Version and Version 1 of Ticket #21256, comment 53
- Timestamp:
- 04/28/2018 06:07:57 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #21256, comment 53
initial v1 2 2 3 3 * Screen size (unknown at the time of generation anyway) 4 * Post type as inferred by the OP4 * Post type, as inferred by the OP 5 5 * Template 6 6 * Post format … … 8 8 * Something I haven't thought of 9 9 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.10 It'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. 11 11 12 12 This is why a simple filter value makes most sense to me. e.g. … … 14 14 `apply_filters( 'content_width', $content_width );` 15 15 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.16 Theme 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. 17 17 18 The definition in themes then becomes the default value and allows flexibility.18 The definition in themes then becomes the default value. 19 19 20 Ultimately, the continued existence of `$content_width` should really be challenged. Any way you look at it, it shouldn't have a long term future.20 Ultimately, the continued existence of `$content_width` should really be challenged. Any way you look at it, it shouldn't have a long term future.