Closed necolas closed 12 years ago
I would definitly go for it, but I wouldn't give the print snippet a seperate file, at least I would name it media-queries - thats more suitable.
Nope.js. It invites bloat (look at all the room for expansion!), causes the code to be less linear (and therefore harder to learn and harder to spot cascades between sections) and adds needless dependencies.
Are end-users expected to run the build script to use H5BP? I would be ambivalent in that case. Can we simply not make this breaking up an opt-in (I think @mklabs already did a task?)
My thinking is:
Drawbacks:
@import
is not an option, bound to get used in production).Still, there might be a solution. I don't think it would invite bloat. We've been pretty rigorous in stripping the project back and improving its organization.
Obviously, catering to people of various levels of experience is important. But I think the project also needs to continue adapting to its use in larger frameworks. Installing node.js and npm is one click away on every platform. Maybe we don't go down this route, this time. But I don't think we should make a habit of avoiding reliance on dependencies that are so easy to install.
It's probably worth creating another issue to solicit feedback from developers and understand what people are doing when they build larger frameworks upon this project.
Why not both?
Include in the repository both the combined file, and the separate files. The combined file would be the result of the build script, and users can decide to either stick with the provided combined file, or investigate the separate files and use the build script to remake the combined file.
Win / win IMO.
Why not both?
Sadly I have seen cases where one member of the team thinks it is combined, and another thinks it is not. Changes happen at both locations and then there is confusion.
People committing to the repo have different responsibilities than causal users downloading H5BP to use it… let's not lump them together.
Just put a word at the top of the combined file to say that it's a. combined, and that githubbers should modify the individual files and re-combine before submitting changes.
On 30 Jun 2012, at 7:20 PM, Divya Manian wrote:
Why not both?
Sadly I have seen cases where one member of the team thinks it is combined, and another thinks it is not. Changes happen at both locations and then there is confusion.
Reply to this email directly or view it on GitHub: https://github.com/h5bp/html5-boilerplate/issues/1132#issuecomment-6687246
@nimbupani There's indeed a related issue on the node-build-script repo, but I wasn't able to work further on this. I've been pretty busy last month, but I really plan to catch up with the build-script issues later in the week. Hopefully, there will be this new css-split
task, should this be useful here.
Why not both?
Yeah I'd thought about that, and had similar reservations to Divya. But I think this is a good option. We can easily combine the files and put a note in the combined one. I'm thinking about using the Sass-style convention of prefixing partials with an underscore, which could also help clarify the relationship between the files.
Hopefully, there will be this new
css-split
task, should this be useful here.
I wouldn't worry about the CSS split task. Not worth your time! I don't think it makes sense to have a build task that splits files for development.
I'd quite like to break the CSS up into separate files. Something like: normalize, base, helpers, print.
We could include a simple grunt.js (like jquery does) for people to easily concatenate and minify them. Not a full build script.
Thoughts? Drawbacks?