Fix dropdown menu CSS to permit links and buttons to co-exist

The following comment should be addressed https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27275#note_160467439:

Clever patch to get buttons working in this dropdown without causing unintended side-effects!

I'm okay with doing this for now, but I'd like to create a follow up issue to address some concerns. Patches like this are a sign that there's something wrong happening...

The problem

We want .btn in this dropdown menu to actually be styled as buttons, but we have some preexisting style rules which want them to be dropdown links.

What's great about @patrickbajao's patch?

This change only effects the elements of this feature, so there is a pretty low risk of unrelated regressions 🎉

What's wrong with this patch?

This change adds an even more specific selector to beat a less specific selector .dropdown-menu li a which beat .btn. Unfortunately, this patch will silently break when an even more specific selector comes along 😞

What's the real problem?

We are abusing semantics in _download.html.haml by having every block (i.e. header, content, seprator) be a <li>. We should only use <ul> and <li> for things that are actually lists. Otherwise, issues like this come up.

Here's a patch to semanticize the views: 20190412_semanticize_download_views.patch. I don't think this should block this MR, so I'd like to create a follow up issue/MR for this. WDYT @nick.thomas?

Edited Apr 15, 2019 by Nick Thomas
Assignee Loading
Time tracking Loading