Yeah, that's a fairly strong indication it's not being used (for its intended purpose at least... that's the only function it has.) It wouldn't surprise me if there are <view> element's in content though (after all they are theoretically useful for sprite-definitions and such.)
The view element is still in the SVG spec:
https://svgwg.org/svg2-draft/linking.html#ViewElement
So a good first step is to measure the SVGViewElement contructor and any other interesting points where it has an effect, to get an idea of whether removing it would be safe. It might also be a good idea to file an SVG spec issue to float the idea of removal, in case somebody can say up front why it's not a worthwhile effort.
Agree..
I will add a UseCounter in SVGViewElement contructor.
There is already usecounter (SVGSVGElementFragmentSVGViewElement), when SVGViewElement having some effect.
But this usage is already pointing to Zero.
Right, we should expect that usage of the view element is roughly zero as well. Getting the spec discussion started to reach some consensus in spec land and then waiting for the use counter data to arrive seems like a good approach to me.
Spec bug discussion going towards continuing support of SVGViewElement.
https://github.com/w3c/svgwg/issues/231
As per the discussion , SVGViewElement seems useful.
So can we proceed to deprecate SVGViewElement.viewTarget ?
As per https://github.com/w3c/svgwg/issues/231, it is decided <view> element will stay.
So proceed to deprecate SVGViewElement.viewTarget is meaningful for this bug.
Any thoughts?
I've confirmed that the viewTarget content attribute doesn't do anything except being reflected in the viewTarget IDL attribute, so attempting removal sounds good. Suggest sending an Intent to Deprecate and Remove with 2 milestones for the deprecation message since this is not in a hurry.
Comment 1 by shanmug...@samsung.com
, Aug 3 2016