{"action":"created","issue":{"url":"https://api.github.com/repos/zurb/foundation/issues/6196","labels_url":"https://api.github.com/repos/zurb/foundation/issues/6196/labels{/name}","comments_url":"https://api.github.com/repos/zurb/foundation/issues/6196/comments","events_url":"https://api.github.com/repos/zurb/foundation/issues/6196/events","html_url":"https://github.com/zurb/foundation/issues/6196","id":54470097,"number":6196,"title":"Foundation 6: HTML/Sass feedback","user":{"login":"gakimball","id":1142001,"avatar_url":"https://avatars.githubusercontent.com/u/1142001?v=3","gravatar_id":"","url":"https://api.github.com/users/gakimball","html_url":"https://github.com/gakimball","followers_url":"https://api.github.com/users/gakimball/followers","following_url":"https://api.github.com/users/gakimball/following{/other_user}","gists_url":"https://api.github.com/users/gakimball/gists{/gist_id}","starred_url":"https://api.github.com/users/gakimball/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gakimball/subscriptions","organizations_url":"https://api.github.com/users/gakimball/orgs","repos_url":"https://api.github.com/users/gakimball/repos","events_url":"https://api.github.com/users/gakimball/events{/privacy}","received_events_url":"https://api.github.com/users/gakimball/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/zurb/foundation/labels/Foundation+6","name":"Foundation 6","color":"008cba"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":22,"created_at":"2015-01-15T16:29:04Z","updated_at":"2015-01-20T23:49:05Z","closed_at":null,"body":"In this thread, we'd like you hear your feedback on how HTML, Sass, and CSS is written in Foundation for Sites.\r\n\r\n## Accessibility\r\n\r\nAbout half of the Foundation framework is currently keyboard/AT accessible. The goal for version 6 is 100%, so we're writing every component from the ground up with accessibility in mind. Of course, the mixin-based strucutre of our components means the user will have plenty of flexibility when it comes to HTML, but in our documentation we'll prescribe a recommended way of writing accessible markup.\r\n\r\n## Class style\r\n\r\nFoundation has never enforced a rigid style for writing and structuring CSS classes. In fact, our mixins allow you to use our components in BEM, SMACSS, et al. if you want. That being said, we have heard a few things repeatedly about how our CSS could be structured.\r\n\r\n### Tag vs. class selectors\r\n\r\nFoundation has an even mix of tag and class selectors. For some components, child elements are selected with tags (e.g., button groups, which use `.button-group` for the container and `.button-group > li` for children), while others are selected with classes (e.g., accordions, which use `.accordion` and `.accordion-navigation`). We've had some requests to shift to a more heavily class-based approach to writing styles.\r\n\r\nThere are a few benefits to a class-based approach, including:\r\n - Less specificity, due to a reduced need for nesting selectors. A common criticism of large frameworks is that it's difficult to override the default styles, and this is a step in that direction, if the user doesn't have to look up (or guess) the specificity of an element.\r\n - Less potential for collision between components. Users often run into trouble when trying to put one component inside of another. If the parent component includes descendant tag selectors, those will cascade down to the inner component, disrupting its styling.\r\n\r\nThe knocks against it would be:\r\n - More verbosity. A heavier (or entirely) class-based approach means longer class names in general. If a component is a list of items, writing `<li class=\"component-item\">` is a much bigger hassle than just `<li>`.\r\n - Not leveraging HTML semantics. \"Separate style from structure\" is a common mantra in CSS, which is why people avoid tag selectors, but tags exist for a reason. This is more important for Foundation 6, because it's going to be accessible from the ground up, and accessible markup can't just be a sea of `<div>`s.\r\n\r\nHeydon Pickering wrote [a great article](http://alistapart.com/article/axiomatic-css-and-lobotomized-owls) on A List Apart that briefly touches on this. Read the comments as well to see more thoughts of his.\r\n\r\n## The Settings File\r\n\r\nWhile Foundation for Apps was in development, we had a [discussion](https://github.com/zurb/foundation-apps/issues/23) on ways to make the settings file more useful. Right now Foundation (and most other customizable UI frameworks) dumps all of its settings into a single file as individual variables. There's no concept of namespacing or structure, other than the structure we enforce by how we write the code. It's served us well so far, and people don't really complain about it, but that doesn't mean there isn't a better way.\r\n\r\nFor example, to configure the Sass grid framework Susy, you create a `$susy` map which will override the default values.\r\n\r\n```scss\r\n$susy: (\r\n  columns: 12,\r\n  gutters: 1/4,\r\n  math: fluid,\r\n  output: float,\r\n  gutter-position: inside,\r\n);\r\n```\r\n\r\nThe problem with Foundation is that it has a good two dozen components, which makes your map a lot bigger:\r\n\r\n```scss\r\n$foundation: (\r\n  global: (\r\n    rem-base: 16px,\r\n    primary-color: #2ca9cd,\r\n  ),\r\n  grid: (\r\n    column-count: 12,\r\n    column-gutter: rem-calc(30),\r\n  ),\r\n);\r\n```\r\n\r\nWe could also streamline this by using individual variables for each component, and then merging them in the background.\r\n\r\n```\r\n$foundation-grid: (\r\n  column-count: 12,\r\n  column-gutter: rem-calc(30),\r\n);\r\n```\r\n\r\nThere's also an issue of access. Maps have been around for a while now in Sass, but I can tell you from experience there are plenty of more casual users of Sass who wouldn't know what they are, much less what an \"array\" is, since they aren't programmers. Maps feel like more of a Sass developer feature than a Sass user feature. Here are some ways variable access might work:\r\n\r\n```scss\r\n.component {\r\n  // The current way\r\n  color: $primary-color;\r\n\r\n  // With a pure map function\r\n  color: map-get($foundation-global, primary-color);\r\n\r\n  // With an abstraction function\r\n  color: foundation(global, primary-color);\r\n}\r\n```\r\n\r\nThe question is if that is any more or less difficult to access than a typical Sass variable. To be sure, the vast majority of Sass variables are never used by developers. It's mostly global styles like `$primary-color` that gets used a lot, so we don't want to confuse people too much with new syntax.\r\n\r\n**Here's what we'd like to hear:**\r\n  - Should we go all-in on verbose class names and shallow nesting, or keep things how they are with some slight improvements?\r\n  - Should we enforce a specific naming convention, like BEM or SMACSS? Traditionally, Foundation's class names haven't adhered to any strict guidelines.\r\n  - How can we improve the settings file?\r\n\r\n**[View our other discussion topics for Foundation 6 here.](https://github.com/zurb/foundation/labels/Foundation%206)**"},"comment":{"url":"https://api.github.com/repos/zurb/foundation/issues/comments/70758658","html_url":"https://github.com/zurb/foundation/issues/6196#issuecomment-70758658","issue_url":"https://api.github.com/repos/zurb/foundation/issues/6196","id":70758658,"user":{"login":"rafibomb","id":5652085,"avatar_url":"https://avatars.githubusercontent.com/u/5652085?v=3","gravatar_id":"","url":"https://api.github.com/users/rafibomb","html_url":"https://github.com/rafibomb","followers_url":"https://api.github.com/users/rafibomb/followers","following_url":"https://api.github.com/users/rafibomb/following{/other_user}","gists_url":"https://api.github.com/users/rafibomb/gists{/gist_id}","starred_url":"https://api.github.com/users/rafibomb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rafibomb/subscriptions","organizations_url":"https://api.github.com/users/rafibomb/orgs","repos_url":"https://api.github.com/users/rafibomb/repos","events_url":"https://api.github.com/users/rafibomb/events{/privacy}","received_events_url":"https://api.github.com/users/rafibomb/received_events","type":"User","site_admin":false},"created_at":"2015-01-20T23:49:04Z","updated_at":"2015-01-20T23:49:04Z","body":"@christoffervivian We actually discussed this here at ZURB too. We'll work to make the _settings.file less bloated. The challenge as always will be to deny PR's to add more."}}