Re: SVG2: 10.12 Editable text fields

Hi, Jonathan-

Jonathan Chetwynd wrote (on 9/11/10 3:40 AM):
> SVG2: 10.12 Editable text fields
>
> I am concerned that my contributions both in filing SVG errata and bugs
> over almost a decade has not resulted in my inclusion as a contributing
> author, and hope the Working group will take steps to amend this.

First, I want to acknowledge your contributions... I suspect that you're 
one of the most prolific filers of SVG bugs for browser implementations, 
and that has greatly aided interoperability.  You've also been diligent 
in pushing the edges of SVG, not only in SVG content, but also in 
comments on the SVG mailing list.  So, you certainly deserve some 
recognition for that.

In previous SVG specs, we have included a blanket acknowledgment of the 
SVG community for all its help; for SVG2 and the SVG modules, we will 
aim to credit specific individuals in the acknowledgment section.  I 
will make sure you're on that list of names.

Other folks in W3C are looking at how we foster and reward our 
community, and better incorporate their feedback; while the SVG WG list 
is not the forum to discuss that (it's for technical comments on the 
spec itself), I am tracking that work and will be happy to give you a 
pointer when there's something more concrete.

As a final note on this subject, the authors of a spec are typically 
those members of the working group that write or refine the wording of 
the spec, and the editors are the ones who integrate that wording into 
the spec itself and maintain consistency; it's a lot of work, 
investigating the issues and use cases, sorting through (often 
conflicting) public comments, coming up with detailed proposals that 
meet the requirements and edge cases, coordinating with the different 
opinions of the people and companies on the group via email and telcon, 
establishing and maintaining liaisons with other groups, and so forth... 
so I think it's fair that they are acknowledged for their time-consuming 
effort; listing everyone as an author who has contributed via the public 
list would make for a prohibitively long list.  This is not to diminish 
the contributions of dedicated people like you, but to point out that 
there are different roles that different people play, and there are 
different ways in which they are denoted in the spec.


> Two proposed changes for SVG2 which may be errata for SVG1.2
>
> SVG 1.2 10.12 Editable text fields does not mention password, please add
> ie input is displayed as asterix, but content is available through DOM

SVG has deliberately avoided adding such high-level form controls; you 
can certainly roll your own, but that's never been intended as native 
SVG functionality.

You could easily simulate this feature with different hacks... here are 
a few ideas:
* for the "password field", use a font that only has a single glyph, the 
asterisk, used for every character (in an SVG Font, this would be the 
‘missing-glyph’ element)
* use visibility=hidden or opacity=0 to hide the characters, and 
substitute symbols or icons, or even just a numerical count of how many 
characters have been typed, as the visible display (it might be cool to 
generate a custom symbol, like an identicon, based on a hash of the 
user's password as they type; they would have a visual recognition of 
when they got their password right, without revealing it to observers)
* use a blur filter set very high to obscure the glyphs while still 
showing each one as a blurry blob

The SVG WG doesn't want to recreate all the features of HTML in SVG; 
instead, we are working on making SVG and HTML work well together. HTML 
form controls are an obvious thing for people to include using 
'foreignObject', etc.  We will define some of this in more detail in the 
SVG Integration spec.  If you want more control over styling, you should 
follow the threads on styling form controls on the CSS mailing list.


> SVG 1.2 10.12 Editable text fields does not describe clipping, once the
> text area is full, one would expect text to move to the left and be
> hidden, caret remains near right edge of box, for l-r languages
> however see http://www.w3.org/TR/SVGTiny12/examples/textArea02.svg
> in Opera text overflows to right. Is this an Opera bug? seems not to be
> defined.

As far as I know, it's not really defined.  We have talked about adding 
an ellipse for overflow, similar to a CSS property.  We could add a new 
property, perhaps, to control scrolling, or just use the default for the 
language.  I've added this as ISSUE-2373 for SVG2:
  http://www.w3.org/Graphics/SVG/WG/track/issues/2373


> finally: where is the public space where SVG2 is being discussed and
> edited?

It's being discussed here on www-svg, with all of our technical 
discussions, and in our telcons (again, the minutes are posted here). 
We plan to start checking in spec text soon... we're still working on 
the infrastructure, because SVG2 will not simply be patches on top of 
SVG 1.1.  We're going to go over it with a fine-tooth comb.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 11 September 2010 14:33:18 UTC