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

Add "Text & Image" Block #9416

Merged
merged 2 commits into from Oct 19, 2018

Conversation

@jorgefilipecosta
Member

jorgefilipecosta commented Aug 28, 2018

Description

Context: #6993

This PR implements a block that contains two areas one for a media element (image/video) and one area for blocks (buttons, paragraphs etc). The elements of both areas are vertically aligned.
This PR contains an alternative to #7414. So we can compare the two approaches side by side.
Here instead of middle blocks, the parent block will self-contain the media area (that allows images or videos), so we have only one simple nested area for the content.

Screenshots

sep-04-2018 18-49-22

image

Reviewer notes:

Files under packages/editor/src/utils/media-upload and packages/editor/src/hooks/align.js should not be reviewed in this PR as they are just cherry picks from other PRs: #9707, #9704, and #9634.

Depends on: #9707, #9704, and #9634

@jorgefilipecosta jorgefilipecosta self-assigned this Aug 28, 2018

@jorgefilipecosta jorgefilipecosta changed the title from [Try] [WIP] Half image Layout - Media Area part of the parent no middle blocks to [Try] Half image Layout - Media Area part of the parent no middle blocks Aug 31, 2018

@jorgefilipecosta jorgefilipecosta requested review from mtias and jasmussen Sep 4, 2018

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 5, 2018

Contributor

Love the most recent changes. This is going to be a great block. Love:

  • That the block is simple — child blocks that aren't manipulable aren't surfaced.
  • Easy to add images, easy to resize, easy to add text, easy to configure the block

It's delicious!

The drag handle to resize needs a little love. Can we make sure the drag handle is only visible when the block is selected first?

In addition to this, can we change it to use the same resizing handle that images do? I.e. instead of this:

screen shot 2018-09-05 at 09 05 41

We do this:

this

And instead of this:

screen shot 2018-09-05 at 09 08 33

We do this:

this2

I'd also personally be okay if the placeholder spot wasn't resizable, and it wasn't until a media item was added that the resize handle appeared. But it's fine either way.

Contributor

jasmussen commented Sep 5, 2018

Love the most recent changes. This is going to be a great block. Love:

  • That the block is simple — child blocks that aren't manipulable aren't surfaced.
  • Easy to add images, easy to resize, easy to add text, easy to configure the block

It's delicious!

The drag handle to resize needs a little love. Can we make sure the drag handle is only visible when the block is selected first?

In addition to this, can we change it to use the same resizing handle that images do? I.e. instead of this:

screen shot 2018-09-05 at 09 05 41

We do this:

this

And instead of this:

screen shot 2018-09-05 at 09 08 33

We do this:

this2

I'd also personally be okay if the placeholder spot wasn't resizable, and it wasn't until a media item was added that the resize handle appeared. But it's fine either way.

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Sep 5, 2018

Member

Thank you for your reviews @ZebulanStanphill and @jasmussen all the concerns were addressed :)

Member

jorgefilipecosta commented Sep 5, 2018

Thank you for your reviews @ZebulanStanphill and @jasmussen all the concerns were addressed :)

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 6, 2018

Contributor

This is really nice, I'm digging this block a lot:

screen shot 2018-09-06 at 10 46 28

However, possibly a rebase issue, but I'm seeing the title spot way smaller font size than in master:

screen shot 2018-09-06 at 10 45 51

Actually that's also in master.. I will investigate that separately. But 👍 👍 on the design! All this needs is a code review update and good to go I'd say.

Contributor

jasmussen commented Sep 6, 2018

This is really nice, I'm digging this block a lot:

screen shot 2018-09-06 at 10 46 28

However, possibly a rebase issue, but I'm seeing the title spot way smaller font size than in master:

screen shot 2018-09-06 at 10 45 51

Actually that's also in master.. I will investigate that separately. But 👍 👍 on the design! All this needs is a code review update and good to go I'd say.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Sep 10, 2018

Contributor

Nice! Everything looks good, except for two things.

First of all, is the image supposed to extend outside of the container once you increase it to a really large size? I think it probably is intentional, but I just want to make sure.
image

