The future of Fomantic as v3.0

y0hami commented 5 years ago

We have a ROADMAP now 🎉

We created Fomantic-UI (FUI) to continue the active development of Semantic-UI (SUI) until development on the main project could continue, that was 199 days ago (as of writing this) and the last SUI release 2 months ago (as of writing this). SUI has shipped 4 releases since then and we have shipped 13. That being said you can probably see that development has drastically slowed down over time on the main repository which brings me to my next point.

When we created the project we stated that FUI has the

intent to be merged back into the master repository once active development can restart

now with the following changes/plans which are listed in this issue you will get a clear understanding why we have changed our minds and why this can benefit you and the FUI project as a platform.

To be clear merging back into SUI is still our intention, read this comment for more info

Before I get started feel free to leave comments and suggestions, remember this is a community fork and we want as much input as we can get to make this a truly community built platform.

New Documentation Website

This has been on the todo list for awhile now but was too big of a task to do for a single release so 3.0 is a perfect time to do this and especially with all the new changes.

Currently we are still investigating what software we want to use and how we want to build the site (statically generated etc.) but we do have a few requirements

Must be easy to edit
Must be easy for new contributors
Must be quick to start and build
Must be able to render/compile large pages

New Build Process

We have been talking about this for awhile because the current system is too bulky for what we want. Also when rewriting it we can investigate new technology and processes which might make the build system more efficient and faster.

We are still looking to how we want to do this but we do have a few requirements

Must be able to compile LESS to CSS
Must be able to bundle CSS and JavaScript
Must be able to customize it
Must be quick
Must be small and not bulky

Theme Builder & Web Store

Starting off in the paragraphs above you may have noticed I mention the word platform a lot, this is because for 2019 and 3.0 we are pushing to make more then just the CSS/JS framework your familiar of. We are planning to start building 2 new websites first a theme builder to make it easier to create themes since the current method just isn't good enough. Second is a community powered "store" which allows users to download themes, templates, plugins etc. When we get to making the store the one promise I will keep is that all content will be free and won't cost a penny!

I am taking name suggestions for the web store because I don't want to call it a store.

Project Structure

This change will be big and will require other items on this list to be complete for we can 100% do this. We want to convert this repository (fomantic/Fomantic-UI) into a centralized location for all "modules". Basically that means making a directory called packages which will contain all components as individual npm packages and also have a few core packages e.g.

repo/
  packages/
    utils/
    core/
    css/
    components/
      button/
      container/
      grid/
      icons/
      input/
      form/
      dropdown/
      calendar/
      ...

On npm we will have a new org called fomantic which all packages will be published under. The npm naming will be like the following

@fomantic/core  - The core package with all components (basically the current repo)
@fomantic/css   - The CSS only distribution
@fomantic/utils - A set of core functions used throughout the library
@fomantic/component/button    - The button component
@fomantic/component/grid      - The grid component
@fomantic/component/icon      - The icon component
@fomantic/component/form      - The form component
@fomantic/component/dropdown  - The dropdown component
@fomantic/component/calendar  - The calendar component
...

All components will contain all the required assets and resources to work i.e. all LESS and JavaScript files and any image/font assets.

Now you might be asking how does this benefit the development, well this will make all components module therefore in theory they should be decoupled. This can help with development because it makes it easier to manage each components changes and make it easy for new contributors to make changes because they can easily find the code related to components. This also solves a problem where some components depend on others by allow us to use npm to manage the dependencies and now have to have duplicate files in each separate component to distribute them separately.

Another big benefit to this is it makes it really easy to only include the components you need.

You may have a few questions relating to versioning and changelogs well we haven't come to a decision on how we will do that but a changelog in each package probably to keep track of changes and then a larger changelog in the to act as a library changelog like the current one. Versioning is a bit different, maybe versioning each component and then when releasing new library versions we could change the "mega" version to the total calculated via all component changes using semver. If you have any suggestions feel free to too.

ES6 & JS Rewrite

So this is a big task to undertake but all current contributors are for it.

We want to rewrite all the JavaScript modules to remove the dependency on jQuery and to clear up the syntax and complexity to make it easier for new contributors. We also want to centralize all the common functions used throughout the library. We are currently going to make a module called @fomantic/utils which will hold all the common functions which all the individual components can depend on since the new structure will allow that.

