Try: Refactor block margins #5217

jasmussen · 2018-02-23T13:18:37Z

This PR has been rejiggered to be a block margin refactor. It was previously a larger PR to allow margins to collapse, which would still be good to revisit. But keeping things slightly smaller, this is a step in that direction. Nested UI improvements and collapsing UI are next steps on this path.

GIF:

Original text:

What this PR does, is change how we render blocks, toolbars, and selected block borders. We now let the natural block margin shine through the chrome, and arrange blocks on the page. This also means we allow those very same margins to collapse according to standard web rules, which you can read about here: https://css-tricks.com/what-you-should-know-about-collapsing-margins/

Why?

Because this is a more accurate representation of the natural structure of web content. The chief benefit is that once we start loading theme stylesheets into the editor, the standard margins applied by the theme author should map 1:1 to the structure of content inside Gutenberg, whereas right now in master special rules would have to be written for it to visually match, as in master we space blocks using paddings instead of margins.

Another benefit of this refactor is that it takes the block-padding math mostly out of the block UI, which will benefit nested block UI. There's still an artificial padding left and right to enable hovering to get to the movers and ellipsis, but we are many steps closer to that being easily addressed with a negative margin, which should fix nested blocks also.

I had hoped that content adjecent to content in the new columns block would also magically collapse, but we probably need a special case for that block as according to the spec, CSS grid based elements don't allow collapsing margins: https://stackoverflow.com/questions/18963421/wanted-css-grid-system-and-collapsing-margins

The next steps for this PR is lots of testing. There are many little UI glitches and positioning math that's just slightly off, which we'd need to fix before a merge. But most importantly it's important to test lots of edgecases, and verify that everything still works as intended.

jasmussen · 2018-02-23T13:20:57Z

editor/components/block-list/block.js