Second, the blocks does not have any default responsive styling. Of course, themes could provide styling, but I wonder if Gutenberg should provide default styles that themes could opt-out from.

I know right now Gutenberg has opt-in styles for blocks, but that seems very backwards to me. Gutenberg should not be providing any opt-in styles... only opt-out styles which exist for compatibility with older themes. Newer themes should be expected to provide most, if not all the styling for blocks. Perhaps even the "essential" styles for blocks should be opt-out so that themes can get maximum control over how blocks appear.

Contributor

ZebulanStanphill commented Sep 10, 2018

Nice! Everything looks good, except for two things.

First of all, is the image supposed to extend outside of the container once you increase it to a really large size? I think it probably is intentional, but I just want to make sure.
image

Second, the blocks does not have any default responsive styling. Of course, themes could provide styling, but I wonder if Gutenberg should provide default styles that themes could opt-out from.

I know right now Gutenberg has opt-in styles for blocks, but that seems very backwards to me. Gutenberg should not be providing any opt-in styles... only opt-out styles which exist for compatibility with older themes. Newer themes should be expected to provide most, if not all the styling for blocks. Perhaps even the "essential" styles for blocks should be opt-out so that themes can get maximum control over how blocks appear.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 10, 2018

Contributor

@jorgefilipecosta in Spotlight mode we are losing the ability to resize the image.

Contributor

mtias commented Sep 10, 2018

@jorgefilipecosta in Spotlight mode we are losing the ability to resize the image.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 10, 2018

Contributor

I know right now Gutenberg has opt-in styles for blocks, but that seems very backwards to me.

This is not entirely correct. Structural styles are loaded for all themes. It's visual styles — which have been separated through the theme.scss files — the ones that are opt-in. They include things like the quote left border, typographic opinions and certain colors, etc. And it's necessary for it to be this way because otherwise enabling Gutenberg could visually break a theme's expectations.

New themes that want to work with Gutenberg out of the box would accept these styles and build on top of them.

Contributor

mtias commented Sep 10, 2018

I know right now Gutenberg has opt-in styles for blocks, but that seems very backwards to me.

This is not entirely correct. Structural styles are loaded for all themes. It's visual styles — which have been separated through the theme.scss files — the ones that are opt-in. They include things like the quote left border, typographic opinions and certain colors, etc. And it's necessary for it to be this way because otherwise enabling Gutenberg could visually break a theme's expectations.

New themes that want to work with Gutenberg out of the box would accept these styles and build on top of them.

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Sep 10, 2018

Member

@jorgefilipecosta in Spotlight mode we are losing the ability to resize the image.

Hi @mtias, nice catch this problem was solved.

Member

jorgefilipecosta commented Sep 10, 2018

@jorgefilipecosta in Spotlight mode we are losing the ability to resize the image.

Hi @mtias, nice catch this problem was solved.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Sep 11, 2018

Contributor

@mtias Having theme.scss files at all is a strange decision. There should not be any theme.scss because new themes should be providing their own styles for blocks anyway, should they not? Gutenberg should not take on the responsibility of non-essential styling. The opt-in styles should be in a new default theme or something, shouldn't they? Putting it in core feels like bloat to me.

Contributor

ZebulanStanphill commented Sep 11, 2018

@mtias Having theme.scss files at all is a strange decision. There should not be any theme.scss because new themes should be providing their own styles for blocks anyway, should they not? Gutenberg should not take on the responsibility of non-essential styling. The opt-in styles should be in a new default theme or something, shouldn't they? Putting it in core feels like bloat to me.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 11, 2018

Contributor

Appreciate your passion, @ZebulanStanphill, it's visceral 💕

In this case, discussing the theme.scss file is sort of rehashing an old discussion, and it would best to keep the discussion on the older tickets. Not only so we don't have to explain it again — that's not scalable — but to keep the context and history together. The discussion starts in #2905 (old ticket, as you can see), was refined in #5360, and there are some future ideas in #5445.

To summarize briefly, the most basic example I can give is of the Separator block.

