[Design] Input styles in mediawiki.ui right now

[Steven Walling]

Hi all,

In the interest of closer collaboration, Jon and Matt have merged a patch
to upstream new mw-ui-input styles, which I believe originated in Flow.
It's at https://gerrit.wikimedia.org/r/#/c/149173/

I'm glad we merged this sooner rather than later, since it means there are
fewer Flow-specific overrides on top of mediawiki.ui and it forces us to
have a cross-team discussion. However, with the new input styles going out
on desktop search, log in, and create account there are some design issues
we need to resolve.

1. This appears to have caused a regression, where the CAPTCHA input
field on create account is not styled correctly. It's now way too small for
the container.
2. We now have multiple indicator styles showing up. In form fields, the
blue bar on the left appears. On elements like page links and checkboxes,
the softer blue outline appears. This mixed experience is distracting.
3. The left-aligned blue bar is way too close to the cursor, and makes
it harder to see where it is. In an RTL language like Hebrew, the blue bar
overlaps entirely with the cursor.

You can see all of these by checking out the relevant forms on Beta Labs
right now. You can see the previous forms on English Wikipedia, or via the
style guide (which hasn't been updated yet):
http://tools.wmflabs.org/styleguide/desktop/section-3.html

Overall, the issues identified lead me to believe this new input indicator
is the wrong way to go for now. This is particularly true when you consider
that previously one input indicator was applied to all elements
consistently, and with the new style you see both the blue outline and the
new in-field indicator depending on which element type you're selecting.
I'm okay updating form-by-form with mediawiki.ui, but the forms themselves
cannot be sloppy like this.

On a related issue, but not caused by the latest updates: we need to sort
out what the type styles are for forms and buttons. Right now I am getting
the system font of Lucida Grande. That doesn't appear to meet the spec,
according to the Trello card mocks like https://trello.com/c/8FOi1X1x and
https://trello.com/c/4TfdOik8. Let's update so at least we're using the
plain sans-serif, so the user is not getting a mix of different sans-serifs
on one form.

[Jon Robson]

Hi Steven

Post by Steven Walling
Hi all,
In the interest of closer collaboration, Jon and Matt have merged a patch to
upstream new mw-ui-input styles, which I believe originated in Flow. It's at
https://gerrit.wikimedia.org/r/#/c/149173/
I'm glad we merged this sooner rather than later, since it means there are
fewer Flow-specific overrides on top of mediawiki.ui and it forces us to
have a cross-team discussion. However, with the new input styles going out
on desktop search, log in, and create account there are some design issues
we need to resolve.

Yes, I'm sure there will be some teething problems but right now I
think getting our teams using standard UI elements and site
consistency should be the top priority.

Post by Steven Walling
This appears to have caused a regression, where the CAPTCHA input field on
create account is not styled correctly. It's now way too small for the
container.

I'm working on a fix as we speak.

Post by Steven Walling
We now have multiple indicator styles showing up. In form fields, the blue
bar on the left appears. On elements like page links and checkboxes, the
softer blue outline appears. This mixed experience is distracting.

Can you give some example pages of this?

Post by Steven Walling
The left-aligned blue bar is way too close to the cursor, and makes it
harder to see where it is. In an RTL language like Hebrew, the blue bar
overlaps entirely with the cursor.

I will let designers comment on that

Post by Steven Walling
You can see all of these by checking out the relevant forms on Beta Labs
right now. You can see the previous forms on English Wikipedia, or via the

Please please please someone find a way to auto-update this. This is
supposed to be a living style guide and that's embarrassing :) Any
takers?

On a side note: whether we decide to stick with the design or not, we
only now need to change it in one place and I think that's awesome.

PS. Please make mediawiki ui checkboxes happen:
https://gerrit.wikimedia.org/r/#/c/149121/ it would be great to have
BetaFeatures, core and other extensions using the same checkbox
element!

[Steven Walling]

Post by Jon Robson

Post by Steven Walling
We now have multiple indicator styles showing up. In form fields, the

blue

Post by Steven Walling
bar on the left appears. On elements like page links and checkboxes, the
softer blue outline appears. This mixed experience is distracting.

Can you give some example pages of this?

Login form, which has a checkbox. You can also tab through any page until
you get to something that's not a text field. With the text field blue bar,
blue outline glow, and the hover state for mw.ui buttons, we've three
wildly different indicators going on.

The simple fix here is to revert everything to use the normal blue outline,
which is way less distracting.

[Jon Robson]

https://gerrit.wikimedia.org/r/150464 Fixes captcha
PS. Are we aware account creation is impossible without JavaScript on
desktop (on mobile it is fine..)..?

Post by Jon Robson
Hi Steven

Post by Steven Walling
Hi all,
In the interest of closer collaboration, Jon and Matt have merged a patch to
upstream new mw-ui-input styles, which I believe originated in Flow. It's at
https://gerrit.wikimedia.org/r/#/c/149173/
I'm glad we merged this sooner rather than later, since it means there are
fewer Flow-specific overrides on top of mediawiki.ui and it forces us to
have a cross-team discussion. However, with the new input styles going out
on desktop search, log in, and create account there are some design issues
we need to resolve.

Yes, I'm sure there will be some teething problems but right now I
think getting our teams using standard UI elements and site
consistency should be the top priority.

Post by Steven Walling
This appears to have caused a regression, where the CAPTCHA input field on
create account is not styled correctly. It's now way too small for the
container.

I'm working on a fix as we speak.

Post by Steven Walling
We now have multiple indicator styles showing up. In form fields, the blue
bar on the left appears. On elements like page links and checkboxes, the
softer blue outline appears. This mixed experience is distracting.

Can you give some example pages of this?

Post by Steven Walling
The left-aligned blue bar is way too close to the cursor, and makes it
harder to see where it is. In an RTL language like Hebrew, the blue bar
overlaps entirely with the cursor.

I will let designers comment on that

Post by Steven Walling
You can see all of these by checking out the relevant forms on Beta Labs
right now. You can see the previous forms on English Wikipedia, or via the

Please please please someone find a way to auto-update this. This is
supposed to be a living style guide and that's embarrassing :) Any
takers?
On a side note: whether we decide to stick with the design or not, we
only now need to change it in one place and I think that's awesome.
https://gerrit.wikimedia.org/r/#/c/149121/ it would be great to have
BetaFeatures, core and other extensions using the same checkbox
element!

[Jon Robson]

Also https://gerrit.wikimedia.org/r/150465

In terms of checkbox glow, that goes away when merging the mw-ui-checkbox patch.

I'd rather not do any reverts the process so far has already been
painful and I think it would be better to put up with pain and work
towards a long term solution then worry about more short term
inconsistencies.

Post by Jon Robson
https://gerrit.wikimedia.org/r/150464 Fixes captcha
PS. Are we aware account creation is impossible without JavaScript on
desktop (on mobile it is fine..)..?

Post by Jon Robson
Hi Steven

Post by Steven Walling
Hi all,
In the interest of closer collaboration, Jon and Matt have merged a patch to
upstream new mw-ui-input styles, which I believe originated in Flow. It's at
https://gerrit.wikimedia.org/r/#/c/149173/
I'm glad we merged this sooner rather than later, since it means there are
fewer Flow-specific overrides on top of mediawiki.ui and it forces us to
have a cross-team discussion. However, with the new input styles going out
on desktop search, log in, and create account there are some design issues
we need to resolve.

Yes, I'm sure there will be some teething problems but right now I
think getting our teams using standard UI elements and site
consistency should be the top priority.

Post by Steven Walling
This appears to have caused a regression, where the CAPTCHA input field on
create account is not styled correctly. It's now way too small for the
container.

I'm working on a fix as we speak.

Post by Steven Walling
We now have multiple indicator styles showing up. In form fields, the blue
bar on the left appears. On elements like page links and checkboxes, the
softer blue outline appears. This mixed experience is distracting.

Can you give some example pages of this?

Post by Steven Walling
The left-aligned blue bar is way too close to the cursor, and makes it
harder to see where it is. In an RTL language like Hebrew, the blue bar
overlaps entirely with the cursor.

I will let designers comment on that

Post by Steven Walling
You can see all of these by checking out the relevant forms on Beta Labs
right now. You can see the previous forms on English Wikipedia, or via the

Please please please someone find a way to auto-update this. This is
supposed to be a living style guide and that's embarrassing :) Any
takers?
On a side note: whether we decide to stick with the design or not, we
only now need to change it in one place and I think that's awesome.
https://gerrit.wikimedia.org/r/#/c/149121/ it would be great to have
BetaFeatures, core and other extensions using the same checkbox
element!

--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson

[Steven Walling]

Post by Jon Robson
I'd rather not do any reverts the process so far has already been
painful and I think it would be better to put up with pain and work
towards a long term solution then worry about more short term
inconsistencies.

Sure, I'm all for followup patches rather than reverts. Improve what can be
improved, and remove what can't. But the current forms are a mess. The
usability and aesthetics of login and signup directly impact our highest
priorities as an organization, so it's not okay to let them degrade in the
name of hypothetical future improvements.

[Erik Moeller]

Post by Steven Walling
Sure, I'm all for followup patches rather than reverts. Improve what can be
improved, and remove what can't. But the current forms are a mess. The
usability and aesthetics of login and signup directly impact our highest
priorities as an organization, so it's not okay to let them degrade in the
name of hypothetical future improvements.

I agree we have to be wary about consistency. I'm not sure putting
these kinds of changes on the release train incrementally is the way
to go -- perhaps having a test instance in Labs run a WIP changeset or
branch til we're happy with it, including things like RTL testing?

We do have a bit more time since the release train is slowing down
over the Wikimania period, AIUI.

With that said, kudos for moving this forward :)

Erik

[Shahyar Ghobadpour]

On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
I'm glad we merged this sooner rather than later, since it means there are
fewer Flow-specific overrides on top of mediawiki.ui and it forces us to
have a cross-team discussion.

Flow doesn't use overrides on top of mediawiki.ui (except for mw-ui-button,
which only started recently). We wrote all mw-ui components independently
of Core, using a flow-ui prefix -- including a rewrite of mw-ui-button,
which I felt had become too messy and confusing. When I felt that the
flow-ui versions had reached a certain level of maturity, I'd put them for
review into Core's gerrit as mw-ui components.

Post by Steven Walling
I agree we have to be wary about consistency. I'm not sure putting
these kinds of changes on the release train incrementally is the way
to go -- perhaps having a test instance in Labs run a WIP changeset or
branch til we're happy with it, including things like RTL testing?

This is specifically the reason I was using Flow as the testbed to develop
and iterate upon the mw-ui components. However, I think my team jumped the
gun on putting this into Core without fully testing all of the use cases. I
take responsibility for this, as I should have been more careful to a)
include i18n people in the design mocks, and b) thoroughly test any current
uses of affected mw-ui components being moved to Core.


Going forward, I think we will need to shift from a single +2 in gerrit, to
a +1 from several teams (perhaps Flow, Growth, Mobile, and Language),
before approving a merge to Core. For these mediawiki.ui design goals to
succeed, we'll need to make sure we have our primary bases covered via
these teams.

