41–50 of 107 posts
People on this thread are saying it's the network speed thing, coming from china and all, but isn't this supposed to have downloaded all the js modules initially?
I just keep thinking "it would have been much faster and I wouldn't have to wait for these progress bars to finish if it were just a static page".
Why does a documentation need a progress bar anyway?
These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language. There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build…
At least on paper, it solved the issues you raise. Time will tell I suppose.
These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language. There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build…
I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/
This is the nicest collection of web UX components I've ever seen (better than bootstrap). All of the look and feel (responsiveness and delays) are just right. Animations are not too heavy-handed and add to the experience. Is this by Stripe? The components look just like their dashboard.
These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language. There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build…
Theming is a difficult problem. Each component has a couple of visual properties which may depend on the state (hover, focus, error, internal variable). Having a separate variable for each visual property would be a nightmare. I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/
You can separate component Style into - BASE + States classes.
classnames[0] can used to use multiple classes, the classes can be activated using component state. This provides a viable solution for Structure & Style.
I tried using these components in Buttercup (our open source password vault https://github.com/buttercup-pw/buttercup ), but immediately regretted it. It's impossible to theme, the less/css files are dirty and not extensible, defaults mess with your current style, etc. At first look, it looks promising and great but not when you actually try to use it.
Earlier quoted context omitted.
Theming is a difficult problem. Each component has a couple of visual properties which may depend on the state (hover, focus, error, internal variable). Having a separate variable for each visual property would be a nightmare. I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/
Today, I was thinking about this problem. You can separate component Style into - BASE + States classes. classnames[0] can used to use multiple classes, the classes can be activated using component state. This provides a viable solution for Structure & Style. [0] https://github.com/JedWatson/classnames
What you want from theming is a global skin. You want users of your component library to be able to say "I want all of my buttons to be red" without having to wrap the component or pass a prop to every component. (simplified example)
Doing so just with class names is very very hard. It's what we've done for ElementalUI (together with Less), but it just doesn't work – it's a pita for users!
These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language. There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build…
Theming is on of the big reasons we saw the need to make styled-components[0] (new lib to style React apps and component libraries) I'm one of the maintainers of ElementalUI, and Glen Maddern, the styled-components co-creator, one of the creators of CSS Modules. One of the biggest downsides of CSS Modules (and, by extension, every other styles in JavaScript library right now) is that theming is simply impossible. Bui…
[1]: https://github.com/styled-components/styled-components/issue...
Earlier quoted context omitted.
Theming is a difficult problem. Each component has a couple of visual properties which may depend on the state (hover, focus, error, internal variable). Having a separate variable for each visual property would be a nightmare. I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/
Today, I was thinking about this problem. You can separate component Style into - BASE + States classes. classnames[0] can used to use multiple classes, the classes can be activated using component state. This provides a viable solution for Structure & Style. [0] https://github.com/JedWatson/classnames