As for the rewrite, it will be ES6 and classes, maybe something to produce code like this?

import { Dropdown } from '@fomantic/core';

const countryDropdown = new Dropdown('#countryDropdown');

countryDropdown.on('change', (value) => {
  console.log('Country Changed', value);
});

countryDropdown.select('gb');

Why classes? Well making the modules classes will make the library easier use and understand and will modernize the framework by using new JavaScript features and standards.

Again we are open to feedback.

Tests tests tests

From the start of making FUI we have been trying to figure out how to implement CI/CD and tests because we believe this is the best way to ship code fast but while staying efficient. Near the start of FUI we partnered with BrowserStack to help test features and bugs which we still use and is amazing but with that partnership we also got automated testing which we have yet to get a chance to look into and that would be awesome but we need a way to test the components in a browser which is our biggest problem. We first agreed to making pages which contained all the components which we could load in something like nightmare but that soon became a large task.

What we want

Full CI/CD process
Testing of all JavaScript components
Testing of all CSS components (checking they don't change a components style when they shouldn't, maybe something like percy)

I hope this helps you understand why we have made the decision to branch away from SUI and start moving towards our own plans. We are truly trying to make a library which works for everyone and with the restrictions of being compliant with the SUI repository this goal was no longer possible.

Again if you have any feedback you may have from other requests or suggestions feel free we are open to all 😃

We are also available on our discord throughout most of the day (EU timezone) so if you want come and chat!

Additional v3 issues:

We are running a survey for v3 research, if you have 5 minutes to spare to fill it in we would be much appreciated! https://www.surveymonkey.co.uk/r/398M9YJ (Survey is now closed)

batata004 commented 5 years ago

@ColinFrick FUI will not be bigger in size when it removed jquery dependency? So how will you do all the "selector" stuff without adding new code? "queryselectorall" will not do all the heavy lift on its own.

PS: thanks for pointing the calendar, I was not aware FUI had it!!! GREAT!

etshy commented 5 years ago

@batata004 you can still stick to v2.x.x of fomantic to have jQuery, no ?

And when v3.x.x will be released + a jQuery wrapper, you'll get all you want.

I can't understand your worries here, when semantic ui is clearly too slow to be interesting to use at the moment.

batata004 commented 5 years ago

@etshy so let's wait to find out. I agree with your last statement. However, I better stick with SUI (despite slow updates) to avoid changes/troubleshooting on thousand of websites when FUI decide breaking backwards compatibility.

y0hami commented 5 years ago

@batata004 I think you have misunderstood something while reading. In this comment and the following replies we mention about adding a "pollyfill"/adapter from v2 to v3, this will mean all your websites will work exactly as expected with no code change even if we remove jQuery.

Your point about FUI increasing in size. The library won't increase if we remove jQuery since we will be removing jQuery it will be reducing the size because we will be using native functions.

Atulin commented 5 years ago

Also, the current code is not exactly up to modern standards in all places. Removal of jQ would also be a good opportunity to go over the entirety of the code, finding unoptimized pieces and optimizing them.

Far as I can tell, the removal of jQ will most probably result in decreased size and increased performance.

batata004 commented 5 years ago

@hammy2899 great news!

@Atulin @hammy2899 time will tell if the "jquery less" version will be smaller. Respectfully disagree, you cant make a code smaller adding news features (like removing jquery). Somehow you're gonna have to code your "selector engine".

I dont want to keep this jquery discussion further, I dont want to bother you guys here with this jquery thing. It's a bold move and clearly it's gonna happen and, despite disagreeing, I know for sure you are doing this for the better :) Keep on good job!

Just one question, unrelated to this thread (sorry for posting here): I didnt know FUI used calendar and I checked the component and it works amazingly well! You did a master job with it, simple and effective. I was not aware of it and, after reading the documentation of FUI, I didnt find any component/code related to "masks". For example: when user types a phone number a mask would automatically add ()- chars as needed. I just want to make sure I am not missing anything! Could you confirm that "masks" are not implemented with fomantic? I will remove this last phrase if not answered in the next hours to avoid breaking context of this discussion.

lubber-de commented 5 years ago

