As we now have tiles in ShadowDOM, we could mess with DOM there.
We would still keep the grail of not touching user's elements, and polluting the (light) DOM.
But we will simplify the component, on both conceptual and code level.

The price is that we may hit the performance as we would perform DOM moves.

However, I think it's worth to measure the impact, as we wouldn't probably do much around the DOM - we will construct the separated tree on load(or setup change), then just distribute child nodes as we do anyways.

So it will indicate that tile, after being packed should adapt it's dimensions to changes.

Maybe it's more like Juicy/juicy-tile-grid feature.

We can divide our automated test to

• unit test group - for very atomic tests for individual functionalities, and
• smoke test group - which will contain common use cases, or use cases that were reported as bugs

Currently most methods of https://github.com/Juicy/juicy-tile-list/blob/gh-pages/src/package.js call packItems() at the end. This is not very useful anymore, because method packItems does not rerender DOM (I have to manually call <juicy-tile-list>.refresh() for that). Maybe packItems() call should be removed from these methods then?

In the source code, there is a console.info line:

Make configuration easier and shorter:

{
    items:[
        {
            priority:0.9,
            height: 50,
            width: 50
        },
        {
            priority:0.8,
            height: 100,
            width:50
        }
    ]
}

should be enough, as we could use indexOf element in items array if not given explicitly.

However it should work only for root level, and naturally will require index, if you want to mix virtual containers between real items.

It seems that changes made to migrate to Vanilla JS https://github.com/Juicy/juicy-tile-list/blame/gh-pages/src/juicy-tile-list.html#L411
caused addResizeListeners being executed twice, I susspect that may be a reason why
https://github.com/Juicy/juicy-tile-list/blob/gh-pages/test/refresh/onResize.html#L87
fails.

@miyconst Could you take a look, at it, and other attributes that are processed by lines 411-415

Currently workaround just finds parent <juicy-tiles> element and listen to its change.
However, current <juicy-tiles> ma get resided by any other element or event.

Consider writing cross-browser Element#onresize support, or even make it separated Web Component..

Now polymer 1.0 is out, it would be nice to have a compatible version of this..

In order to improve performance, we will separate <juicy-tile-list> to layers as bellow, so most common case will use raw CSS configuration and get reduced to almost just browser rendering.

• <juicy-css-tile-list css=".."> will just decorate child nodes in ShadowDOM, and apply given CSS. Given as text or file path.

• <juicy-tile-list>/<juicy-tile-list-json-to-css-manager json="{}" css="{{}}"> will take readable json configuration and process it to the CSS code which will be used by layer above.

• <juicy-tile-list> or just suggested use case code, that will use CSS if given, or call <juicy-tile-list-json-to-css-manager> , or <juicy-tile-editor> if needed:

  <template>
  <template if="{{relayout || !css}}">
    <link rel="import" href="juicy-tile-list-json-to-css-manager.html"/>
    <juicy-tile-list-json-to-css-manager css="{{css}}" json="{{json}}"></juicy-tile-list-json-to-css-manager>
  </template>
  <juicy-tile-list css="{{css}}">
    <content><!-- content of "polyjuice-merger" HTML --></content>
  </juicy-tile-list>
  </template>

So it will work smoothly with view-model like:

{
    Html: "/path/to/merged.html?..",
    app1: {..},
    app2: {..},
    setup: {
        css: "/path to virtual.css",
        relayout: true/false, // set when something get changed in merged HTML, or just set empty css property
        json: {..}
    }
}

Naming suggestions welcome ;)

Jocke pointed out that element name should always be singular to avoid confusion.

Maybe we should rename juicy-tiles to juicy-tile (Jocke's suggestion) or juicy-tile-list.

Ideas go!

Just to make it more reusable by others, and give conceptual separation.

Auto-arranging tiles could be quite commonly used, but full stack of features we need in PJ is probably quite specific.

So we could divide what we have to:

• Just tiles
• Prioritized/weighted tiles
• Virtual recursive groups for tiles
• Editor for above (https://github.com/Juicy/juicy-tile-editor)
• Element/Rectangle selector (https://github.com/Juicy/juicy-highlight)

It happened to me more than once that I was trying to render such template in juicy-tile-list:

<template>
   Hello World
</template>

As an app developer I would totally expect this to work. It doesn't work with juicy-tile-list, because only element nodes are rendered. Text nodes are ignored.

This works as expected:

<template>
   <div>Hello World</div>
</template>

I propose to either:

1. wrap text nodes in Shadow DOM (hard)
2. show console.error for any non-empty text node in juicy-tile-list root (easy)

To make it easier to integrate with Polymer, debug and maintain. We can simplify setup change flow, by just defining a setter.

As we are adding more renderers -grid, -flexbox, -table it's better to keep it short and clean.

As this describes precisely what it is and does not lead to the confusion, especially, when re-packing will be disabled for resize event

.. or fix #6 and leave it for container of <juicy-tile-list> to be resized or not (according to media queries breakpoints, element-queries or whatever).

From @miyconst on May 22, 2015 13:12

If input/select/a controls were reordered by priority property, then tabindex should also be applied.

It looks ugly when focus jumps from the bottom of a form to the top or to some other place.

@warpech, @tomalec any thoughts?

Copied from original issue: Juicy/juicy-tile-editor#57

Implementation of first breakpoint uses width/height of given setup. But usually, when refreshonresize attribute is on, someone may expect size to adjust to the new values, instead of keeping the first one.

We may once again consider use of precalculateWidth/-Height for root containers.

Comments <!-- my comment --> in the html will cause some exception in
juicy-tile-list.html (line 220).

 child.setAttribute('juicytile', id);

Instead of using position: absolute; we could try render packed items using CSS grid layout.

We could either hardcode it within juicy-tiles, or make separate component, that renders layout according to same JSON config.

Currently groups are implicitly called "root_0", "root_1", "root_0_0", etc

It should be "Group 1", "Group 2", "Group 3" respectively.

Related to: https://github.com/Polyjuice/Launcher/issues/57

In some kind of <juicy-tile> or just <div>.
It should

• simplify code and concept,
• make our component way less intrusive,
• we will not modify CSS of content nodes,
• 3rd party tiles may use padding/margins etc. freely.

DOM related operations should be moved from Package.js to juicy-tiles.html (perhaps inside refresh() method). It may be required to create one or two callbacks to be passed to Package.packItems() that will prepare layout of elements and apply the styles.

I have a mixture of images and probably sized DIV elements that I'd like to dynamically create. But when I try to appendChild(element) to the juicy-tile-list, I don't see any results.

Is there a different way to add elements? Looking for some documentation on this.

As we still didn't find a way to Wrap tiles in Shadow DOM (#22), and we overwrite child element's style, it could be nice to cache/expose original dimensions somewhere.
It should help with:

• applying "auto" height according to initial styles,
• reverting styles back,
• at least notice users(devs) what's going on

@warpech ideas from discussion started at https://github.com/Polyjuice/Launcher/issues/79#issuecomment-48712000 :

I propose to store the original inline style as a data attribute (https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes, https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement.dataset)

We may toggle css transition animations using attribute/class/custom style as one one hand, they looks nice, but they complicate automated tests, and juicy-tile-grid extension

Height auto should be reimplemented. We discussed that a way to achieve it is to remove height from being passed to Packer.js.

Instead, we should just pass one dimension constraint, which will be width for horizontal direction or height for vertical direction.

The other dimension becomes unconstrained. This means Packer.js will create slots with infinite maximum size and report that size back to Package.js upon finish.

Then, Package.js can decide whether that size exceeds the assumed dimensions for the container and show it (if height="auto") or clip it out.

This goes in line with suggestions in this ticket: https://github.com/Polyjuice/Launcher/issues/44

As discussed today on a call with Tomek:

Loading/saving of the setup should not be the responsibility of <juicy-tile-list>.

Proposed solution - move load & save methods out from <juicy-tile-list> to <juicy-tile-editor>.

Currently we do support following directions of packing

• "rightDown" - find place on right, if none go down /
  horizontal layers left-to-right
• "downRight" - find place bellow, if none go right /
  horizontal layers left-to-right

It would be nice to support at least left-to-right direction: for RTL languages, though layouts, for compatibility with bootstrap/flexbox/flexgrid demos (Juicy/juicy-tile-grid#13) ;)
Bottom up seems awkward, but why don't we support it as well.

On this page
http://juicy.github.io/juicy-tile-list/examples/nested.html
Links in the Other examples section leads to 404 page.

By @tomalec

Could you check if we need those changes also in juicy-tile-list?
It's good idea to keep also absolute positioned up to date, especially that CSS Grid Layout is not yet widely supported, and we may fallback to it.

See tile 3 here:

Configuration:

{
  "gap": 25,
  "items": [
    {
      "name": "name",
      "background":"rgba(150,150,150,0.15)",
      "priority": 0.9,
      "gap": 0,
      "heightAuto": true,
      "width": 320,
      "items":[
            {
              "index": 0,
              "priority": 0.9,
              "height": 50,
              "width": 160
            },
            {
              "index": 1,
              "priority": 0.8,
              "height": 140,
              "width": 160
            }
      ]
    },
    {
      "index": 4,
      "priority": 0.79,
      "height": 115,
      "width": 160
    },
    {
      "index": 5,
      "priority": 0.61,
      "height": 25,
      "width": 160
    },
    {
      "index": 2,
      "priority": 0.7,
      "height": 140,
      "width": 160
    },
    {
      "index": 3,
      "priority": 0.6,
      "height": 50,
      "width": 160
    }
  ],
  "name": "root",
  "width": 539.703125,
  "heightAuto": true
}

I discussed this with @Starcounter-Jack on the phone today.

It seems that a lot of times we are fighting with bin-packing algorithm, which fills the gaps with contents with lower priority, if elements with higher priority are already placed.

For example, consider such layout:

<span juicy-style="width  50px; priority 1.00"></span>
<div  juicy-style="width 400px; priority 0.75"></div>
<span juicy-style="width  50px; priority 0.50"></span>
<div  juicy-style="width 400px; priority 0.25"></div>

When the container is 400px wide, bin-packing renders it like below (disregarding the arbitrary priority):

SPAN SPAN
DIV
DIV

Whereas word-wrapping would render it like this:

SPAN
DIV
SPAN
DIV

I would like to discuss creating word-wrapping mode in packery and turn it ON by default.

Bin-packing is a nice feature in general (when you are building Pinterest), but not so efficient when you are building a business form.

Also, with word-wrapping, line break feature (#47) makes much more sense.

In

 {width: 200,
    items: [{
      id: "group",
      items:[
        {
          id: 0,
          priority: 0.9,
          height: 50,
          width: 100
        },{
          id: 1,
          priority: 0.7,
          height: 50,
          width: "50%"
        }
      ],
      priority: 0.9,
      height: 50,
      width: 200
    }]
}

Second item is not packed after first.

Today @Starcounter-Jack suggested changing the priority range to 1-100 (and direction to ascending).
The goal is to avoid 0.00000000000001 hacks in case of tiles provided by different vendors.

With priorities still used as (real) Numbers, but advertised as in natural range, with somehow described steps, we would not block it technically, but we hope that naturally people will use numbers like 1,2,3. So instead of thin tailed exponential distribution, we will get something more log-normal.

Right now juicy-tile-list is a Polymer 0.5 WebComponent. It should be migrated to pure vanilla WebComponent to work with both Polymer 0.5 and Polymer 1.1.

Umbrella issue: https://github.com/Starcounter/Starcounter/issues/2854

Just not to have create huge setup manually if we would like for example to make every tile .heightAuto

There should be gap only between elements, not between element, and border of container. Therefore, there should be no adjacent gaps.

On today's (2016-02-04) meeting @Starcounter-Jack came with the idea of "line break" feature, that will make sure that the element will be packed in the "new row". The way to achieve that would be to mark entire space before the highest x and y of items packed before, as not available.

Here is a picture that visualize the "line break" set for tile 4:

I would suggest to rephrase it a little bit:

As the button uses return/line break icon, we will call the property "line break", and attach it the the last element (3) before marking space as not available.
("line" applies for vertical and horizontal breaking, "new row" could be confusing, as there are grid/table "rows" between 3 and 4, so someone could think, we went too far; "line break" in other environments is used at the end of a line, not at the beginning).

Then (to adhere to the implementation specifics), after "line break" element we will simply use current \max_{packed} y (\max_{packed} x, for column axis), to remove from free slots set all rectangles that starts at smaller y (x).

With such definition, we could apply it to any axis (rows/cols), in any direction (vert./horiz.) and orientation (RTL/..).

Plus, you closes your line, so event without specifying new line, you will be sure that no other new element (with lower priority) could break into 'your' free space.

Naturally, we do not have to expose all directions to the editor/end user.

I just forgot to set property 'index' for items and it went in a infinite loop when I refreshed the browser.

It seems that everything works, but for some reason tests fail on Win 10 Edge.

I bet it's similar issues to the ones I have fixed for Firefox and IE recently: Web Components shims make every thing asynchronous.

I tried to test it on virtual machine, but there most of them pass, so maybe it's a matter of increasing the timeout.

@miyconst, if you will have some spare time could you take a look at it?

Calculating desired dimension reads scrollSize of the element in its previous position, so its content may wrapp. We could move it to (0,0) before, but still we will read dimensions before transition is finished, so when the element is still on its previous position, but it is "cut" by windows size.

It could be fixed by disabling transition while calculating size, but this would result with no transition at all when window is being resided smoothly.

This should simplify code, and give transparent two-way data binding.

Some tiles get wrong positions. This is fixed when I set each item priority in descending order, but it could be done automatically.