Limit the width of the document selectors to the width of the parent.

[larseggert]

It's unfortunately not responsive (select2 limitation), but better than being too long.

[codecov]

Codecov Report

Merging #4968 (fc3e3d8) into main (0cc907f) will decrease coverage by 0.01%.
The diff coverage is n/a.

❗ Current head fc3e3d8 differs from pull request most recent head 96c83fd. Consider uploading reports for the commit 96c83fd to get more accurate results

@@            Coverage Diff             @@
##             main    #4968      +/-   ##
==========================================
- Coverage   88.48%   88.47%   -0.02%     
==========================================
  Files         296      296              
  Lines       39818    39818              
==========================================
- Hits        35234    35229       -5     
- Misses       4584     4589       +5     

Impacted Files	Coverage Δ
ietf/utils/pipe.py	82.60% <0.00%> (-4.35%)	⬇️
ietf/utils/text.py	86.58% <0.00%> (-1.22%)	⬇️
ietf/group/utils.py	93.72% <0.00%> (-0.90%)	⬇️
ietf/nomcom/utils.py	91.30% <0.00%> (-0.25%)	⬇️
ietf/doc/views_search.py	89.02% <0.00%> (ø)
ietf/utils/fields.py	91.75% <0.00%> (+0.54%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[jennifer-richards]

What do you mean by "it's not responsive"? (I understand the words, but not sure what you're getting at.)

If I understand what it's doing, it should be computing the style seen by the select element and applying that to select2's magic. Does applying responsive style to the input not pass through correctly?

[larseggert]

I mean that if you resize the window, it doesn't grow or shrink.

[jennifer-richards]

Interesting. I toyed with it on Firefox here and it seemed to behave reasonably when the window was narrow. If I put a %-based style on the select, that caused it to track the window width (without that, it started narrower than the window allowed).

In any case, it looks fine to me.

[larseggert]

What I mean that it looks fine with the change, but when you then narrow or widen the window, the select doesn't grow or shrink.

[jennifer-richards]

I see what you mean now. Not sure why I didn't notice before - I must have mixed up what I was looking at.

If I put an explicit style="width: 100% on the field then it expands/shrinks with the width and never exceeds the page width. With that, it seems to behave the same with or without the data-width="resolve". Maybe add this to the CSS as a workaround instead or in addition to the change in this PR?

[larseggert]

@jennifer-richards I can't style="width: 100%;" to work? It just stays too large.

[jennifer-richards]

Maybe I'm misunderstanding the intention and wandering into the woods. For me, the width tracks the <div class="col-sm-10">, so 100% is indeed quite wide, but not wider than the div.

[larseggert]

This is what I see now:

With the PR, it becomes:

But when you widen the window, it stays at that width:

[jennifer-richards]

Ah, ok. I was looking at a different view (that template is also used on the 'History' tab). It looks to me like there are other width problems on the sidebar. Note the up-arrow button at the top in this screenshot - it's running off the viewport just like the select boxes. I think they're accurately filling a parent that's too wide. (In the screenshot, the top select has both style="width:100%;" and data-width="resolve', while the bottom has neither. They both seem to behave the same.)

[larseggert]

Yes, the button is in the top right of the sidebar and the sidebar gets stretched too wide by the select.

[jennifer-richards]

Ah, I see. I haven't found anything that behaves better than your patch. It'd be nice if it could at least show the end of the selected value - that has more useful info than the start.

[jennifer-richards]

That looks much better.

On a lark, I tried throwing in a window resize handler that destroys and re-initializes the select2 fields. It worked great when increasing the width of the window but still happily stretched off the viewport when decreasing it. It really doesn't want to do the right thing...