Most themes style the hr tag. Gutenberg also styles this, by making it 2px tall, centered, and not full-width. Because most themes already have a style for this, the CSS that makes the separator 2px tall, centered, and not full width is stored in theme.scss. That way themes need to explicitly say "yes, give me that style".

But the Separator block also has two variations, one which is full wide and thin, and one which is just 3 dots. No WordPress theme has styled these yet, because they are new. That's why those are stored in style.scss and are given to themes automatically. That way if a user uses TwentySixteen which has no concept of blocks, those variation styles will still work fine, without the theme having to be updated.

Ultimately it's about allowing Gutenberg to provide some well-designed blocks out of the box, ensuring that expectations are met between what a user sees in the editor and sees on the front-end, and giving theme developers options at the same time. This way, a freshly built theme that has an editor style and is Gutenberg aware will have lots of options of ensuring consistency between the frontend and the backend, providing their own styles where they want to. But at the same time every existing WordPress theme which has no concept of blocks can have some measure of consistency between the frontend and backend also, without having to do anything.

Contributor

jasmussen commented Sep 11, 2018

Appreciate your passion, @ZebulanStanphill, it's visceral 💕

In this case, discussing the theme.scss file is sort of rehashing an old discussion, and it would best to keep the discussion on the older tickets. Not only so we don't have to explain it again — that's not scalable — but to keep the context and history together. The discussion starts in #2905 (old ticket, as you can see), was refined in #5360, and there are some future ideas in #5445.

To summarize briefly, the most basic example I can give is of the Separator block.

Most themes style the hr tag. Gutenberg also styles this, by making it 2px tall, centered, and not full-width. Because most themes already have a style for this, the CSS that makes the separator 2px tall, centered, and not full width is stored in theme.scss. That way themes need to explicitly say "yes, give me that style".

But the Separator block also has two variations, one which is full wide and thin, and one which is just 3 dots. No WordPress theme has styled these yet, because they are new. That's why those are stored in style.scss and are given to themes automatically. That way if a user uses TwentySixteen which has no concept of blocks, those variation styles will still work fine, without the theme having to be updated.

Ultimately it's about allowing Gutenberg to provide some well-designed blocks out of the box, ensuring that expectations are met between what a user sees in the editor and sees on the front-end, and giving theme developers options at the same time. This way, a freshly built theme that has an editor style and is Gutenberg aware will have lots of options of ensuring consistency between the frontend and the backend, providing their own styles where they want to. But at the same time every existing WordPress theme which has no concept of blocks can have some measure of consistency between the frontend and backend also, without having to do anything.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 12, 2018

Contributor

I pushed a little tweak to increase the space between image and text. It looks nicer.

But I also noted a quick bug that somehow I missed previously. This block isn't responsive:

bug

It's due to the explicit width set on the image. I'm trying to figure out how we can make it responsive, and it's tricky. On one hand it's about meeting user expectations — if it's resizable, then for sure reflect what I see. But at the same time, we have to make this responsive.

Perhaps using percent can work? I'm going to try and see if I can get that to work.

Contributor

jasmussen commented Sep 12, 2018

I pushed a little tweak to increase the space between image and text. It looks nicer.

But I also noted a quick bug that somehow I missed previously. This block isn't responsive:

bug

It's due to the explicit width set on the image. I'm trying to figure out how we can make it responsive, and it's tricky. On one hand it's about meeting user expectations — if it's resizable, then for sure reflect what I see. But at the same time, we have to make this responsive.

Perhaps using percent can work? I'm going to try and see if I can get that to work.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 12, 2018

Contributor

Okay so the responsiveness here is going to be tricky. If we remove the resizing feature entirely, it's trivial:

responsive

This is because with the grid layout, grid-template-columns: auto fit-content(50%); takes care of everything.

Which means if we are to have a resizing feature, which I think is killer, we need the resize handle to change that rule instead. Is that even possible?

Contributor

jasmussen commented Sep 12, 2018

Okay so the responsiveness here is going to be tricky. If we remove the resizing feature entirely, it's trivial:

responsive

This is because with the grid layout, grid-template-columns: auto fit-content(50%); takes care of everything.

