This pull request is automatically built and testable inCodeSandbox.

To see build info of the built libraries, clickhere or the icon next to each commit SHA.

Latest deployment of this branch, based on commit2399b82:

ReactDOM: size: 🔺+0.3%, gzip: 🔺+0.3%

Size changes (experimental)

Generated by 🚫dangerJS against2399b82

Size changes (stable)

Generated by 🚫dangerJS against2399b82

Is<base href="" /> useful?

SSR should probably just work, in the sense that it just removes it from the HTML, since it calls this.

You could add some tests to the server integration tests.

Note sure if that causes problems in practice but I can't think of one other than maybe<base href="" />.

Should this be accompanied with a warning too since this is likely a bug and you should be setting the value to undefined or null if you want this behavior?

Seems like a reasonable approach that's inline with sanitizeURL.

Is<base href="" /> useful?

I don't think so.

Mozilla says:

If the document contains no<base> elements,baseURI defaults tolocation.href.

Based on my own testing (Chrome, Firefox, Edge) adding<base href=""> does not affect thedocument.baseURI value (still the defaultlocation.href).

SSR should probably just work, in the sense that it just removes it from the HTML, since it calls this.

Great. I was hoping that was the case, and tests seemed to confirm.

Should this be accompanied with a warning too since this is likely a bug and you should be setting the value to undefined or null if you want this behavior?

Seems reasonable to add a warning.

Seems odd to suggest "null orundefined" rather than"" when we treat them the same. (undefined seems at least as likely to be a potential mistake as""?)

How about:

Invalid value "" (empty string) for attribute%s. Usenull instead to indicate an empty value.

Based on my own testing (Chrome, Firefox, Edge) adding does not affect the document.baseURI value (still the default location.href).

What if there's another<base href="somethingelse" /> before it?

<basehref="something/else/"/><basehref=""/>

vs

<basehref="something/else/"/><base/>

What if there's another<base href="somethingelse" /> before it?

Same behavior. The empty one does not modify thedocument.baseURI value.

Edit Is it even valid to have multiple ones on the same page? Looks like the browser only pays attention to the first one, regardless.

The spec says:

There must be no more than onebase element per document.

What aboutclass attribute? Can it be added?

The warning should probably recommend not rendering the element at all as the primary recommendation and only null if that doesn’t work (i.e. if someone is too lazy to refactor).

I could see someone using<a href=“”> for a reload link or open this page in a new tab.

The warning should probably recommend not rendering the element at all as the primary recommendation and only null if that doesn’t work (i.e. if someone is too lazy to refactor).

Yeah, that sounds like kind of a long and confusing warning 😉 I can change the rec. to "don't render at all" though I guess.

I could see someone using<a href=“”> for a reload link or open this page in a new tab.

Yeah... that's the use case that seems most likely I guess. They could always use<a href=“#”> instead?

What aboutclass attribute? Can it be added?

@JeromeDeLeon No. This is something different.

I dunno. Is this warning better?

Invalid value "" (empty string) for attribute%s. This will be a no-op. Either do not render the element at all or usenull instead to indicate an empty value.

I'm wondering why it would be necessary to filter these?

@koenpunt to prevent unnecessary network requests, for example<img src=""/> would make a GET request to the current url

@bvaughn We were recently going through React warnings with@rachelnabors and she mentioned “no-op” is unfamiliar jargon. We’ll need to take a pass over them. But for now, I suggest:

An empty string ("") was passed to the%s attribute. This may cause the browser to download the whole page again over the network. To fix this, either do not render the element at all or pass null to%s instead of an empty string.

I appreciate the re-worked error message,@gaearon! These things are difficult to write 😅

That being said, I think the middle sentence of the one you mentioned is tooimg+src specific. Happy to use the first and third sentence though.

I think this makes sense for every case exceptmaybe<a href="">. (I'm still a little uncertain about that one.)

I think the middle sentence of the one you mentioned is too img+src specific

Maybe, but can we leave this wording forsrc then? The reason I'm asking is because it looks like we're just being pedantic. It's not obvious from the warning just how bad it is.

Sure.