notes:
this is controlled by the temporary flag
instead of the text "search goes here", there is a basic html scoped search

The spec doesn't describe the width of the full component, but only the Select part. Is it right to assume that the width should be defined by whatever controls the width of the current TypeaheadSearch element?

Change #1116801 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/skins/Vector@master] Add support for Wikibase scoped typehead search

https://gerrit.wikimedia.org/r/1116801

Change #1116803 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Enable typeahead search in vector for tmpEnableScopedTypeaheadSearch

https://gerrit.wikimedia.org/r/1116803

Change #1117515 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Restrict SpecialSearch by selected scope

https://gerrit.wikimedia.org/r/1117515

From the daily: it’s okay if the CSS-only version doesn’t have functional scoping. For visual consistency between no-JS and JS versions, we’re thinking of still putting a <select> in the no-JS version, but without any other options – by default it looks like the JS version (“Items” selected) but if you open the <select>, it just shows a disabled option like “this feature is not available without JavaScript” or similar.

Change #1117515 abandoned by Arthur taylor:

[mediawiki/extensions/Wikibase@master] Restrict SpecialSearch by selected scope

Reason:

No longer needed as the no-JS search is not restricted by scope

https://gerrit.wikimedia.org/r/1117515

Test wiki created on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/d98a3dd59e/w/

Test wiki created on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/e4bb62d0a4/w/

Test wiki on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/d98a3dd59e/w/

Test wiki created on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/22cac51637/w/

Test wiki on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/e4bb62d0a4/w/

Test wiki created on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/2dfe9857c0/w/

Test wiki on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/22cac51637/w/

Also from task description, pls note: fit-content doesn't fulfill our current basic browser support requirements, which specifically apply to CSS. Ensure that it is a falling back with acceptable rendering without.

A few of us are out next week. I'll reach out soon and organize something for the week of the 24th. Thanks for your patience!

Sounds good - thanks. Please include @karapayneWMDE and @Arian_Bozorg in planning.

In T384943#10505480, @AudreyPenven_WMDE wrote:

Is it right to assume that the width should be defined by whatever controls the width of the current TypeaheadSearch element?

That's right, @AudreyPenven_WMDE. This is the common approach for system components that don't wrap their content (e.g. buttons).

The spec doesn't describe the width of the full component, but only the Select part.

I just checked the component specs, and the width defined in them actually only applies to the Select's menu. On the other hand, I realized that the menu is missing a min-width of 100% to prevent scenarios like the following:

There doesn't seem to be any width defined for the Select component itself, but it'd make sense to also make it wrap its content by default. We should probably enforce a max-width for the Select, and apply ellipsis to its value to avoid "eating up too much space" from the search input in case the selected option is too long (i.e., for certain translations). Unfortunately, 256px is too big of a width/threshold for this composition, and alternative system sizes are too small or even bigger. Since this might be an edge case, I'd say it might be ok to wait and apply the mentioned solution if we detect there's a problem. (In which case, I would go for a custom 160px/10em max-width).

I'm sorry for leaving room for assumptions. These specs never reached a point of being fully polished or properly reviewed due to conflicting priorities. I cannot actively follow the team's progress, but please feel free to ping me if any other design doubts come up.

Codex has a mixin for text inputs with an end button. These styles are what makes the button flush with the input box. This is done by removing the rounded corners and causing the neighboring borders to overlap.

We'll need to do something similiar with the select dropdown at the start of the input.

There's actually a comment in the linked file that says:

// TODO: also support start buttons (for things like NumberInput).

A few of us met today and our understanding is that we can decline this ticket (at least for now). When the search input is focused via JavaScript, the namespace dropdown will display.

I plan to meet with an engineer from WMDE over the next 2 weeks to get input on the web team's plans to move TypeaheadSearch out of Vector to make sure this doesn't break the WMDE integration and that we get input about how we can better organize code to support WMDE's custom TypeaheadSearch. @karapayneWMDE will connect me with someone (hopefully next week and at a more comfortable time given our time zones!).

Meeting attendees:
@karapayneWMDE @CCiufo-WMF @Jdrewniak @AnneT @Jdlrobson-WMF @Arian_Bozorg

Please let me know if anything above is inaccurate and thanks in advance!

Thank you all for your time today!

Test wiki on Patch demo by Arthur Taylor (WMDE) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/2dfe9857c0/w/

without API changes, there was no good way to have a non-js version that would work. instead we've solved it with an animation of the select dropdown sliding into existence

Change #1116803 abandoned by Arthur taylor:

[mediawiki/extensions/Wikibase@master] Enable typeahead search in vector for tmpEnableScopedTypeaheadSearch

Reason:

this approach abandoned in favour of direct search module support in vector.

https://gerrit.wikimedia.org/r/1116803

Change #1116801 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] Add support for Wikibase scoped typeahead search

Reason:

Associated task has been resolved via other changes. Please raise a new ticket if you need anything else!

https://gerrit.wikimedia.org/r/1116801