@batata004 masks for Form inputs are not yet implemented. But it's a good idea I can think of an enhancement of the already available Form validation behavior to work instantly on input fields instead of validate only on Form submission ... Would you like to create a feature request issue? 😉 So we can continue talking about that in a different thread.

batata004 commented 5 years ago

@lubber-de sure! Thanks a lot! I will do that right now and provide you a link of a good jquery mask library that we use here for years and it works great!

levithomason commented 5 years ago

It would be really great to discuss collaboration and sharing before this project progresses too far ahead. The primary focus I have is in sharing state, styles, and accessibility. These things are common between all implementations.

Consider that there is a SUI jQuery dropdown of 3,955 lines, a SUI React Dropdown of 1,425 lines, and now a Fomantic Dropdown of 4,113 lines. This component has the highest rate of bug reports and feature requests. The sad part is, we share only CSS between the implementations. What a shame that every bug fix and feature needs to be reimplemented over and over again.

Every one of these Dropdowns is a finite state machine. They all need to open on spacebar. They all need the same aria-* attributes on the items within. The list goes on for a very long time here and for every component.

Wouldn't it be great if UI framework components had the same consistency and expectations that HTML elements do, for developers and end users? Web apps are only possible due to the consistency of HTML/CSS/JS across browsers. Imagine what we could do if we had an open standard for more advanced common web app components, like calendars and dropdowns.

We could save untold manhours by creating vanilla JS solutions for state management, styles, and accessibility and sharing those in all three implementations. As I've eluded to above, I'm actually leading teams full-time at Microsoft on this effort right now. We have a dedicated accessibility team, accessibility contractor, designers, UX engineers, and software engineers working full-time across two continents.

Anywho, I'll leave this conversation at this for now. We'll publish much of this information and many packages through 2019 on this effort. It would be so superb to have a motivated and capable group of Semantic UI folks like yourselves join us.

khornberg commented 5 years ago

@levithomason That is a great goal. I am curious what you will publish. My understanding has been that Web Components were supposed to do that.

Where will you publish

this information and many packages through 2019 on this effort

douglasg14b commented 5 years ago

@batata004

My $0.02 on JQuery. Before I begin I'll say that I still use JQuery on many projects that don't use a framework like Vue, React, or Angular. It provides plenty of functionality that vanilla JS still doesn't.

It's not used everywhere (contrary to claims, most of it's usage are VERY old versions), has been effectively replaced by many vanilla and framework alternatives. It's clunky, messy, and will drag down the framework in the future where JQuery will no longer exist in mainstream applications. There is no reason to have a death-grip on the past that is JQuery. Your arguments that the time can be better spent else-wear is a false economy, as it will cost much more time in the future to remove JQuery Which WILL happen eventually. And cost an indescribable amount of dev hours for users of the frameworks who are held back by the JQuery dependence, and the bugs/issues/slow development inherent to sticking with it's patterns. When we could be making an agnostic framework that works out of the box for SPA frameworks. You are potentially hamstringing the future of the project by forcefully keeping a dependency that has been fading from modern use...

Other UI frameworks have already made this leap, and are ploughing forward and leaving Semantic in the dirt to wallow around as part of the "old guard". Similar to how NLog or Log4Net are nearly considered legacy in the .Net ecosystem for their inability to adopt new ideas and paradigms. Lets not become a legacy framework.

We have something great with @levithomason who appears to be using vanilla JS/Web Components to build out SemanticUI in a more framework agnostic way. Which is EXACTLY what anyone could wish for from a modern UI library/framework. It would be silly to throw away the opportunity to work with what I could only consider a sponsor (through time, not money) just to hang out in a comfort zone. The web will move forward, with or without Semantic/Fomantic, and all of us are sitting on an opportunity to push Semantic/Fomantic ahead of the pack. Lets not squander it.

douglasg14b commented 5 years ago

On second thought, I think JQuery-related discussion should be in it's own thread/issue to prevent it muddling up more important conversations about the future of SUI/FUI. Not that the JQuery conversation isn't important, but it's divisive, which can be very bad for a discussion meant to be future-facing. Since it shifts the focus into an argument over one item, instead of a discussion about the framework as a whole...

I fell into that trap with my above comment. and contributed to the off-topic mess.

y0hami commented 5 years ago

@douglasg14b I agree, this thread is starting to get slightly off topic...

douglasg14b commented 5 years ago

