Use bootstrap 4 for phx generator markup/css

[michalmuskala]

Since phoenix does not include all of bootstrap anyway in the default generators maybe it would make sense to have something other than that? Maybe even keep generating the same markup, but with some custom css? I think including parts of bootstrap is only confusing to people - there's a lot of questions about that.

[chrismccord]

The original goals were to have something that looks nice out-of-the-box that folks can roll with as they are getting started or prototyping. So we are not married to bootstrap, but given its ubiquity, having a popular solution can be more helpful over some custom css and markup or another more obscure setup. I would be open to alternatives, assuming:

• Someone wants to own this markup and css update, including making sure our forms style properly
• It works across all major browsers
• Is responsive out of the box

I agree including only parts of bootstrap can be confusing, but bootstrap itself is often used piecemeal so it's not completely unexpected. For giving workshops and teaching around Phoenix, having the sane grid system and styles that a lot of folks (and me :) already know about is extremely useful.

[webdeb]

Since https://github.com/phoenixframework/phoenix/pull/2779 is merged. It would make sense to provide a proper configuration layout based on the webpack guides here: https://getbootstrap.com/docs/4.0/getting-started/webpack/

And try to prevent the confusion by referencing to the guides of webpack / bootstrap..

In case of --no-webpack just a link tag to the official build, so its also easy to remove.

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous">

[inoas]

Maybe this can be revisited once native css grid are widely adopted by browser vendors. With autoprefixer it is at 86% now - still a way to go: https://caniuse.com/#feat=css-grid

Then I suggest to take a look at https://github.com/mblode/marx

Combined with native css grids / flexbox productivity is great and dependencies are low (no class/div soup).

[arlomba]

May I suggest Bulma (https://bulma.io/)? Is the CSS framework of my choice after using Bootstrap for a long time, some advantages:

• Easy to learn (very intuitive classes).
• Responsive.
• Uses flexbox.
• No JavaScript.

Other CSS frameworks are too minimal (Pure, Milligram...) or too bloated with JavaScript and jQuery (Foundation, Semantic UI...). Bulma works just fine for me.

I already have some progress in templates. I'm not a good designer to be honest so... any feedback would be much appreciated! Here's how it looks like:

Desktop: https://image.ibb.co/cFGyHn/Screenshot_2018_3_5_3.png Mobile: https://image.ibb.co/eYO0V7/Screenshot_2018_3_5_1.png Mobile (burger expanded): https://image.ibb.co/ikjUOS/Screenshot_2018_3_5_2.png

Notable changes:

• Added Font Awesome 5.
• Added a navbar. I think this is a must on every webpage and could be handy to have some scaffold.
• Added nav burger for mobile, requires a few lines of JavaScript to work properly.
• Added link to Stack Overflow.
• Updated doc links to hexdocs.pm.
• Updated Mailing list to Phoenix Forum.

If everything is fine, then I'll take CSS update on forms.

[thiagomajesk]

+1 for Bulma as a simpler alternative - considering its small footprint and simpler style.

PS.: @chrismccord not necessarily related, but I think we could use that as an excuse to revamp Phoenix's welcome page (look at recent rails landpage for inspiration)

[josevalim]

@anticide Keep in mind that our goal here is to provide the minimum necessary so a just generated Phoenix application looks decent. So for example, adding new font dependencies is a no-no. Let's keep it simple and light because the odds are, whatever we do, users will just remove it anyway. So let's optimize for removal.

Another thing to keep in mind is that we also need to update the phx.gen.html generators if we change frameworks and I would like to avoid that the maximum we can. We already changed them for Phoenix v1.3, changing them again is just too many changes in a short period of time.

However, if bootstrap4 also requires changing the templates, then there is nowhere else to run.

And great catch on updating the links!

TLDR - think about incremental improvements rather than a full redesign.

[webdeb]

What if we completely get rid of bootstrap like @michalmuskala suggested. For the index.html we could just add some css <style> and for generators there should be actually an api, so that people can come up with their own templates, and use the classes they prefer instead of cleaning up each time after generation.

As a developer, I do not care about the default fancy styling of some magically generated stuff, more interestingly for me is how I can change this default behaviour..

Just my 2 cents

[josevalim]

As a developer, I do not care about the default fancy styling of some magically generated stuff, more interestingly for me is how I can change this default behaviour..

Which is why bootstrap is in a single file that you can just remove. You are right: being able to remove is the most important bit here.

The choice here is not supposed to matter. If someone wants to write a custom .css file that would look decent and responsive, we are fine with that too. We only use bootstrap because that's the easiest way to do this.

[inoas]

You are right: being able to remove is the most important bit here.

The benefit of using MarxCSS (Demo) would be that everyone can throw it away with zero tech-debt as there are no css classes being used and this you don't pollute your eex view templates / DOM with tech-debt (as Twitter Bootstrap, Bluma, Foundation and similar do). As such it works well with Elm/ReactJS especially if you simply add native CSS grids/flexbox code.

Note 1: If you add autoprefixer via gulp/webpack or whatever native css flexbox is already commercially viable and native css grid will soon be. Note 2: If there is any CSS framework that imposes html template dependencies it should be Twitter Bootstrap 4.x as that then makes the most sense economically.

[josevalim]

I like the idea behind MarxCSS because we can get something nice looking without touching the markup.

I am not worried about the Phoenix index.html because that's definitely a one-off page and we can add at least some CSS in there.

Can someone build a small prototype and let us know how the phx.gen.html index and edit pages would look like with MarxCSS?

[pragmaticivan]

If there are any thoughts to incorporate bootstrap 4 using SCSS, it would be a simple transition, since you can use mixins to handle the grid part of it. Ex: https://getbootstrap.com/docs/4.0/layout/grid/#example-usage

It would reduce the efforts of updating the markup on index.html as long it has enough identifiers (classes/ids) to allow the simple usage of it.

[chrismccord]

We shipped scss initially but dropped it because it included like 20MB of test stubs node_modules. Has the situation improved there?

[webdeb]

We shipped scss initially but dropped it because it included like 20MB of test stubs node_modules.

What? ...compiling node_sass is the most enjoyable process :D

[webdeb]

MarxCSS was initially designed as a reset. Thats what you need anyway, so 👍

[arlomba]

@josevalim makes sense, thank you.

Regardless of the CSS framework, I'd suggest moving the header tag out of the layout (e.g. to the generated page). This is something that you'll always remove:

https://github.com/phoenixframework/phoenix/blob/master/installer/templates/phx_web/templates/layout/app.html.eex#L16-L23

This way the layout looks cleaner IMO. Also I noticed that the default meta tag is missing shrink-to-fit=no property, the standard meta tag is:

<meta name="viewport" content="width=device-width, initial-scale=1.0, shrink-to-fit=no">

More about this: https://bitsofco.de/ios-safari-and-shrink-to-fit/

[josevalim]

Regardless of the CSS framework, I'd suggest moving the header tag out of the layout (e.g. to the generated page). This is something that you'll always remove:

Then let people remove it. Again, the focus is on generating enough for what Phoenix needs, and Phoenix does not need headers per page.

[rockwood]

I'd like to second the idea of switching to something that doesn't require specific css classes. I use Bootstrap for just about everything, but I can understand how a newcomer might be confused by all the generated bootstrap classes. I also think it's important to have the generated templates look professional out of the box.

I built out examples of class-less generators using these three frameworks:

• Marx
• Tacit
• BareCSS

I think Marx is the best choice since it's the least intrusive. Tacit is nice, but it wanted to change the body color and add rounded corners in places that looked a little funny. I really like BareCSS's approach, but I think it's form styles are a little too complicated.

Here are some screenshots of Marx:

index.html

edit.html:

show.html

This removes all classes from the generated form markup, and adds a couple custom classes for flashes, help text and the home page. I'm going to prefix these with phx- so it's obvious that they're coming from phoenix.css.

Let me know if you think this will work, and I'll put together a PR.

[raarts]

As a newcomer I can confirm often being confused by irrelevant additions. My preference would even be to do no styling at all, because that's irrelevant to what I'm trying to learn (the templating process).

[yordis]

@chrismccord dont you think is better to add that as an extra deps? And then you would configure your default generators?

I don't use bootstrap since Bootstrap since 2016. Also from maintainability perspective, Bootstrap likes to break every major release their code so that will means more open issues and maybe causing Phoenix release delay.

[josevalim]

We went with miligram at the end of the day:

The header and alerts were based on the PR by @inoas.

@rockwood, if you have suggestions, please let us know!

[webdeb]

The logo is also very nice, may I ask if it played a significant role for the final decision? ;-)

[inoas]

The font choices Milligram makes are terrible though. And not some of them - all of them: Kerning and font weights (too much/too little) as well as font sizes.

[josevalim]

@inoas is it something that we can easily change without overriding all definitions?

[inoas]

I got problems getting phoenixframework/master to run as demo locally (as a newbie): But this could help:

Roboto:

Without Roboto AND without Helvetica Neue AND without letter-spacing (bad practise globally/on body as it breaks/may break default font kerning)

[josevalim]

Done in master. I do like it more too.

[glhrmv]

I feel like a classless CSS file is the best approach. It was mentioned that optimizing for removal is essential, so a single phoenix.css with Bootstrap made sense. But this ignores the consequences in the markup that including a class-based framework implies: it is not particularly fun having to delete the Bootstrap-specific markup, especially with all the ugly div nesting that it encourages by design.

I don't see how Milligram helps this issue, either, it seems like it will only make it more difficult for newer users by virtue of being much less known than Bootstrap, which is widely used.

[josevalim]

@glhrmv if you look at the PR that added miligram, it is mostly classless, we only had to had classes in one or two occasions (and those occasions also required classes in the other classless libraries).