Inconsistent placement of icons

[Ryuno-Ki]

When expanding the HTML elements in the side navigation of http://localhost:5000/en-US/docs/Web/HTML

the icons appear before the list items.

However, in other places (take http://localhost:5000/en-US/docs/Web/HTML/Element/table for example), the icons are shown behind the name. I'd vote for this approach to keep it consistent.
I tried pulling out the icons to the left, so that the element names aligns nicely, but that will fail once more than one icon applies. Thus, turning it into a suffix is preferable.

[peterbe]

@schalkneethling Can you triage this? I'm sure I've filed an issue about it before but I couldn't find it from a quick search. Perhaps it got closed by mistake in the rush to land Fiori.
But who cares, it's still a bug.

[schalkneethling]

This is not ideal but is a decision we made after exploring various design options. Because the number of icons that can be associated with a sidebar menu entry is variable we settled on the current design implementation. While moving the icons to the end of the menu entry, you do get the text to all align on the left but, you could also run into situations like this:

or even this:

This is not set in stone, however, and I am happy to have a discussion around this. If people generally feel that the icons work better at the end of an entry than the current implementation, we can change.

[peterbe]

Your argument is so good that it justifies de-prioritizing this issue. To add to your argument, yes, it becomes harder to eye-scan down the list when you have move horizontally a bit too. But, the icons are there to call to your attention which is important for your knowledge acquisition too. I.e. you really should pay attention to the fact that <hgroup> is an experimental HTML element after all.

So, shall we make this a post-launch instead of a Yari1 one?

[tannerdolby]

I've been going through the issues in Developer Insights to try pruning away old issues that could use a fix or be closed as they have already been resolved.

After reading the comments in this thread, it seems like icons are no longer displayed on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table but they are still around for https://developer.mozilla.org/en-US/docs/Web/HTML for which they appear at the beginning of the line on the left of the text.

This is not set in stone, however, and I am happy to have a discussion around this. If people generally feel that the icons work better at the end of an entry than the current implementation, we can change.

@schalkneethling I personally think the icons look fine and make sense being placed at the beginning of the line, if there was a readability or a11y gain by moving them to the end of the line, then I might be for that, but at the current moment I can't see any valid reason to reposition the icons.

[tannerdolby]

There is one situation where it made me scratch my head a bit on https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String where the icon is above its corresponding text similar to how two block elements would stack. You've already sort of touched on the drawbacks of the design implementation having the icons at the end of the line for similar reasons. The <svg> appears inline with the <code> text at larger viewport widths but when decreasing the screen size many of the <svg> icons appear on top of their corresponding <code> instead acting inline and wrapping to the next line (breaking words if needed).

I think the point I'm getting at is, Should the <svg> icons always keep their default display: list-item behavior or change to a different layout to ensure that the <svg> and <code> always appear "next" to eachother even if the code text wraps to the next line. The list-item display works for about 90% of viewport widths but there are spots where the icons occupy a separate line than the <a> text with icon on top of text, if we add float: left to the nested <svg> elements they will always be positioned on the same line and the inline <a> element is free to overflow and wrap onto the next line.

[tannerdolby]

@schalkneethling Using display: flex or essentially any other display value to the <li> elements won't fix things in terms of keeping the <svg> and <a> inline but allowing the <a> to break and wrap onto the next line. It seems that using float: left on the <svg> elements fixes the problem of the <svg> appearing above the <a> on a separate line, with float: left the icon and text will always appear on the same line even if the code text overflows and wraps to next line. If we give both .icon-deprecated and .icon-nonstandard a float: left like:

.sidebar .icon-deprecated {
    color: #95353a;
    float: left;
}

Updated with float: left added to <svg> icons:

The icons are now always on the same line as the <a> text and inline elements like the anchor tag with nested <code> will wrap onto the next line. One small hiccup is that adding float: left does bump the icon up about 1px which makes it horizontally misaligned by just a few pixels. Giving the .icon-deprecated and .icon-nonstandard selectors a top margin of 3px seems to do the trick and matches the same alignment has previously achieved before changes. Alignment is fixed and the icons/text always are next to eachother for when display: list-item moves them to separate lines when <a> is long and overflows.

After adding margin-top: 3px to both the nested svg elements:

[schalkneethling]

Thank you for looking into this @tannerdolby. That last suggestion does indeed improve the situation. As mentioned in another issue, we are working on a redesign of MDN Web Docs and the sidebars will be a big part of it. Feedback and suggestions are super welcome and appreciated but, I would not want to put too much work into it before we have finalised our possible approach.

I reckon what I am going to do is start a discussion around sidebars to gather people's feedback and suggestions and reference this and the other issue there as a conversation starter 😄

[schalkneethling]

@tannerdolby #4033

[tannerdolby]

Your welcome @schalkneethling. Yeah I thought the last suggestion of adding float: left to the child <svg> elements with a bit of top margin improved the situation, but your right its best we don't put too much work into this before finalising a possible approach.

I reckon what I am going to do is start a discussion around sidebars to gather people's feedback and suggestions and reference this and the other issue there as a conversation starter 😄

Agreed. I will head over to #4033 and participate in the discussion, I think my PR #4027 is ready for closing until we come to a conclusion on a design path for sidebars when discussion is resolved.

[Ryuno-Ki]

I'm fine with seeing this issue closed until #4033 yields a direction to follow.

[mirunacurtean]

Just an update with the latest layout of the icons+text in the sidebar after redesign, on production and tag it as a known issue for QA at this point.

[schalkneethling]

Just an update with the latest layout of the icons+text in the sidebar after redesign, on production and tag it as a known issue for QA at this point.

Thanks, @mirunacurtean. There needs to be a larger discussion on this, so I will start a discussion and let you know so we can direct all discussions there until we have an actionable decision around this problem.

[schalkneethling]

Closing in favour of the discussion started here: mdn/mdn-community#69