The problem disappears if the browser window is sized below 1000px, a CSS breakpoint at which the page wraps and the "Sunday" link becomes clickable. So this seems like it has something to do with how the >1000px page is being drawn by Chrome.

Chrome keeps #leftwrapper (a floating <div> that contains a <table>) width to its original value (i.e. it doesn't add the specified "margin-left: 20%") so the padding of the right column partly obscures the left column and any clicks there hit this padding, thus nothing happens. Hit-testing per se is correct. The question remains if Chrome renders the layout correctly or Firefox (it extends #leftwrapper by the added margin so no overlapping occurs).

bhagerty@ Thanks for the Feedback.

Able to reproduce the issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 66.0.3356.0 and Stable 64.0.3282.186.

On navigating to the above link and hovering on Sunday, can observe that the pointer doesn't change to a hand icon.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..

The issue, as indicated in comment #4, is that the float: left div (#leftwrapper) has a margin that moves it over but that margin does not seem to be considered in positioning the float: left that comes after it (#rightwrapper).

Firefox does use the margin to influence position.

To me this is a layout issue. I think Firefox does the right thing.

Edge renders like Chrome. Safari renders like Chrome.

bhagerty@, What other browser behaves like Firefox?

I was told, but cannot verify, that Internet Explorer (unspecified version) renders like Firefox. I was also told that the link was clickable on various phone-based browsers, but that is probably because the window is under 1000px wide. The problem only arises when the page is wider than 1000px. 

The NextAction date has arrived: 2018-03-19

I don't understand the alert about the NextAction date. I don't have any other information.

Would you mind commenting on this Ian? Looks like we're matching Edge here.

(TL;DR intrinsic sizing with margins)

The rendering is unfortunately correct in this case.

DOM structure:

#leftwrapper (float: left)
  #leftcontent
    #daylinks (margin-left: 20%)
#rightcontent

As #leftwrapper is a float, we perform shrink to fit sizing. The intrinsic size calculation resolves the size of #daylinks margin-left to 0px. This sizes the float's width to approx 435px.

After we've determined the float's width via. shrink-to-fit, we perform layout where now the margin-left gets resolved to 87px or so, shifting the table over and making the sibling #rightcontent now "overlap" with #leftwrapper.

This works in Firefox as they have implemented a different algorithm to other engines when it comes to intrinsic-sizing where they attempt to be able to resolves the percentages against something that is non-zero.

Other engines are unlikely to implement FF's algorithm at the moment.

For the site if they are able to update their CSS would be to either change the margin-left to something not percentage based on #daylinks, e.g. 10vw, 80px, etc, or move the margin up to leftwrapper.

Thanks,
Ian