3 ms·

Thanks for taking the time to make those screenshots. To me they reveal a couple of misconceptions: 1. That a WYSIWYG should provide a pixel perfect like-for-

Thanks for taking the time to make those screenshots. To me they reveal a couple of misconceptions: 1. That a WYSIWYG should provide a pixel perfect like-for-like view of the front end on the back end. As you mention, the theme you chose doesn't have full Gutenberg styling, so front and back end differences are more pronounced. But even themes that have good integration will display differences, because the back-end cannot perfectly model the front if users are going to do more than manipulate data inside it (i.e. change styling). I do agree that there are other ways to provide more intuitive editing (like in-place editing), but they are not without downsides too. In-browser editing is a compromise and balancing act. 2. That the structural blocks around visual elements on the back end designed to enable UI elements and controls interfere with styling by theme developers in some way. That was definitely my experience at first (I've just spent three months updating several themes for use with Gutenberg), but it isn't now that Gutenberg has evolved and I better understand how editor styling works. In short: - You enqueue your editor styles after calling add_theme_support( 'editor-styles' ); with add_editor_style( 'style-editor.css' ); - You can then copy the bulk of your styles from the front end to that stylesheet (with a few exceptions, such as the post title, which do need editor-specific wraps at present). - Gutenberg/WP 5.0 prepends those styles with a block-specific selector when you view the Gutenberg editor so that you don't need to worry about the “soup of UI markup”, as you put it. - You can automate much of the CSS re-use using Sass, like the Twenty Nineteen theme is doing. Theme developers need not think about the extra wraps unless they are developing custom blocks, and even then it's largely abstracted away for them by the JS API. I would much rather have editor styling handled automatically by Gutenberg, and I think it will get there, but for the moment this is a small stepping stone on that path.

