24424 2014-01-28 10:24:26 +0000 Add parser support for feDropShadow 2014-01-30 02:38:30 +0000 1 1 1 Unclassified WHATWG HTML unspecified All All RESOLVED FIXED P2 normal Unsorted 24428 1 hsivonen ian cam dschulze ian longsonr mike zcorpan contributor oldest_to_newest 99285 0 hsivonen 2014-01-28 10:24:26 +0000 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. 99287 1 longsonr 2014-01-28 10:59:31 +0000 That specification also adds feCustom, feCustomSource and feCustomParam. Presumably these would need similar treatment. 99292 2 dschulze 2014-01-28 11:54:08 +0000 (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. 99293 3 dschulze 2014-01-28 11:54:34 +0000 (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. 99294 4 zcorpan 2014-01-28 13:11:29 +0000 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? 99309 5 cam 2014-01-28 16:57:50 +0000 (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/. 99333 6 ian 2014-01-28 18:50:22 +0000 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? 99334 7 ian 2014-01-28 18:52:09 +0000 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. 99338 8 longsonr 2014-01-28 19:22:34 +0000 Chrome already supports feDropShadow and there's a Firefox bug almost ready to land that would implement it too, camel case and all. 99385 9 hsivonen 2014-01-29 06:20:19 +0000 (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! 99458 10 contributor 2014-01-30 02:38:30 +0000 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