Semantic-UI: Duplicate class names are removed by Meteor

It is not an issue of semantic-ui per se. I am using Meteor with semantic-ui and trying to make my columns responsive for device like this:

<div class="ui grid">
  <div class="sixteen wide mobile eight wide tablet four wide computer column">
    <p></p>
</div>

Meteor removes all the duplicated class “wide” and it becomes:

<div class="ui grid">
  <div class="sixteen wide mobile eight tablet four computer column">
    <p></p>
</div>

Just wonder do you have any workarounds?

About this issue

  • Original URL
  • State: closed
  • Created 10 years ago
  • Reactions: 7
  • Comments: 36 (7 by maintainers)

Most upvoted comments

Fix

  1. Go to \semantic-ui\definitions\collections\grid.import.less
  2. Do a search and replace:
    • Search for [space]wide[space]
    • Replace with -wide-

_OLD_

Original file with separate classes

.ui.grid > .row > [class*="sixteen wide tablet"].column,
.ui.grid > .column.row > [class*="sixteen wide tablet"].column,
.ui.grid > [class*="sixteen wide tablet"].column,
.ui.column.grid > [class*="sixteen wide tablet"].column {
    width: @sixteenWide !important;
}

_NEW_

Updated file with one class separated by dashes

.ui.grid > .row > [class*="sixteen-wide-tablet"].column,
.ui.grid > .column.row > [class*="sixteen-wide-tablet"].column,
.ui.grid > [class*="sixteen-wide-tablet"].column,
.ui.column.grid > [class*="sixteen-wide-tablet"].column {
    width: @sixteenWide !important;
}

Update your classes to include dashes <div class="eight-wide-computer sixteen-wide-tablet column">

These will now be treated as a single class and Meteor will not remove any duplicate classes… since there will be none.

So am I understanding correctly that this actually breaks Semantic UI?

Because if so, it’s not just a framework-specific issue, even the browser Native classList.add does the same thing: https://developer.mozilla.org/en-US/docs/Web/API/Element.classList

I fixed the issue like this for myself:

<template name="div">
  <div>
    {{> Template.contentBlock}}
  </div>
</template>
Template.div.onRendered(function() {
  $(this.firstNode).get(0).className = this.data.class;
});

How to use:

<div class="ui grid">
   {{#div class="sixteen wide mobile twelve wide tablet ten wide computer column"}}
      <!-- column content -->
   {{/div}}
</div>

The problem is not just for “wide” classes, we have “center aligned middle aligned” as well. I think the proposal to make these changes only for the meteor builder or other XYZ framework would work reasonably as it won’t be adding any more bloat to the actual framework.

The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)

This is right and per spec, however most browsers don’t follow this spec, in the sense they don’t remove duplicates so it was kind of bad on Meteors part to remove them. That’s why I submitted that pull request to begin with.

@jlukic No it isn’t. Code is not moral philosophy. When you ignore the spec you get Internet Explorer. My point, however, was that if you freely interpret the specification in a way that is different to how everyone else does, at some point you are going to run in to problems.

In any case, on reviewing it again, Semantic UI does actually break the spec, Meteor is correct.

“The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)”.

EDIT: Added reference

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

Would like to +1 a solution to this

@jlukic, not sure I understand.

On another issue, I was thinking, instead of changing the CSS globally, why not only change the JS builder for Meteor. It could run the above changes during build time. This way you don’t have to change it for everyone.

I think it does make sense to support, but I need to evaluate the KB size required for me to modify the rules in grid. It might be substantial.