|
Gmaz posted:You might want to check out: https://www.toptal.com/companies/apply Cool thanks, that seems a little more straightforward than freelancer or guru. e: Looks like you have to apply (as a hiring business) to even contact the developers on that site. There's a lot of money floating around this project but not like SV $$$ startup millions - hope we make the cut :P Rubies fucked around with this message at 19:30 on Jan 17, 2015 |
# ? Jan 17, 2015 19:22 |
|
|
# ? May 14, 2024 11:56 |
|
I need to find a good method for printing my "reports" page. I only want certain DIV elements (incl chart contents etc.) to print and not the site header, filtering menus etc. What's a pretty good unobtrusive way to do this? Current libs in use are JQuery and D3.js for charts so I need it to work with the javascript generated charts/diagrams. Thanks! EDIT: Bonus if I can also wrap up this printout into a PDF for user downloading as well.
|
# ? Jan 18, 2015 04:35 |
|
Just add a print stylesheet and set display: none for everything you don't want to print. If you need to bring up the print dialog through javascript, you just do window.print();.
|
# ? Jan 18, 2015 04:51 |
|
So I have to programmatically set display none to everything on my page? Then set it back after printing? Whats a print stylesheet? Is that the simplest method to limit printing? For example, Id much rather mark my 5 or 10 divs dynamically for printability (or however you do so) than mark my left nav, top nav, sub menus etc.
|
# ? Jan 18, 2015 05:07 |
|
A print stylesheet is just a separate CSS file (or a media query in your existing CSS file) that only affects the page when it's printed. There's no need to change any styles programmatically for this. Your use case sounds like it can be accomplished very easily. Add a class called "printable" (or whatever) to the HTML elements you want to be printed. Include "media" attributes in your css links like this: code:
Add this to your print CSS file: code:
You can add more CSS as needed to get the layout how you want it, but this will accomplish what you're asking for.
|
# ? Jan 18, 2015 05:28 |
|
Was reading the MaterializeCSS thing and it reminded me of this question I've had for some time: Since when has writing HTML like this been okay? code:
code:
And why the gently caress does half the internet look like this now? code:
And when you go the Sass route and just @extend everything from boostrap components you get horrors like this as the CSS output: code:
Someone please explain this to me. Are there any non-horror ways of actually using all these fancy new frameworks?
|
# ? Jan 18, 2015 11:26 |
|
You use those frameworks when you don't give a poo poo and want things looking decent quickly for no effort. Or well, that might just be my use case.
|
# ? Jan 18, 2015 11:41 |
why I don't use bootstrap.txt
|
|
# ? Jan 18, 2015 12:12 |
|
Gmaz posted:You use those frameworks when you don't give a poo poo and want things looking decent quickly for no effort. Or well, that might just be my use case. This. If you actually care about this stuff use create your own component system. Frameworks are just that, and as a consequence they contain mountains of utility classes, components, and all sorts of poo poo you don't need and can even impact on maintainability down the track. If you want custom, go custom and ignore the frameworks. What they give you is not that difficult or even time consuming if you know your way around CSS.
|
# ? Jan 18, 2015 12:17 |
|
Loezi posted:Isn't the whole idea of CSS and HTML that content is separated from the visual representation? What the hell am I not getting here? Grid systems, for example, are quite popular. They create a grid on which you can lay out your content so that your site has a pleasing visual harmony and becomes responsive as the individual elements reflow according to the screen size of the visitor. All good stuff, but they do tend to require a lot of extra markup and almost recreate the old table-based markup by creating columns, rows and blocks. There's also an OOCSS (object-oriented CSS) trend; CSS files block rendering of the page until they are fully loaded, so it pays off to have your CSS files as small and lean as possible. By creating smaller sets of declarations in your CSS and sprinkling your HTML with classes to apply the right ones, the CSS file contains less repeating or overriding statements and ends up being smaller. The speed increase from the CSS loading faster tends to outweigh the size increase in your HTML file. And of course as Maluco Marinero already said, many CMS's and frameworks add a ton of extraneous stuff since they need to cater to a lot of use cases and designs; their strength lies in having many options and being able to set something up quickly and easily, not in being highly optimized.
|
# ? Jan 18, 2015 14:04 |
|
Leshy posted:There's also an OOCSS (object-oriented CSS) trend; CSS files block rendering of the page until they are fully loaded, so it pays off to have your CSS files as small and lean as possible. By creating smaller sets of declarations in your CSS and sprinkling your HTML with classes to apply the right ones, the CSS file contains less repeating or overriding statements and ends up being smaller. The speed increase from the CSS loading faster tends to outweigh the size increase in your HTML file. I have my doubts about the assumptions behind this. Many times, there's a reason you want (some of) your CSS to block the rendering. Take the CNN website for a random example. Go there and delete the CSS links via your developer console. The site is unusable. Now the "smart" way (I've been told) to use OOCSS and still get a usable baseline site for your user would be to serve the CSS in multiple chunks: Really basic CSS that provides a "usable but bad looking" user experience and blocks the rendering, followed by non-blocking "make it pretty" CSS. But now you are loading more assets. And the platform that suffers the most from CSS processing - mobile - also has the slowest internet speeds and longest RTTs. So you are adding essentially saving a few milliseconds from the fetch-to-first-view time but adding possibly hundreds of milliseconds more to the fetch-to-complete-site time. Is this a sensible trade off? Another way to solve the problem would be to embed the basic CSS in the .html file but then you are serving the same CSS with every page the user requests, making caching the "get-this-first" CSS file impossible. This is even worse. I'm also a bit wary of the possible development time overhead caused by embedding tons of class declarations to the HTML, since this would make changing things much much harder and more time consuming. Are we saving a non-noticeable amount of user time to spend hours/days more on site housekeeping? Is this sensible? Furthermore, I'd say that going from "sensible and minimized" CSS to "really optimized" CSS should probably be the absolutely last thing to optimize in your website considering that 90% of websites built in the last year or so are serving the user absolutely huge background images for those fancy new parallax scrolling sites that everyone and their dog ignores. What I'm asking really is that are there any in-depth, neutral-POV articles that actually look at these questions and doubts I have with real data backing up their conclusions?
|
# ? Jan 18, 2015 14:34 |
|
Loezi posted:I have my doubts about the assumptions behind this. External CSS files can't be. Or rather, they can, but it leads to an unstyled, possibly dysfunctional page that suddenly re-renders as the proper styles are loaded. Leading to... quote:Many times, there's a reason you want (some of) your CSS to block the rendering. [...] serve the CSS in multiple chunks: Really basic CSS that provides a "usable but bad looking" user experience and blocks the rendering, followed by non-blocking "make it pretty" CSS. In the ideal scenario you load all of your CSS asynchronously so that it doesn't block rendering. You identify the minimal amount of CSS that you need to properly style the part of the page that a user first sees when he visits your site and you inline that in your page. When a user visits, that page will immediately start rendering and apply the needed CSS to make everything look normal, while in the background the full CSS files load and style everything that the user doesn't see immediately. To avoid the inline CSS from cluttering up each page and making the HTML files unnecessarily large, you set up a check for a cookie on the users system, which you set after the first page load. If the cookie isn't present, the user hasn't requested and cached your full CSS files yet, so you inline the critical CSS; if the cookie is there, so are the cached CSS files and no CSS needs to be inlined. quote:So you are adding essentially saving a few milliseconds from the fetch-to-first-view time but adding possibly hundreds of milliseconds more to the fetch-to-complete-site time. Is this a sensible trade off? As a hobbyist, non-professional web designer I can't say how OOCSS compares to 'traditional' CSS in terms of maintenance or change time in a large-scale environment, so I can't comment on that. I would say that the user time is not non-noticeable if it leads to an increase in conversions, however. And all signs point to a direct 'less loading time = less users impatiently turning away' relation, so quote:Furthermore, I'd say that going from "sensible and minimized" CSS to "really optimized" CSS should probably be the absolutely last thing to optimize in your website considering that 90% of websites built in the last year or so are serving the user absolutely huge background images for those fancy new parallax scrolling sites that everyone and their dog ignores. I don't really know of any completely neutral articles with a lot of data, but an interesting read I know of was Smashing Magazine's article on their optimization process which covers some of this topic. Leshy fucked around with this message at 17:15 on Jan 18, 2015 |
# ? Jan 18, 2015 16:56 |
|
Gmaz posted:You use those frameworks when you don't give a poo poo and want things looking decent quickly for no effort. Or well, that might just be my use case. Like everything in software, you can have it done right, fast, or cheap: pick two. Bootstrap and pals value fast and cheap. Being a world driven by business concerns, this may be a "good" or at least acceptable decision. Personally, I very rarely use frameworks, but I do try and look at them and learn things from them. Sometimes that learning is what not to do.
|
# ? Jan 18, 2015 17:13 |
|
One other thought I have about the separation if content and style, is it may be more useful to look at the separation as not HTML/CSS (which are tied no matter what), but structure vs presentation. This may be obvious but here's my cut point, the HTML should represent the structure of your document with classes added. Therefore, with no stylesheet the website should be to some degree usable. A few things fall out of this: - use semantic html5 that represents your correct content order - apply classes on top of that ideal structure - style using classes only, never style elements(h1, p, h2, etc) except in your foundational styles. - attempt to make styles by classes ignorant of structure, so essentially avoid nesting selection. I use BEM as a rule, with additional rules I call contexts (working in this concept with a mate). Context rules are classes with an asterisk, like front-page\* where I shed the nested selector rule because it's pragmatic to do so. This way I have largely single concern style rules, using extend isn't too nasty, and at the end of all that we use contexts to ramp up the specifity where required. As a result we end up with fairly predictable CSS rather than a mash of utility classes. End words, longer than intended but maybe this sparks discussion/is helpful.
|
# ? Jan 18, 2015 21:22 |
|
Diabolik900 posted:A print stylesheet is just a separate CSS file (or a media query in your existing CSS file) that only affects the page when it's printed. There's no need to change any styles programmatically for this. Your use case sounds like it can be accomplished very easily. Thanks. I am having a little trouble though. I have everything setup but the NOT selector doesn't seem to work as expected. I went ahead and marked my chart/report DIVs with the class printable, added print stylesheet, reference in head etc. But it doesn't work. To test, i removed the not (intentionally selecting the printable class) but keeping display:none, and my charts successfully vanished from the print page (showing that the print stylesheet was set right and doing its job). I guess I could go around my html adding no-print to the classes but maybe there is something I need to do.
|
# ? Jan 18, 2015 21:25 |
|
Ahz posted:Thanks. I am having a little trouble though. I have everything setup but the NOT selector doesn't seem to work as expected. The not selector may not work in your browser. Try something like this as your print.css: code:
|
# ? Jan 18, 2015 21:38 |
|
Ahz posted:Thanks. I am having a little trouble though. I have everything setup but the NOT selector doesn't seem to work as expected. the 'not' will match html and body so you probably have to tag those as printable.
|
# ? Jan 18, 2015 21:48 |
|
Yeah, I was being a little over-ambitious in suggesting *:not(.printable). The .printable elements won't show up either, because their parents are set to display: none. You're going to have to get a little more specific in your print CSS.
|
# ? Jan 18, 2015 22:21 |
|
Or you could just make a .not-printable class and put that on everything you don't want to print, if that's simpler
|
# ? Jan 18, 2015 22:22 |
|
vOv posted:Or you could just make a .not-printable class and put that on everything you don't want to print, if that's simpler That's the right way to do it, but he wants to avoid that, so we're tossing out bad ideas to try an make it happen!
|
# ? Jan 18, 2015 22:56 |
|
Yeah I gave in and just made all the nav, menus etc non printable and it works fine, thanks! My new problem is SVG printing. I can easily render my charts (using c3js library) for my responsive bootstrap layout, but when I want to print my charts, the SVGs vary wildly in size depending on window size. Most printouts look find until my window is beyond 1200px width, then my SVGs start rendering to get cut off the page etc. Right now I have one chart per page with 'page-break-after:always' and thats fine, but I would like to have each chart take up maybe 80% of the width of the page without cutting off the side or losing center (which happens when the window is too wide).
|
# ? Jan 19, 2015 00:59 |
|
Lumpy posted:I just saw this here thing on the internet and I thought it looked interesting: http://materializecss.com/ Material Design CSS framework. I'm probably late to the party on it, but it's new to me! syrup posted:Nice find -- I hadn't seen that one yet. There are also similar projects that work out of the box with React, Angular, and Ember if you're into any of those. Ooh, wow, I hadn't heard about any of this. Material Design is totally new to me...is this basically a Google-made CSS framework, like Bootstrap?
|
# ? Jan 19, 2015 01:07 |
|
Pollyanna posted:Ooh, wow, I hadn't heard about any of this. Material Design is totally new to me...is this basically a Google-made CSS framework, like Bootstrap? Material Design is Google 's visual language for app design. The thing I linked is something some folks made based on it. Google's thing: https://www.google.com/design/spec/material-design/introduction.html
|
# ? Jan 19, 2015 04:36 |
|
Lumpy posted:Material Design is Google 's visual language for app design. The thing I linked is something some folks made based on it. I have absolutely no idea what this is, but it looks cool.
|
# ? Jan 19, 2015 05:08 |
|
It's the design language Google unveiled when they unveiled Android 5.0.
|
# ? Jan 19, 2015 05:40 |
|
Actually that's a point, is it OK to be using Material Design in projects not specific to Android / Google products?
|
# ? Jan 19, 2015 19:44 |
|
There's a background video at the top of this page and some people are saying they see a black screen for a split second before it loops back to the beginning: http://178.79.163.93/littlefish/ I don't see it... Is there anything I can do? Can I encode the mp4 differently or something?
|
# ? Jan 21, 2015 10:00 |
|
fuf posted:There's a background video at the top of this page and some people are saying they see a black screen for a split second before it loops back to the beginning: You could try adding a poster that's the first frame of the video
|
# ? Jan 21, 2015 18:14 |
|
Anyone have a no-hassle color picker library? I've tried a couple and they all either have way too many dependancies (images? wtf?) or don't work properly even on their own demos. All I need is a way to show a color picker when a user clicks on an input type="text" box and show the hex code. I've done this in the past but I can't remember what I used and everything I've tested today is crap. I just want something with a single js file and a single css file.
|
# ? Jan 22, 2015 16:31 |
|
revmoo posted:Anyone have a no-hassle color picker library? I've tried a couple and they all either have way too many dependancies (images? wtf?) or don't work properly even on their own demos. Don't know your use case / target browsers, but is <input type="color" /> an option for you? Every polyfill I searched for (admittedly only for a few seconds) seems to want jQuery, but there's probably one out there for vanilla JS. If not, write one! EDIT: Maybe this? https://github.com/bebraw/colorjoe \/\/\/ Well then, one of the bajillion results for 'html5 color input ployfill' will probably work. Sorry I do not have a specific suggestion. Lumpy fucked around with this message at 17:00 on Jan 22, 2015 |
# ? Jan 22, 2015 16:54 |
|
I have jquery loaded, so that's not an issue. The above picker doesn't do input boxes (and looks like a whole lot of work). I really should be able to just do $('element').colorpicker(), that's all I've had to do in the past. EDIT: Meh, ended up going with this: http://www.eyecon.ro/colorpicker/ it's not great but it works. revmoo fucked around with this message at 17:03 on Jan 22, 2015 |
# ? Jan 22, 2015 16:58 |
|
Does anyone know a good source for SVG icons or graphics? Something where if I want to use a single icon, I can just use that instead of a whole pack (I already have glyphicons pro) Nice packs are fine too, though I also have font awesome.
|
# ? Jan 22, 2015 18:17 |
|
http://thenounproject.com would probably be your first stop for stuff like that.
|
# ? Jan 22, 2015 18:23 |
|
Maluco Marinero posted:http://thenounproject.com would probably be your first stop for stuff like that. The free version requires that you "give credit" to the image creator. Any idea if they're cool with me doing this via code comments?
|
# ? Jan 22, 2015 19:47 |
|
caiman posted:The free version requires that you "give credit" to the image creator. Any idea if they're cool with me doing this via code comments? I bet if you emailed and asked, they'd tell you.
|
# ? Jan 22, 2015 20:02 |
|
Ahz posted:Does anyone know a good source for SVG icons or graphics? Something where if I want to use a single icon, I can just use that instead of a whole pack (I already have glyphicons pro) I've tried perfect icons and glyphter before.
|
# ? Jan 22, 2015 22:29 |
|
I am very new to javascript programming and had what I hope is an easy question. Say I have some text and buttons on a page. Is there a way I can, on command, remove that stuff from the screen and replace it with a new set of text and buttons?
|
# ? Jan 23, 2015 03:56 |
|
Sure, use something like jQuery to show/hide elements easily. http://jsfiddle.net/t1gyspzj/1/ There are many different ways to achieve this, depending on what exactly it is you're trying to do.
|
# ? Jan 23, 2015 04:31 |
|
Ahz posted:Does anyone know a good source for SVG icons or graphics? Something where if I want to use a single icon, I can just use that instead of a whole pack (I already have glyphicons pro) Just this evening I came across this: https://fonticons.com/. It seems to basically be a way to create a customized group of icons without having to load an entire pack.
|
# ? Jan 23, 2015 05:04 |
|
|
# ? May 14, 2024 11:56 |
|
I've got an app that displays hundreds of thousands of dom nodes and that number is only going to increase. I update their contents with AJAX. I'm running into performance issues and from profiling it appears that I may just be hitting the limits of what you can do with a browser. Right now I'm sitting at 153k dom nodes, and there are elements, roughly 10-15,000 of which, that actually get updated every 20 seconds. This of course, runs like dog poo poo. The core of the issue appears to be the main loop that does the actual updating of the html. I tried throwing it into a staggered setTimeout but it didn't help at all. Where do I go from here to scale this thing? Do I need to use some sort of canvas/svg tech or what? I'm kind of stumped. revmoo fucked around with this message at 14:38 on Jan 23, 2015 |
# ? Jan 23, 2015 14:35 |