Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Drop the HTML5 element styles #60

Closed
necolas opened this Issue · 5 comments

4 participants

@necolas

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.

@aFarkas
Owner

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

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

I'm ok with that.

@paulirish
Collaborator

+1

@aFarkas aFarkas closed this
@jonathantneal
Collaborator
  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

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
Something went wrong with that request. Please try again.