This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/ Multipage: https://html.spec.whatwg.org/multipage/#sandboxCookies Complete: https://html.spec.whatwg.org/#sandboxCookies Referrer: Comment: Value of lastModified probably shouldn't change during the lifetime of the document Posted from: 98.110.194.132 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:37.0) Gecko/20100101 Firefox/37.0
In particular, the "current time" thing should be a snapshot taken at a well-defined point in document setup instead of having a lastModified that changes every time you access it. In my opinion, of course.
Why?
Why which? Why should it not change? Conceptually, lastModified is when the HTML the browser is rendering was last modified. This can obviously be sometime before the browser received the HTML, but, still conceptually, it can't be _after_ the browser has received it, because it's already received it. So let me turn this around. Why should this value possibly change during the document lifetime? That's completely nonsensical behavior.
(In reply to Boris Zbarsky from comment #3) > Why which? Why should it not change? Right. > Conceptually, lastModified is when the HTML the browser is rendering was > last modified. This can obviously be sometime before the browser received > the HTML, but, still conceptually, it can't be _after_ the browser has > received it, because it's already received it. > > So let me turn this around. Why should this value possibly change during > the document lifetime? That's completely nonsensical behavior. It's what the majority of implementations do (WebKit/Blink/IE11/Presto). So it's a shorter path to interop for Gecko to change to match everyone else. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3363
That's fair, but it seems to me that converging on nonsensical behavior is not a success story, even if it achieves interop. If we can't achieve interop in any other way, then maybe it's worth it. But it's very definitely a tradeoff, and I'm not convinced we can't achieve interop in any other way.
lastModified is crazy town anyway. I would just pretend it wasn't there.
I would totally love to do that, but people are insisting on writing test suites that test its behavior.
(In reply to Boris Zbarsky from comment #5) > That's fair, but it seems to me that converging on nonsensical behavior is > not a success story, even if it achieves interop. In this case I think both behaviors are basically not useful. The author wants the date when the document was actually last modified, not the current date and not the date when the document was loaded (nor the date when the server generated the page and put that in Last-Modified). So which we pick doesn't matter as far as usefulness of the API goes.
What do browsers do today, with respect to the issue in this bug?
Looking at the test in comment 4, it seems like the spec matches the majority of implementations already. I see no value in changing the spec here.
OK. I'm not going to waste more time on this; I guess we'll just update to the pointless behavior everyone else picked, yet again...