- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 18 Nov 2008 08:22:21 +0000 (UTC)
On the basis that the data template and repetition block template sections didn't actually solve enough problems, I've dropped them from the spec. If there are specific features we could add that would make it easier to implement custom templating features, please do let me know. It seems almost everyone with needs for templating has different specific needs, so it would be better for us to provide a generic API for custom templating features instead. The feedback below is thus being dropped at this point, as it no longer applies to the spec. Thanks for the feedback anyway! On Thu, 4 Oct 2007, Rikkert Koppes wrote: > > Related is the movement of repetition blocks, section 3.6.3 step 3: > http://www.whatwg.org/specs/web-forms/current-work/#movement > --- > # If distance is negative: while distance is not zero and target's > |previousSibling| is defined and is not a repetition template > <http://www.whatwg.org/specs/web-forms/current-work/#repetition2>, set target > to this |previousSibling| and, if it is a repetition block > <http://www.whatwg.org/specs/web-forms/current-work/#repetition3>, increase > distance by one (make it less negative by one). > --- > blocks might move above previous siblings that are not repetition blocks > (picture a legend element). On Thu, 4 Oct 2007, Rikkert Koppes wrote: > > the addition sequence, step 14 states > (http://www.whatwg.org/specs/web-forms/current-work/#addition): > --- > If the first argument to the method was null, then the template once again > crawls through its previous siblings, this time stopping at the first node > (possibly the template itself) whose previous sibling is a repetition block > (regardless of what that block's template is) or the first node that has no > previous sibling, whichever comes first. The new element is the inserted into > the parent of the template, immediately before that node. Mutation events are > fired if appropriate. > --- > > Furthermore, as I interpret correctly, this is also the case at > initialisation, i.e. the addRepetitionBlock() method is invoked with null as > it's argument (http://www.whatwg.org/specs/web-forms/current-work/#initial). > (not quite sure whether this is indeed correct interpreted, see further) > --- > For each element that has a |repeat > <http://www.whatwg.org/specs/web-forms/current-work/#repeat>| attribute with > the literal value |template > <http://www.whatwg.org/specs/web-forms/current-work/#template>|, the UA must > invoke the template's replication behaviour as many times as the |repeat-start > <http://www.whatwg.org/specs/web-forms/current-work/#repeat-start>| attribute > on the same element specifies (just once, if the attribute is missing or has > an invalid value).[...] (Invoking the template's replication behaviour means > calling its |addRepetitionBlock() > <http://www.whatwg.org/specs/web-forms/current-work/#addrepetitionblock>| > method). > --- > > If this is the case, at initialisation, when there are no repetition blocks, > the first block is added as the very first child of the template's parent, > which is not necessarily before the template. This doesn't seems to be desired > very often. Picture a fieldset with a legend where the first replicated block > ends up before the legend. Should the initial replication behaviour maybe call > the addRepetitionBlock with the template's previous sibling as argument? On Thu, 4 Oct 2007, Rikkert Koppes wrote: > > Nowhere in the addition and removal steps, the setting / clearing of > repetitionTemplate and repetitionBlocks attributes is listed (3.6.2 and 3.6.3) > > suggestion: > In the case of addition, insert a step after step 12 which tells to equip the > clone with a repetitionTemplate DOM attribute and add the clone to the > repetitionBlocks collection of the template > In the case of removal, it is unclear whether these attributes have to be > adjusted. It might be the case that the removeRepetitionBlock returns the > removed block (as is the case with removeChild), in that case, it seems > logical to keep the cross references alive On Sun, 14 Oct 2007, Rikkert Koppes wrote: > > Note that this is also an issue in Opera's current implementation > > test case: http://www.rikkertkoppes.com/other/wf2-repetition-model/ > note the legend element ending up halfway the fieldset. It occurs to that this > is unwanted bahaviour, it follows directly from the current wd though On Thu, 26 Jan 2006, Anne van Kesteren wrote: > > In <http://www.whatwg.org/demos/repeat-02/> the <p repeat="template"> should > also have repeat-start="0" set to make it not repeated. On Sun, 19 Nov 2006, J. King wrote: > > I was reading the section on seeding forms[1] earlier today, and I > couldn't figure out how one is supposed to seed fields that are part of > repetition templates with initial values. Is this not possible? Or am > I just not reading the spec right? > > I find that the section in question is particularly hard to read: I'm > sure it's very helpful for implementors, but it doesn't seem to do a > very good job of explaining the functioning of the form-data schema for > authors. On Sat, 9 Apr 2005, Lachlan Hunt wrote: > > I've just done some experements with the repetition templates, and > tried to devise a way to help IE end up with usable submit buttons, > rather than useless push buttons. The solution I came up with involves > a little (read: extremely evil and dirty) hack with IE's proprietary > conditional comments. > > However, it doesn't quite work as expected, and I thought someone may be > able to figure out a way to extend this idea a little more to make it > work. > > > For the remove button, this displays the correct button for IE 5 and 6. > > <!--[if IE 1]>--><button type="remove" name="remove" value="[player]"> > Remove</button><!--<![endif]--> > > <!--[if IE]><button name="remove" value="[player]" type="submit"> > Remove</button><![endif]--> > > > Note: This: <!--[if IE 1]>-->...<!--<![endif]--> is a validating version of > the so-called "downlevel-revealed" conditional comment: > <![if expression]> HTML <![endif]> > (which should probaby be nick-named "uplevel-revealed" :-)). > > > For the add button, this code works as intended, but still buggy like remove > is (as I will explain later): > > <!--[if IE 1]>--><button type="add" name="add" value="add"> > Add Player</button><!--<![endif]--> > > <!--[if IE]><button type="submit" name="add" value="add"> > Add Player</button><![endif]--> > > > Ok, the problem with the solution is that IE still sends the name/value pair > for both the add and remove button regardless of which one was clicked (ie. > "successful") and sends the button label as the value, rather than the value > attribute. This can be seen by looking at the resultant query string from the > submission: > > ...&remove=Remove+IE&add=Add+Player+%28IE%29 > > This seems to works as intended for the add button because the add name/value > pair must be detected and used in the server-side script, before the remove. > So, it ends up adding a field regardless of which button was pressed. > > The only solution I could think of was to change the <button>s to <input>s, > however the buttons would then be labeled with the text from the value > attribute (ie. "[player]" and "add" for remove and add buttons, respectively). > And changing that value attribute, at least for the remove button, would stop > server-side script form working correctly to remove the correct fields. > > > Lastly, for anyone wondering how this solution would work after IE7 is > released, and if IE fixes their <button> implementation, then the conditonal > comments can be altered as follows: > > Change: <!--[if IE 1]>--> To: <!--[if IE 7]><!-- -- --> > Change: <!--[if IE]> To: <!--[if lt IE 7]> > > However, even without these alterations the IE 5/6 version of the buttons > should still work in IE7 anyway. > > Without the special <!-- -- --> pseudo-comment [1], IE7 would end up > outputting the "-->" from the original "if IE 1" version. The 3 > double-hyphens "--" ensures that the enitire comment remains valid in SGML. > > [1] I called it a pseudo comment because it's not really a full comment in > SGML terms, it only looks like one. The real SGML comment is the full thing > including: <!-- ... -- -- --> On Sat, 10 Dec 2005, Dean Edwards wrote: > > This is something for Web Forms 3.0 (though it would be nice for WF2). > > In the repetition models I've implemented in the past (always tables) I've > provided a way to select a table row. This meant including either a radio > button or checkbox in the first column. When checked, the entire row would be > selected. > > <input type="selector"> > ======================= > > I suggest introducing a new input type to facilitate the selection of > repetition blocks: <input type="selector">. > > This would render as either a radio button or checkbox depending on an > additional constraint on the repetition template. > > When the selector control is checked it results in the repetition block being > selected (the CSS3 ":selected" pseudo class would apply). > > repeat-selection="single|multiple" > ================================== > > I suggest adding a new attribute to repetition blocks (although this is only > appropriate to repetition templates). > > "single" would be the default and would mean that only one block can be > selected at a time. If another block is selected the currently selected block > is deselected. <input type="selector"> controls are rendered as radio buttons. > > "multiple" means that any number of blocks can be selected. <input > type="selector"> controls are rendered as checkboxes. > > Changes to <input type="delete"> > ================================ > > the current definition of this control means that a <input type="delete"> > element must be contained by a repetition block for it to be active. I suggest > allowing the same constraints that apply to <input type="add"> so that the > delete control can apply to selected elements if placed outside of a > repetition block. In reality this means that you only need one delete button > to control your repeating form controls. > > .selected DOM Property > ====================== > > Not sure we need this but it would be nice to be able to test whether or not a > repetition block is selected using a DOM property. > > Other Possible <input> Types > ============================ > > The introduction of <input type="selector"> opens the door to other input > types. Possibly <input type="copy"> and <input type="paste">? They would be > similar to the add/delete controls but would use the clipboard. > <input type="copy"> would delete selected blocks but store the associated > data. <input type="paste"> would add new rows and populate them with data from > the clipboard. On Thu, 31 Mar 2005, Olav Junker Kj?r wrote: > John Burns wrote: > > I believe this list selector should be updated to provide columnar > > data formatting and enable properties that include: Greenbar > > (alternating colors - odd rows/even rows), header row, header column. > > Nice idea. Instead of doing this as an extension to the select-element, I > think we should consider a more general approach to selection. It would be > nice to make it possible to select one or more rows in a table, for example. > > This would also be useful in combination with the repetition model. For > example, instead of having a delete button on every block, we could have just > one delete button, which deleted the currently selected block. > > Since any element may be a repetition block, the ability to be > selectable must also apply to all elements. > > It not enough to be able to declare that an element is selectable. We have to > be able to declare the "scope" of selection, i.e. the collection of elements > from which only one element at a time can be selected. > > In most cases it would be sufficient to declare that all immediate > children of a certain element are selectable. E.g.: > > <table> > <tr><th>Name</th><td>Address</td></tr> > <tbody childrenselectable=multiple> > ... some rows... > </tbody> > </table> > > In this case all tr-elements in the tbody is selectable. > However in the case of a tree widget or optgroup elements it gets more > complicated, since the selectable elements might be nested or grouped by other > non-selectable elements. Perhaps it should be possible to declare that all > descendants of a certain type is selectable. > > When an element is turned into a container for selectable items, the DOM > should expose methods for retrieving the current selection (or the list > of current selections) and for selecting and unselecting elements > through script. > > Btw. I believe alternating colors for table rows is already supported in CSS > through the :nth-child pseudo-class. On Tue, 6 Mar 2007, Elliotte Harold wrote: > > I've been able to get Opera 9.1 Mac to display repeating groups with > markup like the below. Furthermore I've been able to get it to add new > items to the repeat. However, I haven't been able to get it to remove or > move a repeat item. The buttons show up but they're disabled. > > Is this just an Opera limitation for the time being or am I missing something? > > <div id="observation" repeat="template" repeat-start="5"> > <label>Species: > <input type="text" name="species[observation].name" value="" /> > </label> > <label>Count: > <input type="number" min='1' value="" > name="species[observation].number" /> > </label> > <button type="remove" template="observation">Delete</button> > <button type="move-up" template="observation">Move Up</button> > <button type="move-down" template="observation">Move Down</button> > </div> > <div><button type="add" template="observation">Add Species</button></div> On Wed, 3 Oct 2007, Henri Sivonen wrote: > > I started reviewing data templates to assess the impact on my conformance > checker work. Here are some questions and comments about data templates in > general: > > * What's the use case for data templates? It is hard to review them without > knowing what they are for. Conjecture-based comments/questions follow. > > * If data templates are a replacement for WF2 repetition templates, they look > like a harder-to-understand overkill. > > * Simple declarative markup templating mechanisms have a tendency to either > severely limit what you can do or have a tendency to grow into awkward > programming languages (like XSLT). Both end up being worse than doing straight > DOM scripting with JavaScript. Is there a plan to avoid these usual > tendencies? > > * It seems to me that data templates do not do a lot of things. Is there a > clean way to escape to JS without having to take out data templates from a Web > app UI and reimplementing the whole thing straight in JS. > > * What's the relationship with XBL2 tree adornments? > > * Markup templating on the server side is far from being a solved problem > with a single right dominant design even though the templates don't need to > re-evaluate on dynamic changes. Is now the right time to lock down one > solution for clients when the server side hasn't settled? (Aside: My > understanding is that the state of the art in markup templating is compiling > an XML template into executable Python byte code that calls Python code > written using the normal Python syntax. So far, I haven't seen declarative > approaches that weren't bad.) > > * Is there a reason why querySelector() and E4X tree literals together don't > solve what data templates seek to solve? > > * It seems to me that all non-trivial inline template uses are severely > incompatible with HTML parsing (especially in legacy UAs). Is there a reason > why inline templates won't break after all? If not, why bother with inline at > all? > > * External templates seem create a new kind of busy state that DOM building > and scripting needs to interact with. Do we really want that? On Wed, 3 Oct 2007, Keryx Web wrote: > > I am also very interested in this question. I think there is a tendency > to include too much in HTML - "since that what developers know". > > Except for the case of repeating stuff on a multi-line form (already > covered in Web forms 2) I have never felt the need for any client side > template system, nor have I read of any app where this might be useful. > > BTW, will they degrade gracefully? Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 18 November 2008 00:22:21 UTC