Which means if we are to have a resizing feature, which I think is killer, we need the resize handle to change that rule instead. Is that even possible?

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Sep 12, 2018

Member

Okay so the responsiveness here is going to be tricky. If we remove the resizing feature entirely, it's trivial:.

One simple option to get a responsive layout would be to use a media query. That makes the layout appear in two rows (using a different value for grid-template-areas) if the size is bellow a certain threshold. Themes can also easily do that, making sure this block is responsive when using this layout.
I can add a commit with this so we can test how it looks.

Which means if we are to have a resizing feature, which I think is killer, we need the resize handle to change that rule instead. Is that even possible?

I guess we can change the rule by applying an inline style:
e.g: 'grid-template-columns: auto WIDTHpx'

Member

jorgefilipecosta commented Sep 12, 2018

Okay so the responsiveness here is going to be tricky. If we remove the resizing feature entirely, it's trivial:.

One simple option to get a responsive layout would be to use a media query. That makes the layout appear in two rows (using a different value for grid-template-areas) if the size is bellow a certain threshold. Themes can also easily do that, making sure this block is responsive when using this layout.
I can add a commit with this so we can test how it looks.

Which means if we are to have a resizing feature, which I think is killer, we need the resize handle to change that rule instead. Is that even possible?

I guess we can change the rule by applying an inline style:
e.g: 'grid-template-columns: auto WIDTHpx'

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 12, 2018

Contributor

I guess we can change the rule by applying an inline style:
e.g: 'grid-template-columns: auto WIDTHpx'

I like this option the most. But can we use % instead of px here?

Contributor

jasmussen commented Sep 12, 2018

I guess we can change the rule by applying an inline style:
e.g: 'grid-template-columns: auto WIDTHpx'

I like this option the most. But can we use % instead of px here?

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Sep 12, 2018

Member

I like this option the most. But can we use % instead of px here?

Unfortunately, % here seems very tricky. When using a % the resizer component computes the % of space in relation to the parent of the object we are resizing. But in this case, the parent of the object we are resizing is the grid cell whose width depends on the child. In my tries to use %, I got the idea our resizer component can deal with configuring size in % but when we are not using a flex or grid layout that already manages the dimensions.
Just to confirm, this responsive system would never put the media and content on different lines. They would always be side by side, but instead of the media area having a fixed size, its size would be a fixed % of the size available for the media block? Is that right?

Member

jorgefilipecosta commented Sep 12, 2018

I like this option the most. But can we use % instead of px here?

Unfortunately, % here seems very tricky. When using a % the resizer component computes the % of space in relation to the parent of the object we are resizing. But in this case, the parent of the object we are resizing is the grid cell whose width depends on the child. In my tries to use %, I got the idea our resizer component can deal with configuring size in % but when we are not using a flex or grid layout that already manages the dimensions.
Just to confirm, this responsive system would never put the media and content on different lines. They would always be side by side, but instead of the media area having a fixed size, its size would be a fixed % of the size available for the media block? Is that right?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 12, 2018

Contributor

Unfortunately, % here seems very tricky. When using a % the resizer component computes the % of space in relation to the parent of the object we are resizing. But in this case, the parent of the object we are resizing is the grid cell whose width depends on the child.

Yes, I noticed that. Which means we need to resize the grid-cell itself, right?

Just to confirm, this responsive system would never put the media and content on different lines. They would always be side by side, but instead of the media area having a fixed size, its size would be a fixed % of the size available for the media block? Is that right?

Correct.

I think we could explore additional responsive measures like stacking on top on mobile, I think that would be fine, but can totally be done separately. Right now the real issue here is that even on desktop breakpoints, it's not responsive due to the inline pixel width of any media item resized using the size handler.

So say you are on a big 27 inch display with a fullscreen browser, and you have this lovely half media block with text on the right and it's looking great. Now you resize the browser, but because the image was sized according to what you saw on the big when you looked at it on the big screen, suddenly it's way too big and the text becomes a thin sliver on the right.

Contributor

jasmussen commented Sep 12, 2018

