Skip to content
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.

Sign up for GitHub

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

Plugin: Quote Block Initial Attempt #327

Closed
wants to merge 6 commits into from
Closed

Plugin: Quote Block Initial Attempt #327

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
6afa34a
Plugin: Quote Block Initial Attempt
BE-Webdesign Mar 25, 2017
45414b6
Updating quote block to use JSX and Editable component.
BE-Webdesign Mar 28, 2017
ca95a8c
Fix for tests.
BE-Webdesign Mar 28, 2017
d253927
Fix component to work with new Editable component.
BE-Webdesign Mar 28, 2017
89c8dce
Updating Quote Block.
BE-Webdesign Mar 29, 2017
3cb0c08
Updating Quote Block.
BE-Webdesign Mar 29, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions editor/assets/stylesheets/main.scss
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
@import './variables';
@import '../../inserter/style';
@import '../../editor/style';
@import '../../blocks/quote/style';

body.toplevel_page_gutenberg {
background: #fff;
Expand Down
1 change: 1 addition & 0 deletions editor/blocks/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1 +1,2 @@
import './text';
import './quote';
42 changes: 42 additions & 0 deletions editor/blocks/quote/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
const Editable = wp.blocks.Editable;
const { html } = wp.blocks.query;

wp.blocks.registerBlock( 'core/quote', {
title: 'Quote',
icon: 'format-quote',
category: 'common',

attributes: {
value: html( 'blockquote > p' ),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A blockquote could contain multiple paragraphs. In my explorer demo I use text: query( 'p', html() ) instead which assigns text as an array of each paragraph's HTML.

https://aduth.github.io/hpq/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh my bad, it was my recommendation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we join the output directly using hpq?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will probably want to map the values in value to its of <p> component as well right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we join the output directly using hpq?

Not super cleanly, but possible. Since each matcher is just a function receiving a node, you can create your own pass-through:

attributes: {
	value: ( node ) => query( 'p', html() )( node ).join()
}

Or some compose-y equivalent.

I don't know that it's necessary a big issue to need to deal with this in the render behavior though.

citation: html( 'footer' )
},

edit( attributes, onChange ) {
const { value, citation } = attributes;

return (
<blockquote>
<Editable
value={ value }
onChange={ ( newValue ) => onChange( { value: newValue } ) } />
<footer>
<Editable
value={ citation }
onChange={ ( newValue ) => onChange( { citation: newValue } ) } />
</footer>
</blockquote>
);
},

save( attributes ) {
const { value, citation } = attributes;
return (
<blockquote>
{ value }
<footer>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may want to account for the case that citation is empty and avoid including the footer if possible. This was one of the reasons for hpq: to account for cases where the markup isn't always necessarily the same in the generated output (maybe a quote citation, maybe an image caption, but not necessarily).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup sounds good! For some reason this slipped my brain, great catch. Does hpq return an empty value if there is nothing matched by the query?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does hpq return an empty value if there is nothing matched by the query?

Yeah, specifically an undefined value if I recall correctly.

{ citation }
</footer>
</blockquote>
);
}
} );
24 changes: 24 additions & 0 deletions editor/blocks/quote/style.scss
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
#editor blockquote {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's preferable to add a class to the quote block (Similar to this https://github.com/WordPress/gutenberg/blob/master/docs/tinymce-per-block/src/blocks/quote-block/form.js#L95). Other blocks may use the blockquote with other styling options.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, sounds good. core-quote?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the best person for naming things hahaha :) Always had trouble with it. I'll choose editor-blocks-quote to match the folder structure, I guess we should define a convention somewhere

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think matching the slug for the block would be a good place to start. That way the css classes are namespaced like the blocks are.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some point we'll also need to consider if blocks can define their own default styles when rendered on the front-end of a site.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some point we'll also need to consider if blocks can define their own default styles when rendered on the front-end of a site.

To make it overridable, the fewer inline styles the better. The editor can't prevent the user from adding inline styles in raw mode, but it shouldn't encourage them in visual mode. The theme and plugins will be supplying the styles for the front-end look, though, so the block itself shouldn't have "default" styles beyond what the browser defines. The current method of defining editor-style.css should work the same way for this, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I don't think we'd want to encourage any inline styles, which furthers the need to consider stylesheets distinguished between the editor and front-end versions of a block. While the blocks here are first-party, we should outline and use an approach consistent with what we expect from plugin authors who implement their own blocks (a plugin which implements a slider block will need ability to define editor and front-end baseline styles). Whatever we land on, I agree that theme styles should always take precedence when defined for a block.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, I think the editor should not define any styles for rendering the content in the blocks.
The theme and plugins can supply styles, because they can also put those on the front end. But the editor can't put any on the real front end, so to get the correct preview, it shouldn't put any in the editor either.
As for "blocks defining their own default styles", a block is either core or added by user code, so how is it "defining its own"?

margin: 2em;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

margin: 0 ?

Copy link
Contributor Author

@BE-Webdesign BE-Webdesign Mar 29, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just copying styles that I found in one of the prototypes. I can change these later got to go for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I guess the other one had a margin in all the blocks. The margin felt a bit weird while testing.

box-shadow: inset 0px 0px 0px 0px #e0e5e9;
transition: all .2s ease;
font-size: 20px;
border-left: 4px solid black;
padding-left: 1em;
font-style: italic;
}

#editor blockquote footer {
color: #86909b;
font-size: 0.9em;
font-style: normal;
margin-left: 1.3em;
position: relative;
}

#editor blockquote footer:after {
content: '— ';
position: absolute;
left: -1.3em;
top: 0;
}