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.

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 Grid Support #168

Merged
merged 13 commits into from
Apr 19, 2016
Merged

Add Grid Support #168

merged 13 commits into from
Apr 19, 2016

Conversation

jshcrowthe
Copy link
Contributor

PR per comments in #167

@blasten Here you go!

@blasten
Copy link
Contributor

blasten commented Jan 8, 2016

Thanks, I will take a look :)

@@ -349,7 +383,12 @@
/**
* The height of the list. This is referred as the viewport in the context of list.
*/
_viewportSize: 0,
_viewportHeight: 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@MeTaNoV
Copy link

MeTaNoV commented Jan 8, 2016

/sub +1

width: 100%;
};

:host([grid]) #items > ::content > * {
Copy link
Contributor

Choose a reason for hiding this comment

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

replace :host([grid]) #items > ::content > * for #items > ::content > *. Even for the !grid case, setting margin in the item isn't allowed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Gotcha! I'll add that in.

@blasten
Copy link
Contributor

blasten commented Jan 9, 2016

@kevinpschaaf would you mind taking a look at this PR?

@jshcrowthe
Copy link
Contributor Author

In doing more testing I discovered that it also seems that adding and removing items from the list is not properly recomputing the height of the items list. Will investigate further.

@jshcrowthe
Copy link
Contributor Author

I have broken out my commits into a smaller series that you can look at (they can be squashed later). I fixed all broken tests and have fixed all issues (that I was aware of) related to resize and item addition/deletion/reassignment.

I will go add some tests for this to cover all of the cases that I tested.

Let me know what you think: @blasten @kevinpschaaf

@MeTaNoV
Copy link

MeTaNoV commented Jan 13, 2016

@jshcrowthe are you also on Polymer slack?

@blasten
Copy link
Contributor

blasten commented Jan 14, 2016

Thanks!

@jshcrowthe
Copy link
Contributor Author

@blasten This has been updated to account for the merged PR's.

@jshcrowthe
Copy link
Contributor Author

@blasten Rebased to v1.2.4

@jshcrowthe
Copy link
Contributor Author

This seems to have stagnated a little bit, is there anything I can do to help move this forward?

@blasten
Copy link
Contributor

blasten commented Feb 23, 2016

Thanks I will take a look

@jshcrowthe jshcrowthe changed the title Working Proposal for Grid Support Add Grid Support Mar 7, 2016
@jshcrowthe
Copy link
Contributor Author

I have added in a unit test suite that is based off of basic.html (just adapted for grid mode). Let me know if there are any other tests that you'd like to see.

@jshcrowthe
Copy link
Contributor Author

@blasten: Any word on this?

@Westbrook
Copy link
Contributor

@jshcrowthe excited to see someone looking at the grid functionality! Took a look at how your update works, and saw one thing I wondered your thoughts on.

When positioning horizontally there is a much higher chance of "requiring" sub-pixel positioning to be "correct" to the layout. However, when you translate3d at that level (i.e. translate3d(100.5px, 0px, 0px)) the element you are positioning acquires a marked blur on its contents. It's a little hard to notice in the demo you've posted, but if you manually edit the sub-pixel out of the transform by comparison it becomes apparent. Here I've done just that to the item on the left:

screen shot 2016-04-07 at 10 46 16 am

What are your thoughts on using Math.floor() on your "x" and "y" values at line 1240 to prevent that from happening?

@jshcrowthe
Copy link
Contributor Author

@Westbrook - I'd be fine with that. Probably would want to keep track of the delta in pixels to properly compute the height. But I'd support that. We could also just Math.ceil the offsetHeight to ensure that we never need to handle an non-integer height.

@blasten
Copy link
Contributor

blasten commented Apr 18, 2016

Great job @jshcrowthe. I updated the demo, but so far this is looking awesome!

@jshcrowthe
Copy link
Contributor Author

@blasten - Thanks for the nice demo, that rocks!

@Westbrook - I retract my last comment we probably could just Math.floor() the values without needing to recompute the height. With the floor only happening on the positioning and not the actual viewport size computations we should be fine.

@Westbrook
Copy link
Contributor

@jshcrowthe that makes sense. My local version hasn't had any issues with Math.floor().

Speaking of which, is there a way for me to support the addition of that to this PR?

@@ -187,7 +187,7 @@
<div class="photoContainer">
<div class="photoContent" tabindex$="[[tabIndex]]">
<iron-image sizing="cover"
src="//farm[[photo.farm]].staticflickr.com/[[photo.server]]/[[photo.id]]_[[photo.secret]].jpg">
src="//farm[[photo.farm]].staticflickr.com/[[photo.server]]/[[photo.id]]_[[photo.secret]]_n.jpg">
Copy link
Contributor Author

@jshcrowthe jshcrowthe Apr 18, 2016

Choose a reason for hiding this comment

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

Showed this demo to a friend (@spacerockzero) who pointed out we weren't using the Size Suffixes. Just adding this saved us 1.3mb on initial render.

} else {
this.translate3d(0, y + 'px', 0, this._physicalItems[pidx]);
}

if (this._shouldRenderNextRow(this.grid ? vidx : pidx)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@jshcrowthe question: why were you using the vidx instead of pidx in grid mode?

Copy link
Contributor Author

@jshcrowthe jshcrowthe Apr 19, 2016

Choose a reason for hiding this comment

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

Great question!

When iterating through the list from the beginning the value of pidx accurately represents the row breaks in grid mode. However based on the size of the screen the row breaks (as computed by pidx) can occur at the wrong points in the actual list itself. This can result in stacked items. By computing based on vidx we ensure that we are always attempting to move to the next row at the proper "row breaks."

Copy link
Contributor

Choose a reason for hiding this comment

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

that makes sense. sweet!

@blasten blasten merged commit 44e3939 into PolymerElements:master Apr 19, 2016
@blasten
Copy link
Contributor

blasten commented Apr 19, 2016

thanks @jshcrowthe for your contribution!

@MeTaNoV
Copy link

MeTaNoV commented Apr 19, 2016

oh wow! yes! nice job @jshcrowthe ! :)

@jshcrowthe
Copy link
Contributor Author

Thanks for the merge! Hope this helps!

@jshcrowthe jshcrowthe deleted the grid-mode-refactor branch April 19, 2016 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants