New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor: HTML Editor per block #2797

Merged
merged 12 commits into from Oct 10, 2017

Conversation

Projects
None yet
8 participants
@youknowriad
Contributor

youknowriad commented Sep 26, 2017

Description

This PR explores the idea in #2794 This is largely unfinished yet but this shows how this could work. The button to switch to HTML mode is located on the menu on the right of block instead of the inspector because it's not possible to keep showing the inspector controls while in HTML mode (this is probably temporary, we need some design input here)

Checklist:

  • Button to toggle the mode per block
  • BlockHTML form
  • Run the block validation when switching back to the visual mode
  • Make this pretty
  • Add unit tests

Screenshots (jpeg or gifs if applicable):

screen shot 2017-09-26 at 14 47 27

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 26, 2017

Contributor

There's a little "HTML Code" icon we use for the HTML block that should be used if we need an icon.

Contributor

mtias commented Sep 26, 2017

There's a little "HTML Code" icon we use for the HTML block that should be used if we need an icon.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 26, 2017

Contributor

@mtias Actually, I'm already using it when you're still on the visual mode, but the icon changes when you trigger the HTML mode. Probably a bad choice but you know, early iterations :)

Contributor

youknowriad commented Sep 26, 2017

@mtias Actually, I'm already using it when you're still on the visual mode, but the icon changes when you trigger the HTML mode. Probably a bad choice but you know, early iterations :)

@mcsf

This comment has been minimized.

Show comment
Hide comment
@mcsf

mcsf Sep 26, 2017

Contributor

It would be cool if, when switching back to Visual, the same kind of prompts would be seen as when returning from global HTML to global Visual mode:

screen shot 2017-09-26 at 15 19 19

(For the record, currently, the changes performed in per-block HTML mode are discarded and the visual block is rendered as it previously was.)

Contributor

mcsf commented Sep 26, 2017

It would be cool if, when switching back to Visual, the same kind of prompts would be seen as when returning from global HTML to global Visual mode:

screen shot 2017-09-26 at 15 19 19

(For the record, currently, the changes performed in per-block HTML mode are discarded and the visual block is rendered as it previously was.)

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 26, 2017

Contributor

@mcsf I was thinking it was already the case, but I think you're right, I need to run the validation manually

Contributor

youknowriad commented Sep 26, 2017

@mcsf I was thinking it was already the case, but I think you're right, I need to run the validation manually

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 26, 2017

Contributor

There's a case to be made that opting into the HTML mode converts it to an HTML block entirely.

Contributor

mtias commented Sep 26, 2017

There's a case to be made that opting into the HTML mode converts it to an HTML block entirely.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 26, 2017

Contributor

Also, somewhat related, the invalid dialog should include an option to edit as an HTML block, not just Classic Text.

Contributor

mtias commented Sep 26, 2017

Also, somewhat related, the invalid dialog should include an option to edit as an HTML block, not just Classic Text.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 27, 2017

Contributor

Love this feature!

Designwise I think we'll want to think about this for a bit. I'm concerned with adding still more buttons to the side. (Oh and tiny nitpick on current implementation, the hover text says "Delete the block").

For a while I've been suggesting that we implement an overflow menu — that is, an ellipsis that sits at the end of every toolbar. On click it shows a dropdown with items that don't fit in the menu. This is especially important for mobile, where the toolbar might not fit. This space would be perfect for an "Edit HTML" button, I think. What do you think, @karmatosed

Contributor

jasmussen commented Sep 27, 2017

Love this feature!

Designwise I think we'll want to think about this for a bit. I'm concerned with adding still more buttons to the side. (Oh and tiny nitpick on current implementation, the hover text says "Delete the block").

For a while I've been suggesting that we implement an overflow menu — that is, an ellipsis that sits at the end of every toolbar. On click it shows a dropdown with items that don't fit in the menu. This is especially important for mobile, where the toolbar might not fit. This space would be perfect for an "Edit HTML" button, I think. What do you think, @karmatosed

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 27, 2017

Contributor

@jasmussen Agreed about the design issues, If we can have a mockup or I'd be to try to implement this (maybe separately)

Contributor

youknowriad commented Sep 27, 2017

