Return to Answer

The reason this is happening is because the slds-table class is applying a padding to the td elements within the lightning input date selector.

The exact style definition of this is

.slds-table td,.slds-table th{ // column 414975 in minified css
    padding:.25rem .5rem; // This .5rem is causing your problem
    white-space:nowrap;
    position:relative
}

This style was never meant to be applied to the date picker which results in the cells within being too large to fit in the container.

This is the style that should be applied but is being overridden:

.slds-datepicker td{ // column 253420 in minified css
    padding:.25rem;
    text-align:center;
    font-size:.75rem
 }

You can become more familiar with the CSS order of precedence here.

The slds-datepicker style appears 161,555 characters earlier in the code then the slds-table style which is what causes it to lose precedence.

This has other impacts that you didn't point out. For instance, when you mouse over the date picker, the rows of the inner table are highlighted grey which is also not supposed to happen.

Unfortunately, since we can't put a <style> tag in a template and we don't have access to the inner workings of the component and CSS doesn't have the ability to use inline styles to modify child elements, The fix would be to stop using the slds-table class and apply your styles manually.

I would argue this could be considered a bug/unintended behavior and you may be able to report it to SF for a fix.

The reason this is happening is because the slds-table class is applying a padding to the td elements within the lightning input date selector.

The exact style definition of this is

.slds-table td,.slds-table th{ // column 414975 in minified css
    padding:.25rem .5rem; // This .5rem is causing your problem
    white-space:nowrap;
    position:relative
}

This style was never meant to be applied to the date picker which results in the cells within being too large to fit in the container.

This is the style that should be applied but is being overridden:

.slds-datepicker td{ // column 253420 in minified css
    padding:.25rem;
    text-align:center;
    font-size:.75rem
 }

You can become more familiar with the CSS order of precedence here.

The slds-datepicker style appears 161,555 characters earlier in the code then the slds-table style which is what causes it to lose precedence.

This has other impacts that you didn't point out. For instance, when you mouse over the date picker, the rows of the inner table are highlighted grey and the header cells have a grey background, neither of which are supposed to happen.

Unfortunately, since we can't put a <style> tag in a template and we don't have access to the inner workings of the component and CSS doesn't have the ability to use inline styles to modify child elements, The fix would be to stop using the slds-table class and apply your styles manually.

I would argue this could be considered a bug/unintended behavior and you may be able to report it to SF for a fix.

The reason this is happening is because the slds-table class is applying a padding to the td elements within the lightning input date selector.

The exact style definition of this is

.slds-table td,.slds-table th{ // column 414975 in minified css
    padding:.25rem .5rem; // This .5rem is causing your problem
    white-space:nowrap;
    position:relative
}

This style was never meant to be applied to the date picker which results in the cells within being too large to fit in the container.

This is the style that should be applied but is being overridden:

.slds-datepicker td{ // column 253420 in minified css
    padding:.25rem;
    text-align:center;
    font-size:.75rem
 }

You can become more familiar with the CSS order of precedence here.

The slds-datepicker style appears 161,555 characters earlier in the code then the slds-table style which is what causes it to lose precedence.

This has other impacts that you didn't point out. For instance, when you mouse over the date picker, the rows of the inner table are highlighted grey which is also not supposed to happen.

The fix would be to stop using the slds-table class and apply your styles manually.

I would argue this could be considered a bug/unintended behavior and you may be able to report it to SF for a fix.

The reason this is happening is because the slds-table class is applying a padding to the td elements within the lightning input date selector.

The exact style definition of this is

.slds-table td,.slds-table th{ // column 414975 in minified css
    padding:.25rem .5rem; // This .5rem is causing your problem
    white-space:nowrap;
    position:relative
}

This style was never meant to be applied to the date picker which results in the cells within being too large to fit in the container.

This is the style that should be applied but is being overridden:

.slds-datepicker td{ // column 253420 in minified css
    padding:.25rem;
    text-align:center;
    font-size:.75rem
 }

You can become more familiar with the CSS order of precedence here.

The slds-datepicker style appears 161,555 characters earlier in the code then the slds-table style which is what causes it to lose precedence.

This has other impacts that you didn't point out. For instance, when you mouse over the date picker, the rows of the inner table are highlighted grey which is also not supposed to happen.

Unfortunately, since we can't put a <style> tag in a template and we don't have access to the inner workings of the component and CSS doesn't have the ability to use inline styles to modify child elements, The fix would be to stop using the slds-table class and apply your styles manually.

I would argue this could be considered a bug/unintended behavior and you may be able to report it to SF for a fix.

The reason this is happening is because the slds-table class is applying a padding to the td elements within the lightning input date selector.

The exact style definition of this is

.slds-table td,.slds-table th{
    padding:.25rem .5rem; // This .5rem is causing your problem
    white-space:nowrap;
    position:relative
}

This style was never meant to be applied to the date picker which results in the cells within being too large to fit in the container.

This is the style that should be applied but is being overridden:

.slds-datepicker td{
    padding:.25rem;
    text-align:center;
    font-size:.75rem
 }

You can become more familiar with the CSS order of precedence here.

My best guess is that the slds-datepicker style appears earlier in the code then the slds-table style which is what causes it to lose precedence.

This has other impacts that you didn't point out. For instance, when you mouse over the date picker, the rows of the inner table are highlighted grey which is also not supposed to happen.

The fix would be to stop using the class and apply your styles manually.

The reason this is happening is because the slds-table class is applying a padding to the td elements within the lightning input date selector.

The exact style definition of this is

.slds-table td,.slds-table th{ // column 414975 in minified css
    padding:.25rem .5rem; // This .5rem is causing your problem
    white-space:nowrap;
    position:relative
}

This style was never meant to be applied to the date picker which results in the cells within being too large to fit in the container.

This is the style that should be applied but is being overridden:

.slds-datepicker td{ // column 253420 in minified css
    padding:.25rem;
    text-align:center;
    font-size:.75rem
 }

You can become more familiar with the CSS order of precedence here.

The slds-datepicker style appears 161,555 characters earlier in the code then the slds-table style which is what causes it to lose precedence.

This has other impacts that you didn't point out. For instance, when you mouse over the date picker, the rows of the inner table are highlighted grey which is also not supposed to happen.

The fix would be to stop using the slds-table class and apply your styles manually.

I would argue this could be considered a bug/unintended behavior and you may be able to report it to SF for a fix.