This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See the thread at https://groups.google.com/forum/#!topic/polymer-dev/mTM1-rByfZY for a limitation of the current spec. The current design of <content></content> means the default insertion point for all nodes not otherwise distributed (via select="...") must always appear last in the template. This could lead to situations where it is difficult to update a template and reposition this default insertion point before other insertion points that have explicit select="..." clauses. It would be beneficial if there were a way to explicit indicate that <content></content> element should pick up all nodes not otherwise distribution to other insertion points. Alternatively, the meaning of the plain <content></content> form could be changed to: "insert here all nodes not otherwise distributed, including nodes distributed to insertion points which follow this default insertion point".
You may be able to work around this problem by using CSS Regions. Two slightly more powerful mechanisms than the proposal to make <content> happen "last" are: 1. Distribute to <content> elements not in document order, but in selector specificity order. Make <content> with no selector less specific than any selector. Document order of <content> element is a fallback for tiebreaking. 2. Let the author separately specify an order to do distribution.
I think you understand the use case, and defer to your judgment on the best solution. My proposal was just an example. For reference: I did try using CSS regions to workaround this problem, but am unable to get this to work. See http://jsbin.com/areqez/1/edit. I'll follow up separately on that.
Personally I like @Dominic's first proposal. I think the root of the problem is that node distribution is in document order instead of the order of a form of specificity.
I prefer Dominic's suggestion #2. The author could specify selectIndex attribute on insertion points which would conceptually act like tabIndex. I think the problem with #1 is that the set of selectors used for insertion points is already highly limited. I think, in practice, this would make using specificity problematic.
This might be moot if we get an API.
Moved to https://github.com/w3c/webcomponents/issues/64