--Shahyar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140730/2e16747f/attachment.html>

[Steven Walling]

On Tue, Jul 29, 2014 at 10:08 PM, Shahyar Ghobadpour <

Post by Shahyar Ghobadpour
This is specifically the reason I was using Flow as the testbed to develop
and iterate upon the mw-ui components. However, I think my team jumped the
gun on putting this into Core without fully testing all of the use cases. I
take responsibility for this, as I should have been more careful to a)
include i18n people in the design mocks, and b) thoroughly test any current
uses of affected mw-ui components being moved to Core.

In this case, it's not just any one person's process failure. Jon did come
to Matt and I, we also didn't fully realize the implications and test
things properly. In the meantime, we have plenty of time to clean up some
things, since it doesn't look like this will go out with 1.24wmf15? After
that release to the wikis this week, deployments will get frozen until
after Wikimania.

Going forward, I think we will need to shift from a single +2 in gerrit, to

Post by Shahyar Ghobadpour
a +1 from several teams (perhaps Flow, Growth, Mobile, and Language),
before approving a merge to Core. For these mediawiki.ui design goals to
succeed, we'll need to make sure we have our primary bases covered via
these teams.

Something like this would be good for a shared library. In our
retrospectives (notes at Growth/Retrospectives on mediawiki.org) we already
committed to giving people a heads up about large mediawiki.ui changes
before we submit them, so that y'all can comment.

