@Mittineague if you are referring to the concept in the video, then since I couldn’t capture the mouse cursor it may not be evident but the expanding occur on mouse hover on the smaller bar. No dragging involved
update: actually draggable version can be good for touch enabled devices. where there is no mouse to hover with.
I am not sure I understand you completely but I will share this:
I was actually investigating today the affect of repeating string attributes on memory, cause I did notice that if for example you scroll down the topics list there will be many category buttons added to the DOM ( document )
So I was thinking does every time a category button is added do we add a full category description over and over to the memory.
I tested the hypothesis on chrome by observing memory and objects allocations ( Dev tools)
The test included setting the title attribute of over 10,000 elements in the document with a long string
From my not so scientific test, I have concluded that chrome is actually smart about it and the DOM is setting the "title " attribute of all the selected DOM elements by reference to the string. which make not much difference if title is set to 5 chars or 100 chars or more, under normal use cases.
It might not always be the case (bad code) , for example if the string we set can be the same but might not have the same reference, that can happen we pull that string dynamically everytime we are asked to generate the button, which I don’t think will be the case as it is inefficient anyway.
It is appear that there are much worst memory usage on Discourse when loading topics item in the list.
@sam after V1 may be it will be worth looking on improving that. Right now I can observe about 3mb on each “load more.” on chrome 35
It might not big issue ( may be on really limited memory devices) , Because on a normal use, user is unlikely to load more then a few pages.
It is interesting to know why there is so much new object created is that a bloating the ember.js introduces?