Semantic-UI web components

[caitp]

So, cool things are happening with Web Components these days, FF landed a lot of support (pref'd off by default) in December, Chromium has had some experimental web component support for ages now (pref'd off by default), and Safari is in a similar boat. It's getting close to being usable completely by default on the web.

That's all great and all, but people want to use this stuff right now! I think working with Polymer, it should be fairly trivial to turn all of the Semantic-UI components into proper web components, and should allow the project to be a lot lighter, too.

Cool things that this would afford:

• among others, removing any dependency on jQuery and making use of the framework much more declarative, which is really cool.
• much simpler interoperability with outside frameworks (like Ember, AngularJS, etc)

I realized, since I'm not putting too much work into angular-semantic anymore, that really all it's doing is trying to make some nice declarative components which play nicely with the Angular ecosystem. That's a cool thing and all, but it could be a whole lot cooler if it was designed around components to begin with.

That's all a pretty tall order, but lets face it, there are issues with the code as it stands:

• Creates absolutely horrific markup, div soup
• Requires some imperative logic to make anything actually "work"

I think this could be done a lot better. Hide the div-soup behind the shadow-DOM, let users write proper semantic markup that is easily understood

This sounds like a complaint, but it's not. This sounds like a feature request, and I guess in a way it is. It means re-writing and re-organizing a lot of code, and I think that's okay. It means simplifying and improving the performance of a lot of code, and I think that's always a good thing.

So, I think some thought should be given to turning semantic-ui into something which plays nicely with the web components specifications, and which gives programmers and designers the chance to work with truly semantic markup. Keep the issue open as a reminder of what the web is starting to look like now that these features are widespread.

[brigand]

The main problem with removing the jQuery dependency is how much it simplifies the code. We could use something that's like jQuery but much lighter (connivence selector, animation function, simple event handler).

As far as web components; what would have to be changed to support them? As far as I understand it, there's no reason why it wouldn't be wrapable as web components as-is.

[caitp]

They could be wrapped as web components. What would be really good is if they were simply packaged as web components to begin with.

Even if jQuery weren't totally removed, it just strikes me as weird that we're still writing massive UI frameworks for the web build on a ton of javascript code, when we have Polymer now, and unpref'd native component APIs in the next few months to a year. It is mind boggling that front-end frameworks are not taking advantage of that

[brigand]

Polymer isn’t really good for production use, and the fact that there’s a Polymer global used in their web components asserts that it’s more than a polyfill.

I think that writing a very small utility library would make more sense for our purposes than jQuery, e.g., .hide() vs .style.display = “none”; doesn’t really make things better. Just include the things that’ll actually simplify the code. Something that can be bundled into Semantic UI’s built files would be much better (i.e. it should be smaller than a single JS component).

On Sat, Jan 18, 2014 at 6:24 PM, Caitlin Potter notifications@github.comwrote:

They could be wrapped as web components. What would be really good is if they were simply packaged as web components to begin with.

Even if jQuery weren't totally removed, it just strikes me as weird that we're still writing massive UI frameworks for the web build on a ton of javascript code, when we have Polymer now, and unpref'd native component APIs in the next few months to a year. It is mind boggling that front-end frameworks are not taking advantage of that

— Reply to this email directly or view it on GitHubhttps://github.com/Semantic-Org/Semantic-UI/issues/565#issuecomment-32699341 .

[caitp]

Polymer is a collection of polyfills (as well as) a framework, and now a collection of UI widgets. It's a big project, and it's not all interdependent, it's very modular.

Polymer/platform would be a big help for making this stuff work "today" (and perfectly fine in production, HTML imports will be pref'd on pretty soon, but for people using production apps they're not going to have a huge problem with a few XHR requests).

Even if polymer/platform can't be used, this stuff is literally only a few months away from being pref'd on by default, which means it is pretty close to being ready for production.

I've already stated, this is a pretty tall order, it's not "one actionable item", so I'm not saying people need to run off and write patches working on this. I'm saying that the future is not that far away, and it's going to be a much better way to operate, so it should be a kind of vision to steer towards

[jlukic]

These technologies are based on W3C draft specification. The aim of Semantic UI is to base its tech stack, and internal naming through usage and convention, not prescription from standards bodies.

This makes sure the project is useful to the most people, and also saves us from having to worry about adopting technologies which might be forgotten, not supported, or not understood by the community of web developers at large.

The baseline for the web today for most projects is (arguably) jQuery, CSS, and vanilla Javascript. If this changes and adoption favors new technologies like web components, shadow DOM etc then the project will adapt.

[caitp]

As stated, I realize this isn't really an "actionable issue" that can be fixed with a quick patch, it's more of an ongoing thing. Having said that, the technology is pretty much there, we're very close to having web components support pref'd on by default in both Gecko and Blink, and while Safari and IE might be a bit further behind, Mozilla's X-Tags and Google's Polymer both offer tools to work around this perfectly (which is already being used by commercial products on the web).

So, while this isn't a "make this happen right now", it's just a reminder that yes, the landscape IS changing, yes, it's almost there, and yes, it is quite possible to do it already, and fairly easily.

I'm not looking to start a big argument about this, but the bottom line is that it really is a web component collection, it just doesn't look like one because it comes with the typical div-soup and jQuery imperative gunk. I realize the tone of that statement sounds a bit harsh and critical, and that's not really the intent, so take it with a grain of salt =)

[jlukic]

"div soup and jQuery imperative junk" is how most of the web is created today.

In my opinion useful technologies are decided by the consensus of the masses who use technology to create things, rather than the intent of the select few who are implementers or have roles in drafting standards. This is part of my critique of the orthodoxy of FED.

The central problem in drafting a web framework like SUI to me isn't necessarily uncovering the most academically pure and succinct representation of an idea through code, but creating something that has the most utility to the most people. The best way to do that is to defer to the community of "linguists" (users of a programming language) as a deciding body for weighing the merit of new language feature, and not authorities who seek to evolve the language through prescription.

That being said, web components may become a feature of the language in the future, and there are large organizations standing behind it (Google etc). My critique isn't with suggesting that web components don't seem useful (it does), or aren't well backed by large companies (Google and others stand behind them), but that they should not be adopted unless they are accepted by the community at large as a convention.

[balupton]

For what it's worth, I've jumped on the web component bandwagon. It makes soo much sense.

Let's take this SUI modal:

<div class="ui modal">
  <i class="close icon"></i>
  <div class="header">
    Modal Title
  </div>
  <div class="content">
    <div class="left">
      Content can appear on left
    </div>
    <div class="right">
      Content can appear on right
    </div>
  </div>
  <div class="actions">
    <div class="ui button">Cancel</div>
    <div class="ui button">OK</div>
  </div>
</div>
<script>
$('.test.modal')
        .modal('setting', 'transition','scale')
        .modal('show');
</script>

As a web component it would be:

<modal id="test" transition="scale">
  <close/>
  <header>
    Modal Title
  </header>
  <content>
    <left>
      Content can appear on left
    </left>
    <right>
      Content can appear on right
    </right>
  </content>
  <actions>
    <cancel>Cancel</cancel>
    <ok>OK</ok>
  </actions>
</modal>
<script>
document.getElementById('test').show();
</script>

Of course, renaming the stuff inside it is a bit out of scope, but would be interesting.

I'm not saying that SUI should, or that it makes sense for SUI to do so, but just saying I love web components, and will be looking for alternatives to SUI for them.

[Anachron]

Actually I vote for div-soups, as it's just too much efford to tell every browser (for example IE) how to implement the elements.

[DavidPesta]

I really like Polymer. But both @caitp and @jlukic are right.

What if someone created a guide of conventions and/or separately maintained a library for wrapping Semantic-UI components into semantically analogous Polymer elements?

Would this work? Are there any pitfalls to this approach? Gotchas or limitations?

[jlukic]

Web component conversation skirted for now. Lets see how the ball drops on the issue.

[anunos]

Hello there, @jlukic @caitp any intentions to reopen this issue now that Polymer 1.0 is out and production ready?

[caitp]

it would be cool, and Blink is improving the CSS encapsulation of their components fairly frequently (I believe shadow piercing selectors landed a few days ago, or will be landing soon (okay this isn't really encapsulation, it's the opposite, but still)). So good things are happening there --- But, it might be a bit crazy to refactor the entire framework just for those niche benefits. Maybe a "semantic-component" repo could be opened for some experimental work in that arena.

[jlukic]

I'm pretty much of the same mindset as @caitp.

I'm not confident yet that the front end development community will embrace the shadow/logical DOM and its idiosyncratic selector engine. Swapping everything over to web components may mean I risk making a framework that only a few people would know how to tinker with or contribute to.

[kapouer]

I started using Custom Elements and Link imports on a new website with a cms. It is very useful for development and clean separation of components, and it is very easy to setup. CSS componentization wasn't possible in that case because we started from a static website, written beforehand using another framework (bootstrap). The custom elements we defined are things like sliders, figures with caption, whole menus, not "small" elements like the Material custom elements - working with those feels like learning a whole new set of constraints. To sum up, i don't think semantic-ui would benefit from those (maybe in a few cases like the progress module) but it certainly shouldn't get in the way of using them !

[ansarizafar]

1+ for Semantic ui for Web components (Polymer). Is there any update?