-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(react-core/card): added PatternFly 4 Card Component #458
Conversation
Pull Request Test Coverage Report for Build 1687
💛 - Coveralls |
Deploy preview for patternfly-react ready! Built with commit 860aeca |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
no issues here, just need to rebase the commit and remove the |
The only potential concern I have is about the default html elements defined. I realize that a request was made in PF4 core to default cards to
Does anyone have thoughts or suggestions on that? I'm torn between using these defaults, which are likely to be the right elements to use for most cases, versus requiring consumers to explicitly set what they want these elements to be. My concern is that if we make assumptions and set defaults, and the consumer isn't fully aware, then we're partly responsible for bad semantics. Is it possible to switch the default from |
This comment may be out of scope for this PR, but when I look at the preview, it looks like I'm only seeing details about the parent Card component, and not the children components being used, like CardBody and CardHeader. Would you expect all components that are used to create the example to be represented in the Props section? |
@jgiardino What is the risk of header/footer being used outside of a sectioning element? I can't find that in the docs it just mentions to not do it. Is it treated like a |
5df1cfb
to
82325a0
Compare
@dmiller9911 My best guess is that the first occurrence of I'm on the fence for this one. I'm guessing this situation could come up again for other components. I added this as an agenda topic for our weekly a11y review on Thursdays. I'm also copying @andresgalante on this one in case he has any suggestions before then. While I'm all for promoting the use of semantically correct elements, I don't like making assumptions about the consumer's use case. Something seems off about requiring the consumer to 1.) understand that default elements are defined, and 2.) explicitly define generic elements if the default ones aren't appropriate for their use case. One possible solution is to use a default |
@jgiardino That seems like a good middle ground. |
affects: @patternfly/react-core, @patternfly/react-docs Added the Card Component from here: https://pf-next.com/components/Card/examples/ ISSUES CLOSED: patternfly#386
82325a0
to
860aeca
Compare
@jgiardino mind taking a look and giving the thumbs up for this? The extra component docs will be coming soon with a different PR. Most likely early next week. Right now Card defaults to article. Header and Footer default to divs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
affects: @patternfly/react-core, @patternfly/react-docs
Added the Card Component from here: https://pf-next.com/components/Card/examples/
ISSUES CLOSED: #386