hey @dang the file is an svg, shouldn't it be possible to make it any size you want? the file you're using also seems to not be the correct one since it does not include the text. the correct file is this one. can you try again with that?

my question was, whether we could also remove the border for when there's a warning

Hey @dang @Tarrow i'm wondering if this is expected behaviour?

@Andrew-WMDE looks fantastic, thanks!

1. unfortunately the margin is not correct yet. it currently looks like this at 320px

Hey all, this looks great but could we remove the gap between the number and its respective metric?

hey @dang there is no netlify link for me to click to review your changes. could you please provide it for me? thanks!

In T301390#10362224, @Andrew-WMDE wrote:

In T301390#10347767, @Charlie_WMDE wrote:

Hey @Andrew-WMDE

1. validation: currently the domain input field gets validated after the terms of use. I can input an invalid domain name and click CREATE WIKI and the error I get is for the terms of use checkbox. Only once that is selected, I get an error in the domain name input field. (see screenshot)
   
   Would it be possible, to do the validation in order of the components?

Checking whether or not a domain is valid is done server-side, which happens after the form is submitted to our servers. Verifying that the user accepted our "Terms of Use" occurs before anything is submitted. Modifying this behavior is sort of out of scope for this ticket.

sure, i'll schedule us a slot

looks great, thanks!

Hey all! Everything looks good to me except that the labels aren't bolded. Looking at the codex specs, I gather that in the case of Label + description, the label should be bold. Is that something that you can still add?

hey @Andrew-WMDE i would like the look/behavior to stay as it currently is (current screenshot)

In T371369#10361479, @Tarrow wrote:

@Charlie_WMDE unfortunately there is no netlify preview for this. Are you happy to "post merge" review it?

For a quick peak from the branch I checked out

yay, that looks much better, thank you! 🤗

hey all, i'm struggling to find the netlify link to review the changes. could someone provide it for me please? thanks!

hey @HasanAkgun_WMDE when do you think the migration to vue3 would be complete and therefore this issue resolved? i would make it dependant on the timline, whether we come up with a workaround in the meantime. but in the end it would be a decision for @Arian_Bozorg

@Andrew-WMDE i want the styling of the vuetify 2 text button with an icon. which button style have you added the icon to?

for me the max width of the settings cards now ends up being 624px and of the features cards 880px. also the cards are now left aligned instead of centred. Do you encounter the same issue?

@Andrew-WMDE ah shit, i didn't realise adding an icon to a text style button isn't possible 😢 that's so dumb... what are our options here?

Hey @Anton.Kokh that's a great question. I had to google a bit myself to find the answer since it seem to be primarily a security best practice which then in turn created the UX best practice but from what I can tell the reasoning has to do with how the password is sent/stored and how it could potentially be reused by a malicious third party. I don't understand the exact technical reasons, but it seems like for now the web development world has agreed that that is the safest way to go about it, hence most login in pages display the behaviour you mentioned.

hey @dang i can not find the netlify link to review the changes. could you please provide it for me? thanks.

here are the things i noticed:

1. validation: currently the domain input field gets validated after the terms of use. I can input an invalid domain name and click CREATE WIKI and the error I get is for the terms of use checkbox. Only once that is selected, I get an error in the domain name input field. (see screenshot)
   
   Would it be possible, to do the validation in order of the components?

both points from my previous comment are resolved, thanks!

In T301390#10330999, @Andrew-WMDE wrote:

@Anton.Kokh should we also change "Your User" to "Your user" and "Terms of Use" to "Terms of use"?

everything looks perfect, thank you!

forgot to say: the placement of the deletete card looks good!

i notices two things:

looks good 🎉

looks good 👍

@Anton.Kokh the 320px are the reccomended min width by Codex and even before Codex that has been the smallest size we made sure to support because of accessibility reasons. You can read more about this WCAG requirement here.

hey @Anton.Kokh the proposed solution looks good to me 👍

