- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 21 Jun 2004 14:38:46 +0000 (UTC)
On Mon, 14 Jun 2004, Sander wrote: > > The parsing of [ID] is by default limited to the "for", "form", > "headers", "id", "name" and "template" attributes. For those cases where > inserting the [ID] in another attribute is desired, a new attribute > "parseattributes" (needs a better name, obviously) is defined for use > within a repetition template. This attribute is used to specify a > comma-separated list of those attributes of descendant elements in which > the [ID]-string will be searched for and replaced by the repetition > block's index. This specified list of attributes replaces the default. > Thus, if this attribute exists, but is empty, no attributes will be > matched. I really don't like this. It might be the only solution though. How about this? We say that all attributes are processed, except those starting with the two character string "[]", which just have their two leading square brackets removed and are otherwise untouched. Then any unsafe attributes can just have "[]" put at the front. Ugly, but at least we don't have a weird attribute and a list of magical attributes that get processed... >>> More on repetition: I find the existence of the <repeat> element next to >>> the repeat attribute with numerical value to be confusing. I suggest >>> dropping the latter. (Comparing against an older draft, I vaguely >>> suspect this already being the plan, with the necessary editing simply >>> not having been done yet.) >> >> Not sure what you meant by this. > > You specify both repetition blocks (3.2.2: "An element ... with the repeat > attribute ..., with the attribute's value equal to an integer") and initial > repetition blocks (3.5.4: "The repeat element ... is used to insert > repetition blocks without having to explicitly copy the repetition template > markup in the source document.") > I just now grokked that the former might exist so that you can (dynamically) > set the "repeat" attribute on an existing element to turn it into a > repetition block, but the benefit of setting an attribute versus replacing > a node seems very small to me, and the existence of two ways to create a > repetition block both confusing and wasteful. The existence of the numeric "repeat" _attribute_ is largely because when you hit the "Add" button, there needs to be a way of distinguishing the repetition blocks from just random other blocks. That is, authors won't generally use the numeric "repeat" attribute (it isn't mentioned in the intro, for instance). >> [<repeat>] > > I at least oppose the idea of removing it; no matter how odd or > unconventional (though really, it's not that bad - it's just a > placeholder for content to be added at run-time), the benefits of its > existence are huge. Ok. >> Maybe we should drop "precision" altogether and just have "step", then >> make it apply to all the numeric and date/time types. > > That's throwing away the ability to specify logarithmic numbers. Not > used very often admittedly (at least in my experience), but the > possibility of them is very welcome nonetheless. We can add them back if there really is a good use case. I haven't seen one, to be honest. I originally added it because it fit into the model easily. It no longer fits into the model easily. > I'm personally leaning toward the earlier suggestion of a list of > datetime-part values ""y,m" for expdate, "y,w" for week, "y,m,d,h,M"" > (which you called "nice and generic, but ... much more complicated"), > but extended to (for example) "h,15M" - which would specify a precision > of 15 minute increments for a time consisting of hours and minutes. I > think authors will be more than willing to put up with the complexity of > this (I know I would be) to have just one general purpose datetime > element which can deal with all the weird requirements which comes up in > actual use. Is the current text (using step) acceptable? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 21 June 2004 07:38:46 UTC