@hammy2899 If so, is there a way to move comments to another issue? Failing that, copy/pasting them as quotes would do if a line can be drawn pushing that conversation over there.

y0hami commented 5 years ago

@douglasg14b I will sort something out 😉

batata004 commented 5 years ago

@douglasg14b I agree with most what you said but I was never trying to predict the future. You said that in the future jquery will be "legacy". Sure. As will "Fomantic/Semantic". As time passes by, browsers are implementing lots of standards and helping devs to spend less and less time with that "semantic stuff". I am pretty sure, a few years ahead, it will be much easier to users customize their websites/buttons without relying - or having to choose - a framework. You certainly will be able to use frameworks but they will add more than an overhead than a significant leap. Today, FUI/SUI helps A LOT when building apps/websites. In the years to come, I dont think it will be that much* important. I just want to say that, when jquery is gonna be considered "legacy" I am pretty sure most of what FUI/SUI provide today, will so too. But I understand the reasons why devs usually want to create "indepedent framework" ("jqueryless", for example) and most of the time I dont agree. But I've been wrong much more times on my life than right, so yeap, dont mind my opinion.

I also agree with @@douglasg14b that this jquery discussion shouldnt be part of this thread and I promise I will stop posting about it.

levithomason commented 5 years ago

That is a great goal. I am curious what you will publish. My understanding has been that Web Components were supposed to do that.

@khornberg Web Components offer an API for creating custom HTML elements. They are often used in tandem with the Shadow DOM to isolate HTML and CSS to your component and solve the bleed problem. That is where it stops.

First, we are defining:

Component names
Component slots (anatomy)

This will give the UI community a common language for talking about components, but more importantly, for sharing code. We can't share abstractions if we don't use the same terminology.

Second, armed with consistent naming and reliable anatomies, we are creating vanilla JS abstractions for:

State Vanilla JS state managers that produce a JSON serializable state shape. Each stateful component has a dedicated state manager. The JSON state description is named and structured according to the component names and anatomies above.
Style Vanilla JS functions which return style objects based on component state and a theme. The functions can be used to generate traditional CSS stylesheets or used directly in CSS-in-JS libraries. Style objects are named and structured according to the component names and anatomies defined above.
Accessibility Vanilla JS functions that return JSON serializable objects defining accessibility attributes and key bindings. The objects are named and structured according to the component names and anatomies defined above.

As you can see, once we agree to component names and supported structures for common UI, we can use this specification to create and share abstractions. Imagine if I were to give you JSON objects describing the state, style, and accessibility of a certain Dropdown and asked you to apply it to a component in your favorite framework. This is what we're after. We see UI frameworks as different implementations of the same UI information.

Looks like we have a confirmed call this Friday 🎉 Really looking forward it!

gaurav- commented 5 years ago

This sounds like Semantic-UI version of what Ionic4 is doing. Something like StencilJS might be useful. Just a note for the decision makers.

jouni commented 5 years ago

First, we are defining:

Component names

Component slots (anatomy)

This will give the UI community a common language for talking about components, but more importantly, for sharing code. We can't share abstractions if we don't use the same terminology.

@levithomason, that sounds super interesting! Is there any way to be involved, or at least follow the process/progress?

levithomason commented 5 years ago

@jouni Our work isn't ready to show yet, however, we are organizing under the https://github.com/stardust-ui organization.

It is not clear from looking at those projects just exactly what we're actually doing. We've been focused on proving out some core patterns and practices for a while. It is looking good, so I'll take time this year to clean things up and make it more presentable and understandable to the public.

murbanowicz commented 5 years ago

I think that one of key points for 3.0 should be making theming easy. One of the worst things about SUI/FUI is customisation. It is really painful to even change the colors pallets at the moment. It would be great to make it possible to just import FUI less and then perform any variables changes etc which is impossible at the moment...

lubber-de commented 5 years ago

@murbanowicz You may look at https://github.com/fomantic/Fomantic-UI/issues/402#issuecomment-454913211 where it's shortly described how easy you can define the color palette using the names and colors you want at a central place now as of Fomantic-UI 2.7.0 Of course we will also focus to improve this even more in 3.0

murbanowicz commented 5 years ago