Hey @Anton.Kokh , do I understand correctly that Questy Captcha is adding no additional protection unlike we intended? If that is the case I think we should have a look to see whether we can improve QuestyCaptcha in any way so that it does its job properly or consider deactivating it in lieu of a more effective alternative.

Hey @Anton.Kokh ! it doesn't overlap but to make it more clear i will change the title of this ticket to be more precise!

hey @HasanAkgun_WMDE thanks for the ping. Everything looks great except for one little thing I noticed.

Hey @ArthurTaylor, sorry for proposing a new size. I honestly didn't think to double check with codex sizes in the moment. Thank you for noticing and proposing a much better alternative! font-size-x-large sounds like a much better idea 🙏

thanks. let's keep that then and remove the new 8px margin :)

Had time earlier than I thought! Here's my two cents.

@ArthurTaylor yes, this looks great, thank you! i will try to do the reviews today

In T370053#10192965, @AudreyPenven_WMDE wrote:

@ArthurTaylor suggested in a different ticket to push the changes to beta from where i could then review the changes. would that be an option?

For reference, that suggestion is in T370052. Wherever that conversation ends up, we'll do the same to review this ticket.

I was curious where exactly the codex styling was coming from, and found that it comes from Vector's stylesheet for links. There's something similar in MinervaNeue

/* Vector/resources/skins.vector.styles/links.less */
a {
	.cdx-mixin-link-base();
	/* T373989 */
	border-radius: 0;
}

If one of these skins is used, all links are styled by Codex's Link mixin by default, unless they're overridden by more specific styling. The links mentioned in this ticket don't seem affected by overrides.

This does bring up a meta-question. @Charlie_WMDE, maybe you can help with this:
When we're applying Codex styles, should we override the skin's styles?
For Vector and MinervaNeue, it (probably) doesn't matter because they're the same. But I don't have a good sense about how other skins might be affected.

In T359861#10196026, @ItamarWMDE wrote:

In T359861#10186936, @Charlie_WMDE wrote:

Hey @ItamarWMDE

it looks to me like most things i noted in my previous comment are still happening.

