Only practical example I've seen of this so far is from @BinaryMoon: BinaryMoon/granule@777cd29

If you're incorporating Gutenberg it should be opt-in. Let's not forget that WordPress as a CMS is used for a variety of content, not all of which requires blocks.

@caraya Gutenberg is going to be a core feature in WordPress in a few months. Gutenberg support is necessary to allow the theme authors full control over the theme.

@mor10 either through plugins or via some sort of theme customization people who don't want them will remove Gutenberg support. I believe it's better if the removal happens through theme customization, it saves people from having to install yet another Wordpress plugin

Am I missing something?

In the short term, developers can declare lack of Gutenberg support in plugins to force WordPress to fall back on the classic editor. That's a stop-gap measure until plugins have time to update. Blocking Gutenberg at theme level goes against how WordPress will work. Once Gutenberg evolves beyond the editor, which is the next step, blocking it will no longer be a viable option.

Here are Gutenberg docs for themes. Mainly about add_theme_support() at the moment.

The Theme Team here at Automattic is looking at adding Gutenberg support to _s in the near future.

@crunnells Where's the patch for this? I saw the label has been removed. We could probably remove Second Opinion. It seems unlikely that keeping as much support as possible for Gutenburg out of _s would be a bad idea. :-)

Has this been completed with the release of 5.0 just around the corner?

@tessak22 No it hasn't.

@samikeijonen is there a way I can dig in and help?

@tessak22 I'm not sure about status of _s, and what kind of support it's maintainers want to go with.

One helpful thing would be to dig in what have been done in default themes, and what parts of that could be used in _s.

Just checking in on this. I see on the main page it says Build Failed. Is _s still safe to use moving forward?

I have a new project I am starting and wanted to use _s but unsure if it is Gutenburg ready. Thanks!

It's not Gutenberg ready in that sense but other than that safe to use.

@tessak22 the twenty nineteen theme was built primarily around Gutenberg support and think that might be the best starting theme to dig in. I'm doing the same :)

So far the best solution I've come up with is to convert the compiled block css from gutenberg to scss. Does anyone know if there is a gutenberg update coming for _s anytime soon??

I dug around in twentynineteen (https://github.com/WordPress/twentynineteen/blob/master/sass/blocks/_blocks.scss) but it's philosophy doesn't fit with _s IMO. Too many specific/opinionated variables and breakpoints. _s doesn't even support breakpoints at this moment, and I'm not sure it should in the future.

The problem is, with the nature of gutenberg there are a lot of new variables and things to take into account such as breakpoints and columns....and I have a block.scss I am happy to share, but as I said, it's either _s accepts responsive styles, or I strip out the responsive styles altogether.

+1

The Theme Team here at Automattic is looking at adding Gutenberg support to _s in the near future.

@crunnells, this comment was more than 12 months ago. Do we have an update? It would be great to have sample Gutenberg blocks out-of-the-box for _s.

I can probably help with this if anyone knows what's needed?

Seems like Gutenberg has its own classes for things like columns, so should just be a case of copying them from twentynineteen or converting them to sass?

Edit: Should have read @jaclyntan's post first. Would like to see your block.scss if possible.

Any update for Gutenberg yet?

The blocks.scss I am using at the moment is just a compiled version of this file:
https://github.com/WordPress/twentynineteen/blob/master/sass/blocks/_blocks.scss. I've been using it in projects very minimally since I have yet to use GB substantially. I don't think it is a good reference or addition to _s as there are media queries and random units mixed in throughout.

If anyone wants to tackle formatting twentynineteen's scss for _s please have a go. I think we all really need a gutenberg update at this point and something that is formatted with respect to _s' philosophy is definitely needed imo, especially if WP want more devs to support gutenberg........

Can anyone give an update on current state of underscores?

Pretty much abandoned. #1369

I don't read that as being abandoned.
#1369 (comment)

@robwent A simple look at open issues, pull requests, and general activity around the project will clear up any confusion.

"Abandoned" could easily be called "not a priority anymore", for now.

If/when it is I'm sure everyone will see more activity around the repo. Until then, yeah, I'd focus on default themes or some of .com's more recent themes for new ideas or ways of coding themes.

Would it be helpful to add in some empty placeholder rules to address the different block selectors available? Something like:

.wp-block-group {
}

.wp-block-image {
}

.wp-block-button {
}

// ... etc.

Similar to some other parts of _S where there are placeholders in the sass, e.g. https://github.com/Automattic/_s/blob/master/sass/navigation/_menus.scss

That way there are no unnecessary "opinions" inserted about what the theme dev should do with these blocks, but they're there for us to add to as we go along.

new ideas or ways of coding themes

This is pretty neat. https://github.com/WordPress/theme-experiments/

Would it be helpful to add in some empty placeholder rules to address the different block selectors available?

I don't have yet a strong opinion about the best way to approach gutenberg integration for _s, but I'm sure that we should tackle #1215 first, as it will help us generate the frontend and the editor stylesheets from the same code base.

Oups ! I clicked the wrong button. 😅

The minimum that could be added, in my opinion, is support for editor-styles, like for example:

add_theme_support( 'editor-styles' );
add_editor_style( '/css/editor-styles.css' );

Personally, I put all gutenberg-related code in a special "gutenberg/gutenberg.php" file, since I usually need some more adjustments like additional alignments for core blocks, blacklist or whitelist blocks etc. and it helps keeping it better organized.