Remove inline style colors atributes from paragraph. #3722

jorgefilipecosta · 2017-11-29T16:39:24Z

Description

This is a second take on #3669 and tries to accomplish the first step of the tasks discussed in #2862
. The objective is to remove inline styles. Here we are using #ids instead of .classes so our custom attributes have higher specificity. The styles are not saved at all in the post content they are generated by PHP on render time.

The styles are targeted using anchor if the user set one that anchor is used, if not anchor exists, one is automatically generated when needed (and the user is able to change it, but not remove it).
The inline styles remaining in paragraph size and align will be replaced by classes.

This is a WIP in progress when adding the anchor support to paragraph (even just than change) we starting getting tinymce erros in the console, but things work as expected. This changes the markup of paragraph so some blocks may now be invalid some migration/version should be added.

How Has This Been Tested?

Add a paragraph write some text.
Add other paragraphs change text color in one, background color in other and both attributes in another. Verify HTML anchors are automatically added when the first style is chosen. Verify you can change the anchor.
Save the post and view it verify it shows as expected.

Types of changes

Added anchor support to paragraph.
Added a hook to implements automatic addition of anchors when needed.
Added a PHP mechanism to generate the styles in the server.
Remove in style colors from paragraph block saving.

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows has proper inline documentation.

codecov · 2017-11-29T16:39:28Z

Codecov Report

Merging #3722 into master will decrease coverage by 0.55%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master    #3722      +/-   ##
==========================================
- Coverage   38.24%   37.68%   -0.56%     
==========================================
  Files         282      280       -2     
  Lines        6859     6751     -108     
  Branches     1256     1229      -27     
==========================================
- Hits         2623     2544      -79     
+ Misses       3563     3544      -19     
+ Partials      673      663      -10

Impacted Files	Coverage Δ
blocks/hooks/anchor.js	`80% <ø> (+21.17%)`	⬆️
blocks/hooks/index.js	`100% <100%> (ø)`	⬆️
blocks/library/paragraph/index.js	`23.07% <100%> (ø)`	⬆️
blocks/hooks/custom-anchor-styles.js	`40% <40%> (ø)`
blocks/api/serializer.js	`94.33% <50%> (-3.67%)`	⬇️
blocks/block-controls/index.js	`0% <0%> (-100%)`	⬇️
components/panel/row.js	`0% <0%> (-100%)`	⬇️
editor/components/warning/index.js	`0% <0%> (-100%)`	⬇️
components/panel/color.js	`0% <0%> (-100%)`	⬇️
blocks/alignment-toolbar/index.js	`16.66% <0%> (-83.34%)`	⬇️
... and 59 more

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 e619be5...b64945f. Read the comment docs.

aduth

Here we are using #ids instead of .classes so our custom attributes have higher specificity.

Which specificity are we seeking to defeat, and are we sure ID specificity is enough to do so?

aduth · 2017-12-05T20:00:09Z

lib/blocks.php