@lubber-de I am more looking for being able to easily use LESS file to customize any variables I want etc... I am struggling with that for long hours now and can't get it working (posted an issue #411)

douglasg14b commented 5 years ago

To keep the topic flowing, has there been word on what @hammy2899 and @levithomason might be planning out in regard to collaboration?

y0hami commented 5 years ago

@douglasg14b Me and the FUI team had a call with @levithomason and he showed us what his team is currently working on and what their goal is in regards to their project. This tied to us because it's basically a rewrite if SUI but in more of an agnostic way which allows us to use that code which would save us a lot of time. We also discussed some other ways we could collaborate like theming, specs and a definition/dictionary repo (sounds weird but it makes sense when you know the full context 😂) and some other things.

We are currently waiting for a prototype so we can mess around and see if it will benefit us and if it will actually work in our project. This is why the v3 talk has slowed down for us a little since we don't want to rush ahead and then find all the work we did was for nothing.

douglasg14b commented 5 years ago

@hammy2899 Thanks for the information! I'm very interested in where this heads as I'd like to contribute to an agnostic rewrite if it happens. Mainly because I do some work In Vue these days, and would love to see a version of Semantic that doens't have the be kludged into components (which has unfortunately caused a couple projects to use other UI libraries :disappointed: ).

The more information the better.

levithomason commented 5 years ago

Confirming what @hammy2899 has stated. We currently have framework agnostic accessibility abstractions that are ready to use in other frameworks. We also have a great start on a framework agnostic styling mechanism. I just completed the first prototype for generating SCSS from our styles and it is going well. I will continue working on this so we can share and collaborate on the abstractions.

In addition to the engineering, we are producing specifications for components. Think of a shared Design System where the language and anatomies are common between frameworks. This is essential so that we can share engineering abstractions on top of the common language and component structures.

...Thanks for the patience, more coming soon.

Clindbergh commented 5 years ago

When we created the project we stated that FUI has the

intent to be merged back into the master repository once active development can restart

now with the following changes/plans which are listed in this issue you will get a clear understanding > why we have changed our minds and why this can benefit you and the FUI project as a platform.

The "entry point" of this repo, the README.md still states the intent of merging this repo. This note should be removed or at least a link to this issue should be added. It would become clearer that this project is more than a temporary measure, but an active, long-term and new project, whose only tie to Semantic-UI is the original code base and thus be helpful in establishing trust.

I second the point made by

The biggest hurdle I see facing Fomantic is community growth and use. Semantic UI users won't know about Fomantic, and are likely to move onto other frameworks instead once they get the "dead project" feeling.

and

How does Fomantic grow it's community and user base under the shadow/growing stigma of Semantic UI? https://github.com/fomantic/Fomantic-UI/issues/319#issuecomment-449877919

As a user and advocate of Semantic-UI I have found it increasingly disturbing that development seemed stale. I'm glad I found out about Fomantic (and stardust-ui, very interesting!) today and seeing it is actively maintained!

y0hami commented 5 years ago

@Clindbergh I agree that can be a bit misleading, we are planning to release 2.7.2 this week so I will update the README then.

mikejf-pr commented 5 years ago

Is the intention to maintain backwards compatibility in FUI 3 with SemanticUI components? I'm wondering with regards to the ng2-semantic-ui componentry: if the CSS is compatible, the ng2 components should continue working with FUI3, but if not we'll have to stay with SUI.

y0hami commented 5 years ago

