ClayButton borderless

[carloslancha]

We need btn-borderless class to fit with Lexicon style:

https://lexicondesign.io/docs/patterns/buttons.html

Right now we have this:

[pat270]

@carloslancha We have this btn btn-outline-secondary btn-borderless and btn btn-link the only thing is btn-link isn't bolded like in the screen shot.

[carloslancha]

@pat270 lexicon doesn't define the outlines styles so in ClayButton we're just adding the class btn- + specified style (primary, secondary, etc). Couldn't be possible to style borderless to work just in that way?

[pat270]

Basic Sites Elements have btn-outline-*

btn-borderless also doesn't make sense with something like btn-primary. It's already borderless visually. The only one it makes sense with is btn-secondary, but this is an exception to regular buttons.

[carloslancha]

For us btn-borderless is not an utility for other kind of buttons but a kind itself, just in the same level as btn-primary btn-secondary and bnt-link

[pat270]

We should also be considering the things Bootstrap has provided. .btn-outline-* is shipped by default, I can't get rid of it. Clay is already bloated as is and adding another button variant doesn't seem like a good idea to me. Where are the use cases exactly?

[carloslancha]

I'm just following docs https://lexicondesign.io/docs/patterns/buttons.html

[yuchi]

Bystander’s 2cents again: both primary and secondary are semantic adjectives, while borderless is not. That’s confusing.

If you called it btn-tertiary the confusion here would have been prevented.

[natecavanaugh]

I have to agree with @yuchi that borderless isn't a semantic name, but I'm not sure if tertiary works (because it implies that the button is lower in the hierarchy, but reading the docs, it may be considered on it's own, less important level).

Some other possibilities might be (if they're not already being used) btn-label or btn-subtle.

But as I'm writing this, I think Pier had it right, btn-tertiary may be the best one, unless we can think of some actual functionality that these buttons have.

[yuchi]

Thanks @natecavanaugh. You are indeed right that “tertiary” does imply a lower level in the hierarchy and the docs do not imply that. Anyway that specific proposal was just to give an example.

[pat270]

I like the name btn-tertiary much better than borderless as well. I'm still hesitant to add a new set of buttons when we already have a set of unused buttons that are styled like the borderless buttons with the exception of colored borders. Maybe I can name it btn-outline-borderless?

Edit: I say unused, but btn-outline-primary will actually be used in Basic Site Elements.

[jbalsas]

Hi, thanks everyone for chiming in!

There are different realities we need to reconcile here:

Clay as a general CSS framework

I think this is where the stance against btn-borderless relies more heavily. Since I'm not really been developing it, I can't 100% grasp the implications, so I leave these considerations to @pat270's expertise.

Clay as a web implementation of Lexicon Experience Language

This is what we are actually preaching, above the general css framework. We want to build and adhere to Lexicon standards easily by using Clay.

For someone checking Lexicon, and seeing there are 4 main types of buttons (primary, secondary, borderless, link), making the mental connection to css styles btn btn-${type} is immediate. Figuring out that the borderless main type is implemented via btn btn-outline-secondary btn-borderless is not all that obvious.

I think, for us, Lexicon defines semantics , and so far, those 4 types are the button semantics we have. I'll defer discussions about that to @victorvalle and the rest of the Lexicon team. If a better, more meaningful name for borderless could be found, I'm all for it.

For as long as I remember, @victorvalle, @juanhidalgo and others have continually asked us to stick to their guidelines for better consistency. As @pat270 mentions, Clay is already bloated as it is, but it is with things Lexicon doesn't define or want to see in an application following it's guidelines. This, however, looks like something they do want, so it shouldn't be counted as bloat.

Clay as a framework for components

The last piece of the puzzle is Clay as CSS framework for components. In trying to provide an easy way to implement Lexicon interfaces, we're realizing the different abstract Lexicon molecules into clay-components

Imagine this scenario (not real) where we have 4 types of main buttons A, B, C, and D

// Button A
<button class="btn btn-A">...</button>

// Button B
<button class="btn btn-B">...</button>

// Button C
<button class="btn btn-something btn-anotherthing btn-C">...</button>

// Button D
<a class="btn link-btn link-btn-D">...</a>

I think it's easy to see that this is less than convenient when trying to generalize markup and put it into reusable pieces since the variations are not predictable and consistent.

TL;DR (but got this far)
We need to take into account all these 3 dimensions to take good decisions and help drive the project forward as it all moves together.

[jbalsas]

So, a brief update.

After checking with @victorvalle and the Lexicon team, Borderless is indeed a variation, not a new type of button. They will proceed to document it in a different way and we can proceed to remove it from the clay component implementation.

If someone wants a borderless button, as @pat270 mentioned, she can use the outline modifiers accordingly, or it will be styled by default based on context (like in a toolbar).

Closing here, thanks everyone!