-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add classes to style h2 tags like an h1 tag #100
Comments
Notes from Logan about HeadingsSpoke with @loganmccaul offline to get a better sense of the problem he's raising. (Paraphrasing here. Correct me if I'm wrong) FEDs like Logan are at odds with the following:
☝️ None of these really match up and in Logan's case, for him to do his work is more complicated than strictly following Carbon Design System vs Design Comps vs Accessibility. According WebAIM on Semantic Structure,
For users who rely on screen readers, these heading tags are going to create a navigational hierarchy that will help them navigate the UI they're using. Also, see W3 on Headings. Example from BluemixThere should only be one Since Carbon Design System says TL;DR: Here's what I think we should do:
|
Yes, we should definitely talk about this. I don't think I'm quite understanding all the problems and requirements just from this issue. To be honest I don't really understand how heading tags work or should properly work, especially across pages/areas of the product.
We did a smart default in-case no hierarchy is applied but from a system standpoint we do not define global Carbon specifically doesn't define a heading scale because the hierarchy of each page/section could be different. A designer should be picking from the carbon typescale to define their own heading tags/scale. Also cc: @iangfleming since he helped with the type scale and defaults |
I can set up a meeting with all of us. It was helpful for me to hear from Logan in-person about why this issue was raised originally.
Yes, I believe this is the same reasoning @iangfleming settled on when we helped to define the typescale. For example, we have our h1 {
@include reset;
@include font-size('32');
@include line-height('heading');
@include letter-spacing;
} There isn't really an easy way for the user to reuse this style without doing one of the following:
I think the solution is to offer a CSS class like @loganmccaul originally suggested. h1,
.bx--heading--1 {
@include reset;
@include font-size('32');
@include line-height('heading');
@include letter-spacing;
} Providing a class lets users use the class in their HTML or SCSS to reliably use our <h2 class="bx--heading-1">I look like an h1 but I'm really an h2</h2> |
* add tests to numberInput, refactor * refactor a bit more * switch from children to label prop * more refactoring * refactor handleChange, refs carbon-design-system#102 * remove onKeyDown handler, move {...other} to input * make sure onChange is fired when arrow value is clicked * remove default label * remove default min/max, fix logic to allow no min/max * refactor click logic, add more tests * add storybook info
A recent change used the React PropTypes property instead of the React one. Fixes carbon-design-system#99
Currently, the heading tags (
h1 ... h6
) are being used to style a page to be visually correct without regard to html structure, causing a situation where the html structure is broken.If new classes, such as
bx--heading--1
, were added ah2
tag could be style like anh1
tag, but remain anh2
element allowing for proper HTML structure.The text was updated successfully, but these errors were encountered: