Foundation-sites: Why `<hr/>` max width is 75 rem instead of 100% width
IamManchanda
All 8 comments
Width of <hr> is generated from $hr-width -> $global-width -> rem-calc(1200px) by default. This is to ensure the <hr> is displayed correctly when between grids. However, we may should remove this max width and rely on a "container" instead.
ncoden
on 5 Jan 2018
👎1
👍1
Only my opinion, but...
Please do not style base HTML tags for any other reason than _providing consistency between browsers and devices_.
The
<hr>tag, like many others, now has a _semantic meaning_. A responsible and mature frontend framework will avoid mixing styles with semantics. Allow those who manage content and context to do so without worrying about the styling that's applied.If you (Zurb Adopter) want to add your own personal style to
<hr>- that's great. Please do. For your site, for your project, for your branding standards, for your content authors who've been trained - this is fine.If you (Zurb) absolutely must style this element due to consistency reasons, non-breaking changes, etc - please scope it out. You mentioned that the
<hr>tag needs these properties when displayed correctly between grids. Why did you not go with an adjacent sibling selector like.row + hr?
markadrake
on 8 Jan 2018
@markadrake I fully agree with you.
I simply explained the reasons why <hr> _currently has_ these styles. But if we talk about what I think we _should_ do, i'll promote a .hr class independant from to the <hr> tag. A standalone component without side-effects on the semantic of the document.
This is the idea behind "However, we may should remove this max width and rely on a "container" instead": remove the max-width (and others properties) from <hr> and rely on dedicated components (.container or .hr) to get the same render.
The best would be something like:
```html
ncoden
on 8 Jan 2018
👍2
Please do not style base HTML tags for any other reason than providing consistency between browsers and devices.
Why not? The only problem is that it is generally applied and not a component with a better scope like @ncoden writes.
DanielRuf
on 11 Jan 2018
The only problem is that it is generally applied and not a component with a better scope
This is the problem ;) <hr> can be used in a lot of complex contexts where we do not expect it to have the Foundation design.
Look at how many issues reported to Foundation and others frameworks are _unexpected CSS properties_.
ncoden
on 11 Jan 2018
Look at how many issues reported to Foundation and others frameworks are unexpected CSS properties.
Ok so Foundation Sites is too opinionated in some places atm and this should be prevented in upcoming releases?
DanielRuf
on 11 Jan 2018
If you mean opinionated yes, it is.
ncoden
on 11 Jan 2018
I don't think there is anything to resolve here. Let's keep this in mind for V7.
JeremyEnglert
on 27 Jan 2018
Was this page helpful?
0 / 5 - 0 ratings
Related issues
Mojtaba-Reyhani
·
3Comments
foodgy
·
3Comments
lspoor
·
3Comments
BicanMarianValeriu
·
3Comments
curtisblack2004
·
3Comments
Most helpful comment
@markadrake I fully agree with you.
I simply explained the reasons why
<hr>_currently has_ these styles. But if we talk about what I think we _should_ do, i'll promote a.hrclass independant from to the<hr>tag. A standalone component without side-effects on the semantic of the document.This is the idea behind "However, we may should remove this max width and rely on a "container" instead": remove the
max-width(and others properties) from<hr>and rely on dedicated components (.containeror.hr) to get the same render.The best would be something like:
```html