search

muicss / mui

Lightweight CSS framework
https://www.muicss.com
Other
4.51k stars 425 forks source link

Proposal: Use data-attributes instead of classes #41

Closed amorey closed 8 years ago

amorey commented 9 years ago

Hi Everyone,

In some cases, using HTML classes to markup components feels awkward. One option is to use data-attributes instead. Here are some examples of what MUI markup would look like with data-attributes instead of classes:

Button colors

Classes:

<button class="mui-btn mui-btn-default">Button</button>
<button class="mui-btn mui-btn-primary">Button</button>

Data-attributes:

<button class="mui-btn" data-mui-color="default">Button</button>
<button class="mui-btn" data-mui-color="primary">Button</button>

Button styles

Classes:

<button class="mui-btn mui-btn-default mui-btn-raised">Button</button>
<button class="mui-btn mui-btn-default mui-btn-flat">Button</button>

Data-attributes:

<button class="mui-btn" data-mui-color="default" data-mui-style="raised">Button</button>
<button class="mui-btn" data-mui-color="default" data-mui-style="flat">Button</button>

Let me know your thoughts on data-attributes syntax!

Andres

ghost commented 9 years ago

I think I like it. Are you planning on keeping both forms? or move to just data attributes?

amorey commented 9 years ago

Great, thanks for the feedback! I think it should be either/or to keep the css simple. I'll put together some more examples so we can evaluate.

amorey commented 9 years ago

Here are some more examples of MUI components with data-attributes syntax. Let me know what you think!

Layout

<div class="mui-container-fluid"></div>

<div class="mui-container" data-mui-fluid="true"></div>

Typography

<div class="mui-text-display4 mui-text-white"></div>

<div class="mui-text-display4" data-mui-color="white"></div>

Dropdown

<div class="mui-dropdown">
  <button class="mui-btn mui-btn-primary" data-mui-toggle="dropdown">Dropdown</button>
  <ul class="mui-dropdown-menu mui-dropdown-menu-right">
    <li><a>Option 1</a></li>
    <li><a>Option 2</a></li>
  </ul>
</div>

<div class="mui-dropdown">
  <button class="mui-btn" data-mui-color="primary" data-mui-toggle="dropdown">Dropdown</button>
  <ul class="mui-dropdown-menu" data-mui-align="right">
    <li><a>Option 1</a></li>
    <li><a>Option 2</a></li>
  </ul>
</div>

Table

<table class="mui-table mui-table-bordered"></table>

<table class="mui-table" data-mui-borders="true"></table>

Dividers

<div class="mui-divider-top"></div>

<div class="mui-divider" data-mui-position="top"></div>
sakulstra commented 9 years ago

:+1:

igitur commented 9 years ago

I actually prefer the old way, only because it's in line with most of the other frameworks that I know.

amorey commented 9 years ago

@igitur Thanks for the feedback!

The old way was defined by Bootstrap before data-attributes became popular so I think it's worth considering if data-attributes might make the syntax better. The main benefits I see are:

  1. Separation between component identifier (mui-btn) and options (data-mui-style="flat")
  2. More explicit behavior (class="mui-dropdown-menu-right" vs. data-mui-align="right")
  3. Consistency with other JS attributes (e.g. data-mui-toggle="dropdown")
ghost commented 9 years ago

I like the idea of using data-attributes for overriding class defaults. On Aug 20, 2015 7:43 AM, "Andres Morey" notifications@github.com wrote:

@igitur https://github.com/igitur Thanks for the feedback!

The old way was defined by Bootstrap before data-attributes became popular so I think it's worth considering if data-attributes might make the syntax better. The main benefits I see are:

  1. Separation between component identifier (mui-btn) and options ( data-mui-style="flat")
  2. More explicit behavior (class="mui-dropdown-menu-right" vs. data-mui-align="right")
  3. Consistency with other JS attributes (e.g. data-mui-toggle="dropdown")

— Reply to this email directly or view it on GitHub https://github.com/muicss/mui/issues/41#issuecomment-133011691.

amorey commented 9 years ago

As a next step I'll put together a more formal proposal so we can take a look at the syntax.

amorey commented 9 years ago