@mikejf-pr In most cases yes the CSS will remain backwards compatible with just a few changes here and there. These changes may be slight adjustments to improve theming and inheritance (this is discussed more here https://github.com/fomantic/Fomantic-UI/issues/441) and the implementation of a few things like icons will be changed to use attributes like data-icon="user" but in most cases it will remain the same and will require no changes.

mikejf-pr commented 5 years ago

Hang on, are you implying that the old method of using icons via class will no longer work?

If that's the kind of thing you're proposing, I certainly wouldn't call that 'backwards-compatible'. The changes might be easy, but they'd be extensive to the point of affecting everything you've done, and massively breaking, especially with regards to sites that use external integration projects.

I'd imagined that generation and less would be rewritten and granted increased customisation but generated css (not JS) output would remain compatible but extended to new features and components. Sounds like this is much more drastic.

Ultimately, for future things our company would have to follow the choice made by ng2-semantic-ui as to whether they'd support SUI or FUI, as it sounds like they wouldn't be able to do what I'd initially imagined and maintained a core integration set that worked across both sets of css. I certainly don't think there's enough maintainers to fork that project with any reasonable outcome.

lubber-de commented 5 years ago

Regarding the icons we could think about implementing a switch in the config to create the icon classes the old way. But keep in mind, the reason for the new syntax is there are many issues with icon names interfering with usual fomantic classNames, so we thought about an easy way to separate them

batata004 commented 5 years ago

I think semantic ui should not use icons on it own, except only the main icons like the X (close button that closes modals)... Icons are too heavy, too expensive to load and so on. Everytime you add more icons, fomantic gets even slower.

What I suggest? If you want to keep a ton of icons embbeded with fomantic code you could go in 2 directions:

1) let users choose only the icons he wants to use in the semantic.json file so when the user executes the gulp build he will only have a small set of icons on his final semantic.min.css file

2) let users choose freely ther icons from FONTELLO - which is amazing. You select the icons you want, you export and you can embed on any project. Super easy. This is actually what I am doing BUT this prevents me from using CDN to load FOMANTIC. In some websites I could easily load Fomantic from CDN but it comes with a huge load of icons that make everything slow. So I have to generate my own semantic.min.css/js files and load it from my server.

Keeping the way icons work in Semntic UI is making this library too "bulky". There is no point making the end user waiting to load 500 icons if on the website the user will just see 3 or 4 icons...

Also, every major framework that uses icons usually make it appear inside  elements using the class attribute to be used to referene which icon the dev wants to show. Using data-icon="user" is not backwards compatible at all and is not even what most libraries do so if could confuse most new users.

y0hami commented 5 years ago

@mikejf-pr

I certainly wouldn't call that 'backwards-compatible'. This is why I said in most cases. When I mentioned component changes the biggest change will probably be the icons and as for the icons change I'm sure we could include something inside the v2 polyfill. I also think your way overthinking the changes which we will be doing to the components. We might change a few styles to fix issue but we won't be changing class names and the structure of components and for the theming changes it will only be adding 2-3 classes to your body tag (if we go through with that change).

@mikejf-pr @batata004

Also, every major framework that uses icons usually make it appear inside  elements using the class attribute to be used to referene which icon the dev wants to show. Using data-icon="user" is not backwards compatible at all and is not even what most libraries do so if could confuse most new users.

As @lubber-de mentioned there are lots of bugs associated with the icons because they cause conflicts with their names and the easiest and best way to fix this is to move them into an attribute. Moving the icon names to the attribute also allows us to have better icon names since we can be mores specific in the CSS with names which include spaces etc. That being said yes its different compared to other frameworks but they don't have the problem of the icon names having spaces. SUI/FUI has names like class="american sign language interpreting icon" where as other frameworks could just do class="amer-sign-lang-icon" which is a lot easier to style in CSS without conflicts. An easy example of a conflict could be this class="big text width icon" which is a valid icon but could conflict with the text component, remember there are icons which have words like align, left, right, horizontal, vertical etc. you can probably see how these conflicts can happen.

batata004 commented 5 years ago

@hammy2899 nice example you gave :) But then what is wrong with class="amer-sign-lang-icon"? Why do you want to use space instead of -? Also, to avoid conflicts with other libraries, Fomantic could use a prefix on all of its icon something like fui-amer-sign-lang-icon. For this example it's not completelly necessary cause it's very specific but assume the icon left-arrow. On Fontello you can see there are dozens of icons with that exactly same name. So, if the user wants to use another Icon set from other library together with Fomantic icons, it would create lots of problems. To prevent that, if Fomantic icons where prefixed with fui- this problem would be gone.

y0hami commented 5 years ago

@batata004

But then what is wrong with class="amer-sign-lang-icon"? Why do you want to use space instead of -? SUI/FUI doesn't have - in any class names because the whole point is for the class names to be semantically written.

Also we wouldn't prefix the icon names because the element would be

<i class="ui icon" data-icon="user" />

So it would already be namespaced to FUI.

batata004 commented 5 years ago

@hammy2899 Ah ok! But I still like most the prefix idea than creating a whole new attribute. Also, I dont like spaces used inside names.

