Reviewing Twitter's New Profile Header

Today Twitter announced that it has added header images to profiles, similar to what Facebook and Google+ have done. In addition, Twitter has updated its apps for iOS and Android devices to use those header images. Twitter explains why it has added this feature:

Starting today you can make your presence on Twitter more meaningful with new Twitter profiles. […] You can upload your header photo, which appears above your Tweets, to express yourself instantly, anywhere.

By adding a header image, I am both making Twitter more meaningful and expressing myself. Even though I have used Twitter for 15,000+ of my own tweets so far to express myself, and follow a group of folks that bring meaning to my Twitter stream. In case it's not obvious, I am suspect of the reasoning. It feels to me more like Twitter trying to make itself more like Facebook (and Google+ and App.net), especially with the promotion of any photos from my timeline into their own prominent photo bar on mobile displays.

Twitter offers only two parameters for providing the header image — it should not be over 5MB and it should be 1,252 × 626 pixels. I can only assume this over-sized behemoth is Twitter's way of accounting for high resolution displays. And so I dutifully made and uploaded my header image.

Desktop Browser

Screen capture of new Twitter header on desktop browser.

I am wholly unimpressed with the desktop browser experience. Not only has the image been scaled down (which I expected), it was scaled down to 542 pixels in width, or by a factor of 2.31. That's not a nice even number and it relies on browser image scaling (which isn't even bicubic in older browsers) to present the image.

In addition, my name and description are lost in the image, which means I'd have to build a space into my file just to account for the text. On top of all this, the link to my web site doesn't stand out in any way as a hyperlink. It is not obvious that it is clickable, and that's ultimately the thing I want people to click if they visit my profile page.

Forgetting how the image disrupts copy laid on top of it, the size of the image header leaves (at the window size I was using) only 3 tweets visible in my timeline. While at this same window size I only had 5 tweets visible with the old header, I'd rather have those two tweets back given the issues I have with the new header.

Compare this with my profile page before the header:

Screen capture of old Twitter header on desktop browser.

Mobile Browser

Screen capture of new Twitter header on mobile browser (Chrome on Nexus 7).

The mobile browser experience isn't much better. The text is nearly illegible, but at least the hyperlink to my site appears to be bold, if smaller. Only three tweets are visible and then there is a bar with images I have posted. The worst part is that only one of those is mine (the other five are retweets), they are from July, and the thumbnail, when tapped, loads the wrong image. I don't like my tweets being truncated for this low-value content.

Without the header image, however, the experience is almost no better. I still lose the same amount of space to a header image I have not defined. The only plus is that the text is now legible. See the before photo:

Screen capture of old Twitter header on mobile browser (Chrome on Nexus 7).

Mobile App

Screen capture of updated Twitter app with new header (Nexus 7).

Everything I said about the mobile browser experience with and without the new Twitter header applies.

Except this is even worse.

You can't see my description, location or web site address in my profile without swiping to a second panel. Perhaps in some misguided attempt to make the text more legible by laying down a black overlay on the background header image, Twitter has now made my biographical information and link to my site totally invisible without some user interaction.

Not providing a header image does not save me from this mistake. As you can see below, custom image or not, my information is still a screen away.

Screen capture of updated Twitter app without new header (Nexus 7).

Conclusion

I removed the header image. I see no reason to push all those kilobytes to users to lessen their experience should they stumble across my profile page. On top of that, I don't want to hide any more tweets than necessary nor obfuscate the link to my site (though I have no control over that in the mobile app). Perhaps in the future I'll take time to craft an image to better fit the layout, but I have more important things to do than try to shoehorn something into Twitter's mistake. Not to mention they can just change the rules again at any time.

Frankly, I'd rather Twitter enable Twitter cards for all sites. There is far more value to me as a content creator and as a user in that feature. And that feature leans on the existing Twitter experience, not some vapid attempt to copy other social media platforms.

Update: 2:19PM

I just discovered .net Magazine did a brief piece on the Twitter header image this morning, and the sources they cite say pretty much the same thing as I do.

Facebook, HTML5, and Mis-Reporting

My Twitter stream and the headlines of sites across the web yesterday lit up with Facebook's CEO blaming its stock price (failure to meet hyped expectation) on HTML5 (and its failure to make the Facebook mobile experience suck less).

Even ZDNet jumped on that bandwagon with a post titled Facebook's Mark Zuckerberg knocks HTML5 in favor of native apps, using the summary, Mark Zuckerberg didn't hold back in acknowledging Facebook's mistakes, citing a focus on HTML5 as the biggest one. Bolstering its point, ZDNet included this quote from Zuckerberg:

