{"action":"created","issue":{"url":"https://api.github.com/repos/salsita/inStyle/issues/1","labels_url":"https://api.github.com/repos/salsita/inStyle/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/salsita/inStyle/issues/1/comments","events_url":"https://api.github.com/repos/salsita/inStyle/issues/1/events","html_url":"https://github.com/salsita/inStyle/issues/1","id":110657376,"number":1,"title":"Ch(s)ili outsider's questions","user":{"login":"caryfuk","id":5256550,"avatar_url":"https://avatars.githubusercontent.com/u/5256550?v=3","gravatar_id":"","url":"https://api.github.com/users/caryfuk","html_url":"https://github.com/caryfuk","followers_url":"https://api.github.com/users/caryfuk/followers","following_url":"https://api.github.com/users/caryfuk/following{/other_user}","gists_url":"https://api.github.com/users/caryfuk/gists{/gist_id}","starred_url":"https://api.github.com/users/caryfuk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/caryfuk/subscriptions","organizations_url":"https://api.github.com/users/caryfuk/orgs","repos_url":"https://api.github.com/users/caryfuk/repos","events_url":"https://api.github.com/users/caryfuk/events{/privacy}","received_events_url":"https://api.github.com/users/caryfuk/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-10-09T13:16:46Z","updated_at":"2016-01-13T11:26:31Z","closed_at":null,"body":" 1. Why not use libsass? Are we depending on a functionality only present in sass gem? Probably yes, rhetorical question.\r\n 2. Would be better to use css reset because it's agnostic about styling preferences.\r\n 3. Why that?\r\n```Sass\r\n   $documentMinWidth:  320px\r\n   $documentSafeWidth: 960px\r\n```\r\n 4. Why mapping new keywords on existing flexbox keywords? *I mean I don't like confusing flexbox syntax much, but isn't this making things even more difficult to read and understand?*\r\n```Sass\r\n=distribute($args: (), $dir: row)\r\n  $flexMap: (left: flex-start, right: flex-end, top: flex-start, bottom: flex-end, center: center)\r\n  @if length($args) == 2\r\n    display: flex\r\n    align-items: map-get($flexMap, nth($args, 1)) or nth($args, 1)\r\n    justify-content: map-get($flexMap, nth($args, 2)) or nth($args, 2)\r\n    flex-direction: $dir\r\n  @else\r\n    @warn 'Invalid length of arguments \\'#{length($args)}\\' for distribute() in chain \\'#{&}\\'.'\r\n```\r\n 5. Generally, why so much abstraction? It would make sense to me in a case when I'm building something specific and from it's specific nature, I'm repeatedly using some subset of css or repeatedly building some similar constructs out of it. But I think that can't be the thing, because it's supposed to be universal right? So it seems like, we're trying to create another \r\nis the case, there should be some strong benefit for the developer to justify learning how \r\nabstraction layer works.\r\n 6. Definitions like unstyled-list and unstyled-button are probably there to allow me reset some previously set styles, but why would I do that? I think it might be encouraging the developer to just don't care about structure and reset stuff. But it's mixin so it's not poluting css if it's never used.\r\n 7. Animate scss is huge and probably only a fraction of it is going to be really used, so it would make sense to define everything as mixins insteadm so that parts that are never used don't appear in generated css.\r\n 8. Wouldn't this:\r\n```Sass\r\n@function em($px, $scale: 62.5%, $unit: 'em')\r\n@return unquote(__stripUnit($px)/(.16*__stripUnit($scale)) + $unit)\r\n\r\n@function rem($px, $scale: 62.5%)\r\n@return em($px, $scale, 'rem')\r\n```\r\nbehave unexpectedly if you set different font-size on body than 62.5%? and why that .16 magic constant? What if you set different font-size on body?\r\n\r\nAlso, supposed that:\r\n```Sass\r\n   // 1rem = 10px\r\n   $fontM: rem(16)\r\n```\r\nAnd that rem() just takes anything and makes rem out of it, I would expect fontM to be 160px, which would not be the case. I think the whole concept of using some units and converting them to some different units using some magic constants just makes everything a lot more difficult to understand. To be honest, I have a real difficulty understanding how the font size of rem(16) is going to render. What is the benefit of all this? I believe there must be some - it's just that I don't currently see it.\r\n"},"comment":{"url":"https://api.github.com/repos/salsita/inStyle/issues/comments/171260153","html_url":"https://github.com/salsita/inStyle/issues/1#issuecomment-171260153","issue_url":"https://api.github.com/repos/salsita/inStyle/issues/1","id":171260153,"user":{"login":"caryfuk","id":5256550,"avatar_url":"https://avatars.githubusercontent.com/u/5256550?v=3","gravatar_id":"","url":"https://api.github.com/users/caryfuk","html_url":"https://github.com/caryfuk","followers_url":"https://api.github.com/users/caryfuk/followers","following_url":"https://api.github.com/users/caryfuk/following{/other_user}","gists_url":"https://api.github.com/users/caryfuk/gists{/gist_id}","starred_url":"https://api.github.com/users/caryfuk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/caryfuk/subscriptions","organizations_url":"https://api.github.com/users/caryfuk/orgs","repos_url":"https://api.github.com/users/caryfuk/repos","events_url":"https://api.github.com/users/caryfuk/events{/privacy}","received_events_url":"https://api.github.com/users/caryfuk/received_events","type":"User","site_admin":false},"created_at":"2016-01-13T11:26:31Z","updated_at":"2016-01-13T11:26:31Z","body":"Hey @filipnaumovic I just checked the new version and this **+in syntax looks clean and useful to me**. I can imagine using it and loving it if I styled my components in a way you described. **It clearly is nicer than doing it with without your magic +in syntax.**\r\n\r\nPlease beware, **my comment is not related to how it's implemented. I rather try to explain why I don't find your solution of the problem useful in my use-case and why I think I'm better off not even needing to solve it.** Let me explain.\r\n\r\nInstead of redefining how the component should behave in different contexts, I always try to create a component without adding any context based exceptions to it. When I create a new context, let say header, and I want to make my link look differently within it, I rather define the exception inside the header and not in the original component. **The benefit I see in this reverse approach is that it keeps my components independent on the context.** I want to keep my components reusable and if I need some exception in a header, I rather define it in the header, because I look at it as it's header related exception. The header might not even be there and because of this, I don't want to define any header related styles inside my reusable component.\r\n\r\n**You could argue that it might be the other way round - like the header would be the component you don't want to pollute by some exceptions. But you still gotta define the exceptions somewhere and I think I'm better off not mixing bottom->up approach with top->down approach.** It allows me to never worry about how my element is going to be rendered no matter where I use it and also it allows me to easily reuse my components in different apps without a necessity of checking whether they contain some exceptions I don't want.\r\n\r\nAs I said, if I needed to define the styles in the opposite direction for some reason - just like you do it, I really think your way of doing it would be superior."}}