Unfortunately, % here seems very tricky. When using a % the resizer component computes the % of space in relation to the parent of the object we are resizing. But in this case, the parent of the object we are resizing is the grid cell whose width depends on the child.

Yes, I noticed that. Which means we need to resize the grid-cell itself, right?

Just to confirm, this responsive system would never put the media and content on different lines. They would always be side by side, but instead of the media area having a fixed size, its size would be a fixed % of the size available for the media block? Is that right?

Correct.

I think we could explore additional responsive measures like stacking on top on mobile, I think that would be fine, but can totally be done separately. Right now the real issue here is that even on desktop breakpoints, it's not responsive due to the inline pixel width of any media item resized using the size handler.

So say you are on a big 27 inch display with a fullscreen browser, and you have this lovely half media block with text on the right and it's looking great. Now you resize the browser, but because the image was sized according to what you saw on the big when you looked at it on the big screen, suddenly it's way too big and the text becomes a thin sliver on the right.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 15, 2018

Contributor

Thanks, this seems better.

Right aligned looks a bit awkward, though, we should have a similar padding there:
image

Contributor

mtias commented Oct 15, 2018

Thanks, this seems better.

Right aligned looks a bit awkward, though, we should have a similar padding there:
image

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 15, 2018

Contributor

The margin-bottom: -10px also causes a visual glitch of a couple pixels in my testing (Chrome):

image

Contributor

mtias commented Oct 15, 2018

The margin-bottom: -10px also causes a visual glitch of a couple pixels in my testing (Chrome):

image

@gziolo gziolo self-requested a review Oct 15, 2018

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 15, 2018

Contributor

Looking at this for the first time, there are a few a11y issues to address I've noticed so far.

1
Initial focus. when inserting this block, initial focus goes to the second RichText field:

screen shot 2018-10-15 at 19 32 58

Tab again and focus goes to the sibling Add block button:

screen shot 2018-10-15 at 19 33 04

Tab again and focus goes outside of the block to the following one:

screen shot 2018-10-15 at 19 33 06

This makes all the UI that is before the second RichText hardly discoverable for screen reader users and hardly operable for sighted keyboard users. Ideally, I'd tend to think this is one case where setting initial focus on the block outer wrapper would be the best option, also considering that in an already existing block the order of media and text could be reversed.