[Jon Robson]

Yeah the input case was a kind of weird one as there was undocumented use
of mw-ui-input throughout mediawiki in Special:Search and Special:UserLogin
(it was in the less file and in usage but not in the style guide). May has
suggested linking to live examples in future which I think will help with
this.

I think as a rule we should all get into the habit of making MediaWiki ui
the de facto place for new components and ensuring documentation of when
and how to use is kept to standards. I like the idea of each change
requiring a +1 from the main teams that use it (which I think are Flow,
Growth and Mobile correct me if wrong). e.g. +3 :) I'm happy to see mobile,
Flow and growth caring about the same problems and things getting merged
more rapidly then we have done previously. I'm keen to keep this momentum.

Maybe its worth getting together people not going to Wikimania and getting
mw-ui-input styling resolved in a way that makes everyone happy and keeps
the solution generalised and consistent ?

We may also want to consider a beta concept of mediawiki ui that allows us
to hide experimental styling behind additional modifier classes. I'm keen
for teams to rapidly prototype and experiment with new design ideas but to
do so in a way that keeps compatibility. e.g. mw-ui-beta .mw-ui-button
On 29 Jul 2014 22:08, "Shahyar Ghobadpour" <sghobadpour at wikimedia.org>

Post by Shahyar Ghobadpour
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
I'm glad we merged this sooner rather than later, since it means there
are fewer Flow-specific overrides on top of mediawiki.ui and it forces us
to have a cross-team discussion.

Flow doesn't use overrides on top of mediawiki.ui (except for
mw-ui-button, which only started recently). We wrote all mw-ui components
independently of Core, using a flow-ui prefix -- including a rewrite of
mw-ui-button, which I felt had become too messy and confusing. When I felt
that the flow-ui versions had reached a certain level of maturity, I'd put
them for review into Core's gerrit as mw-ui components.

Post by Steven Walling
I agree we have to be wary about consistency. I'm not sure putting
these kinds of changes on the release train incrementally is the way
to go -- perhaps having a test instance in Labs run a WIP changeset or
branch til we're happy with it, including things like RTL testing?

This is specifically the reason I was using Flow as the testbed to develop
and iterate upon the mw-ui components. However, I think my team jumped the
gun on putting this into Core without fully testing all of the use cases. I
take responsibility for this, as I should have been more careful to a)
include i18n people in the design mocks, and b) thoroughly test any current
uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit,
to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language),
before approving a merge to Core. For these mediawiki.ui design goals to
succeed, we'll need to make sure we have our primary bases covered via
these teams.
--Shahyar
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140729/9a34c5aa/attachment-0001.html>

[Jared Zimmerman]

A few small issues



- The Vform button doesn't seem to have any vertical padding
- the create account button on the login page bottom hover bezel is
weirdly thin and inconsistent
- checkbox isn't mv.ui style yet even though its appearing in the living
style guide




*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