@jasmussen Agreed about the design issues, If we can have a mockup or I'd be to try to implement this (maybe separately)

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Sep 27, 2017

Member

Random thought: With these changes, could we potentially consider dropping the Visual / Text toggle altogether? Maybe a bit too controversial 😉

Edit: Aha, late to the party as always, I see some discussion of this impact in #2794 already.

Member

aduth commented Sep 27, 2017

Random thought: With these changes, could we potentially consider dropping the Visual / Text toggle altogether? Maybe a bit too controversial 😉

Edit: Aha, late to the party as always, I see some discussion of this impact in #2794 already.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 27, 2017

Contributor

Random thought: With these changes, could we potentially consider dropping the Visual / Text toggle altogether? Maybe a bit too controversial

I'm also in favour of this :)

Contributor

youknowriad commented Sep 27, 2017

Random thought: With these changes, could we potentially consider dropping the Visual / Text toggle altogether? Maybe a bit too controversial

I'm also in favour of this :)

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Sep 27, 2017

Member

Random thought: With these changes, could we potentially consider dropping the Visual / Text toggle altogether? Maybe a bit too controversial

I would suggest usability testing on that. I am not personally against it though, it always has been confusing.

Member

karmatosed commented Sep 27, 2017

Random thought: With these changes, could we potentially consider dropping the Visual / Text toggle altogether? Maybe a bit too controversial

I would suggest usability testing on that. I am not personally against it though, it always has been confusing.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 28, 2017

Contributor

Let's step back from the cliff for a second and regroup.

There's a use case for people who never want to use the visual editor, they just want the text editor. We should let them — they might never use Gutenblocks at all, and would have no HTML comments. We should even cookie their choice, so if they are in HTML mode and reload the page, they stay there.

For the occasions where you want to fix tag soup, it makes total sense to be able to edit on a per block basis. Having a "edit HTML" button in context of the block itself is also a delightful callback to the Visual/HTML tabs of the current editor.

As such it seems like there are some opportunities here:

a) rethinking where the editor mode switch lives. Perhaps in the ellipsis menu as suggested in another thread

b) if we can add an unread notification dot to the ellipsis menu, perhaps even a pointer bubble when new plugins add themselves there (see also #2460 ), then when a page builder installs itself, it can draw attention to the "mode switch" there

If we think this is cool, the big challenge then becomes: where do we put this html mode switch, without overloading the toolbar? Is this switch discoverable enough if we were to add an ellipsis dropdown at the end of every toolbar?

Contributor

jasmussen commented Sep 28, 2017

Let's step back from the cliff for a second and regroup.

There's a use case for people who never want to use the visual editor, they just want the text editor. We should let them — they might never use Gutenblocks at all, and would have no HTML comments. We should even cookie their choice, so if they are in HTML mode and reload the page, they stay there.

For the occasions where you want to fix tag soup, it makes total sense to be able to edit on a per block basis. Having a "edit HTML" button in context of the block itself is also a delightful callback to the Visual/HTML tabs of the current editor.

As such it seems like there are some opportunities here:

a) rethinking where the editor mode switch lives. Perhaps in the ellipsis menu as suggested in another thread

b) if we can add an unread notification dot to the ellipsis menu, perhaps even a pointer bubble when new plugins add themselves there (see also #2460 ), then when a page builder installs itself, it can draw attention to the "mode switch" there

If we think this is cool, the big challenge then becomes: where do we put this html mode switch, without overloading the toolbar? Is this switch discoverable enough if we were to add an ellipsis dropdown at the end of every toolbar?

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 28, 2017

Contributor

One crazy idea I was thinking of for the Text mode is using Gutenberg (or precisely a block list) also for the text mode. Let me detail this:

  • Let's say we split Gutenberg into reusable components, one of these components is the BlockList component where we provide an array of blocks to display and also a list of available blocks to add.

  • We use a BlockList with only a unique block type: HTML block, which means the Text mode is a list of HTML blocks, the comments stay hidden, the user can't mess with them.

  • The "serializer" for this Text mode is not the regular Gutenberg serializer, but just a simple one which concats the previous comments with the new HTML content.

Contributor

youknowriad commented Sep 28, 2017

One crazy idea I was thinking of for the Text mode is using Gutenberg (or precisely a block list) also for the text mode. Let me detail this:

  • Let's say we split Gutenberg into reusable components, one of these components is the BlockList component where we provide an array of blocks to display and also a list of available blocks to add.

  • We use a BlockList with only a unique block type: HTML block, which means the Text mode is a list of HTML blocks, the comments stay hidden, the user can't mess with them.

  • The "serializer" for this Text mode is not the regular Gutenberg serializer, but just a simple one which concats the previous comments with the new HTML content.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 28, 2017

Contributor

I utterly love that idea, Riad.

Contributor

jasmussen commented Sep 28, 2017

I utterly love that idea, Riad.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Sep 28, 2017

Member

@youknowriad @jasmussen I proposed this a while ago: https://wordpress.slack.com/archives/C02QB2JS7/p1496215809472978

One advantage there too is that we can scroll to the same block the switching mode.

Member

iseulde commented Sep 28, 2017

@youknowriad @jasmussen I proposed this a while ago: https://wordpress.slack.com/archives/C02QB2JS7/p1496215809472978

One advantage there too is that we can scroll to the same block the switching mode.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 29, 2017

Contributor

Here are mockups of what it would look like if the HTML mode was in the quick toolbar ellipsis menu:

edit html

edit html ellipsis toggled

I keep coming back to the quick toolbar having an ellipsis dropdown being an important task we should start work on soon. We can also choose to show as many items in the quick toolbar as there's space for, and then only "pop off" buttons to the ellipsis menu when we run out of space. In this case there would be space for the two new buttons, so it would look like this:

edit html wide quick toolbar

Here's where the global document switch would live:

edit html global switch

Note, the "footnote" and "spell checking" items are simply examples of what other elements could live in those overflow menus.

Edit: another HTML switcher mockup:

choose editor

CC: @mtias @karmatosed @youknowriad

Contributor

jasmussen commented Sep 29, 2017

Here are mockups of what it would look like if the HTML mode was in the quick toolbar ellipsis menu:

edit html

edit html ellipsis toggled

I keep coming back to the quick toolbar having an ellipsis dropdown being an important task we should start work on soon. We can also choose to show as many items in the quick toolbar as there's space for, and then only "pop off" buttons to the ellipsis menu when we run out of space. In this case there would be space for the two new buttons, so it would look like this:

edit html wide quick toolbar

Here's where the global document switch would live:

edit html global switch

Note, the "footnote" and "spell checking" items are simply examples of what other elements could live in those overflow menus.

Edit: another HTML switcher mockup:

choose editor

CC: @mtias @karmatosed @youknowriad

@codecov

This comment has been minimized.

Show comment
Hide comment
@codecov

codecov bot Sep 29, 2017

Codecov Report

Merging #2797 into master will decrease coverage by 0.06%.
The diff coverage is 30.43%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2797      +/-   ##
==========================================
- Coverage   33.92%   33.86%   -0.07%     
==========================================
  Files         193      194       +1     
  Lines        5701     5741      +40     
  Branches     1000     1009       +9     
==========================================
+ Hits         1934     1944      +10     
- Misses       3187     3212      +25     
- Partials      580      585       +5
Impacted Files Coverage Δ
editor/actions.js 36.84% <0%> (-2.05%) ⬇️
editor/modes/visual-editor/block.js 0% <0%> (ø) ⬆️
editor/modes/visual-editor/block-html.js 0% <0%> (ø)
editor/block-settings-menu/content.js 0% <0%> (ø) ⬆️
editor/selectors.js 96.77% <100%> (+0.02%) ⬆️
blocks/api/serializer.js 98.11% <100%> (+0.11%) ⬆️
editor/reducer.js 88.81% <85.71%> (-0.15%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c80ac15...0a5ae79. Read the comment docs.

codecov bot commented Sep 29, 2017

Codecov Report

Merging #2797 into master will decrease coverage by 0.06%.
The diff coverage is 30.43%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2797      +/-   ##
==========================================
- Coverage   33.92%   33.86%   -0.07%     
==========================================
  Files         193      194       +1     
  Lines        5701     5741      +40     
  Branches     1000     1009       +9     
==========================================
+ Hits         1934     1944      +10     
- Misses       3187     3212      +25     
- Partials      580      585       +5
Impacted Files Coverage Δ
editor/actions.js 36.84% <0%> (-2.05%) ⬇️
editor/modes/visual-editor/block.js 0% <0%> (ø) ⬆️
editor/modes/visual-editor/block-html.js 0% <0%> (ø)
editor/block-settings-menu/content.js 0% <0%> (ø) ⬆️
editor/selectors.js 96.77% <100%> (+0.02%) ⬆️
blocks/api/serializer.js 98.11% <100%> (+0.11%) ⬆️
editor/reducer.js 88.81% <85.71%> (-0.15%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c80ac15...0a5ae79. Read the comment docs.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Sep 29, 2017

Member

There's a use case for people who never want to use the visual editor, they just want the text editor. We should let them — they might never use Gutenblocks at all, and would have no HTML comments. We should even cookie their choice, so if they are in HTML mode and reload the page, they stay there.

Couldn't these users just insert a single HTML block into the editor and have-at-it?

Member

aduth commented Sep 29, 2017

There's a use case for people who never want to use the visual editor, they just want the text editor. We should let them — they might never use Gutenblocks at all, and would have no HTML comments. We should even cookie their choice, so if they are in HTML mode and reload the page, they stay there.

Couldn't these users just insert a single HTML block into the editor and have-at-it?

@aduth

Strange behavior I'm seeing:

  1. Navigate to Gutenberg > Demo
  2. Switch the first Cover Image block to HTML mode
  3. Focus in the block
  4. Focus out of the block

The block changes its HTML inexplicably, resetting its content to the default state.

Show outdated Hide outdated editor/block-settings-menu/index.js
Show outdated Hide outdated editor/reducer.js
Show outdated Hide outdated editor/modes/visual-editor/block-html.js
Show outdated Hide outdated editor/modes/visual-editor/block-html.js
Show outdated Hide outdated editor/reducer.js

Good catch Andrew, the comment attributes were lost when using the HTML mode

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Sep 29, 2017

Member

@jasmussen Honestly my first thought with the ellipsis (both at block level and document level) was... not another hidden area. We already have the inspector, which kind of acts as a place were all the advanced stuff goes. Also for the one at the top next to publish, is that not staff that could go in the document inspector? The generic cog and ellipsis next to each other feel quite strange. What doe those even mean? What's the difference? I understand the need for something at the inline block level, where we need a solution for overflow, I'm still wondering though if we can't just put an ellipsis there that would open up the inspector (and get rid of the other one).

Member

iseulde commented Sep 29, 2017

@jasmussen Honestly my first thought with the ellipsis (both at block level and document level) was... not another hidden area. We already have the inspector, which kind of acts as a place were all the advanced stuff goes. Also for the one at the top next to publish, is that not staff that could go in the document inspector? The generic cog and ellipsis next to each other feel quite strange. What doe those even mean? What's the difference? I understand the need for something at the inline block level, where we need a solution for overflow, I'm still wondering though if we can't just put an ellipsis there that would open up the inspector (and get rid of the other one).

@jasmussen jasmussen referenced this pull request Oct 2, 2017

Closed

HTML mode per block #2794

@aduth

Testing this again, I'm still having some trouble:

  • In demo, switching the first Cover Image block to HTML, I proceed to remove the "has-background-dim" class from the HTML. When I switch back to visual mode, it prompts me that the block has been modified externally. I think I understand this to be caused by an incompatibility between block comments and the markup of the block, but from a user's perspective this is not very obvious. I'm not really sure how we'd want to reconcile this (include the comments in the HTML?)
  • After the invalid block prompt is shown, I wanted to switch back to HTML mode and fix the issue, but clicking "HTML" does nothing at this point. Should we allow a user to switch back to HTML mode to fix the block themselves?
Show outdated Hide outdated editor/block-settings-menu/index.js
Show outdated Hide outdated editor/modes/visual-editor/block-html.js
@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 3, 2017

Contributor

@aduth Good questions

After the invalid block prompt is shown, I wanted to switch back to HTML mode and fix the issue, but clicking "HTML" does nothing at this point. Should we allow a user to switch back to HTML mode to fix the block themselves?

Sounds like a good idea to me, this and showing a nudge indicating if the block is valid or not somewhere when in HTML mode. Thoughts @jasmussen?

In demo, switching the first Cover Image block to HTML, I proceed to remove the "has-background-dim" class from the HTML. When I switch back to visual mode, it prompts me that the block has been modified externally. I think I understand this to be caused by an incompatibility between block comments and the markup of the block, but from a user's perspective this is not very obvious. I'm not really sure how we'd want to reconcile this (include the comments in the HTML?)

I think the "isValid" nudge while editing might help a bit here.

Contributor

youknowriad commented Oct 3, 2017

@aduth Good questions

After the invalid block prompt is shown, I wanted to switch back to HTML mode and fix the issue, but clicking "HTML" does nothing at this point. Should we allow a user to switch back to HTML mode to fix the block themselves?

Sounds like a good idea to me, this and showing a nudge indicating if the block is valid or not somewhere when in HTML mode. Thoughts @jasmussen?

In demo, switching the first Cover Image block to HTML, I proceed to remove the "has-background-dim" class from the HTML. When I switch back to visual mode, it prompts me that the block has been modified externally. I think I understand this to be caused by an incompatibility between block comments and the markup of the block, but from a user's perspective this is not very obvious. I'm not really sure how we'd want to reconcile this (include the comments in the HTML?)

I think the "isValid" nudge while editing might help a bit here.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 3, 2017

Contributor

If we nudge when something is invalid, we ought to also give the option to convert to a plain HTML block. (I somehow expect this to be the most common case here.)

Contributor

mtias commented Oct 3, 2017

If we nudge when something is invalid, we ought to also give the option to convert to a plain HTML block. (I somehow expect this to be the most common case here.)

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Oct 3, 2017

Member

I have to admit visually this is a little 'jarring' and feels easy to miss/confuse.

2017-10-03 at 21 56

It's worth adding, I think we need to explore ... as an option soon for the toolbar anyway, I am not sure this is something to hide there, no. But it's likely to appear and very likely on mobile.

I like the idea of a 'tools' icon maybe for checking spelling and showing html. However we do that. One idea could be have a tools icon. I think top bar feels right for this for the entire document though.

This is just a fast exploration but what about:

1

Member

karmatosed commented Oct 3, 2017

I have to admit visually this is a little 'jarring' and feels easy to miss/confuse.

2017-10-03 at 21 56

It's worth adding, I think we need to explore ... as an option soon for the toolbar anyway, I am not sure this is something to hide there, no. But it's likely to appear and very likely on mobile.

I like the idea of a 'tools' icon maybe for checking spelling and showing html. However we do that. One idea could be have a tools icon. I think top bar feels right for this for the entire document though.

This is just a fast exploration but what about:

1

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

I have a very hard time with us putting a single other button on the side of this box. I've already been arguing we should find a way to consolidate this a bit (and I'm aware of how difficult this is), but having three buttons on the side I don't think can work simply for the fact that it wouldn't "fit" at the side of a single line paragraph block.

At this point I think this mockup reads the best:

Only two problems with that one, as far as I can tell, 1 — it's perhaps a slight stretch to call "Edit HTML" a "formatting" option, but it is a block option. And 2 — it doesn't scale well to mobile unless we implement the overflow ellipsis menu so items can pop off the quick toolbar like they do in Google Docs. I know this is controversial, but for all I care it doesn't have to be an ellipsis — it could be a text label, "More", exactly like Docs:

docs

Contributor

jasmussen commented Oct 4, 2017

I have a very hard time with us putting a single other button on the side of this box. I've already been arguing we should find a way to consolidate this a bit (and I'm aware of how difficult this is), but having three buttons on the side I don't think can work simply for the fact that it wouldn't "fit" at the side of a single line paragraph block.

At this point I think this mockup reads the best:

Only two problems with that one, as far as I can tell, 1 — it's perhaps a slight stretch to call "Edit HTML" a "formatting" option, but it is a block option. And 2 — it doesn't scale well to mobile unless we implement the overflow ellipsis menu so items can pop off the quick toolbar like they do in Google Docs. I know this is controversial, but for all I care it doesn't have to be an ellipsis — it could be a text label, "More", exactly like Docs:

docs

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

Here are some more mockups for how to handle overflow in the quick toolbar.

Desktop breakpoint:

desktop toolbar overflow

Mobile breakpoint version 1, toolbar scrolls:

mobile overflow scroll
mobile overflow scrolled

Mobile breakpoint version 2, "More" button appears (like Docs):

mobile overflow more button

mobile overflow more popout

Pros and cons to all of this:

  • The scrollable quick toolbar won't work on the desktop. It also has challenges with regards to quick toolbar dropdowns, like the switcher.
  • The More button I personally like, but it's probably tricky coding.

Whatever we decide on this, I feel like we need a version of the above. Keeping the quick toolbar slim is a noble goal which we absolutely shouldn't drop. But right now we are putting things on the side of the block, or in the inspector (which users can toggle off) — this is an imbalance, I feel.

Contributor

jasmussen commented Oct 4, 2017

Here are some more mockups for how to handle overflow in the quick toolbar.

Desktop breakpoint:

desktop toolbar overflow

Mobile breakpoint version 1, toolbar scrolls:

mobile overflow scroll
mobile overflow scrolled

Mobile breakpoint version 2, "More" button appears (like Docs):

mobile overflow more button

mobile overflow more popout

Pros and cons to all of this:

  • The scrollable quick toolbar won't work on the desktop. It also has challenges with regards to quick toolbar dropdowns, like the switcher.
  • The More button I personally like, but it's probably tricky coding.

Whatever we decide on this, I feel like we need a version of the above. Keeping the quick toolbar slim is a noble goal which we absolutely shouldn't drop. But right now we are putting things on the side of the block, or in the inspector (which users can toggle off) — this is an imbalance, I feel.

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Oct 4, 2017

Member

I second that the size we have at the side just doesn't really work, I was fitting the best I could and my visuals show it's not the best we can do. I would second having a 'more' option both globally and per block. My only caution is mixing '...' and 'more', I feel it would need to have the same language perhaps? That or the '...' becomes a tool type icon.

Member

karmatosed commented Oct 4, 2017

I second that the size we have at the side just doesn't really work, I was fitting the best I could and my visuals show it's not the best we can do. I would second having a 'more' option both globally and per block. My only caution is mixing '...' and 'more', I feel it would need to have the same language perhaps? That or the '...' becomes a tool type icon.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 4, 2017

Contributor

One drawback of using the block toolbar for this, is that the block toolbar buttons disappear when we switch to the HTML mode, so we'll have a unique button on the toolbar to move back to the visual mode.(Flickering effect)

Also, Moving these icons to the toolbar and handling the overflow in mobile seems like a big task on its own. Should I try to solve this here or leave it to its own issue?

Contributor

youknowriad commented Oct 4, 2017

One drawback of using the block toolbar for this, is that the block toolbar buttons disappear when we switch to the HTML mode, so we'll have a unique button on the toolbar to move back to the visual mode.(Flickering effect)

Also, Moving these icons to the toolbar and handling the overflow in mobile seems like a big task on its own. Should I try to solve this here or leave it to its own issue?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

I really love this feature, and how it improves the handling of this all. But I'm a bit worried about us adding a ton of UI with the hopes that we'll fix it later on. It's not the hill I'll die on, if there's a strong desire to move forward, but I think it'd be good to keep thinking a bit about the UI, perhaps a simple solution can present itself. Perhaps there's preceeding art we can look at. I mean, the current editor has tabs for Visual and Text. Though not the greatest UI (and probably can't form the basis for what we're doing here) it's an example. I'll look around for a bit and see if another solution pops up.

Edit: A "Plan B" is to put this in the inspector. But that also seems like a short term fix.

Contributor

jasmussen commented Oct 4, 2017

I really love this feature, and how it improves the handling of this all. But I'm a bit worried about us adding a ton of UI with the hopes that we'll fix it later on. It's not the hill I'll die on, if there's a strong desire to move forward, but I think it'd be good to keep thinking a bit about the UI, perhaps a simple solution can present itself. Perhaps there's preceeding art we can look at. I mean, the current editor has tabs for Visual and Text. Though not the greatest UI (and probably can't form the basis for what we're doing here) it's an example. I'll look around for a bit and see if another solution pops up.

Edit: A "Plan B" is to put this in the inspector. But that also seems like a short term fix.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 4, 2017

Contributor

@jasmussen what do you think of combining the trash icon, the cog settings, and this new html mode under an ellipsis—but keeping the ellipsis in the right floating side instead of the toolbar?

Contributor

mtias commented Oct 4, 2017

@jasmussen what do you think of combining the trash icon, the cog settings, and this new html mode under an ellipsis—but keeping the ellipsis in the right floating side instead of the toolbar?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

what do you think of combining the trash icon, the cog settings, and this new html mode under an ellipsis—but keeping the ellipsis in the right floating side instead of the toolbar?

Love it.

But I never thought that would fly (which is why I didn't suggest it).

Contributor

jasmussen commented Oct 4, 2017

what do you think of combining the trash icon, the cog settings, and this new html mode under an ellipsis—but keeping the ellipsis in the right floating side instead of the toolbar?

Love it.

But I never thought that would fly (which is why I didn't suggest it).

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 9, 2017

Contributor

After #2884 merge, I updated this and it's in the block's menu right now.

Also, What about the "invalid" nudge, any design thoughts or mockups on this @jasmussen?

Contributor

youknowriad commented Oct 9, 2017

After #2884 merge, I updated this and it's in the block's menu right now.

Also, What about the "invalid" nudge, any design thoughts or mockups on this @jasmussen?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 9, 2017

Contributor

Also, What about the "invalid" nudge, any design thoughts or mockups on this @jasmussen?

I think that is probably best explored separately. But it could be something in this vein:

screen shot 2017-10-09 at 15 18 08

CC: @mtias as I know he had a bunch of thoughts on that.

Contributor

jasmussen commented Oct 9, 2017

Also, What about the "invalid" nudge, any design thoughts or mockups on this @jasmussen?

I think that is probably best explored separately. But it could be something in this vein:

screen shot 2017-10-09 at 15 18 08

CC: @mtias as I know he had a bunch of thoughts on that.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 9, 2017

Contributor

Nice design, so do you feel this is ready to go? what's left here?

Contributor

youknowriad commented Oct 9, 2017

Nice design, so do you feel this is ready to go? what's left here?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 9, 2017

Contributor

Nice design, so do you feel this is ready to go? what's left here?

I feel like this is ready to go, yes. A nice enhancement could be to have the "html mode" button have a "toggled" state — just like if it were a "bold" button. That is, dark square background, and white text on it. I was also thinking instead of having Trash and Configure float on the side, we could put them in a popout menu. But this is an enhancement we can do later on, I feel.

Thoughts, @mtias ? I think it's 👍 👍

Contributor

jasmussen commented Oct 9, 2017

Nice design, so do you feel this is ready to go? what's left here?

I feel like this is ready to go, yes. A nice enhancement could be to have the "html mode" button have a "toggled" state — just like if it were a "bold" button. That is, dark square background, and white text on it. I was also thinking instead of having Trash and Configure float on the side, we could put them in a popout menu. But this is an enhancement we can do later on, I feel.

Thoughts, @mtias ? I think it's 👍 👍

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Oct 9, 2017

Member

👍 from me and :shipit: :)

Member

karmatosed commented Oct 9, 2017

👍 from me and :shipit: :)

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 9, 2017

Contributor

From an accessibility perspective, I have no objections if you want to implement an HTML mode that is basically a single contenteditable block.

I'd just like to remind you all that a "text mode" with a simple textarea is a must-have for accessibility, as it's the only guarantee it can be operated by all users with any device or assistive technology.

Contributor

afercia commented Oct 9, 2017

From an accessibility perspective, I have no objections if you want to implement an HTML mode that is basically a single contenteditable block.

I'd just like to remind you all that a "text mode" with a simple textarea is a must-have for accessibility, as it's the only guarantee it can be operated by all users with any device or assistive technology.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 10, 2017

Contributor

Merging this, should we open an issue for the updated design

Contributor

youknowriad commented Oct 10, 2017

Merging this, should we open an issue for the updated design

@youknowriad youknowriad merged commit 6268099 into master Oct 10, 2017

3 checks passed

codecov/project 33.86% (-0.07%) compared to c80ac15
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@youknowriad youknowriad deleted the try/html-per-block branch Oct 10, 2017

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 10, 2017

Contributor

Merging this, should we open an issue for the updated design

I'm working on some enhancements here, will open a ticket as soon as I can.

Contributor

jasmussen commented Oct 10, 2017

Merging this, should we open an issue for the updated design

I'm working on some enhancements here, will open a ticket as soon as I can.

DevinWalker added a commit to DevinWalker/gutenberg that referenced this pull request Oct 12, 2017

Merge branch 'master' into update/html-block-description
* master: (45 commits)
  Parser: Hide the core namespace in serialised data (#2950)
  fix: Undefined index warning (#2982)
  navigation via keydown
  PHPCS improvements (#2914)
  Update/html block description (#2917)
  Framework: Merge EditorSettingsProvider into EditorProvider
  Framework: Move the store initialization to a dedicated component
  Rotate header ellipsis to match block ellipsis
  add/459: Added support for ins, sub and sup
  Refresh nonce with heartbeat (#2790)
  Paste: add table support
  Bump version to 1.4.0. (#2954)
  Blocks: The custom classname should be persisted properly in the block's comment
  Editor: Fix the scroll position when reordering blocks
  Polish spacing in block ellipsis menu (#2955)
  Editor: HTML Editor per block (#2797)
  Show most frequently used blocks next to inserter (#2877)
  add/459: Added light grey background to selected inline boundaries
  Extend inline boundaries to other elements
  Move markdown fix to own plugin-compatibility file
  ...

DevinWalker added a commit to DevinWalker/gutenberg that referenced this pull request Oct 12, 2017

Merge branch 'master' into update/class-editor-block-description
* master: (45 commits)
  Parser: Hide the core namespace in serialised data (#2950)
  fix: Undefined index warning (#2982)
  navigation via keydown
  PHPCS improvements (#2914)
  Update/html block description (#2917)
  Framework: Merge EditorSettingsProvider into EditorProvider
  Framework: Move the store initialization to a dedicated component
  Rotate header ellipsis to match block ellipsis
  add/459: Added support for ins, sub and sup
  Refresh nonce with heartbeat (#2790)
  Paste: add table support
  Bump version to 1.4.0. (#2954)
  Blocks: The custom classname should be persisted properly in the block's comment
  Editor: Fix the scroll position when reordering blocks
  Polish spacing in block ellipsis menu (#2955)
  Editor: HTML Editor per block (#2797)
  Show most frequently used blocks next to inserter (#2877)
  add/459: Added light grey background to selected inline boundaries
  Extend inline boundaries to other elements
  Move markdown fix to own plugin-compatibility file
  ...

DevinWalker added a commit to DevinWalker/gutenberg that referenced this pull request Oct 12, 2017

Merge branch 'master' into update/embed-block-description
* master: (45 commits)
  Parser: Hide the core namespace in serialised data (#2950)
  fix: Undefined index warning (#2982)
  navigation via keydown
  PHPCS improvements (#2914)
  Update/html block description (#2917)
  Framework: Merge EditorSettingsProvider into EditorProvider
  Framework: Move the store initialization to a dedicated component
  Rotate header ellipsis to match block ellipsis
  add/459: Added support for ins, sub and sup
  Refresh nonce with heartbeat (#2790)
  Paste: add table support
  Bump version to 1.4.0. (#2954)
  Blocks: The custom classname should be persisted properly in the block's comment
  Editor: Fix the scroll position when reordering blocks
  Polish spacing in block ellipsis menu (#2955)
  Editor: HTML Editor per block (#2797)
  Show most frequently used blocks next to inserter (#2877)
  add/459: Added light grey background to selected inline boundaries
  Extend inline boundaries to other elements
  Move markdown fix to own plugin-compatibility file
  ...

@aduth aduth referenced this pull request Oct 19, 2017

Closed

Text Mode on a block basis #2219

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment