Editor: HTML Editor per block #2797

youknowriad · 2017-09-26T13:48:56Z

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):

mtias · 2017-09-26T14:16:59Z

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

youknowriad · 2017-09-26T14:19:27Z

@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 · 2017-09-26T14:21:04Z

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:

(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 · 2017-09-26T14:23:28Z

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

mtias · 2017-09-26T14:25:09Z

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

mtias · 2017-09-26T14:25:49Z

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

jasmussen · 2017-09-27T07:29:38Z

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 · 2017-09-27T08:15:26Z

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

aduth · 2017-09-27T16:21:32Z

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 · 2017-09-27T16:27:19Z

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 · 2017-09-27T21:19:40Z

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 · 2017-09-28T07:11:53Z

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 · 2017-09-28T08:59:24Z

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 · 2017-09-28T09:39:26Z

I utterly love that idea, Riad.

ellatrix · 2017-09-28T10:11:58Z

@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 · 2017-09-29T09:08:48Z

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

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:

Here's where the global document switch would live:

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:

CC: @mtias @karmatosed @youknowriad

codecov · 2017-09-29T10:15:32Z

Codecov Report

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

@@            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 · 2017-09-29T14:27:00Z

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:

Navigate to Gutenberg > Demo
Switch the first Cover Image block to HTML mode
Focus in the block
Focus out of the block

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

aduth · 2017-09-29T14:29:29Z

editor/block-settings-menu/index.js

+				className="editor-block-settings-menu__control"
+				onClick={ onToggleMode }
+				icon="html"
+				label={ __( 'Switch between the visual/textual mode' ) }


TIL "textual" is a word - still think "HTML" or "text" might be clearer.

TIL "textual" is a word - still think "HTML" or "text" might be clearer.

Still think this ought to be addressed

sorry forgot about this, updating

going for "text" for consistency with the global mode switcher

aduth · 2017-09-29T14:32:18Z

editor/reducer.js

@@ -138,6 +138,20 @@ export const editor = combineUndoableReducers( {
 					},
 				};

+			case 'UPDATE_BLOCK':
+			// Ignore updates if block isn't known


Tab one more.

aduth · 2017-09-29T14:37:31Z

editor/modes/visual-editor/block-html.js

+	componentWillReceiveProps( nextProps ) {
+		if ( ! isEqual( nextProps.block.attributes, this.state.attributes ) ) {
+			this.setState( {
+				html: getBlockContent( nextProps.block ),


Would we need to update attributes state here as well?

aduth · 2017-09-29T14:38:28Z

editor/modes/visual-editor/block-html.js

+		this.onBlur = this.onBlur.bind( this );
+		this.state = {
+			html: props.block.isValid ? getBlockContent( props.block ) : props.block.originalContent,
+			attributes: props.block.attributes,


Why do we need to maintain attributes in state?

The idea is:

don't save the updated HTML (which means parse the attributes) on every key stroke (weird things happen if you do so :) without mentioning the performance reasons) and only persist these changes onBlur

If the attributes change externally, this means something else changed the current block, will have to recompute the HTML again.

Each time the text mode changes the attributes we store them in state to compare with the new prop.

If you have another suggestion to achieve this, I'm all for it.

don't save the updated HTML (which means parse the attributes) on every key stroke (weird things happen if you do so :) without mentioning the performance reasons) and only persist these changes onBlur

This is fine, I understand we don't want to update the block until blur, so storing initial HTML makes sense. Doesn't seem to imply we need attributes to do so, though.

If the attributes change externally, this means something else changed the current block, will have to recompute the HTML again.

Each time the text mode changes the attributes we store them in state to compare with the new prop.

We can compare isEqual( this.props.attributes, nextProps.block.attributes ) in componentWillReceiveProps

you're right 👍

aduth · 2017-09-29T14:40:53Z

editor/reducer.js

+	if ( action.type === 'TOGGLE_BLOCK_MODE' ) {
+		return {
+			...state,
+			[ action.uid ]: state[ action.uid ] && state[ action.uid ] === 'html' ? 'visual' : 'html',


Maybe a destructure could help clear this up a bit:

export function blocksMode( state = {}, action ) { const { type, uid } = action; if ( type === 'TOGGLE_BLOCK_MODE' ) { return { ...state, [ uid ]: state[ uid ] && state[ uid ] === 'html' ? 'visual' : 'html', }; } return state; }

Or inside the condition if we want to avoid assignment for unhandled actions:

export function blocksMode( state = {}, action ) { if ( action.type === 'TOGGLE_BLOCK_MODE' ) { const { uid } = action; return { ...state, [ uid ]: state[ uid ] && state[ uid ] === 'html' ? 'visual' : 'html', }; } return state; }

youknowriad · 2017-10-09T12:49:11Z

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 · 2017-10-09T13:18:45Z

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:

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

youknowriad · 2017-10-09T14:00:56Z

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

jasmussen · 2017-10-09T15:03:25Z

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 · 2017-10-09T20:14:55Z

👍 from me and :)

afercia · 2017-10-09T21:46:45Z

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 · 2017-10-10T08:20:01Z

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

jasmussen · 2017-10-10T08:37:03Z

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.

* master: (45 commits) Parser: Hide the core namespace in serialised data (WordPress#2950) fix: Undefined index warning (WordPress#2982) navigation via keydown PHPCS improvements (WordPress#2914) Update/html block description (WordPress#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 (WordPress#2790) Paste: add table support Bump version to 1.4.0. (WordPress#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 (WordPress#2955) Editor: HTML Editor per block (WordPress#2797) Show most frequently used blocks next to inserter (WordPress#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 ...

youknowriad added Needs Design Needs design efforts. Needs Tests labels Sep 26, 2017

youknowriad self-assigned this Sep 26, 2017

youknowriad requested review from karmatosed, mtias, jasmussen and aduth September 26, 2017 13:48

youknowriad force-pushed the try/html-per-block branch from 291b954 to 38c8d79 Compare September 28, 2017 09:04

youknowriad force-pushed the try/html-per-block branch 2 times, most recently from 3e2458b to 3d65fd6 Compare September 29, 2017 10:15

aduth previously requested changes Sep 29, 2017

View reviewed changes

youknowriad force-pushed the try/html-per-block branch from 437a1fe to 8db20ce Compare September 29, 2017 15:19

youknowriad added 10 commits October 9, 2017 13:37

Block HTML Mode: Validate the block when changing its content

676f4ea

Block HTML Mode: Adding unit tests

96dd6b2

Blocks HTML Mode: Styling change in the reducer

d5456d1

Blocks Per Block: Fix HTML mode for blocks with comment attributes

15711da

Block HTML Mode: Avoid setting attributes in state

6e7b989

Documentation: Inline doc for the getContent function

7fa6f70

Blocks HTML Mode: simplify markup and CSS

b359057

Block HTML Mode: Drop unnecessary omit and fix a label

d4a1e57

Tests: Fix unit tests after a broken merge

5e8de1f

Block settings menu: Fix z-index issues

0a5ae79

youknowriad force-pushed the try/html-per-block branch from c3c8eed to 0a5ae79 Compare October 9, 2017 12:46

afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Oct 9, 2017

youknowriad removed Needs Design Needs design efforts. Needs Tests labels Oct 10, 2017

youknowriad merged commit 6268099 into master Oct 10, 2017

youknowriad deleted the try/html-per-block branch October 10, 2017 08:21

jasmussen mentioned this pull request Oct 12, 2017

Try to reduce the visual weight of the block #2983

Closed

aduth mentioned this pull request Oct 19, 2017

Text Mode on a block basis #2219

Closed

ZebulanStanphill mentioned this pull request Sep 24, 2020

Add border to block "Edit as HTML" style. #25539

Merged

6 tasks

Editor: HTML Editor per block #2797

Editor: HTML Editor per block #2797

Conversation

youknowriad commented Sep 26, 2017 • edited Loading

Description

Checklist:

Screenshots (jpeg or gifs if applicable):

mtias commented Sep 26, 2017

youknowriad commented Sep 26, 2017

mcsf commented Sep 26, 2017

youknowriad commented Sep 26, 2017

mtias commented Sep 26, 2017

mtias commented Sep 26, 2017

jasmussen commented Sep 27, 2017

youknowriad commented Sep 27, 2017

aduth commented Sep 27, 2017 • edited Loading

youknowriad commented Sep 27, 2017 • edited Loading

karmatosed commented Sep 27, 2017

jasmussen commented Sep 28, 2017

youknowriad commented Sep 28, 2017

jasmussen commented Sep 28, 2017

ellatrix commented Sep 28, 2017

jasmussen commented Sep 29, 2017 • edited Loading

codecov bot commented Sep 29, 2017 • edited Loading

Codecov Report

aduth commented Sep 29, 2017

aduth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented Oct 9, 2017

jasmussen commented Oct 9, 2017

youknowriad commented Oct 9, 2017

jasmussen commented Oct 9, 2017

karmatosed commented Oct 9, 2017

afercia commented Oct 9, 2017

youknowriad commented Oct 10, 2017

jasmussen commented Oct 10, 2017

youknowriad commented Sep 26, 2017 •

edited

Loading

aduth commented Sep 27, 2017 •

edited

Loading

youknowriad commented Sep 27, 2017 •

edited

Loading

jasmussen commented Sep 29, 2017 •

edited

Loading

codecov bot commented Sep 29, 2017 •

edited

Loading