Do either work across browsers and Screen Readers?

Details on Use of role=presentation or role=none

Short answer is:

• All modern browsers support both role="none" and role="presentation"
• Internet Explorer 11 supports role="presentation" only
• JAWS 2019 works around IE's lack and so supports role="none"
• NVDA 2018.2.1 does not work around IE's lack of support and so does not support role="none"
• Although Edge 17.17134 supports both, Narrator appears to not take notice of either.
• NVDA and JAWS work as expected with Firefox 64.0b12 (64-bit) and Chrome Version 70.0.3538.110 (Official Build) (64-bit).
• VoiceOver with Safari 12.01 and Chrome Version 67.0.3396 on macOS Sierra works as expected.

Try for yourself:

LEGOs are rigid plastic with only one interface: the stud.

LEGOs do not reconfigure to fit a screen.

LEGOs do not stretch to accommodate their contents.

LEGOs are inaccessible to the blind (colors) and motor-impaired (assembling, disassembling).

LEGOs can be notoriously difficult to separate.

LEGOs cannot join with unofficial materials/pieces or they risk discoloration, deformation, and getting broke. This includes sunlight.

If you need a piece that LEGO doesn’t make, you are out of luck.

If you need a color that LEGO doesn’t make, you are out of luck.

Nobody is allowed to create stuff that works with LEGO pieces other than LEGO.

LEGOs that change state, have memories, or are otherwise useful are banished to other, more advanced brand names, like Technic and Mindstorms/NXT.

Web components (not Web Components™) are not quite like LEGOs.

In fact, they’re very different.

LEGOs are toys, as it turns out.

Theming apps

A not so surprising use-case of CSS variables is theming apps. Think of Twitter for example where you can specify the color of your profile. This color and its shades appear on many elements: links, buttons, borders, highlights, etc. Take a look at my annotated twitter profile:

Themed elements on Twitter (...oh yeah, follow me)

When you customize your profile, you only have to specify one color, the rest is magically taken care of. I like the simplicity and ease of use of this concept, and I wanted something similar when I started thinking about making Pure CSS Material Components themeable. So the question was how to create a palette out of a color?

There are at least a few different answers to this, but I had some restrictions. As I was working on a CSS only library, using JavaScript was out of scope. Another thing was adhering to the Material Design Guidelines as much as possible.

Coding

Most of the time Material specifies using semi-transparent versions of colors. This led me to the rgba() functional notation which can be used to create "shades" of a solid color through manipulating the alpha channel. The following snippet specifies the text color to be red, but half-transparent:

  .text {
  color: rgba(255, 0, 0, 0.5);
}

Similar results can be achieved with the opacity property. However it always applies to the whole element (and its children), while a semi-transparent color can be applied on text, border, background, box-shadow, etc. separately.

Next, I extracted a variable for the RGB color from the declaration above. CSS variables can hold any value, and luckily they resolve within the rgba() functional notation so the following snippet works just fine:

  :root {
  --my-color-rgb: 255, 0, 0; 
}

.text {
  color: rgba(var(--my-color-rgb), 0.5);
}

CSS variables also have the fallback feature. So why not use it? It is a great fit for providing default color if the referred variable is undefined. Putting everything together produces something like this:

  .text {
  color: rgba(var(--my-color-rgb, 255, 0, 0), 0.5);
}

HSLA alternative

The HSL (and HSLA) color space is getting more popular lately, probably because it aligns more with the human color perception. The hsla() functional notation adds more opportunites to theming: you can take a hue then saturate/desaturate it, lighten/darken it, or make it more transparent. The above described method could look something like this in HSLA:

  :root {
  --my-color-hue: 0;
}

.text {
  color: hsla(var(--my-color-hue, 0), 100%, 50%, 0.5);
}

Although the HSLA alternative would work flawlessly, I didn't use it in my case. RGBA is completing the task perfectly, and maybe developers are more familiar with RGB than HSL.

Demo time!

I wired this whole concept into my component library. So when there's need for customization one would only have to define one or two variables at top level to create a whole new flavor or even a night mode of their app. Try the sliders under "Colors":

Further demos using the component library:

• Material Registration Form (Amber flavor)
• Duplicate Word Finder (Default colored, I used it for proofreading this post :)
• HTML and JSON Aware Pig Latin Translator (Default colored)

Browser Support

If you liked the demos and would like to implement a similar concept, I have some good news. This works in Chrome, Safari, Firefox, Samsung Internet and Edge. However, I should warn you about some difficulties. It turned out that Safari is not handling the CSS variable with fallback in rgba() in some cases. These cases are the shorthand or shorthandish properties like border and box-shadow. The workaround for this is to create some intermediate variable like:

  :root {
  --my-color-rgb: 255, 0, 0; 
}

.text {
  --intermediate: rgba(var(--my-color-rgb, 255, 0, 0), 0.5);
  border: solid 1px var(--intermediate);
}

CSS variables are also locally scoped, so defining --intermediate in .text won't pollute the global scope.

Yeah, but you forgot that IE11 does not support CSS variables!

You might say. Well you can do multiple things about it. First, I suggest reading The End of Life of Internet Explorer 11 . Second, if you are still not convinced then you can inline your variables with PostCSS.

Final thoughts

When I created Pure CSS Material Components I wanted a lean, easy to use, but accurate component library. Making it themeable was a step that could lead to more complexity. I was also aware that Sass, Less or Stylus were already capable of solving this problem, but I think that's an obstacle for developers who don't use these preprocessors. CSS variables helped me keep things simple and stick to a native solution.

Thanks for reading, I hope this post inspires you to try out CSS variables!

The Problem With Checkbox Toggle Switches

Most checkbox toggle switches created with CSS are confusing UI because they do not function like their real-world counterparts. When I encounter a toggle switch in my iPad settings I slide it over with my finger. Voilà, it works properly just like the real-world toggle on the side of the iPad. Often when I encounter the same toggle switch on the web I slide it over with my mouse and it doesn't work. It doesn't work because it's meant to be pushed like a button; but it doesn't appear as a button.

Looks Like a Range Slider

To make matters worse HTML has actual sliders which look just like these toggles. If you want to make a sliding form element you could use the input[type="range"] element. It does not make sense to style a checkbox to look like a sliding range input, but that's what is being done all over the Internet. YouTube uses a sliding toggle for autoplay, and it works as a sliding toggle - it doesn't use a checkbox.

The Rocker Switch Solution

The rocker switch is a real-life toggle that functions as a button. By styling a checkbox to look like a rocker toggle switch you retain its real-world functionality. This is not the only solution or even the best solution, but it does a better job of conveying a click (or tap) by looking like a button rather than looking like a slider. It's also fun to click (or tap).

I created the above pen to demonstrate the checkbox rocker switch. I look forward to seeing more creative solutions to use in place of checkbox toggle switches.

The CodePen Chicago Halloween event was held at Backstop Solutions for the third year in a row! They provided food, drinks and space; it was much appreciated. We had a lot of attendees presenting their spooky pens from CSS characters to JavaScript web games, we had it all!

Since this is the last one of the year, stay tuned for the next announcement and we plan to do in the future!

Presenters:

Ola Giwa

Ola showed characters made only with CSS and explained the process of blocking out the shapes before filling in the colors. Check out the Mario Ghost and Koala.

See the Pen Mario Ghost by OG (@OG) on CodePen.

See the Pen CSS Image by OG (@OG) on CodePen.

Frederick Wells

Fred created an SVG mask of Zora and talked about how it was built in Illustrator then updated as a mask for the image of Zora.

See the Pen Zora by Frederick Wells (@pandabrand) on CodePen.

Marvin Cespedes

Marvin explored the Web Animation API and made a walking Dry Bones that moves from side to side :D

See the Pen Dry Bones by Marvin Cespedes (@mcespo) on CodePen.

Sean Codes

Sean's pen was the scariest thing shown, an OS update! Just install... or you'll be haunted forever!

See the Pen updates available by sean_codes (@sean_codes) on CodePen.

Colt Borg

Which witch hat to pick? Colt's Vue pen is an example of a Single Page App(SPA) that swaps out the hat on the witch when you make your selection!

See the Pen Witch Hat App by Colt Borg (@coltborg) on CodePen.

Brian Montana

I showed a pen that used fractals that randomized the length of the branches and at the end draw leaves with a curated array of fall colors.

See the Pen Fall trees by Brian Montana (@brianmontanaweb) on CodePen.

Jeremy Kahn

This web game by Jeremy was a learning process to explore flex box, you can buy items, plant them and check out your inventory!

Farmhand

Austin Andrews

Andrew showed Material Design Icons documentation for React and how to use the components, lots of interesting compounding, check it out!

MDI Demo

Photo Gallery:

CodePen Chicago at Backstop Solutions

Thank you!

Thanks to Colt, Andy and Backstop Solutions for the space, food and being wonderful hosts! Thank you to Marvin for the photos and to Austin for the MDI posts again!

If your logo isn't SVG, you should convert ASAP. There are plenty of articles outlining how much more useful SVG logos are from their PNG counterparts. Browser support is awesome for inline and externally linked SVGs.

• Icons

I made the switch from font icons to SVG and I couldn't be happier. There is still debate whether you should inline or sprite the icons, I think it depends on the project. It is so much more semantic to use SVG icons, since you are literally placing an icon rather than using a font glyph. I get mad when I see PNG icons! I can barely recognize them from these pixels!

PNG icons look blurry when scaled

• Image Maps

I remember how hellish those were to code correctly pre responsive design era and they still are. But with SVG, it is way more semantic since you have a text node with a clickable link and that's it!. And you can highlight the link with a pinch of CSS and have cool animation if you like! Not to mention the benefits of accessibility.

<a xlink:href="http://example.com"> <text>Click me!</text> </a>

In one website re-design project, we had a PNG image map of apartment buildings with the numbered flats so when users would hover the unit number will be highlighted and they will be redirected to the apartment details. The problem was, this image was created 10 years ago and it looked awful on mobile - even on desktop it was pixelated. But the project manager needed it on the page with the same functionality.

I came up with the idea of two SVG images - one for desktop/tablet and another for phone. Making them clickable was a piece of cake - just add a:xlink elements! No position:absolute hacks! As for accessibility, in this case, the link text wasn't very descriptive - just the apartment number. But that's where aria-label comes to the rescue!

• Floor Plans

Floor plans sketches are excellent in SVG. They mostly consist of boxes, numbers and are black & white - nothing fancy, and they will look super crisp in SVG and will load incredible fast on mobile (which is where you mostly spend your time looking for a new apartment anyways)

]

Floor plans can be converted into SVG thus decreasing their size

Don't just stop at floor plans! Any time a simple sketch it presented on a site, it is an excellent candidate for SVG!

• Complex Animations

When a simple CSS transition property on a div won't cut it (or it will take a lot of time to code) use SVG to create fancy animations. Then it is simply a matter of moving nodes/paths either with CSS and/or JS. Easy and semantic.

SVG animation by Envy Labs

• No-Image Image You have seen these images when you browse e-stores, "No image available" images that sometimes look blurry. I used SVG last time I needed such a placeholder and it looked awesome! Not to mention how lightweight it was.

That's means it's been 100 weeks since we started sending a weekly newsletter packed with front-end inspiration to hundreds of thousands of devs around the world. Whew!

Though nothing at CodePen is a true solo project, I think it's fair to say The Spark is my domain — I select the content for it and write it each week. It's my favorite thing I do at work.

So, I'm taking this milestone as an opportunity to share a little behind-the-scenes look at how The Spark is made, and reminisce a bit.

The Spark Alumni

I can't celebrate a milestone like this without a shoutout to two CodePen alumni: Tim Holman, who came up with the idea and built the original system we used to create and send the newsletter. And Jake Albaugh, who built the CMS and email system we use to create and send The Spark today.

You can hear Tim talking about the very earliest days of The Spark in 📻CodePen Radio #113: The CodePen Spark, which aired the week after the first issue went out.

Later, Jake was on the show to talk about designing and building the ETL system we use for The Spark in 📻CodePen Radio #157: ETL.

Gathering Sparks

The goal is to spark people's minds with inspiration or new information that makes them want to create, or learn something new. I keep that in mind as I select the content for each issue.

Every issue of The Spark is a mixture of what was popular on CodePen through the week, and things that I feel should get more attention.

To keep things fresh, I try to keep it scoped to things that were created in the week since the previous Spark went out.

The Spark is also a chance to show off the work of the CodePen community at large — I love finding Twitch streams, posts on personal websites, and Medium and Dev.to posts to share.

Sometimes I'll include things that we didn't pick for the homepage, but wanted to. Some front-end experiments need a little extra context. For example, a Pen where all the interesting stuff is happening in the console. Other things need a bit of "fair warning", like when they ask for webcam access, or automatically play sounds or music. We're not able to add that kind of "heads up" to the homepage grid, but we can include it in The Spark.

Captions

Captions are my chance to zoom in to the details and share tidbits that might not always come through on the home page. I can use a caption to highlight interesting technologies or techniques, or give the backstory on where a design idea came from.

I like to use the creator's own words (from the "Description" of the Pen/Project/Collection) when they're available. Sometimes a good description is what makes me choose something for The Spark, so don't forget to fill in that field 😉

And of course, I write a lot of captions from scratch. Here's my favorite I wrote this year, for Cassie Evans' "Shy blob - Face detection" in Spark #82.

Titles

I love writing the titles for each issue.

Usually, I go with 3-part alliteration, like "Melody, Maps, and Mood". But if I can't find a starting-letter match across 3 different entries in the issue, I go with something thematic that ties the week together, like "Time, Perspective, and Expansion".

And, like every headline writer, I've learned some lessons about truncation the hard way....

Tools

I have a couple tools that are indespensible for putting together The Spark.

Slack

Through the week, I save things I'm considering for The Spark in our #newsletter channel in our internal Slack. Since CodePen is fully remote we all live in Slack, so it felt like the natural place to gather up our favorites from the week. I use the "pin to channel" feature to create a list of links right inside the channel.

Images

For still screenshots, I use the built-in macOS screenshot feature and crop it down to size in Preview. Nothing fancy!

Gifs are where it gets tricky. Getting both a good loop and a small filesize presents a challenge. Luckily I have a great tool for that.

I use Giphy Capture. The controls for creating a loop are very intuitive, and it has great export options. I export the gif at a low frame rate to keep its size small. Then, I run it through ImageOptim to compress it further.

ETL

When I'm ready to add an item to The Spark, I post it through the CMS Jake created.

The great thing about this setup is that once the issue is complete, it generates JSON that includes all of the content I manually added to the issue, plus every upcoming event from the Meetups page and all of the current listings from our Jobs board. I used to have to copy those all in manually, which was really slow and typo-prone.

To Hundreds More!

Though 100 is a fun round number, it still feels like we're just getting started with what The Spark can be. I'm looking forward to making new discoveries and sharing new sparks of inspiration ✨

I'd really love to share more long-form writing about front-end development with embedded Pens, and more collections. If you're making those things, let us know! You can share them with us on Twitter @CodePen, or in our Spectrum community at spectrum.chat/codepen.

• Animate.css - https://daneden.github.io/animate.css/
• Animejs - http://animejs.com/
• Magic animations - https://www.minimamente.com/example/magic_animations/
• Hover - http://ianlunn.github.io/Hover/
• Anijs - http://anijs.github.io/

What amazed me most is that some of these libraries, especially those CSS, were introduced several years ago. Although CSS now allows us to find better results and write simpler and more efficient code, these libraries seem timeless (do you remember jQuery?) and only few people really give importance to the complexities that these bring with them once included into our project; especially if we have to take into account weight and performance. For example, a question that we should all ask ourselves, is:

Does it make sense to include the entire library if I need only 3 animations?

The answer is obviously no, and to overcome this, some people "copy" (👮🏻) the individual keyframes and use them independently from the library itself. If you use PostCSS (and you should) there is a plugin that allows you to conditionally import the keyframes you want, when you need them.

The problem

Almost all of these CSS libraries provide a set of classes to which a specific animation is assigned. So, to apply a fade from bottom animation we will add the relative class to the HTML element, then customising it through CSS:

  <progress class="fadeFromBottom"></progress>

<style>
  .fadeFromBottom {
    animation-duration: 2s; /* This may require !important 👀 */
    animation-delay: 0.5s;
  }
</style>

As is easily to understand, this means that for each imported animation (for example, the direction is managed with a different class) there is a corresponding CSS class and to customise it we must overwrite the code, sometime using the !important (❗️) keyword, resulting in a not-so-much scalable code.

How can we therefore evolve this approach using today's tools?

 Continue reading on:

https://equinsuocha.io/blog/smart-animations-with-custom-properties

1. Don't camp on platform names as you extend

This means as you're trying to add new features to a language, avoid using any syntax that could possibly ever be added to the language you're working with in the future.

Example: Some CSS preprocessors have had issues with min() and max() support in CSS because they invented their own min() and max() functions to do something slightly different. Oops!

2. Don't try to predict the future

This means build what you need today and support what you need to support, but don't try to predict what will be standardized in the future, and doubly extra-don't tell people they're 'writing future syntax today'. The future is hard to predict and sometimes one person's misunderstanding can propagate through to an entire industry.

Example: CSSNext claimed to let you use tomorrow's CSS syntax today, and much of the CSSNext functionality was based on a misunderstanding of a dead specification for @apply. There was a dream spec for something called @apply that was only ever intended for ShadowDOM, and the author realized it was flawed and killed it - but not before it was taken and mistakenly applied to light DOM, and thousands of developers got into the habit of using this dead, never-proposed shadowDOM-only feature in a way that was never intended. Now the entire CSSNext project and all code written with it has been deprecated, and 'postcss-preset-env' now claims to let you use tomorrow's CSS today, this time without @apply. Oops!

3. Prefer HTML/CSS/JS over custom syntaxes

The specifications for what valid HTML is, or what valid CSS is, or what valid JS is are published. You can look them up and build a parser that successfully parses these languages. However many tool makers don't do this. Famously, SCSS struggles with just about every new CSS feature that gets added, and based on the limitations of its design and the features we know are coming down the CSS pipeline, we can expect many more breaking changes to come.

Example: SCSS isn't a superset of CSS but is a CSS-like language that can be parsed into CSS. But it also chokes on perfect valid CSS syntax as well, h1 { font-size: max(10px, 1vw); } is a simple example, and if you say "Hey that's valid, but it's a new feature!" fine, this also breaks it and it's been around for years: @supports (--general-enclosed()) { html { background: lime; } } Oops!

4. Abstract HOW you do, not WHAT you do (aka abstract your process, not your product)

When extending a language, don't abstract the pieces you're working with to the point that it's not obvious what's going on, automate your labour but keep your workflow close to the thing you're actually working on. Let your abstraction carry you effortlessly to the place where you need to do your work for maximum effectiveness, rather than trying to abstract the work away from you.

Example: Some CSS-in-JS systems abstract styling so far they're almost impossible to debug, because what you as the author are typing to conjure up styles on an element and the styles that are being put onto the element have little relation to each other. You're not using the tool to help you make your work easier, you're at the mercy of whatever the tool lets you do. Oops!

If you’re coding 3D visualizations with Three.js, sooner or later you’ll want to move beyond using the library’s basic native shapes to using complex custom 3D objects wrapped in UV mapped material.

Blender is a fantastic free open-source software for creating beautiful 3D objects. Since Three.js dropped support of its Blender exporter plugin in favor of relying on its glTF loader, exporting via the popular and versatile glTF file format is now the way to go for bringing Blender objects into your Three.js projects.

This tutorial will walk through each step from creating a Three.js-compatible UV-wrapped 3D object in Blender to loading the object into a Three.js scene. Here’s what we’ll cover:

Part 1: Creating a Three.js-Compatible UV Mapped 3D Object in Blender

Part 2: Importing the UV Image into Blender as glTF Material

Part 3: Exporting the glTF file from Blender

Part 4: Loading the glTF file into a Three.js Scene

Part 1: Creating a Three.js-Compatible UV Mapped 3D Object in Blender

This tutorial will use Bus Derby, a 3D browser-based video game built with Three.js, to provide examples for each step. The game and all of the source code can be found right here on CodePen, or here on GitHub, for reference. (If you're into design, the UI case study is also available on Behance here.)

We’ll be using this bus image as a model to base our 3D Blender object on.

To begin, you’ll first need to have a 3D object shaped in Blender. This tutorial won’t cover the details of using the software to create shapes. If you’re new to Blender, there are tons of existing tutorials to bring you up to speed. I’d recommend this YouTube Blender Beginner Tutorial. When I began the Bus Derby project, I’d barely heard of Blender, and the series gave me the know-how to create this bus body shape below, which we’ll be using as an example.

Unwrapping UVs in Blender to Create a UV map

If you’re already familiar with unwrapping UVs, go ahead and skip down to Part 2. If not, the first step you'll need to take toward UV unwrapping in Blender is to open a new area as a "UV/Image Editor".

Hit TAB to toggle into Edit mode, then “A” to select all. Hit “U” (for unwrap), then select Smart UV Project. Hit “Okay” to accept the default settings. This will automatically unwrap the UVs and place them on the UV map.

(Alternatively, for more control over how Blender unwraps the UV, you can designate seams. Select the edges where you’d like the seams to be, hit CONTROL-E, then select "Mark Seams". Seams will appear as red edges. When all of the seams are marked, hit “U”, then select Unwrap.)

Exporting the UV Map as a PNG file

Position the segments on the UV Map in a way that will be easy to work with when creating the images. Group them by their expected color and arrange them relationally so it’s clear how each segment corresponds to the 3D shape. (Select the “island” mode to easily select and move isolated segments.)

Hit “A” to make sure the the entire map is selected. Open the “UVs” menu at the bottom of the UV/Image Editor area, and select Export UV Layout. Enter the name and location for the file, then click the “Export UV Layout” button. This will export a .png image of the UV map outlines over a transparent background.

Creating the UV Image with Image Editing Software

Open the exported .png file in any image editing software like Sketch, Illustrator, or Photoshop. Add a new image layer beneath the UV map, and fill in the outlines with any combination of color, illustration, or photos. When you’re done with the image, hide or delete the UV map layer, and export as a new image file to the same directory as the .blend file.

Part 2: Importing the UV Image into Blender as glTF Material

To import the UV image .png into Blender in a way that will be compatible with exporting to Three.js, we’ll need to bring the KhronosGroup glTF Blender Exporter plugin. To do so, clone or download the exporter from GitHub into the same directory as the .blend file, and unzip it.

Back in Blender, append the glTF Blender Exporter file’s glTF Metallic Roughness material. To do this, go to File > Append, then navigate to glTF-Blender-Exporter-master/pbrnode/glTF2.blend/NodeTree, and select the glTF Metalic Roughness material. (We’ll use this material in the tutorial, but if you want you can repeat this step to append the glTF Specular Glossiness material as well, which is also compatible with Three.js)

Select Cycles Render from the menu on the top bar.

Now, open another new area as a Node Editor.

In the Properties panel on the right side of the Blender interface, select the Material display, and give the material a recognizable name. We’ll call it “bus_material” here.

In the node editor, Add a new Metallic Roughness glTF material node. To do this, go to Add > Group > glTF Metallic Roughess, and place the new glTF Metallic Roughness node.

Delete the “Diffuse BSDF node”. Just select it, then hit “X”.

Add a new image texture node. Go to Add > Texture > Image Texture, and place the new node. Then, on the new image texture node, go to Open > select UV image, and select your UV Image file.

Connect the Image Texture node’s Color and Alpha connectors to the glTF Metallic Roughness node’s BaseColor and Alpha connectors, respectively. Connect the glTF Metallic Roughness node’s Shader connector to the Material Output node’s Surface connector.

In the 3D view editor, you should now see the UV image projected onto the 3D shape. Looking pretty damn good.

Adjust the MetallicFactor and RoughnessFactor on the glTF Metallic Roughness node to taste.

Part 3: Exporting the glTF file from Blender

For this next step, to send the object to your Three.js project, we’ll first need to point Blender to the KhronosGroup glTF Blender Exporter script. To do this, go to File > User Preferences to open the User Preferences window. Under the File tab, click the “Scripts” folder icon. Navigate to glTF-Blender-Exporter-master/scripts, and click the “Accept” button. Click the “Save User Settings” button. Close the User Preferences window.

Save, close Blender, and re-open Blender for the plugin to persist.

Add the glTF 2.0 format to Blender. Go back to File > User Preferences. This time, open the “Add-ons” tab. Use the search bar to search for “glTF”, then check “Import-Export: glTF 2.0 format”. Click the “Save User Settings” button. Close the window.

Now we’re ready to export the glTF as a Three.js-compatible .glb file. Go to File > Export > glTF 2.0 (.glb). Check “Export all layers”, “Export materials”, “Export texture coordinates”, “Export normals”, and any other properties you’ll need to include for your project. Give the file an appropriate name. I’m calling mine “bus_body_green.glb”. Navigate to wherever you want to save the file, and click the “Export glTF 2.0 binary” button.

Part 4: Loading the glTF file into a Three.js Scene

And now at last we’re ready to load the 3D object into your Three.js project. (Have a look at the Bus Derby example here on CodePen or here on Github for fuller context of the code.)

In your Three.js app’s index HTML file, add the Three.js glTF loader library source.

  <script src=”https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>

Create a new glTF loader object. Load the .glb file and apply the 3D object (which lives at gltf.scene.children[0]) to an object that will be added to the scene. Position and scale as needed.

  var loader = new THREE.GLTFLoader();
loader.load(
   "https://s3-us-west-2.amazonaws.com/s.cdpn.io/409445/bus_body_green.glb",
   function ( gltf ) {
      var scale = 5.6;
      bus.body = gltf.scene.children[0];
      bus.body.name = “body”;
      bus.body.rotation.set ( 0, -1.5708, 0 );
      bus.body.scale.set (.5,.5,.5);
      bus.body.position.set ( 0, 3.6, 0 );
      bus.body.castShadow = true;
      bus.frame.add(bus.body);
   },
);

scene.add( bus.frame )

That’s it! You’ve brought your 3D Blender object into your Three.js project. You’re good to go. :)

And, finally, here's the completed Bus Derby pen live.

Matthew Main is a UI & Digital Designer in New York. Follow on Twitter or GitHub. Read this tutorial on Medium here.