Oh. Sorry about that :( , but I think most are actually part of another ticket. This ticket only replaces TextInput components, those are the Limit input at the bottom of the QB (as you've already noticed), and any string value input we might encounter (you can see it by default or if you choose a property that has a string, url or external-id data type, afaict).

Nice Catch! I should test more often in my native language 😅. This also helped resolve a mysterious issue we had with the whole condition not fitting into one row. Check out https://1075962--clicky-sparqly.netlify.app/ again to revalidate.

Yay, that's awesome, looks good now, thanks!

For some reason on this change (as opposed to T359861: [WtC-M3] [QB] Replace WiKit TextInput component by Codex's) I am able to reproduce the lack of validation. Something very odd is afoot. What do you say we put a pin in it (by creating a separate bug ticket) and perhaps getting back to it after the migration is done, to make sure that everything is fixed by then?

i think jumping on a call would work best for me as i don't have docker installed and the dev tools are not allowing me to make the changes i'd like to see (or i'm lacking the right skills to make it happen.) would this wednesday 3pm work for you?

@Anton.Kokh i updated the ticket description accordingly

I would very much appreciate that! testing on beta sounds like a great option.

@ArthurTaylor suggested in a different ticket to push the changes to beta from where i could then review the changes. would that be an option? without being able to inspect the changes myself i'm unfortunately not able to say whether a plain link style would be a good match for codex's link style :(

Hey @ArthurTaylor I know what the difference between rem and em is, what I was trying to figure out is, since I don't know the document's base font size or the parent element, what the sizes end up being in this particular case. Unfortunately in the dev tools of firefox, i can't change the size from em to rem myself to see how it would look like. That's why i was relying on information from you here. Would it be possible for you to show me how the actual asterisk size changes, depending on which value you input?

Hey all, I'd be super happy about the beta option. I have time next week and could do the review that way. Thanks for suggesting!

Hey @AudreyPenven_WMDE i'd be happy to review the version with the plain link to see if it matches the codex style in all it's specifications. Unfortunately the link in your last comment doesn't show the the correct UI and therefore I can't use it for a review. It looks like this to me

that's exactly the link i was looking at and as you can see it looks very different from what it probably looks like IRL. It would not make sense for me to review the changes using that link. How was Sarai doing your reviews?

@ArthurTaylor it's pretty much impossible for me to fo a review without being able to inspect the component, as I would have to go by eyesight alone which can be quite inacurate. In general a netlify link is always necessary and ideally I would do the review before the technical review is done, otherwise a second technical review is necessary if I find discrepancies and the code needs to be adjusted.

Hey @ArthurTaylor, regarding the asterisk i have a question. What would the font size change when switching from em to rem in absolute numbers (if that makes sense)? I see your point that 1.5 rem is way bigger than 1.5 em but i'm struggling to find documentation to relate the two to each other. My best guess would be that 1rem seems to come close to 1.5em? what do you think?

@Deniz_WMDE looks good, thanks Dena! I noticed that the snackbar gets cut off on the sides at 320px width (which is the min width we support) but this also happens with the other snackbars currently so I'll create a separate ticket to fix that

Hey @ArthurTaylor when I click the netlify link in the PR this is the UI i see

Hey @ArthurTaylor I'm not able to review this change without a netlify link. I followed the PR link and clicked the netlify link there but the UI I was presented with seemed very different from the screenshots that Lucas had posted in the same PR.

all looks good to me except in RTL it seems like the spacing between the text and the icon is not respected. could you have a look?

it looks to me like most things i noted in my previous comment are still happening.

I'm not super certain that the way i think the plaques work is correct, so please if you pick this up and realise it's actually different, feel free to do it your way. You can also always reach out to me to double check before doing something that might contradict my assumptions. Happy to pair!

@ItamarWMDE awesome! looks good to me now and thanks for filing the ticket for the farsi bug! <3

Huh, that makes me wonder why for Codex it was decided to go against current Nielsen/Norman reccomendations that Sarai mentions in her text. I find this a bit tricky now, because where would eb draw the line. Do we consistently want to ignore the Codex reccomendations regarding mandatory fields in all of Wikidata UI in favor of the Nielsen/Norman reccomendations? I would be against doing it just for the Lexeme creation UI because that's where we happened to get feedback on it, and then not do it for other interfaces. My feeling is, that it's going to be hard to consistently maintain all these exceptions and it would be prudent to align with Codex instead. If Codex interfaces receive the same feedback we did, then the design team might decide to change their practice of how to display mandatory fields which would then in turn also affect our components. There's also the option to reach out to the design team should we receive similar feedback again.

Gotcha. Then i guess @Arian_Bozorg has the last word. My reccomendation stands.

Is there any reason we should consider, as to why removing the asterisk might pose a problem? If not, then my reccomendation would be to remove the asterisk.

Hey @ItamarWMDE here's what I could find after a first verification:

In also just noticed that something seems off about the links in the footer in RTL languages

Everything looks great to me except that the focus state seems to be missing/not consistent with codex specification for links.

Looks great!

@Anton.Kokh done. ticket should be ready to go

Hey @danshick-wmde would you mind checking the copy of the tooltip of which I included a screenshot in the ticket description (last image). This is the tooltip that is currently showing when hovering over the info-icon of Site-Domain in the form to create a new wikibase instance

@Anton.Kokh this is done from my side

Youre right! I uploaded the wrong image, thank you for pointing it out, I fixed it now.

waiting on feedback from dan regarding additional copy

It seems like the ticket that adam linked was a suboptimal fix for the problem at hand. My suggestion would be to add the copy from the original ticket using the hint prop.

Hey all, sorry for the late reply.

@Anton.Kokh this ticket has been moved to DONE without pinging me to verify the design and unfiortunately there are two implementation issues that need to be fixed.