2
The two editable fields wrapper are both paragraph blocks and announced as such via their aria label aria-label="Block: Paragraph" (note: I'm referring to the wrapper not the RichText). Not sure this is ideal because that's not what they are. The first block is sort of a big "title", while the second is normal text but not exactly a paragraph. The first one especially, doesn't give any info to non sighted users that it's a "big" text meant to be used as sort of title. Wondering how the blocks aria-label could be changed in this specific case or maybe just make the bit text a heading?

Contributor

afercia commented Oct 15, 2018

Looking at this for the first time, there are a few a11y issues to address I've noticed so far.

1
Initial focus. when inserting this block, initial focus goes to the second RichText field:

screen shot 2018-10-15 at 19 32 58

Tab again and focus goes to the sibling Add block button:

screen shot 2018-10-15 at 19 33 04

Tab again and focus goes outside of the block to the following one:

screen shot 2018-10-15 at 19 33 06

This makes all the UI that is before the second RichText hardly discoverable for screen reader users and hardly operable for sighted keyboard users. Ideally, I'd tend to think this is one case where setting initial focus on the block outer wrapper would be the best option, also considering that in an already existing block the order of media and text could be reversed.

2
The two editable fields wrapper are both paragraph blocks and announced as such via their aria label aria-label="Block: Paragraph" (note: I'm referring to the wrapper not the RichText). Not sure this is ideal because that's not what they are. The first block is sort of a big "title", while the second is normal text but not exactly a paragraph. The first one especially, doesn't give any info to non sighted users that it's a "big" text meant to be used as sort of title. Wondering how the blocks aria-label could be changed in this specific case or maybe just make the bit text a heading?

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Oct 15, 2018

Member

Hi, @mtias thank you for your tests both issues mentioned (right padding and visual glitch on the image were addressed).

Member

jorgefilipecosta commented Oct 15, 2018

Hi, @mtias thank you for your tests both issues mentioned (right padding and visual glitch on the image were addressed).

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 15, 2018

Contributor

Can we remove the second block of text or is that dependant on addressing the trailing inserter issues?

Contributor

mtias commented Oct 15, 2018

Can we remove the second block of text or is that dependant on addressing the trailing inserter issues?

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Oct 15, 2018

Member

Hi @afercia, thank you for testing this PR from an a11y point of view. At first sight, it seems some of the problems are caused by existing issues/bugs and/or require engine feature additions so they can be addressed (e.g: aria-labels dependent on the nesting context). I will dive into your feedback to see if we can address in this PR the issues or if they are general ones and we should work on a general solution.

Hi @mtias,

Can we remove the second block of text or is that dependant on addressing the trailing inserter issues?

We are not inserting the second block of text we just insert the first one. The second block of text is caused by a bug (I think related with the trailing inserter issues) and should not exist at all. This gist https://gist.github.com/jorgefilipecosta/edafb2422ef41020d75619adf31d725e contains a very simple block that shows this bug in action.

Member

jorgefilipecosta commented Oct 15, 2018

Hi @afercia, thank you for testing this PR from an a11y point of view. At first sight, it seems some of the problems are caused by existing issues/bugs and/or require engine feature additions so they can be addressed (e.g: aria-labels dependent on the nesting context). I will dive into your feedback to see if we can address in this PR the issues or if they are general ones and we should work on a general solution.

Hi @mtias,

Can we remove the second block of text or is that dependant on addressing the trailing inserter issues?

We are not inserting the second block of text we just insert the first one. The second block of text is caused by a bug (I think related with the trailing inserter issues) and should not exist at all. This gist https://gist.github.com/jorgefilipecosta/edafb2422ef41020d75619adf31d725e contains a very simple block that shows this bug in action.

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Oct 17, 2018

Member

Hi @afercia,

Ideally, I'd tend to think this is one case where setting initial focus on the block outer wrapper would be the best option, also considering that in an already existing block the order of media and text could be reversed.

I totally agree with this. In my analysis, I checked that currently, we have a limitation where if a block contains a template we never keep the parent selected and we always select one of the children. So this problem is a general one and for any block with an edition area followed by a nested area the edition area would be hard to discover. I created a PR #10696 to overcome this general limitation. It allows blocks with templates to be kept selected when inserted.

The two editable fields wrapper are both paragraph blocks and announced as such via their aria label aria-label="Block: Paragraph" (note: I'm referring to the wrapper not the RichText). Not sure this is ideal because that's not what they are.

Currently, we can not change the behavior of a block depending on the place where it is nested.
For example for an image block nested in an author bio block containing the author picture, we can not disable the alignment controls, even if in that context alignment is not possible and the controls don't make sense. From the a11y point of view for that use case, it would also be helpful to have aria-label="Block: Image (Author Photo)" instead of aria-label="Block: Image".
We have an issue opened that should allow us to change blocks depending on some variables like the place where they are nested. If we provide that mechanism it should be possible to change aria-labels of the blocks from the outside of the block (e.g.from the parent), so describing what the blocks are would be trivial.
I added the accessibility label to the existing issue as the issue looks very important from the a11y point of view #7931.

Member

jorgefilipecosta commented Oct 17, 2018

Hi @afercia,

Ideally, I'd tend to think this is one case where setting initial focus on the block outer wrapper would be the best option, also considering that in an already existing block the order of media and text could be reversed.

I totally agree with this. In my analysis, I checked that currently, we have a limitation where if a block contains a template we never keep the parent selected and we always select one of the children. So this problem is a general one and for any block with an edition area followed by a nested area the edition area would be hard to discover. I created a PR #10696 to overcome this general limitation. It allows blocks with templates to be kept selected when inserted.

The two editable fields wrapper are both paragraph blocks and announced as such via their aria label aria-label="Block: Paragraph" (note: I'm referring to the wrapper not the RichText). Not sure this is ideal because that's not what they are.

Currently, we can not change the behavior of a block depending on the place where it is nested.
For example for an image block nested in an author bio block containing the author picture, we can not disable the alignment controls, even if in that context alignment is not possible and the controls don't make sense. From the a11y point of view for that use case, it would also be helpful to have aria-label="Block: Image (Author Photo)" instead of aria-label="Block: Image".
We have an issue opened that should allow us to change blocks depending on some variables like the place where they are nested. If we provide that mechanism it should be possible to change aria-labels of the blocks from the outside of the block (e.g.from the parent), so describing what the blocks are would be trivial.
I added the accessibility label to the existing issue as the issue looks very important from the a11y point of view #7931.

// video contain the media type of 'file' in the object returned from the rest api.
mediaType = 'video';
}
} else { // for media selections originated from existing files in the media library.

This comment has been minimized.

@youknowriad

youknowriad Oct 19, 2018

Contributor

I guess I have the same remark. Do we have an issue to follow up with this? Unify the media object between the MediaUpload and the rest API?

@youknowriad

youknowriad Oct 19, 2018

Contributor

I guess I have the same remark. Do we have an issue to follow up with this? Unify the media object between the MediaUpload and the rest API?

@youknowriad

Some small remarks, but overall, looking good to me.

I'd suggest doing a quick test in IE11 and ship.

@jorgefilipecosta jorgefilipecosta merged commit e50efbf into master Oct 19, 2018

2 checks passed

codecov/project 49.26% (-0.12%) compared to fd64343
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jorgefilipecosta jorgefilipecosta deleted the add/layout-half-image-containing-centered-contente-media-part-of-parent branch Oct 19, 2018

@paaljoachim

This comment has been minimized.

Show comment
Hide comment
@paaljoachim

paaljoachim Oct 22, 2018

I am trying to recreate these sections using the block: http://edwien.no/publikasjoner/

Result in the backend:
screen shot 2018-10-22 at 17 54 17

Image has space above and below. Heading aligns somewhat to the top of the image. Text links aligns somewhat to the bottom of the image.

In the frontend it looks like this (clicking the preview button):
screen shot 2018-10-22 at 17 55 06

The frontend will show the image nudged up top, left and it is going below the edge of the box.
Heading and text shows up in the center of the image.

Another:
Backend:
screen shot 2018-10-22 at 18 03 03

Frontend:
screen shot 2018-10-22 at 18 03 43

Here it might be good to be able to set the height of the block through the block setting.

paaljoachim commented Oct 22, 2018

I am trying to recreate these sections using the block: http://edwien.no/publikasjoner/

Result in the backend:
screen shot 2018-10-22 at 17 54 17

Image has space above and below. Heading aligns somewhat to the top of the image. Text links aligns somewhat to the bottom of the image.

In the frontend it looks like this (clicking the preview button):
screen shot 2018-10-22 at 17 55 06

The frontend will show the image nudged up top, left and it is going below the edge of the box.
Heading and text shows up in the center of the image.

Another:
Backend:
screen shot 2018-10-22 at 18 03 03

Frontend:
screen shot 2018-10-22 at 18 03 43

Here it might be good to be able to set the height of the block through the block setting.

@lkraav

This comment has been minimized.

Show comment
Hide comment
@lkraav

lkraav Oct 22, 2018

Testing it today, I wasn't sure why I wasn't able to add a Quote block in the Text container.

lkraav commented Oct 22, 2018

Testing it today, I wasn't sure why I wasn't able to add a Quote block in the Text container.

jorgefilipecosta added a commit that referenced this pull request Oct 23, 2018

Fix: Show resizer on "Media & Text" block on unified toolbar mode (#1…
…0913)

## Description
Fixes: #10895
On unified toolbar mode, it was not possible to resize the media on Media & Text block.
During the elaboration of #9416 this bug was addressed but I think during subsequent rebases and changes more concretely the usage of our abstracted Resizable box we had a regression.

This PR applies exactly the same fix that was applied in spacer block to the Media & Text block.


## How has this been tested?
I checked it is possible to resize the media in Media & Text block in all modes including the unified toolbar.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment