todc-bootstrap: a Google-styled theme over Bootstrap's own classes

A Google look layered over Bootstrap's own class names

TODC Bootstrap is a theme rather than a fork that adds widgets. The stated goal is `feature parity with Bootstrap`, themed with Google's UI in mind, and `UI parity with Google Apps` is explicitly not the aim.

That boundary settles most adoption questions on its own. A team that wants the Gmail look for buttons, inputs and menus can take the styling and keep every Bootstrap class, attribute and JavaScript behaviour already in use, which means existing documentation and muscle memory survive the switch.

Where the theming lives is the scss/ directory at the repository root, and the css-compile script runs node-sass across it into dist/css/.

node-sass --output-style expanded --source-map true --source-map-contents true --precision 6 scss/ -o dist/css/

That one line is the whole CSS build: expanded output, source maps with embedded sources, six digits of precision. Editing scss/ is editing the theme itself, while editing dist/ is editing a build product that the next compile will overwrite.

The dist directory ships every stylesheet under two names

Compiled output arrives twice over. The documented tree lists bootstrap-grid.css, bootstrap-reboot.css, bootstrap-utilities.css and bootstrap.css sitting next to todc-bootstrap.css and todc-bootstrap-utilities.css, each with a source map and a minified sibling, and a js/ folder holding the plain, ESM and bundled builds.

The duplication is a choice rather than clutter. A team that commits to the Google styling can reference the todc-bootstrap.* names and stay inside the theme, and a team that decides halfway through a project that it wants the upstream look can switch to the bootstrap.* files without leaving the folder.

Bundling matters more than the naming does. bootstrap.bundle.js and bootstrap.bundle.min.js include Popper, so a page using dropdowns, tooltips or popovers loads one script instead of two, and the .map files sit beside every build for developer tools that read them.

Four install routes, then the one command every route needs

Four ways in are offered, and they all land in the same directory. The quickest is the zip archive of the 5.0.0-5.0.0-alpha2 line; the rest are a git clone, npm, yarn and Composer, which matters when an existing build pipeline already speaks one of those package managers.

git clone https://github.com/todc/todc-bootstrap.git
npm install todc-bootstrap@next
yarn add todc-bootstrap@next
composer require todc/todc-bootstrap:5.0.0-5.0.0-alpha2

Pick one, then read the note before doing anything else. After cloning or installing, the README says you must run grunt checkout-bootstrap from the todc-bootstrap directory, and the stated purpose is to download the correct version of the Bootstrap source. That is a source fetch rather than a package install, and the docs give no output to expect from it.

The version history attached to the project stops at v3.4.0-3.4.1 on 2018-12-15, followed by v3.4.0-3.4.0 the same day and v3.3.7-3.3.13 on 2017-05-24, so the newest tagged build sits behind the 5.0.0-5.0.0-alpha2 line that both package.json and that download link name.

The quick start asks for grunt while package.json runs node

A close reading turns up the first contradiction. Every install route ends with a mandatory `grunt checkout-bootstrap`, yet the scripts block in package.json declares no grunt task whatsoever. The nearest neighbour is clone-bootstrap, wired to `node build/clone-bootstrap.js`, and no grunt configuration appears among the repository root entries.

The documented post-install step therefore does not match the build tooling that ships in the package. A reader who installs from npm and then types grunt is asking for a binary the package never declares, and the fallback the package does define is a plain node script under a different name. Nothing in the docs bridges the gap, and the gap sits on the mandatory path rather than on an optional one.

The step is also hard to skip. The Requirements entry for Bootstrap says it will be automatically checked out, if necessary, during the build process, which is the same source the quick start expects a reader to fetch by hand before that build ever starts.

The gzip size badges measure Bootstrap's main branch

The Status block invites a misreading. Its devDependency badge points at twbs/bootstrap, and the CSS gzip size and JS gzip size badges link to the Bootstrap repository's main branch dist files rather than to anything inside this project. The figures a reader sees on that page describe upstream's compiled output, not the theme that would actually ship.

Two smaller signals sit in the same block. The JavaScript size badge appears twice, once with its label written as JS+gzip+size and once percent-encoded as JS%20gzip%20size, so the page measures the same upstream file from two URLs. Browser coverage is not backed by a live badge at all: the BrowserStack badge is wrapped in an HTML comment in the source, and a TODO line above it says to configure BrowserStack.

The practical effect is that neither the size budget nor the browser matrix can be checked from the page as written. bundlewatch is configured through .bundlewatch.config.json for anyone who wants the size check to run locally instead.

The minifier never names the theme's own stylesheet files

Compare the dist tree with the css-minify chain in package.json and the gap is concrete. Four cleancss passes write bootstrap.min.css, bootstrap-grid.min.css, bootstrap-utilities.min.css and bootstrap-reboot.min.css, and then the chain stops.

cleancss --level 1 --format breakWith=lf --source-map --source-map-inline-sources --output dist/css/bootstrap.min.css dist/css/bootstrap.css

Neither todc-bootstrap.min.css nor todc-bootstrap-utilities.min.css is named by any of those passes, although both sit in the documented tree next to their unminified forms. Either a task outside this chain produces them or the tree has drifted away from the scripts.

That is the kind of detail that only surfaces when someone builds rather than reads. A pipeline that requests a minified theme file should be pointed at an actual published artefact first, and anyone maintaining a fork should treat the scripts block, not the tree listing, as the description of what gets written.

Compatibility still promises IE8 beside a Bootstrap 5 alpha

Compatibility gets a single sentence: Chrome, Firefox and IE8+ are named as the test targets. That line sits directly under a quick start whose download link names 5.0.0-5.0.0-alpha2, the Bootstrap 5 alpha line, and beside a repository carrying a .browserslistrc at its root. Nothing in the docs reconciles the two, so the browser list reads as a leftover from the Bootstrap 3 era rather than a tested matrix.

Packaging shows the same lag. The repository root holds nuget/ and composer.json, which means a .NET channel and a PHP channel exist, yet the quick start names only the zip, npm, yarn and Composer routes and never mentions the NuGet package. A .NET shop reading the root listing has more options on offer than the documentation admits.

The gap matters for an adoption decision more than it first appears. An IE8 claim and a Bootstrap 5 alpha number cannot both describe one support policy, and the reconciliation is not in these files.

Hugo docs share the repository root with the compiled output

The documentation is not a separate site repository. Hugo builds it from the repository root, which is why config.yml and site/ sit beside dist/, scss/, js/ and build/, and the result is served from GitHub Pages at todc.github.io/todc-bootstrap/, with a getting-started page under docs/5.0/.

Two companion projects are named as built for this one: todc-select2 for Google-themed select menus and todc-datepicker for a Google-themed datepicker component. That answers the question a theme always raises, which is what happens to the widgets Bootstrap never had. You take them from the same author, they carry the same visual language, and they live in separate repositories with their own schedules.

The last push landed on 2026-10-05 and the root LICENSE file is MIT, so redistribution of the compiled CSS and JS requires keeping that notice in place and nothing beyond it under the licence terms.

Editorial conclusion

Adopt todc-bootstrap when you want Bootstrap's class names and behaviour wrapped in Google's visual language without maintaining your own Sass variables, and pass on it when your team needs a browser matrix that matches the Bootstrap build you already ship. Check three things first: whether grunt checkout-bootstrap resolves on your machine, whether todc-bootstrap.min.css is published under that name, and which Bootstrap version your pages load today. The docs on GitHub Pages settle the styling question in minutes; the build chain settles everything else.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. todc/todc-bootstrap on GitHub