5 ms·

I think you've missed the point a bit. I'm trying to make a distinction between what is driving Gutenberg and what it's trying to solve and why. Improving the e

I think you've missed the point a bit. I'm trying to make a distinction between what is driving Gutenberg and what it's trying to solve and why. Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. It's primarily vehicle for accomplishing other goals, i.e. improving .com's competitive offering and managing the transition to a JS centric code base. Those things are more important. Understanding the priorities in play explains in part why Gutenberg is causing friction better than saying it exists because it is trying to solve technical problems for users. That would lead you to think that the technical problems were thought about really hard and that is some primary goal. It's not. It's just WordPress trying to modernise an interface. > You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. The reason I bring up the editor and WYSIWYG is that it shows the disconnect between some lauded goal of providing a more seamless experience and the thought that went into the technical solution. My feeling is that we ended up where we are not because we were trying to solve a problem in the best way, but because we were just trying to cram in a new JS way of doing things. It explains better how we arrive at the following mess. Let me show you it through the lens of styling a post: https://imgur.com/a/AThzNns https://imgur.com/a/AThzNns > The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls. Look at the gallery I posted and tell me honestly, are you really saying this is the only way to provide 'intuitive editing'? Of course that is not true, it's simply how Gutenberg decided to implement it. Of course, you can compose your CSS workflow to fit around how Gutenberg's editor functions and you'll get fairly good results if you do. But this is a workaround, it's made the UI a first class citizen at the expense of the rest. So theme developers have to think in terms of the UI, not just what the markup looks like on the front-end. And content creators are forced to think in terms of blocks. It's an UI that is altering how people interact with it, for its own sake.

lmm 8y ago
> Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?
- pknight 8y ago
  Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition, they run the self-hosted version and they are already well served by 3rd party solutions for their more complex needs. So now the community project is trying to prioritise the goals of the for-profit company at the expense of carefully developing solutions to meet its own users in a proportionate way. That's how we've ended up thinking of accessibility/custom fields/theme development/backward compatibility as things that are secondary priorities, if that.
  - lmm 8y ago
    > Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition So free users don't want the features that paying users want? Whyever not? Surely the fact that some people are willing to pay for a particular feature indicates just how important that feature is to a lot of users.
    - pknight 8y ago
      If that were true, why are so many existing users apprehensive about Gutenberg? Self-hosted users of WordPress have different priorities even if most would like a nicer editor, it matters how it comes about and it matters what other sacrifices are made in pursuit of the project.
      - lmm 8y ago
        Many users have legitimate concerns about Gutenberg (compatibility with existing plugins, suitability for ongoing plugin development, migration of existing instances). That's a very different statement from saying that it doesn't solve a real problem that many users have.
  - photomatt 8y ago
    The vast majority of revenue in the WordPress ecosystem is made by hosts other than WP.com. Everyone in the WP ecosystem benefits from increased usage, as it drives more plugins, more themes, more demand for agencies and developers, more books and tutorials about WordPress, et al. It’s all part of the virtuous cycle that has led to WP’s success so far. I’d be far more worried about the WP ecosystem if it started getting smaller and the various constituents were fighting over a shrinking pie.
modernerd 8y ago
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/

lmm 8y ago

> Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?

pknight 8y ago
Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition, they run the self-hosted version and they are already well served by 3rd party solutions for their more complex needs. So now the community project is trying to prioritise the goals of the for-profit company at the expense of carefully developing solutions to meet its own users in a proportionate way. That's how we've ended up thinking of accessibility/custom fields/theme development/backward compatibility as things that are secondary priorities, if that.
- lmm 8y ago
  > Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition So free users don't want the features that paying users want? Whyever not? Surely the fact that some people are willing to pay for a particular feature indicates just how important that feature is to a lot of users.
  - pknight 8y ago
    If that were true, why are so many existing users apprehensive about Gutenberg? Self-hosted users of WordPress have different priorities even if most would like a nicer editor, it matters how it comes about and it matters what other sacrifices are made in pursuit of the project.
    - lmm 8y ago
      Many users have legitimate concerns about Gutenberg (compatibility with existing plugins, suitability for ongoing plugin development, migration of existing instances). That's a very different statement from saying that it doesn't solve a real problem that many users have.
- photomatt 8y ago
  The vast majority of revenue in the WordPress ecosystem is made by hosts other than WP.com. Everyone in the WP ecosystem benefits from increased usage, as it drives more plugins, more themes, more demand for agencies and developers, more books and tutorials about WordPress, et al. It’s all part of the virtuous cycle that has led to WP’s success so far. I’d be far more worried about the WP ecosystem if it started getting smaller and the various constituents were fighting over a shrinking pie.

modernerd 8y ago

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/