The biggest mistake we made as a company was betting too much on HTML5 rather than native.

That's it. No additional context, no more justification. An article clearly buying into the notion that Facebook is doing poorly because it built its mobile experience using HTML5.

Blaming a technology is easy. It takes the burden off the organization using it. No longer do you need to justify that your business model is broken, or the user experience is impenetrable, or that you didn't factor all the use cases. You can just blame the "savior" technology for letting you down.

That would be as silly as blaming responsive web design for Facebook's poor IPO performance.

The W3C, one of the organizations developing HTML5, today tweeted a link to a message from one of its mailing lists that includes the full Zuckerberg quote:

When I'm introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native... because it just wasn't there. And it's not that HTML5 is bad. I'm actually, on long-term, really excited about it. One of the things that's interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.

That statement better summarizes the situation. HTML5 is not done yet. It's not fully formed. Browsers haven't implemented everything and the rules are changing as (parts of the group of specifications that make up the marketing term) HTML5 gets into the wild. It also demonstrates that Facebook made a poor strategic decision by expecting too much.

In Facebook's case, relying on HTML5 to mimic an app just won't cut it for some of its features. While it has worked in other cases, that doesn't mean it will work in all cases. Facebook has consistently had a poor user experience on mobile. That's not the technology, that's strategy and implementation.

You can watch the full interview in the embedded video below. Make your own judgments about Zuckerberg's comments and compare it to how it's being reported across the web.

Head to ~11 minutes for the conversation about mobile.

Related

• Facebook: bet on HTML5 a 'big mistake' from .net Magazine.
• Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 from TechCrunch.
• Zuckerberg’s Biggest Mistake? ‘Betting on HTML5′ from Mashable.
• HTML5 is dead. Long live HTML5! from CNET.
• Failure of Responsive Design is Why Facebook's IPO Tanked, on this blog, May 23, 2012.
• Don't Choose Between Mobile Web and Mobile Apps, on this blog, February 26, 2011.
• Apps Are Not Killing the Web, on this blog, February 5, 2011.

Update, September 18, 2012

Yesterday .net Magazine had a piece about Facebook's W3C representative posting to a W3C mailing list his troubles with the HTML5 approach. I read it not as a complaint but as someone raising issues and asking for help. I also saw some interaction on Twitter this past weekend, spawned by a tweet of mine pointing to the W3C email, between Tobie Langel (Facebook), John Dowdell and Brian Leroux (Adobe), and Steve Souders (Google). Following the link embedded in the tweet below demonstrates that there is discussion among the industry players and perhaps this entire media storm could help move standards further along.

@souders would love your feedback on etherpad.mozilla.org/appcache /cc @brianleroux @jdowdell @aardrian

— Tobie Langel (@tobie) September 17, 2012

More Update, September 18, 2012

Quora answers questions about rebuilding its app, a la Facebook, providing context from a different perspective.

Page-Level Container Discussion for HTML5

As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains "a website or a blog entry's main content" is body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of "main" or "content." In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it's already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn't We Get a Content Element?

The flip side of this argument is that we're just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn't restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of "main" and "content" that already exist in the wild when naming this element.

Where it goes from here is anybody's guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn't expect to see a new element by then.

Related

• Scooby Doo and the proposed HTML5 content element by Bruce Lawson.
• The discussion on the W3C HTML WG mailing list, September 2012.
• The discussion on the WHATWG mailing list, September 2012.
• HTML5 Accessibility Chops: ‘real world’ ARIA landmark use from The Paciello Group.
• New structural elements in HTML5 at Opera
• maincontent element, Unofficial Draft 9 September 2012 (not a W3C draft).

Update, November 28, 2012

The main element was approved by the W3C as a First Public Working Draft, but within the first 48 hours of life has run into significant blocks. Read my write up: New main Element Approved then Blocked.

Use Twitter's New Embedded Timeline without Slowing Your Page

Update: September 7, 2012

I misunderstood how browser load external JavaScript files when that load itself comes from embedded script. Ben Ward explained it to me and referenced this handy article, Thinking Async.

The gist of the article is that using JavaScript to write in a call to a JavaScript file causes the browser to load the external script asynchronously.

While it may be like wearing suspenders with a belt, I'm still going to leave my async edits in my Twitter embedded timeline calls.

Original Entry

Yesterday Twitter announced its new embedded timeline feature for web sites. The gist is that you drop a block of code on your site and users will see the timeline for the selected account as if they were viewing it on Twitter.com — embedded media, expanded links, etc.

This is a new feature and is likely to change, even if the how-to Twitter post isn't too clear on that. I say that it will change because of language in the developer documentation like No other customization options are available at this time, as well as the slew of requests for more type styling options (among other customization requests) on the Twitter Embedded Timelines Questions page(s).

There are also known bugs. If your domain has a hyphen in it, then this won't work. If you are using Opera Mobile, Android 2 or 3 default browser, or an iPad, then the swipe-to-scroll gesture doesn't work (I already reported that one).

Another issue that Twitter may not consider a bug is how the script to embed the timeline is loaded. Currently if you have an embedded tweet or the old embedded timeline on your page and Twitter is down (fail-whale down), then your web page will take quite a while to render. This is a function of how browsers load JavaScript. The browser won't finish rendering the page until it has loaded all the JavaScript or given up (a timeout, which can take minutes).

While there are JavaScript functions that can mitigate this, those don't come into play until the script has downloaded. Instead, HTML5 has a couple attributes for the script element that apply here — async and defer. Essentially these tell the browser it can render the page before the script is downloaded. Since Twitter content is often just add-on content for your existing page, this is the right approach.

Instead of spending a thousand words explaining how this attribute works, I refer you to the WHATWG specification using an embedded tweet where I manually insert the async attribute:

If you use JavaScript and don't know about async/defer HTML5 attributes, you should read up and use: whatwg.org/specs/web-apps…

— Adrian Roselli (@aardrian) September 6, 2012

The new embedded timeline feature doesn't make it quite that easy. Twitter gives you code to drop on your page that has no script element into which you can casually paste async. The script element is generated by JavaScript, which looks like this:

<a class="twitter-timeline" href="https://twitter.com/aardrian" data-widget-id="243755160277487616">Tweets by @aardrian</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

Many of the people who may drop Twitter timelines into their web site are not JavaScript coders. So I whipped up a quick modification you can make to that pre-generated script that will drop the async attribute where it needs to go:

<a class="twitter-timeline" href="https://twitter.com/aardrian" data-widget-id="243755160277487616">Tweets by @aardrian</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.async=true;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

The js.async=true; tells the Twitter function to drop an async into its script reference when it gets created. The generated chunk of code will look like this:

<script src="//platform.twitter.com/widgets.js" async="" id="twitter-wjs">

Now if Twitter goes down again (which it will) your page won't hang as a result. I have also asked Twitter to consider including async in its standard copy-and-paste code.

I have eight (8!) examples of this in play on my Buffalo food truck page, where I have embedded the timelines of the current crop of food trucks in the area so I can check them all at once while aimlessly wandering the streets in a hunger stupor.

If you have a better solution, I am all ears. Please drop it in the comments with any other feedback.

Alt Text on the Picture Element?

This is one of those posts that might interest only a few people and even then only if you are interested in a very specific aspect of this ongoing standard development.

Yesterday I got into a conversation (just one of the messages) on the W3C Responsive Image Community Group mailing list about the alt attribute on the new picture element (see the W3C Editor's Draft). For those who don't know, this community group has been working on producing a method in HTML to allow web developers to specify multiple sources for an image in the same way that we use media queries to specify a particular set of CSS styles to apply to a page.

The discussion was focused on accessibility for the picture element. One suggestion was to use an ARIA role on the picture element to point back to the fallback img. The other suggestion was to just replicate the fallback img's alt text in an alt attribute on the picture itself.

In the end, Mathew Marquis, who is the group chair, proposed these two options:

1. Duplicating the alt attribute on both the picture element and its fallback img;
2. Only specify alt on the fallback img, using aria-labelledby on its parent picture to reference the ID of the fallback img.

Here's the problem—only three people from the community group have responded so far, me being one of them. More responses are needed on issues like this. The broad strokes are in place, but the details are what can kill a specification (or a project, or a patient, or a credit rating). If you are a part of the W3C Responsive Image Community Group (and are reading this and care about these issues) then now would be a good time to pop your head up so others can hear.

In case you are curious, here is my take (which a year from now I may find was an awful idea)…

I think alt on the fallback img should be required and explicitly spelled out as such.

To build on that, I feel that it will be easier for authors and toolmakers to just require the alt on the fallback img, but not on picture. Let picture rely on the fallback img's alt as a single place for fallback content (essentially dump alt from picture altogether).

Then there is no need to worry about duplicating alt to picture and we can lean on existing alt rules, expectations, and even tool implementations even as this new element gets traction.

The two other respondents have far more practical experience with the specifications and accessibility in general, so you should read what Laura Carlson and Bruce Lawson have to say on this. Steve Faulkner has also weighed in, indirectly, on the HTML Working Group mailing list.

And then you can weigh in with your own thoughts. I'd like to see a responsive image solution, whether this one that is proposed or another. Only pushing for something, either way, will make that happen.

Bear in mind, even if this spec doesn't make it and another solution comes forward (server-side or even image-format-based), these conversations help inform other options. This ultimately helps end users, so it's a good idea to get involved. Bruce Lawson helps put a little context around this whole discussion in a post from yesterday, On the publication of Editor’s draft of the picture element.

Almost Related

• Image alt Attributes Not Always Required in HTML5, April 19, 2011.
• More on Image alt Requirement in HTML5, May 2, 2011.
• Image alt Exception Change Re-Re-Requested, June 11, 2012.

CSS Background Images & High Contrast Mode

I try to stay up on accessibility gotchas and weird browser implementations, but I just discovered one that I suspect I should have already known.

In Steve Faulkner's post, Notes on accessible CSS image sprites, he tosses out a factoid that was new to me:

When high contrast mode is enabled in the Windows OS, the sprite is not displayed (CSS background images are not displayed in high contrast mode).

This statement is made in a larger discussion of how to create appropriate fall-backs for designs that rely on CSS image sprites. He provides some handy scripts and techniques within the article.

Separately from this I saw a post yesterday on one of the Microsoft blogs titled -ms-high-contrast media feature that discusses a media query for Windows 8 and IE10 that will detect if the viewer is using high contrast mode (and which flavor).

The code is pretty simple and uses an -ms prefix to do its work:

@media screen and (-ms-high-contrast: active) {/* All high contrast styling rules */}
@media screen and (-ms-high-contrast: black-on-white) {
    div { background-image: url('image-bw.png'); }
}
@media screen and (-ms-high-contrast: white-on-black) {
    div { background-image: url('image-wb.png'); }
}

Clearly this isn't ready for prime time, and you'll still need to use techniques outlined in Faulkner's post, but it is a handy technique that I hope makes it into the spec and gets support from other operating systems and browsers.

Granted, web devs may still screw it up (as they have with accessibility and/or print styles for years now), but at least those worth their salt (and rates) will have another tool to better support users in various configurations.

Related

• Techniques for High-Contrast-Friendly Icons

Update: November 8, 2013

With coming support for the luminosity media query in CSS4, perhaps you can re-use some of your work for high contrast mode or vice versa: Responding to environmental lighting with CSS Media Queries Level 4

Update: October 14, 2014

In CSS Background Images and Accessibility by SSB Bart Group, the author makes the case that not relying on background images is the best approach for accessibility (offering alternative techniques to satisfy design requirements).

CSS-only Radial Menu Experiments

I have been working on a slow and plodding redesign of my personal site and am playing around with some navigation ideas.

I wanted to create a JavaScript-free and image-free radial menu, an idea I toyed with a couple years ago and abandoned due to the lack of CSS support to do what I wanted in current browsers at the time. I decided to give it another shot last weekend while recovering from being pleasant for two days.

If you aren't familiar with radial menus or are curious about why they are popping up as a topic lately, check out Josh Clark's Touch Means a Renaissance for Radial Menus. You can expect to see them more as Windows 8 is released in a couple months.

I threw together a simple five item navigation list, attached no classes or IDs, and decided to see how far I could get before it became untenable (or I got bored).

Single Level CSS-only Radial Menu

.html {
  background-color: #6D695C;
  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAACVBMVEUAAAAAAAAAAACDY+nAAAAAA3RSTlMmDQBzGIDBAAAAG0lEQVR42uXIIQEAAADCMHj/0NdkQMws0HEeAqvwAUGJthrXAAAAAElFTkSuQmCC); }

body{
  margin: 0;
  font-family: Arial, Helvetica, sans-serif;
  /*font-size: 2.5em;*/ }

nav {
  width: 5em;
  height: 8em;
  float: right;
  padding: 0;
  overflow: hidden; }

nav:hover {
  background-color: rgba(0, 0, 0, 0.4);
  width: 16em;
  height: 15em;
  border-radius: 0 0 0 15em; }