Post by Jon Robson
Yeah the input case was a kind of weird one as there was undocumented use
of mw-ui-input throughout mediawiki in Special:Search and Special:UserLogin
(it was in the less file and in usage but not in the style guide). May has
suggested linking to live examples in future which I think will help with
this.
I think as a rule we should all get into the habit of making MediaWiki ui
the de facto place for new components and ensuring documentation of when
and how to use is kept to standards. I like the idea of each change
requiring a +1 from the main teams that use it (which I think are Flow,
Growth and Mobile correct me if wrong). e.g. +3 :) I'm happy to see mobile,
Flow and growth caring about the same problems and things getting merged
more rapidly then we have done previously. I'm keen to keep this momentum.
Maybe its worth getting together people not going to Wikimania and getting
mw-ui-input styling resolved in a way that makes everyone happy and keeps
the solution generalised and consistent ?
We may also want to consider a beta concept of mediawiki ui that allows us
to hide experimental styling behind additional modifier classes. I'm keen
for teams to rapidly prototype and experiment with new design ideas but to
do so in a way that keeps compatibility. e.g. mw-ui-beta .mw-ui-button
On 29 Jul 2014 22:08, "Shahyar Ghobadpour" <sghobadpour at wikimedia.org>

Post by Shahyar Ghobadpour
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
I'm glad we merged this sooner rather than later, since it means there
are fewer Flow-specific overrides on top of mediawiki.ui and it forces us
to have a cross-team discussion.

Flow doesn't use overrides on top of mediawiki.ui (except for
mw-ui-button, which only started recently). We wrote all mw-ui components
independently of Core, using a flow-ui prefix -- including a rewrite of
mw-ui-button, which I felt had become too messy and confusing. When I felt
that the flow-ui versions had reached a certain level of maturity, I'd put
them for review into Core's gerrit as mw-ui components.

Post by Steven Walling
I agree we have to be wary about consistency. I'm not sure putting
these kinds of changes on the release train incrementally is the way
to go -- perhaps having a test instance in Labs run a WIP changeset or
branch til we're happy with it, including things like RTL testing?

This is specifically the reason I was using Flow as the testbed to
develop and iterate upon the mw-ui components. However, I think my team
jumped the gun on putting this into Core without fully testing all of the
use cases. I take responsibility for this, as I should have been more
careful to a) include i18n people in the design mocks, and b) thoroughly
test any current uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit,
to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language),
before approving a merge to Core. For these mediawiki.ui design goals to
succeed, we'll need to make sure we have our primary bases covered via
these teams.
--Shahyar
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/design/attachments/20140818/bd506340/attachment-0001.html>

[S Page]

Also I noticed

- The new input indicator is using a different blue ( I filed
https://bugzilla.wikimedia.org/show_bug.cgi?id=69040 ). It was never
spec'd!
- When you stack mw-ui-input-large and plain mw-ui-input , the left
margin indents don't match, see at
http://tools.wmflabs.org/styleguide/desktop/section-1.html . The text
input and textarea in Flow "Start a new topic" are aligned.


On Mon, Aug 18, 2014 at 1:04 PM, Jared Zimmerman <

Post by Jared Zimmerman
A few small issues

- The Vform button doesn't seem to have any vertical padding
- the create account button on the login page bottom hover bezel is
weirdly thin and inconsistent
- checkbox isn't mv.ui style yet even though its appearing in the
living style guide

[Maryana Pinchuk]

I like the idea of each change requiring a +1 from the main teams that
use it (which I think are Flow, Growth and Mobile correct me if wrong).

Yeahhh, that would definitely be worth considering – I just noticed this
change show up on the mobile site, and it has a few mobile-specific bugs
that need to get ironed out (I reported the issues on BZ:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69724).

Always good to get at least one MFE engineer's eyes on any change likely to
affect mobile before it gets merged; it's either that or the much more
ambitious goal of getting every WMF engineer to remember to test
user-facing changes vigorously on phones and tablets (which I do hope we'll
get to one day...) ;)