+				}
+			}
+			if ( '' !== $rules ) {
+				$styles .= sprintf( "\n#%1\$s { %2\$s\n}", $attributes['anchor'], $rules );


Do we need to escape the anchor?

aduth · 2017-12-05T20:01:07Z

lib/blocks.php

+			$rules = '';
+			foreach ( $map_attrs_styles as $attr_key => $css_property ) {
+				if ( isset( $attributes[ $attr_key ] ) ) {
+					$rules .= "\n\t" . esc_attr( sprintf( '%1$s: %2$s;', $css_property, $attributes[ $attr_key ] ) );


Do we need to do the whitespace prettifying here?

Without this whitespace prettifying when we check the source code the styles are messy and all on the same line but they work. I'm not certain what we normally do in this cases.

aduth · 2017-12-05T20:02:28Z

lib/blocks.php

+		'textColor'       => 'color',
+		'backgroundColor' => 'background-color',
+	);
+	$styles           = '';


Minor: If we added a newline before this, we could avoid the awkward = alignment, and more accurately associate the $styles variable with the foreach block where its value is accumulated.

aduth · 2017-12-05T20:03:29Z

blocks/hooks/custom-anchor-styles.js

+
+class AddAnchorWhenNeeded extends Component {
+	componentWillReceiveProps( nextProps ) {
+		if ( ! nextProps.attributes.anchor && CUSTOM_STYLE_ATTRIBUTES.some( attr => nextProps.attributes[ attr ] ) ) {


Minor: Personally I find the test within the condition to be a bit hard to read (and make the line long), vs. assigning to a separate variable e.g. hasCustomStyleAttribute = ...

Yes, extracting a variable which explains the condition is always a good idea 👍

aduth · 2017-12-05T20:04:21Z

blocks/hooks/custom-anchor-styles.js

+const CUSTOM_STYLE_ATTRIBUTES = [ 'backgroundColor', 'textColor' ];
+
+class AddAnchorWhenNeeded extends Component {
+	componentWillReceiveProps( nextProps ) {


Are we sure this is only necessary to check when props change, not also on the initial mount? Thinking a block which is prepopulated with custom styling attributes.

If a block is prepopulated with custom styles my expectation is that the anchor is already present so we don't need to add it.
Regarding posts created before this change that's problematic. This change changes the markup e.g: changes inline style attributes so, right now we display the message saying the block is invalid. I have not yet addressed the migration, as soon as #3673 or a similar approach is landed I will use the approach to migrate blocks

aduth · 2017-12-05T20:05:15Z

blocks/hooks/anchor.js

@@ -34,9 +34,6 @@ export function addAttribute( settings ) {
 		settings.attributes = assign( settings.attributes, {
 			anchor: {
 				type: 'string',
-				source: 'attribute',


Why is this attributes definition modified?

This change allows the server to have access to anchor attribute which is required to generate the styles in the server.

This change allows the server to have access to anchor attribute which is required to generate the styles in the server.

This will also mean existing blocks with anchors will lose the attribute value after this change (since it was not encoded in the comment delimiters).

I see this was mentioned in #3722 (comment)

aduth · 2017-12-05T20:06:51Z

blocks/api/serializer.js

 /**
 * Returns the block's default classname from its name
 *
 * @param {String}   blockName  The block name
 * @return {string}             The block's default class
 */
 export function getBlockDefaultClassname( blockName ) {
-	// Drop common prefixes: 'core/' or 'core-' (in 'core-embed/')
-	return 'wp-block-' + blockName.replace( /\//, '-' ).replace( /^core-/, '' );
+	return `wp-block-${ friendlyBlockName( blockName ) }`;


Not sure it's worth concerning about, but there's a decent amount of redundancy between the class name and style applied to a block with custom styles, i.e.:

<p id="wp-block-paragraph-z60dssg" class="wp-block-paragraph"> </p>

I agree the naming was redundant, I changed the id's so now they are in format 'paragraph-....'.

jorgefilipecosta · 2017-12-06T17:39:16Z

Hi @aduth thank for your review, some improvements were applied based on the ideas you provided.

Which specificity are we seeking to defeat, and are we sure ID specificity is enough to do so?

The original example was something like "#content p" which as you well noted in a previous talk our approach did not provide enough specificity. I made a change in all blocks with custom styles we add a "has-custom-styles" class. By default we target using .has-custom-styles#blockid. We are using a class and id specify which I think is enough the majority of cases.

The fact we are using an id allows us to target from class/attribute specificity using [id=...blockid] to a hacky multiple id approach e.g: "#blockid#blockid". We will never be able to make sure our default approach for custom styles is enough so I think an option we have right now is provide a default approach that we are comfortable with and is ok for majority cases and then we can provide a way for themes/plugins to change the specificity of our custom styles between a set of allowed options.
I'm not certain if providing a way to set configure specificity is useful or not so I'm open to suggestions.

aduth · 2017-12-11T15:18:02Z

We are using a class and id specify which I think is enough the majority of cases.

This would have the same specificity of #content p, meaning it could depend on the order in which the two styles are defined in the page which would take precedence.

jorgefilipecosta · 2017-12-11T15:26:11Z

This would have the same specificity of #content p, meaning it could depend on the order in which the two styles are defined in the page which would take precedence.

"#content p" has one id and one element selector. Our approach ".has-custom-styles#blockid" has one id and one class selector so I think we have higher specificity against the "#content p" use case (unless I'm missing something).

aduth · 2017-12-11T15:23:58Z

blocks/api/serializer.js

+
+/**
+ * Returns a random base 36 string, 36^7 possible strings, maximum seven chars
+ * According to the birthday paradox repetition occur after sqrt(36^7) = 279936 random strings are generated


If this is random, is it really the case that repetition could only occur after this number of strings has been generated, or is it rather there's a 1 in 279936 chance that a collision could occur? Meaning a post with two blocks could potentially share the same ID (though with a very low chance).

Sorry, @aduth I missed your comment. I changed the comments to be more accurate. The number I wanted to refer is the expected number of ids we have to generate (but I used a wrong formula) to have the first collision. I added the formula to compute the probability of collision given k strings, and the correct number of expected ids we have to generate before having the first collision. Both formulas come from this page https://en.wikipedia.org/wiki/Birthday_attack. A post with two blocks can share the same id but the probability is very very low 1.27*10^-11.

aduth · 2017-12-11T15:24:50Z

blocks/hooks/anchor.js

@@ -34,9 +34,6 @@ export function addAttribute( settings ) {
 		settings.attributes = assign( settings.attributes, {
 			anchor: {
 				type: 'string',
-				source: 'attribute',


I see this was mentioned in #3722 (comment)

aduth · 2017-12-11T15:25:59Z

blocks/hooks/custom-styles.js

+}
+
+export default function customAnchorStyles( { addFilter } ) {
+	addFilter( 'BlockEdit', 'core-anchor-inspector-control', addAnchorWhenStylesNeed );


This implementation would need to be updated per #3827 (not yet merged)

It was merged earlier today :)
Let me push fix.

aduth · 2017-12-11T15:28:13Z

"#content p" has one id and one element selector. Our approach ".has-custom-styles#blockid" has one id and one class selector so I think we have higher specificity against the "#content p" use case (unless I'm missing something).

Nope, you're right, I had a brain fart 😄

gziolo · 2017-12-12T08:40:13Z

@jorgefilipecosta I rebased this PR with master and updated code to work with the latest changes around hooks.

gziolo · 2017-12-12T08:44:10Z

blocks/hooks/custom-styles.js

+}
+
+export function addAnchorWhenStylesNeed( BlockEdit ) {
+	const WrappedBlockEdit = ( props ) => {


@jorgefilipecosta you might want to combine AddAnchorWhenNeeded and WrappedBlockEdit together and provide only one Component. It looks like AddAnchorWhenNeeded is there only for lifecycle method, so could be also a part of WrappedBlockEdit. This would simplify render method and help keep componentWillReceiveProps focused on logic related to anchor.

Thank you for rebasing and updating this PR @gziolo. I tried to simplify things a bit following your advice :)

mcsf · 2017-12-12T16:41:45Z

blocks/hooks/custom-styles.js

+
+const hasCustomStyles = ( attributes ) => (
+	CUSTOM_STYLE_ATTRIBUTES.some( attr => attributes[ attr ] )
+);


This may be a bit too much magic, especially if we think outside the core block library. Why not something based on explicit support (blockType.supports.customStyles = …, hasBlockSupport)?

Hi @mcsf, I added explicit support for custom styles, but this verification still happens, because even if blocks have support for custom styles, this function still needs to execute to check if custom styles are in fact used. I changed the name to hasCustomStyleAttributes.

mcsf · 2017-12-12T16:44:46Z

lib/blocks.php

+ *
+ * @return string CSS style block or empty string
+ */
+function compute_styles( $blocks ) {


do_blocks_styles? gutenberg_generate_blocks_styles?

mcsf · 2017-12-12T16:46:50Z

blocks/api/serializer.js

@@ -15,15 +15,45 @@ import { applyFilters } from '@wordpress/hooks';
 */
 import { getBlockType, getUnknownTypeHandlerName } from './registration';

+/**
+ * Returns the block's name with common prefixes: 'core/' or 'core-' (in 'core-embed/') dropped


I'd wrap the examples with parens to make it slightly more readable: "Returns the block's name with common prefixes ('core/', 'core-') dropped".

gziolo · 2017-12-14T10:25:07Z

blocks/hooks/custom-styles.js

+				! nextProps.attributes.anchor &&
+				hasCustomStyleAttributes( nextProps.attributes )
+			) {
+				nextProps.setAttributes( {


Can you explain what setAttributes is doing here? In general props should be readonly, but it's hard to find out if this call updates props or not. Given that we check whether nextProps.attributes.anchor is empty, I would assume this code updates this attribute. If I correctly assumed, we might want to introduce internal state here, and combine props and state when passing down to the <BlockEdit { ...this.props } /> in render method.

Hi @gziolo, what we are doing here is verifying if no anchor was set yet ( by the user or automatically). If that's the case we check if attributes needing custom styles were used and if yes we set an automatically generated anchor attribute. I think it's not enough to pass a prop we really want to save the attribute for it to be serialized.

The general question here is what is our extensibility solution to allow to set an attribute depending on other. E.g: If I want to have a plugin that sets red text color attribute if the background is blue what would be the best way to do it? Right now it looks like using our hooks we can achieve this result using this solution, but maybe there is a simpler way.

Okey, setAttributes is some magic functions passed down to edit which does all magic. It must be good 👍

gziolo · 2017-12-19T10:41:28Z

It looks like it needs another rebase and final check from @mtias once he is back.

… require.

aduth · 2018-01-11T03:21:29Z

Would it be possible to allow a block to provide their own inline styles to be included in the style tag, rather than just the small whitelisted set included here?

jorgefilipecosta · 2018-01-12T18:55:47Z

Would it be possible to allow a block to provide their own inline styles to be included in the style tag, rather than just the small whitelisted set included here?

Hi @aduth, I think we can allow that by allowing blocks to provide a PHP styles render function that outputs the custom styles they want, similar to what we have for server-side blocks.

cyrildc · 2018-02-15T17:04:30Z

Will it merge into master? IMO it would be a great feature to remove inline styles.

jorgefilipecosta added [Feature] Blocks Overall functionality of blocks [Status] In Progress Tracking issues with work in progress labels Nov 29, 2017

jorgefilipecosta self-assigned this Nov 29, 2017

jorgefilipecosta force-pushed the update/remove-inline-styles-take-2 branch 4 times, most recently from bad8e68 to 38dc117 Compare December 1, 2017 18:56

jorgefilipecosta removed the [Status] In Progress Tracking issues with work in progress label Dec 1, 2017

jorgefilipecosta requested review from youknowriad, aduth, gziolo, mcsf, ellatrix and mtias December 1, 2017 19:14

aduth reviewed Dec 5, 2017

View reviewed changes

jorgefilipecosta force-pushed the update/remove-inline-styles-take-2 branch 2 times, most recently from e4b742f to 48771ef Compare December 6, 2017 16:48

aduth reviewed Dec 11, 2017

View reviewed changes

Added anchor to paragraph.

a9d480f

gziolo force-pushed the update/remove-inline-styles-take-2 branch 2 times, most recently from baeb280 to b64945f Compare December 12, 2017 08:34

gziolo reviewed Dec 12, 2017

View reviewed changes

mcsf reviewed Dec 12, 2017

View reviewed changes

jorgefilipecosta force-pushed the update/remove-inline-styles-take-2 branch from f427d3c to d4b313e Compare December 13, 2017 22:27

gziolo reviewed Dec 14, 2017

View reviewed changes

jorgefilipecosta and others added 5 commits December 19, 2017 16:17

Added anchor when styles need it functionality.

4a62e8a

Created compute_styles php function to output the custom styles block…

74b47db

… require.

Removed paragraph colors from save logic.

267aad1

Blocks: Update custom styles hooks

eae5a48

Improvements/revisions

240fd08

jorgefilipecosta force-pushed the update/remove-inline-styles-take-2 branch from d4b313e to 240fd08 Compare December 19, 2017 16:18

jorgefilipecosta closed this Mar 7, 2018

gziolo deleted the update/remove-inline-styles-take-2 branch May 7, 2018 11:13

Remove inline style colors atributes from paragraph. #3722

Remove inline style colors atributes from paragraph. #3722

Conversation

jorgefilipecosta commented Nov 29, 2017 • edited Loading

Description

How Has This Been Tested?

Types of changes

Checklist:

codecov bot commented Nov 29, 2017 • edited Loading

Codecov Report

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorgefilipecosta commented Dec 6, 2017

aduth commented Dec 11, 2017

jorgefilipecosta commented Dec 11, 2017

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

aduth commented Dec 11, 2017

gziolo commented Dec 12, 2017

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

gziolo commented Dec 19, 2017

aduth commented Jan 11, 2018

jorgefilipecosta commented Jan 12, 2018

cyrildc commented Feb 15, 2018

jorgefilipecosta commented Nov 29, 2017 •

edited

Loading

codecov bot commented Nov 29, 2017 •

edited

Loading