Closed ajb closed 9 years ago
jrubenoff
commented
9 years ago This is a really great start... thanks for doing this!
We definitely want to allow for multiple "code preview blocks" per headline. As the code blocks get longer, it becomes harder to connect the component on the left column to the code on the right:
This is a bit better:
jrubenoff
commented
9 years ago Navbar looks good, although I'm not sure we need the user dropdown / avatar on every site.
ajb
commented
9 years ago We definitely want to allow for multiple "code preview blocks" per headline. As the code blocks get longer, it becomes harder to connect the component on the left column to the code on the right:
Yeah, definitely. I don't intend this to be anywhere near "final" on the style guide side of things, I just want it to be functional enough for people to use.
Navbar looks good, although I'm not sure we need the user dropdown / avatar on every site.
Agree.
I'll go ahead and merge this, only other question: would it be a lot of effort to refactor the respondent_view to be based on dvl/core? (Remember that dvl/core is now different from dvl/app, and only includes the base styles.) IMO it would really make a different in terms of maintainability and interoperability if respondent view used dvl/core, and then just overrode anything it needed to change. If this sounds like too much effort, I can probably accept that for now too.
jrubenoff
commented
9 years ago Yeah, that probably makes sense. I initially wanted it as separate because it will require many, many overrides, so it'll be tougher to maintain. But it definitely makes the most sense for interoperability. Would it make sense to tackle that right after finishing the feature?
ajb
commented
9 years ago Cool, glad we agree. I'd say that we should do it sooner rather than later, but I'll leave it up to you.
On Fri, Feb 27, 2015 at 12:09 PM, Josh Rubenoff notifications@github.com wrote:
Yeah, that probably makes sense. I initially wanted it as separate because it will require many, many overrides, so it'll be tougher to maintain. But it definitely makes the most sense for interoperability. Would it make sense to tackle that right after finishing the feature?
— Reply to this email directly or view it on GitHub https://github.com/dobtco/dvl-core/pull/39#issuecomment-76430748.
Adam Becker (951) 9-BECKER @AdamJacobBecker
Sorry, I massively fucked up by merging the PR by mistake. I cleaned everything up, though. Pasting in my comment from before:
@jrubenoff: I don't think this needs a ton of feedback, but I wanted to run it by you first. It should go without saying, but this PR doesn't mean that I'm going to change any existing apps without approval, too -- e.g. I'm not going to modify
dobtco/splashjust because I've made some changes here.Anyway, checkout this branch and run
script/serverto see the updated docs site (still a WIP). Not much has changed (we should be able to update inside of Screendoor without any side-effects), but I've tweaked the structure of this repo a little bit and I'm pretty happy with where it turned out:dvl/coreis a manifest for thebase stylesthat we'll need for every project. These styles are designed to be overridden with SCSS variables -- see here for an exampledvl/appcontains a bunch more common "app" components, like modals, tooltips, dropdowns, progress bars, etc...@mixins, and I've added some@pushmixins since you had them in your grid. Our grids work a little differently, but the existing one is tried and true IMO.The goal with all of this was to make it really clear which styles are "app" styles and which styles are necessary for default elements to "look right".
Remember how I thought we had "app" styles and "splash" styles? Turns out they can both inherit from the same base, as long as that base is overridable.
LMK if you have questions.
And also, check out the navbar component -- is it good enough to start implementing in help.dobt.co, blog.dobt.co, etc? Do you want to tweak it?