github
local-based defaults for local-time attributes?
I've overcome some earlier difficulties by changing my example usage be like the example HTML. I now have:
<body>
<script type="module" src="https://unpkg.com/@github/time-elements@latest?module"></script>
<h2>Maintenance Window</h2>
<p>The system <i>may</i> be down for 2 hours starting
<local-time datetime="2022-01-01T00:12:00.000Z"
weekday="short" year="numeric" month="short" day="numeric">2022-01-01T00:12:00.000Z</local-time>
</body>
But the displayed result (in my Pacific time browser) says:
The system may be down for 2 hours starting Sat Jan 1, 2022
Using a local-time element, I would expect that formatting including the time of day would be the default. It also seems to me that needing to specify attributes like day="numeric" adds a lot of overhead to using this web component, but if I leave the attribute off, no day-of-month gets shown in the formatted result. It seems like there should be default values (preferably based on locale) for these attributes (perhaps with the exception of datetime.)
As to the datetime attribute, it seems like the body text would be a reasonable default, so that I could simply say:
<p>The system <i>may</i> be down for 2 hours starting <local-time>2022-01-01T00:12:00.000Z</local-time>
Am I missing some relevant point(s) here?
Hey @BurtHarris thanks for the issue.
Specific to the datetime attribute; the attribute is observed for changes, and we alter the inner text of the element to reflect the localised version of that. If we alter the API such that it reads from the inner text, whilst listening for mutations of the the inner text, it would result in an infinite loop. Hopefully this gives some insight into why we have that attribute.
@keithamus: Sure, I understand how the attribute can be useful separate from the body. But I think you mean that the datetime property is observed, rather than the datetime attribute. I think the attribute simply provides an overridable default for the property, but that they are distinct.
I'm suggesting that IIF the datetime property is falsey, the body should be parsed and considered as a default. Only then (and if the parse works) change the property value. That should make generally a one-time code. I don't think that would interfere with an observer or other JS-based manipulation.
It seems like there could be related ways of addressing making an explicit datetime attribute optional. I'm out of my depth here, yet I remember using .innerHtml rather than .innerText to alter the body in the distant past. There's also something called shadow DOM (which I have no expertise on) that seems related.
Aside @keithamus: I see a "staff" label on you. Does that mean you now work for Microsoft now?
I'm retired now, but spent well over a decade at MSFT, most of it in Redmond.
But I think you mean that the datetime property is observed, rather than the datetime attribute.
I mean the attribute. You can call setAttibute('datetime', myNewDateString) and the .textContent of the element will be updated to reflect the new datetime.
I'm suggesting that IIF the datetime property is falsey, the body should be parsed and considered as a default. I don't think that would interfere with an observer or other JS-based manipulation.
That's definitely doable; however it's a very surprising behaviour, and not something that existing HTML elements do. We try to keep our elements behaving indistinguishably from "native" elements, and so we map to attributes the simple ways that existing elements do.
I think the attribute simply provides an overridable default for the property, but that they are distinct.
Just to be clear, setting .datetime = (per my understanding of the nomenclature this is the "property) on the element instance won't do anything. The only way to set datetime is via the attribute (.setAttribute('datetime')).
There's also something called shadow DOM (which I have no expertise on) that seems related.
The ShadowDOM won't be able to help us achieve this, should we want to.
I see a "staff" label on you. Does that mean you now work for Microsoft now?
Depends on who you ask I guess :wink:. I say I work for GitHub.
I'm retired now, but spent well over a decade at MSFT, most of it in Redmond.
I've yet to set foot in Washington, let alone Redmond :laughing:. I've spent a few hours in GitHub's HQ city of San Francisco, but most of my time is spent in the UK :gb:.
If you'd like to try the new release I believe this issue is likely fixed. If not let me know and we can revisit it.