Here's a more formal proposal for using data-attributes to override class defaults. The scope is limited to classes which define components (e.g. buttons, tables). I think we can support both syntax styles for a little while to give developers a chance to migrate.

The following is the list of components and options (written in a JSDoc-like syntax):

.mui-container
  {Boolean} fluid=false - If true, container expands to fit viewport

.mui-btn
  {String} color=normal - Button color (normal|primary|danger|accent)
  {String} style=normal - Button style (normal|raised|flat|fab)
  {String} size=normal - Button size (normal|large|small)

.mui-dropdown-menu
  {String} align=left - Menu text alignment (left|right)

.mui-table
  {Boolean} borders=false - If true, table cells have borders (false|true)

Let me know what you think! In particular, I'd love some feedback on attribute names and values.

amorey commented 9 years ago

Everyone - we're very close to merging the data-attributes branch into master. These are the questions that need to get figured out first:

  1. What should the default value of button color/style/size attributes be called?

    Currently, the default value for all three is "normal". Here are some other possibilities:

    .mui-btn
   {String} color=normal|default|white
   {String} style=normal|default
   {string} size=normal|default|medium

    I'm hesitant to use the label "default" because it has a double meaning in this context and we're not using it in other places.

  2. What should the value of the button style attribute be for "floating action buttons"?

    Currently you can create a floating action button by specifying style="fab". Another possibility is style="round". One drawback of style="round" is that it's not clear that a round button should have a non-zero z-index which floating action buttons do have. Does anyone have any thoughts on "fab" vs. "round" and whether or not round buttons should have a default z-index?

  3. How should we handle large/small button sizes that aren't in the Material Design spec?

    Currently the Material Design guidelines don't have a spec for "small" rectangular buttons and "large" floating action buttons. Also, small floating action buttons are called "mini". Does anybody have any strong feelings on whether we should use "large"/"small" naming scheme and add support for non-standard sizes to MUI?

ghost commented 9 years ago
  1. Can you actually specify the color in the value? If not, I would argue against using white as it is confusing. I prefer default - not sure that I see the confusion. Maybe base?
  2. How about floating? fab is probably fine...
  3. I thinks small and large are the most obvious names to use; though I'm not sure I would add small/large sizes to begin with.
amorey commented 9 years ago

Great, thanks for the feedback.

  1. You can't specify the color itself in the value. The other possible values are "primary", "danger" and "accent". "default" sounds good to me...
  2. The Material Design spec specifies a "large" and "mini" size for rectangular and round buttons respectively. I'm fine leaving rectangular/small and fab/large out of MUI but it might be confusing to users that the allowed sizes depend on the button style.
ghost commented 9 years ago

Three. I didn't see the large reference for rectangular buttons; just the mini for floating action buttons. Odd that they don't allow both on either. My preference would be mini | default or normal | large for all button types.

