carbon
carbon copied to clipboard
Sage
DateInput Custom Calendar Header via pickerProps isn't accessible
Current behaviour
When specifying a custom component for the DateInput calendar via pickerProps, and the captionElement key (to select a Year and Month etc.) the custom header that renders is inaccessible unless you manually set its styling position to "relative". Without manually intervening (setting the position), the component (and its children) don't react to any interaction because it is rendered behind the DateInput calendar itself). Trying to interact sets focus on the calendar as a whole (the ancestor).
Expected behaviour
The implementer/consumer shouldn't have to manually specify the components position relative to the calendar. Ideally this should happen automatically because it is a shared/common concern with the same solution each time. The controls to increment and decrement months should still function as before.
CodeSandbox or Storybook URL
https://codesandbox.io/s/ecstatic-benz-0hzids?file=/src/index.js
JIRA Ticket (Sage Only)
No response
Suggested Solution
Render the provided custom header component (specified in pickerProps via the captionElement key) within a static parent element, styled to have its position set to relative (position: relative). That way each consumer doesn't have to remember to do so.
Carbon Version
107.1.7
Design Tokens Version
2.30.0
What browsers are you seeing the problem on?
Chrome
What Operating System are you seeing the problem on?
Windows
Anything else we should know?
Link to Slack Chat: https://sageone.slack.com/archives/C0D6DD3N2/p1655807687663009
Confidentiality
- [X] I confirm there is no confidential or commercially sensitive information included.
@ljemmo I suppose the question here is does DS want developers to be able to override the controls provided in this way? Or should we provide options through Carbon?
@nicktitchmarsh Looking at the code sandbox example, this is definitely a future enhancement that we would need to review and consider more deeply. I've seen other calendars with similar functionality and it's certainly an enhancement that i think we should explore.
Once reviewed and specs supplied, then I believe we should add carbon props to allow optional dropdowns for year and month (probably stylised in a more subtle way than in the sandbox). I don't think this should be an override.
@ingridzillinger please can you help me document this as a future enhancement on our backlog.
@ljemmo @ingridzillinger , please could you comment the DSY ticket number here so we can track that work?
Hi @ljemmo @ingridzillinger, do you have DSY ticket for this work in place? Or are there still some decisions you need to make?
@nicktitchmarsh and @Parsium - The ticket is DSY-1739. I have a meeting with martin and ashley next week to discuss a proposed solution further.
@ljemmo , what was the outcome of that ticket? Do we have some recommendations?
Ticket DSY-2423 has been cancelled and done in DSY-2581 which has been completed. @clairedenning has a ticket been created on our board for this work or do we need to do that? Thanks.
@sianford we are lumping together all our calendar improvement tasks into 2 pairing tickets:
DSY-2981 DSY-2267
I'm going to close this as the DS have issued new designs that mean this will be baked into Carbon when we align. You can set the container for the calendar header to have position relative as a workaround. If this doesn't address the issue please re-open