The main reason spaces may create lots of problems is this:

If for many reasons you need to select that element with jQuery, you could do this:

$("i.ui.icon[data-icon='x y']")

However, if your HTML becomes (which visually is exactly the same):

That jQuery selector will not work anymore! The same is NOT true when using classes cause if you have:

 or 

the code below still would work fine:

$("i.ui.icon.x.y']")

Imagine an icon named "arrow left" if the user changes his HTML to "left arrow" the icon still would work but if you use "data-icon" and if you have selectors based on icon name, you could get into problems.

ColinFrick commented 5 years ago

@batata004 That's exactly what semantic / fomantic ui stands for! arrow left is not the same as left arrow

Semantic UI treats words and classes as exchangeable concepts. Classes use syntax from natural languages like noun/modifier relationships, word order, and plurality to link concepts intuitively.

batata004 commented 5 years ago

@ColinFrick I agree with what you said but it does not hold true. Open https://fomantic-ui.com/elements/icon.html and look for the icon angle double left. Change it's class (using F12) to double angle left and the icon still works flawlessly. So, clearly to me, Fomantic is not enforcing it's concepts intuitively cause it accepts change of word order. If that is the case, I see no point in using spaces since using - with a prefix would allow better compatibility with other icon libraries and would avoid the problem of the selector I showed you a PoC.

lubber-de commented 5 years ago

Anyway : implementing dashes instead of spaces aswell as moving the icon names from classes to a data attribute is a breaking change in both cases which would require everyone to change their code.

y0hami commented 5 years ago

@batata004 This is one of the reasons we want to make this change, it can allow use to be more specific for the order of words and like @lubber-de as said no matter what option we picked it would be a breaking change which would result in everyone changing their codebase.

Also word order does matter in some places in SUI/FUI https://jsfiddle.net/usq950t8/

batata004 commented 5 years ago

@hammy2899 yeap, word order sometimes work and sometimes doesnt. I think inconsistency should be avoided always. As @lubber-de said, one way or another, changing the way icons work will break things.

I will just leave my last effort to advocate to using prefix with -. In many projects I still have to use external icon sets cause some of my customers want to use very specific icons. Everytime I work with icons (like font-awesome, fontello...) the sintax is always the same: prefix, '-' and the HTML is also the same. Icons will always look like:

BUT with the new propposed change to FUI, in some websites I will have to use

 

This is very different. I will have to use a different "HTML structure" in case I want to use FUI icons or in case I want to use different icon sets from external libraries.

I think, from the developer point of view, it wouldnt be nice at all having to maintain 2 very different HTML code just to show icons. I am not even mentioning JS cause if FUI adopt a new format to show icons, it is gonna have an impact also in Javascript selectors.

IMHO FUI should move along the trend in this specific case cause it may be very common to people using external icon sets with a "standard code structure" and it wouldnt be nice to have different HTML, CSS and JS code just to handle FUI icons.

y0hami commented 5 years ago

@batata004 A big part of developing v3 for me is to stick to the original goals and design of SUI, trust me I have done not hours but days of research into SUI and the background of the project for the sole purpose to keep to the original goals which @jlukic had when developing the library. I didn't just decide randomly to change how icons are implemented just because I can I did it because there is a need and I thought about other possible solutions but others like the one you suggested don't give the advantages of changing to a attribute. Look at tooltip it uses an attribute now you might argue that its because its the only way to achieve that effect but I would argue that moving the icon name to an attribute is the only way to achieve the effect we want for v3.

You have to understand that the changes we propose are not just randomly thought of and thrown out for people to talk about. We discuss these changes before hand and we do a lot of prototyping and research into other ways we can achieve changes without breaking the current API.

Another point is we aren't the first and won't be the last library to introduce drastic breaking changes in a new major version. For example look at angular v1 vs v2. These changes have to happen to libraries otherwise they won't improve.

About the JavaScript, there isn't much to change https://github.com/fomantic/Fomantic-UI/search?l=JavaScript&q=icon

batata004 commented 5 years ago

@hammy2899 I can tell you for sure that I spent a few minutes thinking before posting here, so your thinking of hours/days is surely way more valuable than my tiny effort. I am pretty sure that whatever decision you take is gonna be the best one! I agree with the popup you said too.

Regarding JS I didnt mean about changing the way it works. I meant about how selectors would break sometimes. I will quote what I meant.

The main reason spaces may create lots of problems is this:



If for many reasons you need to select that element with jQuery, you could do this:

$("i.ui.icon[data-icon='x y']")

However, if your HTML becomes (which visually is exactly the same):



That jQuery selector will not work anymore! The same is NOT true when using classes cause if you have:

 or 

the code below still would work fine:

$("i.ui.icon.x.y']")

Imagine an icon named "arrow left" if the user changes his HTML to "left arrow" the icon still would work but if you use "data-icon" and if you have selectors based on icon name, you could get into problems.

jamessampford commented 5 years ago

For this, when using SUI I simply removed all the icons from the CSS file and used them straight from Font Awesome so essentially I could use and everything works fine and I could/can update Font Awesome independently of SUI

Personally, I think we should be able to use any icon set we want, be it Font Awesome Free or Pro, Google Material Icons, and so on, or even a subset of icons to improve loading times but still use the format, where X is the icon set's own class name so we could, if need be, refer back to the original docs

I have Font Awesome Pro, so it would be great to simply drop in those files and simply use them "out the box" without any modification to FUI

y0hami commented 5 years ago

@jamessampford Technically you can use any icon set with SUI/FUI as long as you want to put in the work to modify the icon.overrides file which I agree is a big task. Maybe we could think about making a package for multiple icon sets in v3.

Feel free to suggest more

Also we have a script which you can use to use FontAwesome Pro with SUI/FUI and you can update the icons easily https://github.com/fomantic/icon-script

y0hami commented 5 years ago

Note about merging back into SUI & clearing up some confusion

I have saw a lot of people discussing in other repositories etc. about how FUI no longer has the intention to merge back into SUI. I want to clarify this is not true but merging back into SUI will be under different circumstances because of the changes we will be making with v3.

As I mentioned in this comment I have done lots of research about SUI and with v3 I want to keep to the design choices and ambition that @jlukic set when he started the project. I think people are misunderstanding what v3 is all about, v3 consists of 2 key points

Refactor/reorganize
and Modernize

Refactoring and reorganizing mainly comes down to the project structure itself and shouldn't affect users. Refactoring will be the build system and JS rewrite and could also consist of a CSS/LESS refactor. Reorganizing will be changing the repository to a monorepo and publishing the components as individual packages. The biggest change from the refactor will be the JS implementation which we have said a few times we will provide a polyfill for v2 to v3 to help with migration.

Modernizing the project will be simply changing aspects of the project so they are up to date with modern standards like ES6 for instance.

Now with all these changes yes the library will appear completely different compared to SUI but the underlining philosophy of the project will still be the same and hopefully it will be something @jlukic accepts and maybe agrees to how SUI should be built.

I want to point out 2 specific requirements/goals @jlukic wanted when he made SUI. He didn't want it to be like every other framework which required users to include the whole library he wanted SUI to be collection of components which users can pick and choose from, he describes this like a buffet of components. Now yes you can do that with SUI right now but it gets messy with components depending on other components etc. v3 can help with this because we can restructure the project so the components can be dependent on each other but so the user doesn't have to download and work out what they need to install to get components to work. Take the sidebar for example, it relies on the transition module which a user has to download for it to work. We can change this so the sidebar component includes the transition code which is required for it to work.

My second point is the @jlukic made the theming in SUI based on three levels of inheritance which consists of the default theme as the base layer and then a packaged theme so a theme shipped with SUI or one you download and then the site theme which is custom variables specific for that site. Now I think we can all agree that theming is a huge PITA and sometimes requires more work then its worth. Now for v3 we have a separate issue discussing theming proposals which would allow for the same three levels of inheritance but make it a lot easier and less time consuming to do.

Hopefully you now have a better understanding for why we are doing v3 and what the benefits are for both SUI and FUI as a whole.

If you have any questions feel free to ask 🙂

alexandrtovmach commented 5 years ago

@hammy2899 Thanks for clarifying all points, and yeah I have a question: How can I help?

y0hami commented 5 years ago

@alexandrtovmach If you want to get involved the best way is to start helping with the issues and making some PRs, if you want to help with v3 I would highly suggest you join our discord server so we can chat 🙂

fomantic / Fomantic-UI