(apparently Markdown won't let you start a list with an arbitrary number)

amorey commented 9 years ago

The data-attributes syntax is available for testing in v0.1.22-rc1: https://www.muicss.com/

Let me know if you run into any problems!

amorey commented 9 years ago

Here's another issue to consider: data-attributes aren't supported in some popular email clients (e.g. Outlook and GMail) so the MUI HTML Email library needs to keep using class syntax.

Is it ok that for the CSS/JS and Email libraries to use different syntaxes? Or is it preferable to use class syntax for both? Should we support both syntaxes in the CSS/JS library?

I like how clean the data-attributes syntax is but it would be great to support the same syntax in CSS/JS and Email.

amorey commented 9 years ago

@metatribal After thinking about it some more I think color is confusing because the possible values are not actual colors. What do you think about using type instead of color?

Here are some examples of data-attributes type/style/size in action: https://github.com/muicss/mui/blob/react-bugfix/examples/buttons.html https://github.com/muicss/mui/blob/react-bugfix/examples/react/buttons.html https://github.com/muicss/mui/blob/react-bugfix/examples/webcomponents/buttons.html

Let me know what you think.

ghost commented 9 years ago

I agree, but am thinking style and type should be switched. E.g. style=primary, type=fab On Sep 23, 2015 9:53 PM, "Andres Morey" notifications@github.com wrote:

@metatribal https://github.com/metatribal After thinking about it some more I think color is confusing because the possible values are not actual colors. What do you think about using type instead of color?

Here are some examples of data-attributes type/style/size in action: https://github.com/muicss/mui/blob/react-bugfix/examples/buttons.html https://github.com/muicss/mui/blob/react-bugfix/examples/react/buttons.html

https://github.com/muicss/mui/blob/react-bugfix/examples/webcomponents/buttons.html

Let me know what you think.

— Reply to this email directly or view it on GitHub https://github.com/muicss/mui/issues/41#issuecomment-142801652.

ghost commented 9 years ago

Drat! I anticipate using common styling and layout between my application and support emails. Using two different means is ugly. If this is the case, I would probably opt to use just there classes. On Sep 19, 2015 10:22 AM, "Andres Morey" notifications@github.com wrote:

Here's another issue to consider: data-attributes aren't supported in some popular email clients https://www.campaignmonitor.com/css/ (e.g. Outlook and GMail) so the MUI HTML Email library needs to keep using class syntax.

Is it ok that for the CSS/JS and Email libraries to use different syntaxes? Or is it preferable to use class syntax for both? Should we support both syntaxes in the CSS/JS library?

I like how clean the data-attributes syntax is but it would be great to support the same syntax in CSS/JS and Email.

— Reply to this email directly or view it on GitHub https://github.com/muicss/mui/issues/41#issuecomment-141685025.

amorey commented 9 years ago

Re: style vs type - Yeah, that makes sense. I'll reverse them.

Re: Email css - Ok, I'll start thinking about reverting to class syntax :(. The attribute syntax will still be useful for React and WebComponents. Are you using the MUI Email CSS library for HTML emails?

Any thoughts on BEM syntax (e.g. mui-btn--primary)?

mukuljp commented 9 years ago

this is a nice change @amorey

amorey commented 9 years ago

@mukuljp Which change are you referring to??

ghost commented 9 years ago

I am using it for email, but very limited. I would like to use it more.

Syntax is ok with me. On Sep 24, 2015 8:30 AM, "Andres Morey" notifications@github.com wrote:

Re: style vs type - Yeah, that makes sense. I'll reverse them.

Re: Email css - Ok, I'll start thinking about reverting to class syntax :(. The attribute syntax will still be useful for React and WebComponents. Are you using the MUI Email CSS library for HTML emails?

Any thoughts on BEM syntax (e.g. mui-btn--primary)?

— Reply to this email directly or view it on GitHub https://github.com/muicss/mui/issues/41#issuecomment-142946604.

amorey commented 9 years ago

Here's a preview of buttons with BEM syntax: https://github.com/muicss/mui/blob/bem-syntax/examples/buttons.html https://github.com/muicss/mui/blob/bem-syntax/examples/email/buttons.html

And here's BEM syntax for dropdowns: https://github.com/muicss/mui/blob/bem-syntax/examples/dropdowns.html

I'd be curious to hear your thoughts before I migrate the rest of the code base to BEM.

ghost commented 9 years ago

It's verbose, but looks consistent and readable. Can't think of a better alternative. On Sep 24, 2015 8:50 PM, "Andres Morey" notifications@github.com wrote:

Here's a preview of buttons with BEM syntax: https://github.com/muicss/mui/blob/bem-syntax/examples/buttons.html https://github.com/muicss/mui/blob/bem-syntax/examples/email/buttons.html

And here's BEM syntax for dropdowns: https://github.com/muicss/mui/blob/bem-syntax/examples/dropdowns.html

I'd be curious to hear your thoughts before I migrate the rest of the code base to BEM.

— Reply to this email directly or view it on GitHub https://github.com/muicss/mui/issues/41#issuecomment-143108544.

amorey commented 9 years ago

Here's a proposal for BEM syntax: https://github.com/muicss/mui/issues/47

amorey commented 8 years ago

Everyone - thanks for your feedback on the CSS syntax! In order to maintain compatibility with the email library and to maintain consistency and predictability we've settled on BEM syntax (https://github.com/muicss/mui/issues/49). Please check out the latest release candidate and let us know what you think.

https://www.muicss.com/docs/v1/css-js/reference