This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://dvcs.w3.org/hg/FXTF/raw-file/e1ae5deb9fa8/filters/index.html specifies <feDropShadow> in violation of the expectation that no new camel-case names would be added to SVG. Since camel-casing this is consistent with the existing filter effects, please add a mapping from fedropshadow to feDropShadow to the parsing spec.
That specification also adds feCustom, feCustomSource and feCustomParam. Presumably these would need similar treatment.
(In reply to Henri Sivonen from comment #0) > https://dvcs.w3.org/hg/FXTF/raw-file/e1ae5deb9fa8/filters/index.html > specifies <feDropShadow> in violation of the expectation that no new > camel-case names would be added to SVG. Define "violation"? > > Since camel-casing this is consistent with the existing filter effects, > please add a mapping from fedropshadow to feDropShadow to the parsing spec. Yes, that would be awesome. Thanks.
(In reply to Robert Longson from comment #1) > That specification also adds feCustom, feCustomSource and feCustomParam. > Presumably these would need similar treatment. Hold back with these elements for now please.
Would it be better to use all-lowercase for new SVG element and attribute names even if there are related features with camel-case already? If yes, is it possible to change these to lowercase now?
(In reply to Simon Pieters from comment #4) > Would it be better to use all-lowercase for new SVG element and attribute > names even if there are related features with camel-case already? That's the funadmental problem with saying all new elements/attribute will be lowercase, of course. Sounds good in theory, but completely violates author expectations for people who are familiar with the existing elements/attributes. I still hold out hope that we can move to a world where we support everything lowercased per http://dev.w3.org/SVG/proposals/improving-svg-dom/.
So what's the story here? Should I be changing the parser? Is someone else taking ownership of the issue while we figure out what needs to happen?
Note that I don't think there's anything wrong with adding new camelcase names. It's not like it saves the browsers much work: adding a new mapping is cheap compared to adding support for the actual feature, and there's not much point using the feature before browsers support it.
Chrome already supports feDropShadow and there's a Firefox bug almost ready to land that would implement it too, camel case and all.
(In reply to Ian 'Hixie' Hickson from comment #6) > Should I be changing the parser? Yes. Gecko implementation is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=964200 (In reply to Robert Longson from comment #8) > Chrome already supports feDropShadow Shame on them for not filing this bug!
Checked in as WHATWG revision r8443. Check-in comment: Update the parser to support new SVG camelCase name 'feDropShadow' http://html5.org/tools/web-apps-tracker?from=8442&to=8443