Working around iOS/Safari CSS

Bloke · 2020-07-27 08:59:50

Grrr, Safari on iOS is fast becoming the new IE. Not only have Apple broken parallax scrolling in iOS 13 (which is frustrating given the site I just made uses it and I had to code around it using feature detection in CSS) but I’m really struggling to get a pure CSS menu popup to work.

Flyout submenus work in every browser on tap with really minimal CSS (okay, yes, they don’t close by tapping a second time, so that’s an issue I’ll need to figure out) but on Safari on iOS… nope. I think it’s to do with the fact you can’t have :hover on anything other than an anchor but all the usual workarounds (adding onclick="" / an event handler / ontouchmove as recommended. Nada.

I’m presumably doing something wrong. But then… iOS, so who knows. Standard nested ul/li menu structure:

<nav class="navbar low" aria-label="<txp:text item="site_nav" />" itemscope itemtype="https://schema.org/SiteNavigationElement">
   <txp:section_list wraptag="ul" break="" class="main-nav">
      <li<txp:if_section name='<txp:section />'> class="active"</txp:if_section>>
      <txp:variable name="children" escape="trim">
         <txp:article_custom section='<txp:section />' break="" class="sub-nav" sort="Posted asc">
            <li><a itemprop="url" href="<txp:permlink />" class="nav-links"><txp:title /></a></li>
         </txp:article_custom>
      </txp:variable>
      <txp:if_variable name="children" not value=""><a href="#" itemprop="url" class="nav-links"><txp:section title /></a>
          <ul>
             <li><a itemprop="url" href="/<txp:section />" class="nav-links"><txp:section title /></a></li>
             <txp:variable name="children" />
          </ul>
      <txp:else />
          <a itemprop="url" href="/<txp:section />" class="nav-links"><txp:section title /></a>
      </txp:if_variable>
      </li>
   </txp:section_list>
</nav>

(I haven’t added the ‘active’ class to the article yet, which is why I’m using a hard-coded <li> and not a wraptag on the <txp:article_custom> – in preparation for adding the class).

So the reason for the variable dance is as follows.

The menu is anchored to the bottom of the screen. The (left-right scrollable) nav element houses the main items (section landing pages) and the sub-menu holds any articles inside. If I leave the main menu clickable as a section link, iOS jumps straight to the section landing page when tapping the menu. Other OSs permit long press to pop up the submenu, but then the browser context menu also gets in the way.

So I ‘solved’ that by physically removing the section landing page link from the main bar, replacing it with a '#' link and moving the section nav item into the submenu when it’s rendered.

The upshot is that when you tap a menu item with no submenu, you go straight there. When you tap a menu item that has a submenu, the fact there’s no real link (just a single hash) means the CSS “hover” kicks in and shows the menu, whereby you can pick the section landing page or any of the articles presented. Works across the board. Except in Safari iOS which just does, well, nothing. You tap the main menu item and nothing occurs. Only the single menu items with no submenus work, as normal.

Pertinent CSS:

  .navbar.low {
    display: flex;
    justify-content: space-between;
    align-items: center;
    position:sticky;
    bottom:0;
    z-index: 100;
    background: white;
    border-top:1px solid #999;
    width:100%;
  }
 .low .main-nav {
    display: flex;
    justify-content: space-between;
    flex-wrap: nowrap;
    overflow-x:auto;
    width:100%;
    -webkit-overflow-scrolling: touch;
    -ms-overflow-style: none;  /* IE and Edge */
    scrollbar-width: none;  /* Firefox */
  }
  .low .main-nav::-webkit-scrollbar {
    display: none; /* Chrome, Safari, Opera */
  }
.low li {
    white-space: nowrap;
    border-left:1px solid #999;
    width:100%;
    text-align:center;
  }
  .low li a {
    display:inline-block;
    padding:0.8rem 0.6rem;
    text-transform:uppercase;
    font-size:11pt;
    width:100%;
  }
  .low li a:hover {
    text-decoration: none;
    color: #007ca0;
  }
  .low li:hover {
    background: #ddd;
  }
  .low li.active {
    background:#f6a974;
  }
  .low li.active a {
    color:#333;
  }
  .low li:first-child {
    border-left:none;
  }
/* flyout menu */
  .low li>ul li {
    display:none;
    cursor: pointer;
  }
  .low li:focus>ul,
  .low li:hover>ul {
    display:flex;
    flex-wrap: wrap;
    flex-direction:column;
    position:absolute;
    bottom:100%;
    width:auto;
  }
  .low li:focus>ul li,
  .low li:hover>ul li {
    display:flex;
    background:white;
    border:1px solid #ccc;
    border-bottom:none;
  }
  .low .sub-nav {
    display: block;
    width:100%;
  }

Any ideas what I’m doing wrong? Any better approaches?

I may have to resort to JavaScript here, not only to fix the ‘tap away’ thing but to get it to work across devices. But even then I’m struggling to get it to work, so any hints on how to do this with minimal code is welcome. The closer I get to zero JS for this feature, the happier I’ll be. Thank you.

Last edited by Bloke (2020-07-27 09:03:51)

phiw13 · 2020-07-27 10:21:26

Safari on iOS is fast becoming the new IE

Bull**** sorry for being crude.

CCS only “hover” menus have always been a nightmare accessibility wise. How do you make you menu work for all those poor sods who rely on the keyboard or a largish collection of AT tools ?

Javascript is your friend.

colak · 2020-07-27 10:22:57

Did you try this for parallax scrolling?

Bloke · 2020-07-27 10:35:57

phiw13 wrote #324895:

CCS only “hover” menus have always been a nightmare accessibility wise.

Yeah, true. I was being flippant.

How do you make you menu work for all those poor sods who rely on the keyboard or a largish collection of AT tools ?

I found an interesting resource for handling accessibility better last night for keyboard users (though it does require a few new CSS rules). But yeah it’s a minefield.

Javascript is your friend.

I’m rapidly coming to this conclusion. I’m just being stubborn and don’t want it to be, since it’s soo close to working reasonably well without it.

Last edited by Bloke (2020-07-27 10:43:38)

Bloke · 2020-07-27 10:37:49

colak wrote #324896:

Did you try this for parallax scrolling?

No. Good find, though. Might try that one day. I couldn’t be bothered to debug it as it was getting late, so I just switched it off for the one OS/browser that doesn’t support it any more.

colak · 2020-07-27 13:18:29

Bloke wrote #324897:

Yeah, true. I was being flippant.

I found an interesting resource for handling accessibility better last night for keyboard users (though it does require a few new CSS rules). But yeah it’s a minefield.

I’m rapidly coming to this conclusion. I’m just being stubborn and don’t want it to be, since it’s soo close to working reasonably well without it.

I always go to w3 schools first. You can of course change hover to active, add the ARIA meta, and it should work.

phiw13 · 2020-07-27 13:30:41

colak wrote #324902:

I always go to w3 schools first. You can of course change hover to active, add the ARIA meta, and it should work.

Did you try that using e.g. the keyboard ? Failure all around.

Bloke wrote #324897:

I found an interesting resource for handling accessibility better last night for keyboard users (though it does require a few new CSS rules). But yeah it’s a minefield.

:focus-within helps a little yes. You can even try it on a real world website, visit the index page of meyerweb.com, the second tab press will reveal the in-page menu

Textpattern CMS

Textpattern CMS support forum

#1 2020-07-27 08:59:50