- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 11 Sep 2010 10:33:15 -0400
- To: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- CC: www-svg <www-svg@w3.org>
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