Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Drop the HTML5 element styles #60

Closed
necolas opened this Issue May 12, 2012 · 5 comments

Comments

Projects
None yet
4 participants

necolas commented May 12, 2012

Please reconsider the inclusion of CSS rules. Reasons:

  1. The existing CSS is out-of-date and missing elements like summary.
  2. The existing CSS is not being updating (and wasn't prior to being included in a stable release).
  3. The [hidden] rule should not be in the JS at all. It deviates from the expected behaviour of modern browser defaults by increasing the experienced specificity, meaning that IE's "hidden" will interact with other selectors slightly differently to modern browsers. This is fine if it's packaged in something like normalize.css because all browsers are on the same page and it can easily be stripped from the CSS if there is a problem. That is not the case when it is bundled in a JS lib.
  4. A JS lib is not the place to include CSS that many others many not know is packaged in the lib.
  5. Any changes to the CSS in the future could have substantial knock-on effects for sites that link to the Google Code CDN and build their HTML5-based sites (knowingly or unknowingly) upon the foundational CSS bundled with this lib.

Thanks.

Owner

aFarkas commented May 13, 2012

Hi necolas,

form the feedback to old versions of html5shiv, we know, that people do expect that html5 styles are polyfilled by html5shiv. Additionally, we already are using this version through google code CDN, so we can't simply change those rules anymore, without breaking something.

This said. I'm open to remove most of the stlyes and simply leave the following rule:

 article,aside,figcaption,figure,footer,header,hgroup,nav,section{display:block}

Those rules are the rules, which are expected by most html5shiv users, do not need additional polyfills (like audio, video, details) and are 100% fututreproof.

@necolas, @jonathantneal and @paulirish, what do you think?

necolas commented May 13, 2012

I'm open to remove most of the stlyes and simply leave the following rule.

I'm ok with that.

Collaborator

paulirish commented May 13, 2012

+1

@aFarkas aFarkas closed this May 13, 2012

Collaborator

jonathantneal commented May 14, 2012

  1. Remove the whole thing because some elements are out-dated? Update it.
  2. Same argument as #1? Same answer.
  3. Don't do it because it's JS and hidden gets specificity? Even if it gets specificity what selector added by anyone would not overwrite it? None. I think it was the best place for it, because including it in JS was better than html5shiv.css.
  4. Same argument as #3 sans [hidden]? Same answer sans [hidden].
  5. There may be side effects? Maybe, but were there side effects that folks were experiencing? What were the hypothetical side effects?

This is very confusing. I don't agree with a single reason to remove so much of the functionality of the shiv, and it's already done.

necolas commented May 14, 2012

Update it.

Unfortunately, this wasn't even done prior to the release that decided to bundle CSS in the shiv. I raised it with you on IRC several times.

Even if it gets specificity what selector added by anyone would not overwrite it? None. I think it was the best place for it, because including it in JS was better than html5shiv.css.

Nope. In browsers that don't get the shiv's CSS, a selector like p {display:inline} would render <p hidden> visible, whereas legacy browsers would still have the paragraph hidden. The place for this kind of thing is in an author-controlled stylesheet that affects all browsers in the same way and sits with the rest of the site's CSS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment