search

AusDTO / gov-au-ui-kit

MOVED TO https://github.com/govau/uikit/
https://github.com/govau/uikit/
MIT License
19 stars 12 forks source link

Feature/design 433 consistent vars #383

Closed klepas closed 7 years ago

klepas commented 7 years ago

Still in progress.

Description

Aligns the namespacing of our variables and adds the kit- prefix.

Additional information

Vars replaced so far: https://gist.github.com/klepas/cae16f79bf89e561f6eb1ff860f4d1c9

Definition of Done

klepas commented 7 years ago

So in updating these vars all instances of them in the documentation were also automatically updated (find and replace).

A few things on the edits:

joolswood commented 7 years ago

Hi @klepas and @petronbot

For thoroughness I'd love to do a comparison of the proposed vars against naming in he other major guides, but we don't have the time for that. Can we possibly do a quick run of these under the eyes of the devs in our teams?

Scanning through the proposed list I can't see any real readability problems with the choices, except possibly -bg; but with the prefix of colour it would seem reasonable as an alternative to very long vars.

$kit-transition-timing makes me a little nervous though, from an accessibility perspective - what's this used for?

I can't see these locking us into a problematic hierarchy of vars, I think that's what you were getting to with the comment about "us not really being at that stage"?

Regarding the other points:

  1. kit- aligning to our decision that the Thing should be called UI-Kit for now, I think OK.
  2. To simplify things, my go-to position would be to omit -base. If the -base var is the most frequent usage / the size to which other things are either bigger / smaller / variant then is base necessary? For example: $kit-font-weight You'd then have $kit-font-weight-bold or $kit-font-weight-headings A key question here: is base enough of a keyword it should be included in the var name even if it makes the var longer?
  3. Going on from point 2, larger and smaller would be preferable to large small tiny etc. where you have a base var. So should $kit-spacing-medium then be $kit-spacing?
  4. From what I’m reading about BEM it seems like a good approach; start with the "normal" one and do --inverted eg $kit-body-text-colour--inverted.

In terms of where to notify, obviously high prominence in the CHANGELOG. I'm nervous about adding more to the ever growing README, especially as the majority of the users are still within teams we work with regularly, so they maybe better served with 1-1 chats, perhaps paired with the UR I mentioned at the start?

klepas commented 7 years ago

For thoroughness I'd love to do a comparison of the proposed vars against naming in he other major guides, but we don't have the time for that.

They either don’t do this, and rely on developers who have clashes to deal with namespacing themselves, or they generally prefix in the same way we have.

Can we possibly do a quick run of these under the eyes of the devs in our teams?

Definitely. Would be good to get Elise, Jonathan, Nathan, Rowan, etc. on to take a quick squiz.

Scanning through the proposed list I can't see any real readability problems with the choices, except possibly -bg; but with the prefix of colour it would seem reasonable as an alternative to very long vars.

-bg should… hopefully be fairly evident — I opted for this to avoid overly long vars, yea.

$kit-transition-timing makes me a little nervous though, from an accessibility perspective - what's this used for?

The idea here is that if a var is for a certain CSS property then that var should hold the name of that property. Worth noting too that the only users of vars would really be developers building on from or extending the UI-Kit.

[…] A key question here: is base enough of a keyword it should be included in the var name even if it makes the var longer?

Worthy discussion point. I’d be esp. keen to hear what the front end guild thinks — same for your 3rd point.

In terms of where to notify, obviously high prominence in the CHANGELOG. I'm nervous about adding more to the ever growing README, especially as the majority of the users are still within teams we work with regularly, so they maybe better served with 1-1 chats, perhaps paired with the UR I mentioned at the start?

CHANGELOG, front-end guild, showcase, and 1–1 chats over the README, definitely. (:

petronbot commented 7 years ago

Fixes https://github.com/AusDTO/gov-au-ui-kit/issues/345

klepas commented 7 years ago

Agreed in sprint planning 40 that we would revisit this later, since this would be a breaking change to anyone consuming our SASS.

Attached is a plain text file listing the edits that were made here, just for reference: replaced-vars.txt