Foundation-sites: Normalize does not set <main> display block

[nicolaiwolko]

What should happen?

normalize should set the <main> tag to display: block,
like it has done at version 6.4.4-rc1 with normalize.scss

What happens instead?

Nothing is set for the <main> tag. IE is known for not implementing/support
the main tag, so at least display: block have to be set to make it behave
like a div.

Possible Solution

• Consider using another vendor normalize
• Introduce your own normalization with:
  main { display: block; }

Test Case and/or Steps to Reproduce (for bugs)

Use a <main> tag in IE with foundation and add for instance a background color.
Place some content inside the main and the background color will not be shown.

[DanielRuf]

https://github.com/necolas/normalize.css/blob/master/normalize.css#L32
https://github.com/csstools/normalize.css/blob/master/normalize.css#L50

It seems this was fixed in normalize 8.0.1, see https://github.com/necolas/normalize.css/blame/8.0.1/normalize.css#L32 and https://github.com/necolas/normalize.css/commit/df07c00a92c683e591b68bcc45075ff7253b7482

I propose that we switch to csstools/normalize.css which is the right normalize imo.

[nicolaiwolko]

You are right, you are using normalize 8.0.0 at the moment:
https://github.com/zurb/foundation-sites/blob/develop/scss/vendor/normalize.scss#L2

So updating should fix it too

[DanielRuf]

Well, in the long run, updating is not the solution. We have to migrate to csstools/normalize.css. See https://github.com/csstools/normalize.css/issues/3#issuecomment-421401639 and https://github.com/necolas/normalize.css/issues/664

[ncoden]

@DanielRuf Did you read the whole discussion at https://github.com/necolas/normalize.css/? It is very interesting.

About the comment of jonathantneal:

• > The necolas version includes non-fixes, previously known as opinionated defaults before such documentation was removed, like body { margin: 0 }.

I don't see any problem with that. I would argue like @necolas that a practical approach for the interests of developers is more important that the any philosophical purity. Like most sites, Foundation rely on a "soft reset", not only on a browser styles normalization.

• The csstools version is more actively maintained.

  I would disagree with that assertion. If we compare the GitHub analytics (necolas vs csstools) and releases (necolas vs csstools), we can see that...

  Edit: I took a look at the Changelogs (necolas vs csstools) and, I admit, the csstools's version is more maintained (even if some of these changes are the removal of opinionated rules).

• I am blocked from submitting PRs or following any changes or discussions in the necolas version.

  Sad, but that is not a reason for us to use its version of normalize.css over the necolas's one.

[jonathantneal]

more followed and maintained

Would you quantify that? I maintained the necolas version while he walked away from the project. I’ll admit that it’s hard to follow updates to that version since I’m blocked from the project.

[ncoden]

@jonathantneal I just corrected my comment.

[ncoden]

@necolas @jonathantneal

Hello Guys, I'm happy to see you two there, but at first I have to make this very clear:

You will not start another fight.

[jonathantneal]

I’m really sorry to read that, Nicolas. I would love, love to be on good terms again. I understand if you’re not interested at this time, and I do hope it changes. Would you consider unblocking me from the project if I agree not to comment on any issues until you say it’s okay? It really sucks to not be un-included like that.

As for this thread; y’all pick the libraries that serve your needs best.

I think the issue of body { margin: 0 } is a kind of tabs vs spaces thing. I tend to think normalize should stick to fixes, while many other intelligent people think certain opinions are practical.

I would have personally expected people to “die on a hill” (*) for adding * { box-sizing: border-box } before preserving body { margin: 0 } but the later has obviously had a major influence on the project. I didn’t expect that. 😄

@ncoden, totally understood. Please delete this message if you feel it’s aggravating.

[ncoden]

If I may continue with the purpose of this issue and the problem that Foundation is facing.

We care more about our developer's best interests than the struct following of the "browser normalization" approach. But on the other side, we want to rely on a watched and well-maintained project.

@necolas What is the maintenance status of necolas/normalize.css? Is there someone that currently ensure a technological watch on the project? As you can see, many improvements has been made in the csstools' version this year. Would you consider adding them to your version?

@jonathantneal Developers generally don't like separations in communities and projects, and most often it doens't end very well. Do you think that creating a second csstools/normalize.css project is the best solution? Would there be others options that would be in the best interest of the whole community? For example at Foundation we provide several CSS files so the user can pick the one that fit the best its needs.

[necolas]

Please stop mentioning me in this thread.

[jonathantneal]

@ncoden, I will think more about that. At the moment, I do not like having 2 separate projects. I would prefer the “opinionated” and “fixes only” versions both live in the same repo. I can add the opinionated version to csstools if you think that would be helpful.

I want to be sensitive to others who think the projects should be separate with separate names. For instance, there is sindresorhus’ excellent and well-known version https://github.com/sindresorhus/modern-normalize/. How much of a name change works?

In the meantime, could you take any fixes from mine and make them PRs on necolas’ version if they are not already? That should make it easier to use his version and end any immediate concerns.

EDIT: Removed a tag I added on accident. See history.

[ncoden]

I want to be sensitive to others who think the projects should be separate with separate names.

In the meantime, could you take any fixes from mine and make them PRs on necolas’ version if they are not already? That should make it easier to use his version and end any immediate concerns.

IMHO these 2 solutions in the same time would be the best. Using an other name to avoid confusions, and importing each project advantages into the other. I hope that this conflict will be resolved one day, but until then we would have two distinguishable projects, one with opinionated rules and the other without.

[jonathantneal]

Would you mind helping me with the name? Naming things is hard. Right now it’s @csstools/normalize.css on npm and the README.md just calls it normalize.css, since they have the same initial git history.

I’ve immediately updated the README.md to call it csstools-normalize (following the sindresorhus convention) and I’ve added the opinionated styles (edit) in a separate file (sorry, was rushing typing). I can add the others after referencing the current necolas release. See https://github.com/csstools/normalize.css

Anything else I can do to help?

[ncoden]

@jonathantneal The best you could do is a csstools/normalize version has a distinguishable name and a stable version that include an "opinionated" option (with all the rules from the @necolas' version, not something made in a rush).

Once this is done, released and stable, we could switch to csstools/normalize. But I'd like to get the opinon of @DanielRuf on this before.

[necolas]

Please stop mentioning me in this thread

[ncoden]

@jonathantneal There is just something I did not understood: what is the difference between normalize and sanitize.css ?

[jonathantneal]

csstools’ normalize is just browser fixes, while sanitize is normalize plus opinionated changes based on developer preferences — things that will never ship as the default — things like box-sizing: border-box.

[ncoden]

@jonathantneal What is the difference with necolas' normalize (or any "opinionated normalize") then?

[jonathantneal]

That normalize includes 2 opinionated styles — font styles on inputs and margin removal on the body. (I had added the body margin removal in 2011 https://github.com/necolas/normalize.css/commit/6671403e3ba83cf721795cdc888b7bcda85e374b)