e.g. +3 :) I'm happy to see mobile, Flow and growth caring about the same
problems and things getting merged more rapidly then we have done
previously. I'm keen to keep this momentum.
Maybe its worth getting together people not going to Wikimania and getting
mw-ui-input styling resolved in a way that makes everyone happy and keeps
the solution generalised and consistent ?
We may also want to consider a beta concept of mediawiki ui that allows us
to hide experimental styling behind additional modifier classes. I'm keen
for teams to rapidly prototype and experiment with new design ideas but to
do so in a way that keeps compatibility. e.g. mw-ui-beta .mw-ui-button
On 29 Jul 2014 22:08, "Shahyar Ghobadpour" <sghobadpour at wikimedia.org>

Post by Shahyar Ghobadpour
On Tue, Jul 29, 2014 at 4:29 PM, Steven Walling <swalling at wikimedia.org>

Post by Steven Walling
I'm glad we merged this sooner rather than later, since it means there
are fewer Flow-specific overrides on top of mediawiki.ui and it forces us
to have a cross-team discussion.

Flow doesn't use overrides on top of mediawiki.ui (except for
mw-ui-button, which only started recently). We wrote all mw-ui components
independently of Core, using a flow-ui prefix -- including a rewrite of
mw-ui-button, which I felt had become too messy and confusing. When I felt
that the flow-ui versions had reached a certain level of maturity, I'd put
them for review into Core's gerrit as mw-ui components.

Post by Steven Walling
I agree we have to be wary about consistency. I'm not sure putting
these kinds of changes on the release train incrementally is the way
to go -- perhaps having a test instance in Labs run a WIP changeset or
branch til we're happy with it, including things like RTL testing?

This is specifically the reason I was using Flow as the testbed to
develop and iterate upon the mw-ui components. However, I think my team
jumped the gun on putting this into Core without fully testing all of the
use cases. I take responsibility for this, as I should have been more
careful to a) include i18n people in the design mocks, and b) thoroughly
test any current uses of affected mw-ui components being moved to Core.
Going forward, I think we will need to shift from a single +2 in gerrit,
to a +1 from several teams (perhaps Flow, Growth, Mobile, and Language),
before approving a merge to Core. For these mediawiki.ui design goals to
succeed, we'll need to make sure we have our primary bases covered via
these teams.
--Shahyar
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Matthew Flaschen]

Post by Maryana Pinchuk
Always good to get at least one MFE engineer's eyes on any change likely
to affect mobile before it gets merged; it's either that or the much
more ambitious goal of getting every WMF engineer to remember to test
user-facing changes vigorously on phones and tablets (which I do hope
we'll get to one day...) ;)

It's Jon's change (https://gerrit.wikimedia.org/r/#/c/149173/).
However, I do respect your point about testing on mobile.

Matt Flaschen

[Jon Robson]

Yeh that was my fault. The issue with MobileFrontend is there are
various places, login form included that monkey patch core
functionality. One of my goals this year is to eradicate those, so
styling for mobile becomes less difficult. I've submitted a patch to
fix that [1]. Echo is another one and I'm working with BSitu to sort
this out.

This bug [2]] is also another great example of where mobile is
currently doing its own thing and not using MediaWiki UI where it
possibly should be.

/me imagines a situation where all the teams put their rings together
and become code merging power rangers

[1] https://gerrit.wikimedia.org/r/154979
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=69487

On Mon, Aug 18, 2014 at 5:10 PM, Matthew Flaschen

Post by Maryana Pinchuk
Always good to get at least one MFE engineer's eyes on any change likely
to affect mobile before it gets merged; it's either that or the much
more ambitious goal of getting every WMF engineer to remember to test
user-facing changes vigorously on phones and tablets (which I do hope
we'll get to one day...) ;)

It's Jon's change (https://gerrit.wikimedia.org/r/#/c/149173/). However, I
do respect your point about testing on mobile.
Matt Flaschen
_______________________________________________
Design mailing list
Design at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[Steven Walling]

Post by Jon Robson
PS. Are we aware account creation is impossible without JavaScript on
desktop (on mobile it is fine..)..?

I just created "User:Test user 239f23f0" with JavaScript disabled in
Safari. However, it looks like there's a bug where, if you have JS off and
you hit Enter instead of clicking the submit button, you get sent to
search. Ugh. Filing now...