False positives in jsx-pascal-case when a variable and an element has the same name

[lencioni]

I have a component that renders some SVG elements that are showing up as false positives for the new jsx-pascal-case rule. The one I've found so far is the <stop> element, which is demonstrated by the following code:

<svg>
  <defs>
    <linearGradient
      x1='-1'
      y1='0%'
      x2='1'
      y2='0%'
      gradientTransform='rotate(5 .5 .5)'
      >
      <stop offset='0%' style={{ stopColor: BACKGROUND_COLOR }} />
      <stop offset='20%' style={{ stopColor: SHIMMER_COLOR }} />
      <stop offset='40%' style={{ stopColor: BACKGROUND_COLOR }} />
    </linearGradient>
  </defs>
</svg>

I'm not sure if there are others.

[phun-ky]

I've encountered the same issue with stop within a radialGradient

[lencioni]

I started looking into fixing this by adding the following test case to the valid section of jsx-pascal-case tests

  {
    code: [
      '<svg>',
      '  <defs>',
      '    <linearGradient',
      '      x1="-1"',
      '      y1="0%"',
      '      x2="1"',
      '      y2="0%"',
      '      gradientTransform="rotate(5 .5 .5)"',
      '      >',
      '      <stop offset="0%" style={{ stopColor: BACKGROUND_COLOR }} />',
      '      <stop offset="20%" style={{ stopColor: SHIMMER_COLOR }} />',
      '      <stop offset="40%" style={{ stopColor: BACKGROUND_COLOR }} />',
      '    </linearGradient>',
      '  </defs>',
      '</svg>'
    ].join('\n'),
    ecmaFeatures: {
      jsx: true
    }
  }

and it passed. So maybe this has been fixed somewhere, or the problem exists in some combination of things that aren't true in this test but are true in our environments?

[yannickcr]

Ok, I think the problem only occurs if you have a variable with the same name as your element.

Another example by @yordis:

<label htmlFor={name}>{label}</label>

[calebmer]

Is this being worked on?