@@ -628,6 +606,28 @@ export class BlockListBlock extends Component {
 					aria-label={ blockLabel }
 					data-block={ block.uid }
 				>
+					<BlockDropZone


I know this is not pretty, and I will need some help making sure this works as well as it needs to. But the reason for moving all of this is that it's necessary in order to allow the margins to collapse. Quite simply, all these elements have to be children of the content element itself, otherwise the content elements margins will be uncollapsed by the presence of adjecent divs. See also this codepen: https://codepen.io/joen/pen/aqKLqa?editors=1100

I don't know exactly why these components are outside of this div but what I know is that this block's content wrapper is targeted in code in a lot of places, so this change could have side effects. I'm seeing issues with the movers and with multi-selection in this branch.

Do you think it's possible to use another trick to move the margins to the parent wrapper instead, I'd feel more confident with the changes, if we can do so instead?

This doesn't mean we can't move these here, just that there are probably consequences I'm not aware of.

--
Also, do you think it's possible to split out some of the enhancements of this PR to separate smaller PRs, this would ease reviewing testing and mergin.

Thanks for the thoughts.

I think you've confirmed for me that it's a good idea to split this up into the general enhancements and refactor, and the collapsing margins separately, to let us focus. I will do that.

Do you think it's possible to use another trick to move the margins to the parent wrapper instead, I'd feel more confident with the changes, if we can do so instead?

I don't know, but I don't think so. In https://codepen.io/joen/pen/aqKLqa I basically tried finding the minimal layout we could use, to keep the block-docked toolbar and allow the margins to collapse. Basically, as soon as the block whose margins need to be allowed to collapse gets an adjecent element, like the block toolbar, those margins uncollapse.

jasmussen · 2018-02-23T13:23:25Z

editor/components/block-list/style.scss

+	 * Selected Block style
+	 */
+
+	.editor-block-list__block-edit>div:not( .components-drop-zone ):not( .editor-block-mover ):not( .editor-block-settings-menu ):not( .editor-block-contextual-toolbar ):not( .editor-block-list__block-mobile-toolbar ) {	// @todo — target a classname, not this crazy "not" rule


After moving all the Block UI elements around, there is no longer just a single div inside .editor-block-list__block-edit, there are multiple. And the one we need to paint a border around has no CSS class. If we decide that the approach taken in this PR is worth pursuing, then we need to add a CSS class, so we don't have to use this insane CSS :not rule. Something like editor-block-list__block-edit__content, perhaps?

jasmussen · 2018-02-23T13:27:52Z

editor/components/block-list/style.scss

+			z-index: z-index( '.editor-block-list__block:before' );
+			content: '';
+			position: absolute;
+			top: -$block-padding;


It's quite nice to be able to use negative values here. That means we paint the outline around the content itself, allowing the content margins to position and space items. The border is just painted around that, as is also shown in https://codepen.io/joen/pen/aqKLqa.

This should benefit nested UI also, as it will be one less bit of UI to "offset" in nested contexts.

jasmussen · 2018-02-26T11:12:12Z

Pushed a fix to floats right at the start.

Aside from a number of issues, on a high level, this feels like it's working reasonably well. Some of those issues include:

issue with recent blocks in appender being offset downwards
issues with offset toolbars in floated items
issues with selecting images

However before I spend too much time working on this, I would really appreciate some eyes on this, so we can decide whether it's worth it, and whether there are other endemic issues to this approach that should be considered.

If we do decide it's worth it, then I would appreciate help with #5217 (comment), as that's a blocker for fixing some of the selection issues.

jasmussen · 2018-02-26T12:09:47Z

Pushed another fix. Now there is only a single max-width on the main column. This allows us to eventually utilize the $content_width variable.

In addition to this, it uses negative margins on the side UI to pull it out. It still works on hover, but the chief benefit to this is that blocks have a true width that isn't affected by side UI. That means if your column is 100px wide, your block inside it is 100px wide.

This aspect is also not perfect, but it's yet another stepping stone:

CC: @mtias, would appreciate your eyes on this. Going to step away from it until we can decide.

jasmussen · 2018-02-27T12:27:48Z

Rebased and tweaked the in-between inserter as well. This partially duplicating work from #5282. CC @youknowriad

jasmussen · 2018-03-01T10:52:12Z

There is a lot of good stuff in this branch that isn't directly related to the collapsing margins. Things like:

Improvements to the in-between inserter line positioning (uses variables here)
Uses negative margins in addition to the block paddings, so you can still hover to get to the side UI, but blocks retain their original width
Same with borders, they are painted outside of the block itself
The $content_width variable from the theme can now be used because we no longer rely on an exotic version of that
There's a breakpoint for the $content_width variable so we can easily toggle the mobile UI.

However there are also some fairly big regressions in this branch, very probably as a result of me moving around a bunch of the block helper UI here: https://github.com/WordPress/gutenberg/pull/5217/files#r170248974

Things like the mobile toolbar not showing up on mobile (somehow shouldShowContextualToolbar broke), and other things like pressing delete while in an empty paragraph not deleting/merging with the subsequent paragraph. This is pretty important stuff, and I worry about other things maybe breaking as well.

There are also cosmetic issues/smaller things, like:

issue with offset toolbars in floated items
issue with selecting images being more fiddly
issue with block appender items being pushed downwards

But the bottomline is, I'm wondering whether I should split this PR in two. One that includes the mostly CSS structural stuff and improvements to width specific aspects. Then I can try and revisit the height related collapsing margins stuff separately.

It is a bit difficult to untangle, but it may be necessary to do an in-between step, so we can sort of compartmentalize the collapsing margin work (which requires the rearranging of toolbars/items from https://github.com/WordPress/gutenberg/pull/5217/files#r170248974).

jasmussen · 2018-03-01T10:57:24Z

CC: @youknowriad if you have time to look at the code, notably https://github.com/WordPress/gutenberg/pull/5217/files#r170248974, I would appreciate your opinion:

How much does that rearranging of components break?
How much work would it be to fix that?

This will help me decide whether I should revert the collapsing-margin specific aspects of this PR, get it in, and then try and tackle that again separately. Thanks.

jasmussen · 2018-03-02T12:25:19Z

This PR is now ready for a good code-review.

The short of it is this: I believe it is solid, and brings lots of improvements to how blocks are rendered in our editor. We should not put it in 2.3, but it would be nice to put in 2.4.

Changes in this PR:

Blocks now retain their standard dimensions. The side UI and the fact that these have to work with hover, does not affect block dimensions anymore, through a combination of paddings and negative margins.

This has allowed us to change the main column width to be just a single number, now called $content-width. This is a step towards leveraging the actual theme variable, $content_width, see also #1483.

Then negative margin trick takes steps towards improving the nested UI. There are no visual changes in this PR yet, but with the tiniest code change, we can make it so nested blocks are not indented, simply to make room for their side UI:

I will tackle that further in a separate PR that intends to create a better nested UI, but this refactor will make it much easier.

Due to all of this I have had to tweak the way we do responsive UI, which is now more resilient. There were some edgecases between the small and medium breakpoint where the block-toolbar would cause wide elements to generate a horizontal scrollbar. Due to the simpler $content-width variable, this is now a fixed.

Renamed a couple of variables to be more descriptive, and added some comments and section separators to the CSS files, to better document what's going on.

The insert-between line positioning is now simpler and more code-readable as it uses variables.

Changed the way borders are painted around the selected block, so now these also use negative margins, making the actual block dimensions more true.

The original purpose of this PR was to allow margins to collapse. Per code feedback, I decided to postpone that until later, as this particular refactor was necessary to get in first. So what was removed?

Well, I added back the CSS to disallow margins to collapse. I fully intend to revisit this, but given the refactors in this branch, I can do that separately as it requires somewhat major surgery of block.js, see

gutenberg/editor/components/block-list/block.js

Line 613 in b23cfae

<BlockDropZone

for an example. But by doing that separately from all the other CSS changes, it makes it easier to test for regressions, which will be important to do.

But the todo list for that future PR is now much simpler, as it only has to do the block.js surgery add a new class for the div that will hold the selected block outline, and deal with vertical margins. No responsive shenanigans, no horizontal margins/paddings work.

aduth · 2018-03-05T22:11:12Z

Noting one regression: In the Columns block, the Default Block Appender shows as not occupying the full width of the column, centered:

aduth · 2018-03-05T22:13:58Z

editor/components/block-list/style.scss

@@ -1,46 +1,47 @@
+.editor-block-list__layout {
+	// prevent collapsing margins on container
+	padding-top: .1px;


I'm not seeing any effective changes of removing this style. What is this collapsing into?

Also noting that .editor-block-list__layout is wrapping a nested container, so these styles should apply there as well.

Back when the initial purpose of this PR was to allow margins to collapse, I could swear there was an issue with the columns block and adjecent blocks that was fixed by adding this rule.

However since that's been pulled out, for now I'm going to also remove this rule. Since I hope to revisit collapsing margins in a future PR, I can always restore the rule if I recall what it did.

aduth · 2018-03-05T22:14:19Z

editor/components/block-list/style.scss

+	// make room in the main content column for the side UI
+	// the side UI uses negative margins to position itself so as to not affect the block width
+	@include break-small() {
+		padding-left: $block-side-ui-padding;


Also noting that .editor-block-list__layout is wrapping a nested container, so these styles should apply there as well.

Speaking of... this is probably where the regression I described is introduced.

I fixed it without touching this rule. This is part of the refactor, and it should, for now, bleed into the columns block intentionally.

I fixed the appender by making it more like a block, when in fact it's actually a button.

aduth · 2018-03-05T22:17:46Z

editor/components/block-list/style.scss

-	> .editor-block-settings-menu {
-		right: $block-mover-margin;
+	.editor-block-settings-menu {
+		right: -$block-mover-margin -$block-padding + 2px;


Operators get a bit confusing here; one's a negation, the other's a subtraction, but they're applied the same (where it could be confused as a shorthand syntax e.g. margin: -5px -10px).

At its most verbose, I could see this expressed as: #{ -1 * $block-mover-margin } - $block-padding + 2px

(Not really a suggestion, but it's how I'd express it)

This rule worked:

right: #{ -1 * $block-mover-margin - $block-padding + 2px };

Does that address your concern?

Does that address your concern?

Sure 👍 Assumes one remembers their order of operations though. Tend to paranthesize on mixed operators.

right: #{ ( -1 * $block-mover-margin ) - $block-padding + 2px };

aduth · 2018-03-05T22:18:15Z

editor/components/block-list/style.scss

-	> .editor-block-mover {
+
+	/**
+	 * 	Left and right side UI


Nit: Tab here after comment asterisk should be removed.

aduth · 2018-03-05T22:20:10Z

editor/components/block-list/style.scss

@@ -376,7 +426,7 @@

 .editor-block-list__insertion-point-indicator {
 	position: absolute;
-	top: 16px;
+	top: $block-padding - 1px;	// Half the empty space between two blocks, minus the 2px height


Nit: Tab before comment should be a space.

jasmussen · 2018-03-06T11:19:31Z

Fixed the appender width regression. Here's a screenshot from when I had some debugging outlines enabled to highlight everything:

Will look at the other feedback after lunch. As usual, thank you for the reviews.

jasmussen · 2018-03-06T11:36:43Z

Addressed the remaining feedback.

jasmussen · 2018-03-08T12:18:34Z

Rebased, and pushed a few fixes. Would be nice to get this in soon.

aduth · 2018-03-09T05:21:23Z

editor/components/default-block-appender/index.js

-				onKeyDown={ onAppend }
-				value={ showPrompt ? __( 'Write your story' ) : '' }
-			/>
+			<div className="editor-default-block-appender__content">


There are failing snapshot tests because of the change in markup. Is this nesting really necessary though? Could we apply padding-top to the parent .editor-default-block-appender instead?

Great catch. I could swear it was necessary to make this change, so the hovered style matched what the end paragraph would be, but a later change must've made it unnecessary because reverting this fixes it.

aduth · 2018-03-09T05:23:26Z

editor/components/block-list/style.scss

+	 * Selected Block style
+	 */
+
+	.editor-block-list__block-edit {


Do these styles need to be nested, or can they be defined as a separate top-level style block?

Edit: I guess it has some benefit to colocation of &.is-selected styles. Could also be separate, then targeting .editor-block-list__block.is-selected & {

Not completely sure what you mean here, did you prefer the hover, and selected styles were moved out of .editor-block-list__layout .editor-block-list__block?

.editor-block-list__block-edit - is unique, so it could be moved out of .editor-block-list__layout and everything should still work.

In case of:

// focused block-style &.is-selected .editor-block-list__block-edit:before { outline: 1px solid $light-gray-500; }

it would be more trickly, because of the dependency on the two parent classes.

After Grzegorz' explanation (thank you), and further thinking about this, I understand your initial point here, but also reached your same notion that the colocation of the selected blocks styles is beneficial even though the code is slightly less optimal.

In that vein, I think the entire block-list could be cleaned up a bit, there's a lot bunched together in a less than ideal way. But it feels like that might be good to do separately, and get this PR in as is, especially given that this file is likely to be revisited soon with nested UI improvements and collapsing margins.

Alternately we can move those rules out, as you suggest — it will just put them pretty far down the file as the .editor-block-list__block is pretty big as is.

aduth · 2018-03-09T05:24:01Z

editor/components/block-list/style.scss

+		position: relative;
+
+		&:before {
+			z-index: z-index( '.editor-block-list__block:before' );


We should rename the z-index key for the updated selector path.

gziolo · 2018-03-12T11:44:45Z

I guess also unrelated but documenting in here:

UI elements are hard to notice because overlap with the cover image block.

gziolo · 2018-03-12T11:48:44Z

There are still no movers visible on mobile when the block has wide alignments:

It's fixed for other align types including full.

jasmussen · 2018-03-12T11:49:06Z

Good call.

An ulterior motive of this PR is to start work on the nested UI. That means revisiting all the side UI, including on fullwide images.

I'll take a look at the movers on wide/mobile, thanks.

gziolo · 2018-03-12T11:56:33Z

I guess you don't plan to touch nested blocks on mobile in this PR, but sharing this as I discovered that the block's toolbar is shorter than the block on both sides:

In addition, block movers could fit into the same line as in other cases.

jasmussen · 2018-03-12T12:05:06Z

nested UI is definitely going to be a fun challenge, I have many ideas, but I mean to tackle them next.

A plan b is to scroll the buttons horizontally when there's not enough space. But that's still a plan B. Another question emerges: should the columns block even show multiple columns at the mobile breakpoint?

In any case, I believe this is ready to go. Thanks for the review.

gziolo · 2018-03-12T12:19:54Z

One more thing regarding toolbars:

wide:

center:

jasmussen · 2018-03-12T14:10:23Z

This rebase is really gnarly. I've tried and failed once — I would appreciate help if one of you has a chance to see if you do better than me. Let me know if we should pair or something.

aduth · 2018-03-12T14:37:05Z

@jasmussen To help in the future, I'd recommend rebasing often and squashing commits in the process, whenever sensible. Old branches with dozens of commits are inevitably going to be frustrating to rebase, particularly when you're resolving conflicts for changes which no longer exist in later states of the branch.

What I might suggest at this point is to squash on the merge base (where branch diverged from master):

git rebase -i `git merge-base master HEAD`

You should have no conflicts in squashing here. You're just flattening commits a bit (or entirely to a single commit, if you choose). Then you can proceed to rebase again to master and have fewer individual commits to deal with.

jasmussen · 2018-03-12T14:42:38Z

Ah that's a great tip. I'll try a good squash. For some reason I thought rebasing was the same.

aduth · 2018-03-12T14:47:28Z

Rebasing alone is just moving the branch point from one commit to another (typically the current state of master). It then proceeds to apply all of the same commits, where obviously some conflicts may occur.

Rebasing interactively gives you the opportunity to rewrite the commit history, including squash/fixup, dropping commits altogether, or even rearranging the order in which they're to be applied.

So after squashing on the branch point to first reduce the number of commits, you should have an easier time making sense of conflict resolution of a subsequent rebase against master.

I speak having been in similar nightmarish situations with ugly rebases 😆

gziolo · 2018-03-12T15:16:42Z

yes, squash and rebase works like a charm. Otherwise, you have to apply the same changes over and over again.

gziolo

@jasmussen great news is that your last commit fixed my two comments which cover 3 separate issues:

Great one 👍 I think it looks solid enough to proceed. Let's rebase and merge unless @aduth discovers any blockers :)

afercia · 2018-03-13T08:08:34Z

Quick note: Please be aware of the theme variable $content_width has been discussed a few times in core and it's seen as something "legacy", as it doesn't make much sense in a responsive era. It still make sense just for embeds, maybe. Some references:
https://core.trac.wordpress.org/ticket/21256#comment:25
https://core.trac.wordpress.org/ticket/23863#comment:10
Automattic/_s#100 (comment)

jasmussen · 2018-03-13T10:41:01Z

Okay, I'm pretty sure this is properly rebased now. But because I had to do a bunch of changes as a result of the recent appender/quick-block shortcuts, I'd like a new sanity check that things work as expected.

That is — no need to test everything surrounding images, alignments, toolbars, all that — specifically test issues surrounding empty paragraph blocks, the side inserter, the quick block links on the right. Note that there are separate rules and behaviors for the appender — the inserter at the bottom, and the empty paragraph block. That is, these rules are mostly merged and should behave the same now, but just remember to test both.

Thank you, and CC: @mtias to verify the fading effects work as intended.

This PR is not ready to merge, and is still mostly in the proof of concept stage. What this PR does, is change how we render blocks, toolbars, and selected block borders. We now let the natural block margin shine through the chrome, and arrange blocks on the page. This also means we allow those very same margins to collapse according to standard web rules, which you can read about here: https://css-tricks.com/what-you-should-know-about-collapsing-margins/ Why? Because this is a more accurate representation of the natural structure of web content. The chief benefit is that once we start loading theme stylesheets into the editor, the standard margins applied by the theme author should map 1:1 to the structure of content inside Gutenberg, whereas right now in master special rules would have to be written for it to visually match, as in master we space blocks using _paddings_ instead of _margins_. Another benefit of this refactor is that it takes the block-padding math mostly out of the block UI, which will benefit nested block UI. There's still an artificial padding left and right to enable hovering to get to the movers and ellipsis, but we are many steps closer to that being easily addressed with a negative margin, which should fix nested blocks also. I had hoped that content adjecent to content in the new columns block would also magically collapse, but we probably need a special case for that block as according to the spec, CSS grid based elements don't allow collapsing margins: https://stackoverflow.com/questions/18963421/wanted-css-grid-system-and-collapsing-margins The next steps for this PR is lots of testing. There are many little UI glitches and positioning math that's just slightly off, which we'd need to fix before a merge. But most importantly it's important to test lots of edgecases, and verify that everything still works as intended.

More fixes to come.

More work to do still.

Would like to optimize the CSS a bit further.

jasmussen · 2018-03-15T11:36:54Z

Got a 👍 👍 in chat. Merging.

jasmussen added [Status] In Progress Tracking issues with work in progress General Interface Parts of the UI which don't fall neatly under other labels. Needs Testing Needs further testing to be confirmed. labels Feb 23, 2018

jasmussen self-assigned this Feb 23, 2018

jasmussen requested a review from a team February 23, 2018 13:18

jasmussen commented Feb 23, 2018

View reviewed changes

jasmussen added the Needs Design Feedback Needs general design feedback. label Feb 26, 2018

jasmussen mentioned this pull request Feb 27, 2018

Inserter: Fix the in-between inserter on nested blocks #5282

Merged

jasmussen force-pushed the try/fix-collapsing-margins branch from 620996b to 06b25d7 Compare February 27, 2018 12:26

jasmussen force-pushed the try/fix-collapsing-margins branch from f1a82ac to 7784a1a Compare March 1, 2018 09:21

jasmussen changed the title ~~Try: Allow margins to collapse~~ Try: Refactor block margins Mar 2, 2018

jasmussen removed [Status] In Progress Tracking issues with work in progress Needs Design Feedback Needs general design feedback. labels Mar 2, 2018

aduth reviewed Mar 5, 2018

View reviewed changes

jasmussen mentioned this pull request Mar 8, 2018

Show block inserter to the left of empty paragraphs. #5478

Merged

jasmussen force-pushed the try/fix-collapsing-margins branch from ab7b274 to 71efa33 Compare March 8, 2018 12:13

jasmussen mentioned this pull request Mar 8, 2018

Responsive image gallery block #4035

Closed

aduth reviewed Mar 9, 2018

View reviewed changes

jasmussen mentioned this pull request Mar 12, 2018

Meta boxes area: consider to increase the width #5562

Closed

gziolo approved these changes Mar 12, 2018

View reviewed changes

gziolo force-pushed the try/fix-collapsing-margins branch from d816fd1 to 3ca0ed2 Compare March 13, 2018 08:48

jasmussen force-pushed the try/fix-collapsing-margins branch from 3ca0ed2 to 1d5367f Compare March 13, 2018 09:24

Joen Asmussen added 7 commits March 15, 2018 10:16

Fix _some_ breakage per rebase.

ba7ace1

More fixes to come.

Try to simplify the quick-buttons in the appender

2a30479

More work to do still.

Fix issues with positioning.

e98d0ae

Fix so it's the same as master.

d99b8e0

Would like to optimize the CSS a bit further.

Clean up appender CSS.

de3cb32

Fix regression per rebase.

e87bb0b

jasmussen force-pushed the try/fix-collapsing-margins branch from f02f759 to e87bb0b Compare March 15, 2018 09:24

Remove regressed padding.

5723e68

jasmussen merged commit a3776ed into master Mar 15, 2018

jasmussen deleted the try/fix-collapsing-margins branch March 15, 2018 11:37

afercia mentioned this pull request Mar 16, 2018

content_width and new block widths #5650

Closed

Try: Refactor block margins #5217

Try: Refactor block margins #5217

Conversation

jasmussen commented Feb 23, 2018 • edited Loading

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

jasmussen commented Feb 26, 2018

jasmussen commented Feb 26, 2018

jasmussen commented Feb 27, 2018

jasmussen commented Mar 1, 2018

jasmussen commented Mar 1, 2018

jasmussen commented Mar 2, 2018

aduth commented Mar 5, 2018 • edited Loading

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

aduth Mar 9, 2018 • edited Loading

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

jasmussen commented Mar 6, 2018

jasmussen commented Mar 6, 2018

jasmussen commented Mar 8, 2018

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 Mar 12, 2018

gziolo commented Mar 12, 2018 • edited Loading

jasmussen commented Mar 12, 2018

gziolo commented Mar 12, 2018 • edited Loading

jasmussen commented Mar 12, 2018

gziolo commented Mar 12, 2018

jasmussen commented Mar 12, 2018

aduth commented Mar 12, 2018 • edited Loading

jasmussen commented Mar 12, 2018

aduth commented Mar 12, 2018

gziolo commented Mar 12, 2018

gziolo left a comment

Choose a reason for hiding this comment

afercia commented Mar 13, 2018

jasmussen commented Mar 13, 2018

jasmussen commented Mar 15, 2018

jasmussen commented Feb 23, 2018 •

edited

Loading

aduth commented Mar 5, 2018 •

edited

Loading

aduth Mar 9, 2018 •

edited

Loading

gziolo commented Mar 12, 2018 •

edited

Loading

gziolo commented Mar 12, 2018 •

edited

Loading

aduth commented Mar 12, 2018 •

edited

Loading