18 Comments

  1. Rhys Clay

    The columns feature took me by suprise but is a great addition. Im happy with the way Gutenberg is shaping up

    Report

    • Dave

      Indeed nice, those Columns features. And hopefully this could be the ‘standard’ way for pagebuilders. But the column feature is not yet responsive, guess they are aware of it.

      Report

  2. Cristian

    As long as the Pods Framework will work with Gutenberg I will be happy.

    Report

  3. Tomas M.

    “Post formats should go away” – how they will be replaced?

    Post format has formattings for many elements, like heading, text, background, etc.

    If there is no post format, then a user would have to construct all these settings/styles manually each time, or there are other ways?

    Report

    • George

      Do post formats still exist?

      Report

    • Gary Taylor

      Post formats are ‘just’ a custom taxonomy, so the only change would be how they’re declared in your function.php (or wherever) file. That would also mean you could defined your own formats (such as ‘tweet’) that you can’t do with the baked-in version.

      Report

    • Gary Taylor

      Post formats are ‘just’ a custom taxonomy, so the only change would be how they’re declared in your function.php (or wherever) file. That would also mean you could define your own formats (such as ‘tweet’) that you can’t do with the baked-in version. All the alls in archive.php, single.php etc would stay the same. Some sort of conversion process / code would be helpful though.

      Report

    • Joen

      Just to clarify that statement, post formats aren’t going away. If they ever will, it’ll be down the road, done as a separate task by a separate team, probably like the link menu.

      Post formats are key to the genesis of blocks as a concept. Back in the 3.6 days, post formats as a 1st class citizen were being worked on for core, with a much bigger interface, the idea being that sometimes you want an “image post” to show in a different way than just a post with an image, and sometimes you wanted to show a “link post” where the link received a visual treatment akin to an opengraph card. This idea was sound enough, but the UI was pulled out because it was ultimately confusing.

      They key take-away was that maybe you just want to write, and not have to worry about picking a format that’s abstractly represented in the admin. More than that, maybe you want to write a standard post, but want the image to display the same way as if it was an image post. Maybe you want an “opengraph-style” link card inside that post.

      Blocks can address that by basically making blocks for every post format. Want the image to look big and wide? There’s a button for that. Want a big and bold quote in the middle of your post? Use the pullquote.

      The idea being: the chief benefit that post formats brought — showing types of content in a different way — you can keep that, with a better preview, use those displays in standard posts, and not have to worry about picking a format.

      Report

      • Greg Schoppe

        Wow! With that description, the Post Formats we never got seems like it was a way better idea than Gutenberg! We could have designed interfaces to match formats and given users a logical view for editing various designed templates.

        This would be a great way to manage the separation between graphic designers / layout designers and copywriters, rather than giving content editors the keys to go all Comic Sans / Word Art on carefully designed templates

        Report

  4. pierre

    As a general rule I think anything that makes it easy for non developer to “design” a webpage pisses me off. But I guess we will see what happens.

    Report

    • Rhys Clay

      Why? Its an expectation nowadays – and anyways most people stuff it up, then we can fix it for them? At least now they CAN do it themselves. Its that freedom that’s attractive.

      Report

  5. Mic Sumner

    I will find it interesting to see the reception of Gutenberg to the outside world for clients who will only find out about this upon the release of 4.9.

    I’d really like to see how the Gutenberg grows in this respect.

    I’m sure it’s still in the early stages even if it will have to be released first, but the initial idea looks like it will already be useful to some people.

    And from that point onwards we can make it more useful!

    Also like the idea of the column blocks! Simplifying this for clients would make things so much easier!

    Kind regards,

    Mic

    Report

  6. Milen Petrinski

    The text columns block is totally useless. Instead of using CSS columns so that the browser can take care for balancing the text in the columns, the block uses hard containers and flexbox. This way the user has to manually select which part of the text should go in which column. Also, the columns are not responsive (which is pretty trivial to achieve with flexbox without media queries) and you get a squished tiny little columns on small screen.

    I know CSS columns are not universally supported, but faking text columns in any other way is plain wrong. Hmm, actually, they are pretty well supported: http://caniuse.com/#feat=multicolumn

    Report

    • Riad Benguella

      Any improvement PR is welcome!

      Report

    • Steve Morton

      @milen I’m a bit torn on this. I love the concept of CSS columns. The idea of just writing your text freely without worrying about how it will be displayed is attractive. But a developer I’ve rarely found CSS columns to be practical. It never seems to break your content up quite the way you expect it to.

      Lists broken in the middle of an item. Images moved to the next column at certain breakpoints despite being associated with the text in the first column. There are are many more cases. I have almost always found my clients prefer the increased control that discrete containers offer.

      I would agree that the editor should make the columns responsive by default. But as a developer I’d prefer they leave making them responsive on the frontend up to me in the theme.

      Report

      • Milen Petrinski

        @steve, I know what you’re talking about. Browser support for the fine-tuning properties like break-before, break-inside, and break-after is still poor, and that’s the main cause of frustration when using CSS columns.

        And I agree with you that the theme should control how the various boxes appear in the front-end. And for some things it has – the theme can provide the CSS, needed for the multi-column boxes, I experimented with image alignment and I liked the results so much as to extend the options in the current editor for my latest project.

        Report

  7. Richard Ginn

    ODD you did not talk about the shortcode block in the article, but did mention it in the post title.

    This version of Gutenberg is a step in the right direction, but I am still in wait and see mode on this idea.

    Report

  8. Frank Lindner

    I have just started to look into this Gutenberg project so I am not in a position to make specific comment except “It would appear that the Gutenberg team are striving to bring about a major change to the current WP editor; I congratulate them on their achievements to date and look forward to them reaching their goal”.

    There has always been one thing about the WP editor that intrigues me. I use this quote from the article to illustrate – Quick Toolbar: Has inline formatting options, bold, italic, strikethrough and link My question, why has the toolbar not got ‘underline’ included?

    Report

Comments are closed.

%d bloggers like this: