[wp-trac] [WordPress Trac] #63275: Twenty Fourteen: Sticky menu problem

[WordPress Trac]

#63275: Twenty Fourteen: Sticky menu problem
-------------------------------------------------+-------------------------
 Reporter:  SergeyKovalets                       |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  low                                  |   Milestone:  Future
                                                 |  Release
Component:  Bundled Theme                        |     Version:
 Severity:  trivial                              |  Resolution:
 Keywords:  has-patch has-testing-info dev-      |     Focuses:  ui
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by SirLouen):

 * keywords:  has-patch has-testing-info => has-patch has-testing-info dev-
     feedback


Comment:

 Replying to [comment:20 sabernhardt]:
 > > why not `masthead` >= 50 or even 60?
 >
 > If the header is fixed at the top and anything more than 48 pixels tall,
 it will start to cover the page's content (#25554). One extra pixel is
 //probably// safe, maybe even two. However, the header would already start
 obscuring the top of a Tagline at 53 pixels tall, and other elements could
 be closer. Besides, the odd number 49 is already in the script. Trying to
 solve an uncommon situation in an old theme hopefully would not involve
 much change.
 >
 > If the general idea of 63275.diff is good, the fixed header comment in
 the script likely would need updating too.

 Not sure what you mean with "obscuring". Setting 60 or even 70 won't
 affect anything apart from the fact that if the masthead has more than
 height it will not scroll anymore (when it jumps into two lines or three
 lines, basically)

 [https://streamable.com/ywqn78 Check video at 100]

 PS: Why have you removed `dev-feedback` tag? Although you are in the core
 team, you told me you are not core committing. The problem is that "Future
 Release" without `dev-feedback` means "Ticket Orphaned" like 99% of the
 time (and even with `dev-feedback` 80% of the times).
 Basically, I always put `dev-feedback` to all reports that have been
 tested and are ready to ship to bring attention from someone that can
 actually set a specific Milestone (like 6.8.1 or at least 6.9 in this
 case) or directly commit into trunk.
 I'm trying to figure out the best way to move forward tickets that are
 100% done and just need a deployment, thus avoiding increasing
 indefinitely the massive ball of 100% finished tickets that were never
 committed because they were orphaned. Maybe I should raise this topic in
 one of the next core-dev chats.
 I believe I will raise this issue in the next dev-chat to see if I find
 some consensus on this topic.

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