body {
  background-color: #eee; }

nav h1 {
  position: relative;
  top: -.75em;
  right: -.5em;
  margin: 0;
  background-color: #000;
  color: #000;
  z-index: 1;
  font-size: 2em;
  line-height: 100%;
  width: 1em;
  padding: 1em .5em 1.25em 1em;
  border-radius: 3.0em 0 0 3.0em;
  -webkit-transform: rotate(-45deg);
  -moz-transform: rotate(-45deg);
  -ms-transform: rotate(-45deg);
  -o-transform: rotate(-45deg);
  transform: rotate(-45deg);
  overflow: hidden; }

nav h1::before {
  content: "\AB";/*« «*/
  /*content: "\21D0";*//*⇐ ⇐*/
  color: #fff;
  -webkit-transform: rotate(-45deg);
  transform: rotate(-45deg); }

nav:hover h1 {
  display: none; }

nav ol {
  margin: 0;
  padding: 0;
  list-style-type: none; }

a {
  display: block;
  position: absolute;
  top: -10em;
  right: 0em;
  border-radius: 4em;
  border: .15em solid #fff;
  padding: 1.5em 0;
  width: 4.5em;
  text-align: center;
  box-shadow: .45em 0 1.5em rgba(50, 50, 50, 0.75);
  -webkit-transition: all 0.2s ease-in;
  -moz-transition: all 0.2s ease-in;
  -ms-transition: all 0.2s ease-in;
  -o-transition: all 0.2s ease-in;
  transition: all 0.2s ease-in; }

nav:hover a {
  /*display: block;*/ }

a:link, a:hover, a:focus, a:active, a:visited {
  text-decoration: none;
  color: #ddd;
  background-color: #000; }

a:hover, a:focus, a:active {
  background-color: #222;
  color: #fff;
  text-shadow: 0em 0em 0.2em rgba(255, 255, 255, 0.8);}

nav:hover li:nth-child(1) a {
  right: 13.5em;
  top: .2em; }

nav:hover li:nth-child(2) a {
  right: 12em;
  top: 4.75em; }

nav:hover li:nth-child(3) a {
  right: 9.0em;
  top: 8.5em; }

nav:hover li:nth-child(4) a {
  right: 4.75em;
  top: 11em; }

nav:hover li:nth-child(5) a {
  right: 0;
  top: 12em; }Check out this Pen!

View this directly on the Codepen site.

Note the style for the body. If you uncomment the style /*font-size: 2.5em;*/, you will see that entire menu scales up. You can put any text size in there you want and the menu will scale up and down. All the sizing (text, borders, positioning, padding, etc.) is based off ems, which makes it easier to scale each part of the menu proportionally.

You may note that I put an onclick = "void(0);" on the h1. Without this, the menu just wouldn't work on iOS. Otherwise I am relying on my Android devices to read a touch as a hover.

You may also see that there is an image on the page. This is a striped background that made it easier for me to see where elements aligned. It is not used in the menu itself, but I do like how it looks so I kept it.

I opted for CSS positioning changes instead of CSS animations since the support is consistent. The menu works in IE9, though without animations. Since the menu uses HTML5 elements, and since it is an experiment, I am not testing older than IE9 (yet).

Then I was curious how hard it would be to add another level into the menu and how it would feel as a user…

Two Level CSS-only Radial Menu

<!-- Original pen (~July 2012) lost by CodePen, this is a recreation with their assistance to get the old code. -->
<nav role="navigation">
  <h1 onclick = "void(0);">Menu</h1>
  <ol>
    <li><a href="#">Bio</a>
      <ol onclick = "void(0);">
        <li><a href="#">Bio One</a></li>
        <li><a href="#">Bio Two</a></li>
        <li><a href="#">Bio 3</a></li>
      </ol>
    </li>
    <li><a href="#">Blog</a></li>
    <li><a href="#">Books</a></li>
    <li><a href="#">Articles</a></li>
    <li><a href="#">Contact</a></li>
   </ol>
</nav>

<!--
The onclick attributes are to allow Safari on iOS to see these otherwise non-clickable elements as clickable so it can then apply the hover styles as if they were clicks.
-->
Check out this Pen!

View this directly on the Codepen site.

I forked the single-level menu and put another level under the first item ("Bio"). With only three items it was still time consuming to style the positioning of elements and get the animation look that I wanted.

I also had to put an onclick = "void(0);" into the nested ol in order for iOS to recognize it as a clickable element. Sadly, that means that "Bio 3" always gets the focus on touch devices because it's at the top of the stack when the focus is applied through a tap.

On desktop browsers however, it works well.

Wrap-up

Drawbacks for both of these menus are many. For example, using my positioning method it can be very hard to calculate where additional menus should appear, making this tedious to code into a CMS. The menu items also all rely on very short navigation text in order to fit into the almost-circular navigation items. The collective shadows from nested items make for an interesting shadow stack obscuring subsequent menu items.

However, given the real-life feedback I've gotten I figured there might be some ideas or code chunks others might find useful. Even better would be if someone gets inspired to take this to the next level and clean it up, fixing my own shorthand tricks and making it more robust.

Corrections, suggestions, feedback, and forking are all welcome.