RE: [whatwg] Web Forms 2 Repetition Model-please reinstate on specification

Hi David,

--Original Message--:
>Hi folks, 
>I've written lots of forms like the ones in the example provided (with
>expanding controls for what could be considered repeating values as in
>database apps). I see it as another possible use case for <replicate> .
>(look also at the paper as well as the examples)
>So now we have three proposed domains for applicability of <replicate>: web
>forms. svg, and inkml.

I think the SVG-WG should consider <replicate> for SVG 2.0 since there
seems to be a bunch of useful things it could be used for.

>On the other hand, I was one of those who thought <animate> might apply to
>domains outside SVG.

Indeed. One of the earliest demos I did with my CDF engine had SVG Fonts
pulled in for rendering the HTML text, then when I demo'd it to the
SVG WG back in early 2007, Cameron (McC) asked if the animation could
apply to the HTML markup? I edited the markup placing the <animate>
elements in the SVG namespace and targeted the color of the HTML text
and lo and behold it just worked(tm).

So a clean model should easily handle <animate> on any node in a DOM
tree given this is all unified in one code base in all browsers these
days. And this would naturally extend to things like <replicate>
as well.


>-----Original Message-----
>[] On Behalf Of Ian Hickson
>Sent: Monday, September 19, 2011 7:03 PM
>Subject: Re: [whatwg] Web Forms 2 Repetition Model-please reinstate on
>On Mon, 19 Sep 2011, wrote:
>> Please reinstate this feature (Web Forms 2 / Repetition Model) on the 
>> official specification.
>> My use-case/ justification is explained on this forum thread:
>> I want a declarative solution for simple repetition (e.g. for scientific 
>> data forms, for use in high-security institutions where Javascript may 
>> be disabled); and the ability to write my own Javascript based solution 
>> for anything else. (I can already do the latter, but the former eludes 
>> me; most disappointingly considering that this feature was well designed 
>> and close to being released).
>We took it out because it was just far too complicated a solution to solve 
>far too narrow a set of use cases.
>However, there is a lot of ongoing work in this area of research, 
>especially currently in the group. I encourage you 
>to bring up the suggestion there. Unfortunately, coming up with a 
>declarative solution whose cost-to-usefulness ratio is good enough has 
>proven over the years to be a rather elusive goal.
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 20 September 2011 01:17:56 UTC