React 16 does not lowercase HTML attributes in generated HTML

[chromakode]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

ReactDOMServer generates camelCased markup for the cellSpacing and cellPadding attributes:

<table cellSpacing="1" cellPadding="2"></table>

(Here's an example pen: https://codepen.io/anon/pen/jGBLdP)

I believe these attributes are canonically lowercased. If I lowercase the attributes in JSX, React warns that I'm not using the right names:

Warning: Invalid DOM property `cellpadding`. Did you mean `cellPadding`?

What is the expected behavior?

The attribute names would be rendered lowercase:

<table cellspacing="1" cellpadding="2"></table>

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

This is in 16.0.0. Prior versions of React stripped these attributes.

[thysultan]

Since HTML attributes are case-insensitive this should work as expected.

var div = document.createElement('div')
div.innerHTML = '<table cellSpacing="1" cellPadding="2"></table>'
// produces
<table cellspacing="1" cellpadding="2"></table>
div.cellPadding === "2" // true

[chromakode]

Yes, agreed. Though if there is an easy way to make React output these attributes lower-cased, that would be a more canonical way to format these (does it currently do this for any other attributes?)

[gaearon]

Seems like it doesn't matter in practice. Although I'm open to reviewing PRs that lowercase anything that is in HTML namespace.

[gaearon]

I'm tagging this as feature request because technically it's not a bug. But we can fix this.

[gaearon]

I decided not to fix this. Again, it's not a bug: technically HTML allows attributes to have any casing. We're strictly doing less work on React side, and it doesn't make sense to me to do more work to make the output more aesthetically consistent.

If you feel strongly about you're welcome to provide real-world benchmarks from sites heavily using SSR that demonstrate #11110 has no impact on perf. Then we could take it.

[namnm]

Hey guys, not sure why but charSet makes the page shows invalid character code in some browsers (on iPhone), change it to all lowercase as charset and it works as normal. Now I must render them all to string and use replace to avoid this case.

[gaearon]

Can you file a new issue for this specifically with a reproducing case? Then we could look at it.
Thank you!

[cubuspl42]

I believe that a strong argument in favour of lowercasing (normalising) attributes is that W3 validator marks cammel-cased attributes as an error.

Line 1, Column 584: there is no attribute "cellSpacing"

While the standard might allow aRbiTrAryCasinG, W3 validator suggests that there's such thing as a normalised attribute name and that not using it can be considered an error.

[cubuspl42]

By the way, the funny thing is that React actually complains if one tries to override the attribute name to make the React output validate in the W3 validator:

<table
  style={props.style}
  {...{
    cellspacing: "0",
    cellpadding: "0",
  }}
> ...

Warning: Invalid DOM property `cellpadding`. Did you mean `cellPadding`?
    at table

[antsukanova]

I believe that a strong argument in favour of lowercasing (normalising) attributes is that W3 validator marks cammel-cased attributes as an error.

Line 1, Column 584: there is no attribute "cellSpacing"

While the standard might allow aRbiTrAryCasinG, W3C validator suggests that there's such thing as a normalized attribute name and that not using it can be considered an error.

Usecase: I want to render specific HTML strict markup for emails using React. W3 validator says the same thing as on the screenshot above.
If even this error in HTML doesn't affect users there are developers who rely on this validation and even have it as a requirement in their tasks. So now you can’t just create an email template generator using React with ReactDOMServer because it can't produce code without errors in w3c.

[reverofevil]

@gaearon So we figured out it's actually a bug. Should this issue be reopened, or another one created?