Enjoy.

via labjs or require.

my "boilerplate" load.js file has LABjs inlined in it, and then uses it to load jquery, GA, and one site js file. if it helps, I have an integrated RequireJS+jQuery in one file: http://bit.ly/dAiqEG ;)

also how does this play into the expectation of a build script that concatenates and minifies all script? should script loading be an option?

http://statichtml.com/2011/google-ajax-libraries-caching.html

According to that, there is a very little benefit to using the Google CDN to serve jQuery source. A better option would be to encourage devs to minify and concatenate all of their script files into one JS file served with a long-lived cache time.

This was referenced by Alex Sexton (@SlexAxton) in his talk at jQueryTO March 2nd, 2013.

IE6 is essentially dead in the Americas and Europe...and increasingly rare in the territories where it is clinging on. IE7 is close to dropping under 2%. Firefox 3.6 is no longer supported by Mozilla. Safari 4 died ages ago.

Going forward, we shouldn't actively support these browsers in the HTML5 Boilerplate project. If in the future someone absolutely needs legacy support for a specific project they are working on, then they can download the last stable release of HTML5 Boilerplate that supports it - it will do the job perfectly well.

Probable changes involved in dropping IE 6/7, Firefox 3.6, Safari 4:

• Changes to conditional comments around opening html tag.
• Switch to normalize.css v2
• Update main.css to remove any IE 6/7 hacks
• Change version of IE that gets Chrome Frame prompt.

We should consider their complete removal from the HTML5 Boilerplate template. A good time to do it would be as part of #1050 when IE 6/7 support is dropped for version 5.0.

Reasons:

• You can easily develop without them (personally, I've never used them).
• For IE 8+, their use is much more limited.
• IE 10+ will not support conditional comments.
• We don't explicitly target any other browser versions in the same way.
• It would fix whatever is going on in the very long-standing issues about the X-UA-Compatible meta tag. See #1187.

Hopefully, even "conditional IE class" users will view them as disposable in an IE 8+ development setting. If you need IE 6/7 support, the last 4.* release will still cater to your needs. However, feedback is welcome!

It'd be better for us to author the styles in scss.

We can still host the css in the repo for newbs that can't be bothered with a compass compile step

overall advantages:

• easier for most authors to begin scaling their styles
• better authoring experience
• integrated error checking
• don't need to rewrite everything (like a Sass dialect would require)

individual advantages

• hotpink color could be a variable
• :selection styles DRYd up
• box-sizing mixin for input[type=search]
• probably something very clever with our nonsemantic helper classes
• probably more than i'm missing

disadvantages

• one more step. (not if you're using livereload, codekit, etc)
• double file checkin for css changes (not that they happen often)

Microsoft is ending the extended support for Windows XP on April 8, 2014. Since IE8 is mostly a Windows XP browser, and it's market share is slowly but steadily going down¹ , I think we should start the discussion on dropping IE8 support.

¹ Some current estimates (feel free to share your own/other):

• 6.15% - StatCounter (March 2014)
• 4.24% - W3Counter (February 2014)
• 5.29% - Clicky (most recent)
• 6.93% - 8.73% - Wikipedia (as of September 2013)

Changes involved with dropping IE8 support:

• Remove IE8 related code
• Switch to jQuery 2.x.x
• Update conditional comments for "browse happy" prompt
• Remove html5shiv?
• Update documentation
• Other (which?)

IE6-8 require respond.js to act as a polyfill because H5BP uses mobile-first media queries.

I'm not convinced mobile-first media queries are best.

1. Clearly they have this extra cost for IE baked in.
2. Secondly, it's a little awkward, as a developer, to write your styles mobile first.

What mobile browsers (in use, currently) do not support media queries? Moreover, of the ones who don't, are there browsers that don't scale the content to somehow adapt to the small screen size?

I don't know enough of the Blackberry/Nokia product line to know what's up on this front. But I have a feeling the mobile-first MQ setup is a lot of work. And the payoff is not worth the effort.

• js/css concat and minification
• html minification
• filename revving for far-future expries.
• image optimization (jpegtran, pngcrush, etc)

others: http://daverupert.com/2010/06/web-performant-wordpress/

I'm unsure on how this could be added to the project in a general way.. something php/ruby/py/html folks could all use it.

Even though the doctype is HTML5 recommended and the X-UA-Compatible meta tag is present, by putting the HTML tag in a series of IE conditional comments, IE refuses to believe that the website is indeed "modern" and puts the dreaded "Compatibility View" button in the address bar.

The way I get around this is by using JavaScript to add the ie6/7/whatever classes.

Example:

<html class="no-js" lang="en">
...
<!--[if lt IE 7 ]>
    <script src="js/libs/dd_belatedpng.js"></script>
    <script> DD_belatedPNG.fix('img, .png_bg'); var ie = "ie6"; </script>
<![endif]-->        
<!--[if IE 7 ]> <script> var ie = "ie7"; </script> <![endif]-->
<!--[if IE 8 ]> <script> var ie = "ie8"; </script> <![endif]-->
...
if(typeof ie !== 'undefined') $('html').addClass(ie); // in js/script.js

I'm sure there are better ways to handle this, but this works as expected.

This article claims that -9999px (or -999em in our case) has noticeable performance issues when running animations on the iPad 1.

Performance is dramatically improved because a 9999px box is not drawn. Noticeably so in animations on the iPad 1.

The new CSS would be something like:

.ir {
    text-indent: 100%;
    white-space: nowrap;
    overflow: hidden;
}

Also, H5BP has some non-obvious tweaks in the existing .ir class that would need to be evaluated if this new method were to be implemented.

I'm thinking we should move from the Ant build script to something else..

why?

• XML is gross. Therefore the build.xml is less than sexy.
• ant build files are a pain to read and learn from
• ant build files are not very easy to maintain. we have a lot of unsolved issues and such
• using java hasnt been the cross-platform magic that i was hoping for.

However, what is does is hugely useful.

We're thinking about using Sass and Compass in the build cycle in order to get @import inlining for our stylesheet optimization. This introduces a Ruby dependency. (However I will note that I have nearly successfully campaigned a YUI Compressor (which we're currently using) developer to add the @import inlining feature)

So if we need ruby in the build process.. Let's just go for it. Rakefiles are wayyy better and more readable than Ant build files.

Things to be done:

• Find experts
• Get an estimate on level of difficulty on porting the script
• Determine a lead
• Port it
  • Hopefully breaking this step up into a few developers, if possible
• ???
• Profit? Nah, bro we're public domain. Benefit!!!

Relevant links:

• the build.xml file
• build script docs.. what it does in English
• existing open buildscript tickets

Guys that are interested in helping (and have experience with Rake):

• @joshuaclayton
• https://twitter.com/#!/KushalP
• https://twitter.com/#!/AlexGraul
• @markupboy
• https://twitter.com/#!/halfcube
• @akahn

(alternatively if anyone reading this thinks we should stick with Ant and wants to take the lead on iterating on it... by all means please speak up! :)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [] I have added tests to cover my changes.
• [x] All new and existing tests passed.

Pull requests should be thought of as a conversation. There will be some back and forth when trying to get code merged into this or any other project. With all but the simplest changes you can and should expect that the maintainers of the project will request changes to your code. Please be aware of that and check in after you open your PR in order to get your code merged in cleanly.

Thanks!

I'm submitting a ...

• [ ] bug report
• [ ] feature request
• [x] other (Please do not submit support requests here (below))

How to I make static assets available on the published website? I want to publish at mywebsite.com/some-image.png so I can use it as an OpenGraph image (which does not allow relative URL).

I tried to create a public folder and a static folder but they are not copied on build.

I feel this info should be in HTML5Boilerplate docs.

Sorry in advance if missed it but I read the docs (I checked the README, Usage, the FAQ Miscellaneous and Extending), I searched Parcel docs, Github Issues issues, SO.

Is there something we can do there? Don't mind me, I'm just looking for interesting stuff to do as I try to amp up my OS contributions over this summer.

As multiple third-party scripts might be added to a site during development, it can be difficult to see when a script is attempting to use new browser features that might have privacy consequences.

Consider adding a simple alert so that scripts can be checked and/or the site Permissions-Policy set before deploying to production.

The "alert" is for development purposes, and could be replaced with an analytics event if a site wants to monitor attempted use of Topics API by third parties in production.

Related: https://github.com/h5bp/html5-boilerplate/pull/2459

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ x] My code follows the code style of this project.
• [ x] My change requires a change to the documentation.
• [ x] I have updated the documentation accordingly.
• [ x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.

Pull requests should be thought of as a conversation. There will be some back and forth when trying to get code merged into this or any other project. With all but the simplest changes you can and should expect that the maintainers of the project will request changes to your code. Please be aware of that and check in after you open your PR in order to get your code merged in cleanly.

Thanks!