pknight 8y ago
The UI does interfere, you, as a theme developer, have to adjust to it, as do content creators. This is getting to the point I'm trying to make, that the project wasn't invoked to solve technical problems. It's not answering to technical problems but to the motivations of the project leader. You bring up how Gutenberg solves some of the issues it creates, i.e. how theme developers supply editor styles to match what is seen in the front-end. Until recently Gutenberg didn't even prepend block specific selectors, it was even more broken than now. Why did it even start out that way? How is that even possible to have Gutenberg develop that far without properly thinking about how to style for it? Why is it this solution patched on? (same can be said for meta fields, accessibility and so forth). Because the project didn't start with a clear idea of the technical problems it wasn't going to have to solve, it wasn't a priority. So, for theme developers Gutenberg is more labour intensive (though it can be rewarding). It wouldn't need to be more labour intensive had it started with the full breadth of priorities in mind at the very start. You say 'you don't need to worry about the soup of UI markup, but you do. You have to work around the quirks of the editor or constrain yourself. Say you want to target every 2nd heading, or the paragraph after a blockquote, you can't do that elegantly, because the markup is different in the editor as it is in the front-end and it's not solved by prepending block selectors. Gutenbergs editor styles solution isn't elegant either. It is not a complete disaster, but it's indicative of the fact that the project is imposing its own paradigm over the problems its trying to solve. It's literally creating new problems to solve. > they are not without downsides too. In-browser editing is a compromise and balancing act. I'm not convinced at all that a different approach to how the UI manifests itself in the DOM would have entailed any meaningful trade offs at all. I've been working with this prosemirror implementation recently and the basic example pretty much matches my demo posted earlier: https://tiptap.scrumpy.io/ https://tiptap.scrumpy.io/
- modernerd 8y ago
  +1 I can concede that there are likely better technical implementations than where Gutenberg is at now. (Ghost's Koenig editor with the open block/card model is great, if much simpler and cutting corners by lacking Edge browser support and the ability to add custom cards.) WordPress has always been a project where user happiness outweighs developer happiness, though, as much as I'd love for it to at least bring developer happiness inline. It will be interesting to see what the overall reaction is when 5.0 lands and the editor starts to become more widely used and accepted.
  - pknight 8y ago
    Yes and I'll concede that Gutenberg has a lot of room to grow and will even make plenty of people happy straight away. But I wouldn't call this about user happiness outweighing developer happiness, I'd say it's the other way around. It's based on asserting that we know what the future user wants, not the actual users. Right now user happiness is skewing negative. And Gutenberg's development is precisely characterised by developers/designers prioritising their own happiness. It's a small group of people working mostly at agencies and companies doing enterprise level work who took Matt's idea around blocks and feverishly adopted the tools they personally wanted to use while developing and making decisions at a pace more rapid than other contributors could cope with. That is in part why we lost the accessibility lead.
    - photomatt 8y ago
      Just wanted to clarify one thing, that “we lost the accessibility lead.” There were no accessibility leads until one was designated for the 5.0 release. There were three self-appointed accessibility team reps, one of which decided to step back from the group and blog about it. “Team rep” is largely an administrative role, and as I said before it’s self-appointed. Some teams have 5+ reps, and historically they have not been approved by anyone in WordPress leadership, nor do they connote authority or skill.

pknight 8y ago

The UI does interfere, you, as a theme developer, have to adjust to it, as do content creators. This is getting to the point I'm trying to make, that the project wasn't invoked to solve technical problems. It's not answering to technical problems but to the motivations of the project leader. You bring up how Gutenberg solves some of the issues it creates, i.e. how theme developers supply editor styles to match what is seen in the front-end. Until recently Gutenberg didn't even prepend block specific selectors, it was even more broken than now. Why did it even start out that way? How is that even possible to have Gutenberg develop that far without properly thinking about how to style for it? Why is it this solution patched on? (same can be said for meta fields, accessibility and so forth). Because the project didn't start with a clear idea of the technical problems it wasn't going to have to solve, it wasn't a priority. So, for theme developers Gutenberg is more labour intensive (though it can be rewarding). It wouldn't need to be more labour intensive had it started with the full breadth of priorities in mind at the very start. You say 'you don't need to worry about the soup of UI markup, but you do. You have to work around the quirks of the editor or constrain yourself. Say you want to target every 2nd heading, or the paragraph after a blockquote, you can't do that elegantly, because the markup is different in the editor as it is in the front-end and it's not solved by prepending block selectors. Gutenbergs editor styles solution isn't elegant either. It is not a complete disaster, but it's indicative of the fact that the project is imposing its own paradigm over the problems its trying to solve. It's literally creating new problems to solve. > they are not without downsides too. In-browser editing is a compromise and balancing act. I'm not convinced at all that a different approach to how the UI manifests itself in the DOM would have entailed any meaningful trade offs at all. I've been working with this prosemirror implementation recently and the basic example pretty much matches my demo posted earlier: https://tiptap.scrumpy.io/ https://tiptap.scrumpy.io/

modernerd 8y ago
+1 I can concede that there are likely better technical implementations than where Gutenberg is at now. (Ghost's Koenig editor with the open block/card model is great, if much simpler and cutting corners by lacking Edge browser support and the ability to add custom cards.) WordPress has always been a project where user happiness outweighs developer happiness, though, as much as I'd love for it to at least bring developer happiness inline. It will be interesting to see what the overall reaction is when 5.0 lands and the editor starts to become more widely used and accepted.
- pknight 8y ago
  Yes and I'll concede that Gutenberg has a lot of room to grow and will even make plenty of people happy straight away. But I wouldn't call this about user happiness outweighing developer happiness, I'd say it's the other way around. It's based on asserting that we know what the future user wants, not the actual users. Right now user happiness is skewing negative. And Gutenberg's development is precisely characterised by developers/designers prioritising their own happiness. It's a small group of people working mostly at agencies and companies doing enterprise level work who took Matt's idea around blocks and feverishly adopted the tools they personally wanted to use while developing and making decisions at a pace more rapid than other contributors could cope with. That is in part why we lost the accessibility lead.
  - photomatt 8y ago
    Just wanted to clarify one thing, that “we lost the accessibility lead.” There were no accessibility leads until one was designated for the 5.0 release. There were three self-appointed accessibility team reps, one of which decided to step back from the group and blog about it. “Team rep” is largely an administrative role, and as I said before it’s self-appointed. Some teams have 5+ reps, and historically they have not been approved by anyone in WordPress leadership, nor do they connote authority or skill.