Little style refresh for default web pages

[smartiniOnGitHub]

Hi all, I'm proposing here to do a little refresh (from a stylistic point of view) of Grails generated pages for 3.1.x. ; of course this is a not-so-trivial task, so to avoid breaking a lot of pages and visual behavior with many plugins (like Scaffold) I think we should split this issue in some steps/tasks (and maybe in more than 1 issue, and implement them in the Grails 3.1.x line), this is a sample plan:

• step 1: accept/agree on the proposal page (from many points of view it's subjective I know, but we should try to stay on a balance between modern page looking, functionalities, platforms supported, etc), based on a sample Home Page updated by hand.
• step 2: update Grails sources to implement new style ... do you prefer a custom branch or should I stay with my master ?
• step 3 (as suggested by Ronny): move default sitemesh layout related CSS in a dedicated css
• step 4 (as suggested by Ronny): move scaffold/related styles in a dedicated css style ... published by Grails or by the Scaffold Plugin ? (in the meantime maybe keep in Grails). For this of course we need many user tests to ensure behavior will be good the same.
• others steps to adjust things ...

In my tests I'm using the new Grails web site as a reference; all code is done without other frameworks/libraries, to keep it simple; stay on a basic adaptive design; make it simple to expand or to remove with another (like Bootstrap).

This is the online version for a revised Home page: http://codepen.io/anon/pen/YwPVdN I'll put in attach here a zip file containing all (static-only) files to be able to work offline: grails_pages_tweak_tests_for_3.1.0.zip

What do you think ? I hope to get some feedback, consensus is all here :-) .

The discussion thread is here: https://groups.google.com/d/msgid/grails-dev-discuss/deab1f8c-27e6-4803-9fd2-4abb44a287e4%40googlegroups.com?utm_medium=email&utm_source=footer please put discussion-related things in that thread, and only development-related things/issues/updates (here) in the GitHUB Grails Issue.

Thanks a lot, Sandro

[graemerocher]

From a UI perspective I'm not sure this is much better, it may be better from a underlying implementation perspective

[smartiniOnGitHub]

Hi Graeme, yes I know (for best results a Web Designer here would be better :-) , but I'm open to suggestions); anyway I tried to make it a little more modern and update styles like those in new Grails web site. And tried to update other technical details like:

• update fonts, and texts dimensions
• use most dimensions relative to current font size
• update page elements to use more HTML5 semantic tags
• cleanup the big style section in home page (now for simplicity a big style block is inside that page but it will go in Grails css, maybe polished a little)
• insert an HTML5 centered navigation bar, even to use as a sample
• make content element (section) use most of available width (when resizing the browser window)
• (optional) move some important platform info (Groovy, Grails, JVM version, and environment) in footer, and maybe show them only in DEV environment (later), ok ? In any case I think that a colored footer could be a good addition (at least with only "Made with Grails" and a link to Grails Web Site).
• update width for style changes to higher resolution (more common now)
• add some (commented) styles for other common usage like fixed Header, responsive images, navigation with only links (not inside ul li), etc ... that could go in another css (if wanted)
• removed color gradients, to speedup page rendering
• and others small changes ...

After some tests on latest Chrome, Firefox, IE 11 (Edge), still I have to improve/fix:

• I just seen that on mobile the page is not zoomable (I have to fix it)
• reduce navigation texts
• footer colors have too little contrast
• others ?

Note that all this is related only to Step 1 of original plan (agree that the proposal looks and works good as default), refactoring and other stuff should be done later ...

What do you think, should I proceed with changes (I think it would be a good update, even if not so heavy) or it's better to postpone this to later (no problem, don't worry) ?

Bye, Sandro

[admwx7]

Mobile

• header navigation should degrade a bit more nicely, I recommend a hamburger style navigation for mobile
• footer is almost unusable in mobile, try hiding some information and leaving only the highly important pieces, then serving the rest through an in-depth page or a clickable overlay
• you're actually losing information completely, either inline the left nav on mobile or provide a link to get to the information if the user chooses.

Tablet

• the nav links in the header could use some work on layout to make them a little more smooth, though at this point hamburgers are still acceptable.
• left nav section should be collapsible or hidable in some other way to provide more usable area for the main content

General - footer

• could use some padding for readability
• I agree some contrast would go a long way
• adding a collapsed view that on hover/click expands to show all of the details would clean things up, specifically for all the different versions, maybe hide that under the app version, on hover expands to show all service versions

General - header

• I would pull the grails link to the left of the header and replicate what they use on the grails website, it's much cleaner, however this can be a bit of a trap since people often assume that an icon in your header is the home button for your page, so relocating this to a link in the footer might be better served to deviate from what everyone expects your home button to do, in this case there's already a grails link in the footer, maybe pretty it up with an icon?

General - content

• reduce the opacity, thickness, and color of the divider lines. Subtle lines still give the feel of division but give a more modern and sleek look, github's use of them along the footer is a good example, on that note even the grails website uses them
• level out your left nav and top of the content area, it draws unwanted attention to empty space.

General

• light gray is an easy color to use, especially when drawing light attention or separating areas, such as highlighting a heading, or footer, it also tends to add a modern feel, keeps things crisp. Avoid gray on gray though, hard to read

[rlovtangen]

I would style the hr with a class instead of styling the hr element itself. Same goes with nav, footer and aside. This way it is not intrusive on other hr, nav etc on the page.

[orubel]

An old trick I use constantly is 'dynamic css' (as I call it) wherein I use another language to set variables in a css style sheet and then output the style sheet using 'Content-type: text/css'

So you can write the CSS as groovy and assign the font, colors,sizes, etc all as top level variables pulled from a config or external properties file and then just call the groovy script as a CSS file. As long as it is understood to be CSS, you are good to go and can assign variables dynamically.

[admwx7]

Alternatively, a CSS preprocessor, such as sass or less, could do the same thing, as well as adding in mixins for repetitive tasks. However, for styling a handful of static pages, that's kind of overkill. I agree with styling based on classes instead of directly on the elements, though to reduce class clutter, you can drive styling based on class element selectors, be cautious using > and ~ though as an HTML change can break your styling.

On Wed, Dec 9, 2015, 6:29 PM Owen Rubel notifications@github.com wrote:

An old trick I use constantly is 'dynamic css' (as I call it) wherein I use another language to set variables in a css style sheet and then output the style sheet using 'Content-type: text/css'

So you can write the CSS as groovy and assign the font, colors,sizes, etc all as top level variables pulled from a config or external properties file and then just call the groovy script as a CSS file. As long as it is understood to be CSS, you are good to go and can assign variables dynamically.

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-163446596 .

[rlovtangen]

Can we change the green h1, h2 etc to black? grails.org doesn't use green headers anymore and IMHO black looks better. Would also be a better starting point for most applications, as most sites won't choose green as font color.

[smartiniOnGitHub]

Hi all, and many tahnks for all the feedback (a lot :-) ). Generally speaking without using powerful libraries like Bootstrap (or jQuery effects) I think we shouldn't try to implement something like hamburger menus, rollover/popup effects and other (visually good) things, because for now I think that only a little refresh in styles/layouts should be done ... at least for now, ok ? The same even for css preprocessing frameworks (yes it's a good idea, but I'd move it to a later step). Styling on css classes (and even by element id, more efficient, where possible), ok. Change the link in nav bar with Grails logo to make it point to webapp Home page, and keep a link in the footer to Grails web site, ok ? And maybe move it at left side of header.

@graemerocher do you know if we could use new Grails logo instead (are there licensing issues) ?

@rlovtangen +1 from me for black h1, h2, etc , it is ok even for others ? And other (proposed) colors are good ? I just see your post in mailing list, I'll respond there (anyway thanks for the prototype and the help :-) ) ... because it looks very interesting (but a lot of work to do to have it right) for step 2.

@admwx7 there are many point (thanks for the feedback) ... I'll try to update/improve the live version of the page (the same you are welcome) based on your suggestions, like better degradation (with better usage of padding/spacing/available area), etc.

@graemerocher I think it would be good to try explore further this issue, ok ?

[graemerocher]

@smartiniOnGitHub Of course you can use the logo

[admwx7]

You can include bootstrap CSS only and it will help greatly, especially with responsive support, and allows for hiding elements, though you won't get the jquery support for hamburgers, you can still seamlessly hide elements without that.

On Thu, Dec 10, 2015, 4:50 AM graemerocher notifications@github.com wrote:

@smartiniOnGitHub https://github.com/smartiniOnGitHub Of course you can use the logo

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-163577461 .

[smartiniOnGitHub]

Hi Austin, I agree with you, but I didn't use it only because Grails by default doesn't use it ... and to add by default we should hear from Grails core developers what they think.

Thank you for all the feedback on this issue :-) .

Bye, Sandro You can include bootstrap CSS only and it will help greatly, especially with responsive support, and allows for hiding elements, though you won't get the jquery support for hamburgers, you can still seamlessly hide elements without that.

On Thu, Dec 10, 2015, 4:50 AM graemerocher notifications@github.com wrote:

@smartiniOnGitHub https://github.com/smartiniOnGitHub Of course you can use the logo

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-163577461 .

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-163705605.

[admwx7]

True, but it's bootstrap or writing your own implementation of the bootstrap grid, alternatively flex-box might work if you only want to support modern browsers, opting for something that offers only a grid is always an option too

On Thu, Dec 10, 2015, 4:13 PM Sandro Martini notifications@github.com wrote:

Hi Austin, I agree with you, but I didn't use it only because Grails by default doesn't use it ... and to add by default we should hear from Grails core developers what they think.

Thank you for all the feedback on this issue :-) .

Bye, Sandro You can include bootstrap CSS only and it will help greatly, especially with responsive support, and allows for hiding elements, though you won't get the jquery support for hamburgers, you can still seamlessly hide elements without that.

On Thu, Dec 10, 2015, 4:50 AM graemerocher notifications@github.com wrote:

@smartiniOnGitHub https://github.com/smartiniOnGitHub Of course you can use the logo

— Reply to this email directly or view it on GitHub < https://github.com/grails/grails-core/issues/9467#issuecomment-163577461> .

— Reply to this email directly or view it on GitHub <https://github.com/grails/grails-core/issues/9467#issuecomment-163705605

.

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-163764734 .

[smartiniOnGitHub]

@graemerocher (Graeme and even others :-) ) what do you think on including Bootstrap or Flex-box ?

[graemerocher]

Bootstrap via asset pipeline seems fine to me

[smartiniOnGitHub]

ok, and this would be a great (and important) news !! To better track it (mainly for release notes) I could create a dedicated issue, and then link this issue with that (I miss some JIRA features here :-) ); and later do a dedicated push request for review.

[rlovtangen]

I'm not that big fan of pulling in Bootstrap, although I use it myself. More to remove for users that won't use Bootstrap, and we get code that depends on a specific version of Bootstrap which will make upgrades more difficult for users. I think the initial template should be a minimal starting point that is easy to remove.

[smartiniOnGitHub]

@rlovtangen Hi Ronny, yes I agree with you, a change like introducing Bootstrap by default would be great but too invasive in default pages (we could add in a later major release, if wanted), so a safer approach for now is to continue without any additional library and try to update default pages but without too much/complex changes/effects. Thanks for your point of view.

[hakanernam]

I was quite happy for a while (7 minutes to be exact), now I am sad. @rlovtangen has a good point, but still:

• I presume many of us already remove stuff from default layout, nice as it is, when we start, after a while. Considering bootstrap is already widely used, burden of removing default stuff may actually go down.
• Using Bootstrap as a base will mean scaffolding templates will be updated. This a plus for people already using bootstrap. I have already modified all scaffolding templates to use bootstrap. I had not realized until then how good the default templates were and would very much welcome similar but bootstrap based ones.
• Depending on specific versions of bootstrap may be lesser worry since we already upgrade app's dependencies all the time. If we use asset-pipeline based bootstrap and if someone wants to stick with specific version of bootstrap after creating the app, they can easily do that. Also, bootstrap people have proven very professional in the sense that upgrades were not problematic for me at all.
• I guess it is too early or much to think about making layout part of the profile system at this point. Still with such a system, talented people may make pretty pluggable layouts. Bootstrap would enable this, judging the template sites like wrapbootstrap.com. So being able to go in that direction would be another plus.

[smartiniOnGitHub]

Generally speaking a lot of us (including me) many times use Bootstrap, but others not, so a good default is hard to find ... so now the real main question for Grails is "To Bootstrap or Not To Bootstrap" by default ? But this is an important point, so maybe it would be better to further discuss with all (in Grails mailing lists, usually this kind of questions need some time and many prototypes to have a stable/approved version by the community), and link to a dedicated issue (and maybe implement it later) ... and for 3.1.0 a safer approach could be to continue my little exploration/small improvement work without it.

[admwx7]

• flex-box is built into native CSS now, it just doesn't support all browsers: http://caniuse.com/#feat=flexbox
• even if you use flex-box, you will have something like bootstrap classes littering your html, then a .css file floating around that was custom created to fill out those classes to define columns, the difference is that you're no longer following any standard at all, so literally all of your code is throw away, if you however pick a CSS framework then it's not throw away for that group (bootstrap is the most popular last I looked), the group that wants completely custom styling can hook off bootstrap syntax for naming and build their own .css files, the only group out in the cold is people in favor of say foundation instead of bootstrap.
• adding a bootstrap css file isn't really that big of an addition, you're adding one for your custom styling regardless, and I've never had issues with same major version of bootstrap updates.

The real question isn't to bootstrap or not to bootstrap, it's to follow a set of front-end coding standards or not to. Once you've made the proper decision there, it's just pick the most popular one (ideally for clients of your project, which is probably the same as the overall most popular), then follow that one. Any other decision will turn into throw away code for all of your clients instead of a subset.

Most front-end scaffolding tools that have opt'd for this sort of solution went the way of bootstrap based on popularity. To remove the dependency your just delete the line in your package.json (or bower.json in older tools) and you're good to go.

On Fri, Dec 11, 2015 at 4:44 AM Sandro Martini notifications@github.com wrote:

Generally speaking a lot of us (including me) many times use Bootstrap, but others not, so a good default is hard to find ... so now the real main question for Grails is "To Bootstrap or Not To Bootstrap" by default ? But this is an important point, so maybe it would be better to further discuss with all (in Grails mailing lists, usually this kind of questions need some time and many prototypes to have a stable/approved version by the community), and link to a dedicated issue (and maybe implement it later) ... and for 3.1.0 a safer approach could be to continue my little exploration/small improvement work without it.

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-163906509 .

[smartiniOnGitHub]

@admwx7 Thank you very much for all the tip/info, I'll try to use as much as possible. But for the choice to use or not Bootstrap it's better to see what the community say. Bye

[smartiniOnGitHub]

@graemerocher @rlovtangen Hi, I started to look at Ronny test for changes to the web profile ... but I have a little problem, to try my local changes: from the 'profiles' folder inside my fork of grails-profile-repository, I try to install in my local repository (under the user home folder) with 'gradle install', as written in Grails guide for profiles, but even with a test grailsPublish section configured in my '%user_profile%\gradle.properties' I always get this build error on angular subproject:

No 'user' was specified. Please provide a valid publishing configuration

I'm on Windows 10 at 64 bit, with latest JDK 7 and JDK 8, and as a workaround I just found to update by hand contents inside downloaded jars in my local maven repository (under the folder org/grails/profiles/web/), and I know it's not a great workaround. Probably some more info in docs on customizing profiles and test them would be useful :-) .

Anyway, do you think it would be useful a Gradle command ('install-local' or similar, that doesn't need a grailsPublish configuration block) there to simply jar and copy the 'profiles' folder in the local maven repository in the user profile, to simplify local tests with custom profiles ? Or let the 'gradle install' command work the same at least in local and writing to console that the copy has been done there ? Do you prefer another issue for this ?

[graemerocher]

I ran into this recently too, it is a bug we should probably fix, but can be worked around. See https://github.com/grails/grails-views/commit/ff39ca9e77367b507962cbfd095b0116a5f686a9 for an example workaround

[smartiniOnGitHub]

ok, thanks for the workaround for now. Bye

[orubel]

@admwx7 The reason I use groovy to dynamically set CSS is because it can more easily read and work with external properties file (or even internal properties). This can be very convenient when doing things through the backend.

If STRICTLY frontend, yes... things like LESS are better. But if you are integrating with the application settings, setting CSS with Groovy can be an advantage.

[admwx7]

Not sure why you would want a properties file to affect your CSS, but even then I would just do a file import as a pre-build step for building your less, then you get all the benefits of both.

On Mon, Dec 14, 2015, 9:08 AM Owen Rubel notifications@github.com wrote:

@admwx7 https://github.com/admwx7 The reason I use groovy to dynamically set CSS is because it can more easily read and work with external properties file (or even internal properties). This can be very convenient when doing things through the backend.

If STRICTLY frontend, yes... things like LESS are better. But if you are integrating with the application settings, setting CSS with Groovy can be an advantage.

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-164461274 .

[orubel]

@admwx7 you set all your properties in a properties file. If the CSS is dynamic, you dont want to have to constantly change that CSS file; you want it to load the variables from external source at runtime. This is VERY useful for multitenancy and other uses. Each site can have it's own CSS AND it's own settings.

[admwx7]

The same result can easily be achieved through your build process and any CSS preprocessor, as far as multitenancy and such goes. I'm trying to figure out why mixing languages and config files creates a better solution here?

On Tue, Dec 15, 2015, 8:24 AM Owen Rubel notifications@github.com wrote:

@admwx7 https://github.com/admwx7 you set all your properties in a properties file. If the CSS is dynamic, you dont want to have to constantly change that CSS file; you want it to load the variables from external source at runtime. This is VERY useful for multitenancy and other uses. Each site can have it's own CSS AND it's own settings.

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-164779335 .

[orubel]

Yes but this simplifies it. You are requiring a middleman to do the same thing.

[admwx7]

I'm purely UI, just here to assist with CSS issues, as such I don't know how grails works fundamentally, are you completely generating your CSS, or do you have a .css file floating around somewhere with your styles? If they first, why? That sounds painful.

[graemerocher]

@admwx7 I think the conversation has gone off track, we are not generating the CSS and there is no requirement to do that

[admwx7]

You're correct, sorry. So where we at on that flex-box then? Do you need to support pre-IE10?

[smartiniOnGitHub]

Hi, I'm still working on doing some changes in my fork of projects (to merge later via pull requests); I'll post here some news as soon (and if possible even a live preview somewhere, because to test all otherwise you have to clone my forks and build locally ... anyway I can give you some info if needed) as I'll do some commits but I still need some time, sorry. As Graeme said currently we should focus on improving/update/rewrite existing styles, so even proposals with static css/html files could be good as starting point :-) .

[jameskleeh]

@smartiniOnGitHub We're trying to get this buttoned down for the next release of Grails. Can you update us on your progress?

[smartiniOnGitHub]

Hi, sorry this week I have been very busy (but now I have a working DEV setup for all Grails and for Grails Profiles from my fork, and I already did a check of initial tests from Ronny to better understand his changes) so I have little updates on pages, but I'll work on this during the week-end and post an update here, if possible with an updated static mockup. My forks are here at GitHUB, so during next days I'll commit changes so anyone could try them even with Grails snapshot.

Update: to better see/track changes, I've setup some static pages in a test area grails3-refresh-styles , so even without a Grails-3.1.0-snapshot working in a local environment, anyone can try pages (we need tests under many configurations !!) and give some feedback. Note that all those pages are generated by my updated Grails environment and saved as static files. I'll post soon never version of pages, the next one is the initial version of the modularization. Be free to attach here link/files for suggestions for enhancements.

[smartiniOnGitHub]

Hi all, just pushed other initial samples for pages saved from a webapp generated by an updated Grails-3.1.0.BUILD-SNAPSHOT and updated Grails profiles ; anything is a static resource at grails3-refresh-styles, so anyone can test some changes with only Browser Developer Tools; or clone my repository (the usual branch for GitHub pages) and try some changes. Up to now I've only started with the refactoring of css files suggested by Ronny, but no changes in styles; I'll do them during next days (other than Holidays :-) ) I'll continue the work, and then put in that area other saved pages, so anyone can better see differences and give some feedback (and maybe test changes before and see of they happens). I know that there is not so much time before Grails-3.1.0 final, but in this way we'll get more consensus (and test/feedback) on proposed changes, right ? Bye, Sandro.

[admwx7]

Looking good so far! I'll see if I can get some time to send you some actual code updates, but the major issues that pop out to me still are:

• footer needs some better contrast and spacing to make it more readable
• what's going on with the info link? seems like you could just drop it
• the header could use some better spacing for the links, I'm a personal fan of icon floating left and links floating right
• a nice touch would be a border between the links in the nav, a 1px shade darker of the header color with some opacity on it to show division between the links
• the orange hover color in the header is...startling, how about a darken/lighten to the header color with a nice box shadow to make it feel more like rising towards you instead?
• this is just being picky, but can we ditch that block of whitespace above the left section of info? Or at least trim it down a bit, it just keeps drawing my attention to it when it really shouldn't
• the dividers look weird with an inset border, try setting border: none and box-shadow: 0px 0px 1px #4d8618; on your hr element. Though I recommend moving that styling into something like a divider class, I prefer to use .divider, .divider-after, and .divider-before, then build my styling based off the ::before and ::after classes instead of injecting an hr element. That being said, the more common route is an hr with class="divider".

On Tue, Dec 22, 2015 at 7:20 PM Sandro Martini notifications@github.com wrote:

Hi all, just pushed other initial samples for pages saved from a webapp generated by an updated Grails-3.1.0.BUILD-SNAPSHOT and updated Grails profiles ; anything is a static resource at grails3-refresh-styles http://smartiniongithub.github.io/grails3-refresh-styles/, so anyone can test some changes with only Browser Developer Tools; or clone my repository (the usual branch for GitHub pages) and try some changes. Up to now I've only started with the refactoring of css files suggested by Ronny, but no changes in styles; I'll do them during next days (other than Holidays :-) ) I'll continue the work, and then put in that area other saved pages, so anyone can better see differences and give some feedback (and maybe test changes before and see of they happens). I know that there is not so much time before Grails-3.1.0 final, but in this way we'll get more consensus (and test/feedback) on proposed changes, right ? Bye, Sandro.

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-166773043 .

[rlovtangen]

With regards to how I have split up the css into different files, all the scaffold-xxx files could probably be merged back to one file (scaffold.css) when we're done. I just thought it was nice to separate things as much as possible now during development to understand the bits and pieces.

[smartiniOnGitHub]

@rlovtangen hi Ronny, yes at the end I'll merge all scaffold-xxx files in a single file, for now they are good as in your proposal, thank you again :-)

@admwx7 hi Austin, I'm taking your suggestions and integrating in my fork of profiles, then generate an empty Grails webapp with them and add some content (any time I do some changes) so it's not a fast process (and I have little time) ... anyway in a few days I'll commit some changes (from my original proposal and then apply your suggestions) and post in GitHUB pages some pages with updated content, as static mockup; then I'll wait for other feedback (for sure it's needed :-) ). Note that for colors and fonts I tried to stay as close as possible to new Grails.org web site, as first impression it would be better to have a similar style/look, but I think we are free to change styles here a little.

A little update on plan (based on pages for first proposal):

• I just updated jQuery to latest stable (2.1.4) and renamed the file to remove the version in the file name, to simplify further updates.
• proposal: zoom pages from mobile, ok
• weight for titles is too thin when shown from mobile
• header, footer, navigation, etc have to be updated, I agree with you: header with logo at left (but with a link to current webapp home page, and maybe with Grails new svg logo) and navigation at right; footer with a darker background and maybe only with a "Powered by Grails" text with a link (only here) to grails.org web site (or maybe only here the new grails svg logo); etc
• the Info menu element is empty just to show a not active menu element, it will be removed
• more progressive degradation of css styles (as you suggested) so maybe sidebar would be visible even with a modern smartphone but only in in large view; use more horizontal space at lower resolutions (like 90% for desktop, up to 96% or 98% with lower resolutions)
• what do you think on moving the sidebar at right (to give it less importance) ?
• update layout with flex-box, I'm not against it but I'd try after other things are fixed ... main concern here is on required browser, as seen here ... I think it would be a good solution anyway, what others say ?
• a note on generating well-formed css: some time ago I've seen a demo of Compass (or Sass, don't remember) with an awesome feature to generate css directives depending on diffusion % of browsers ... could be an idea for the future, or for generate/check static css files.

Last, Ronny said that he doesn't like so much the redefinition of base tags, but I think that here we are trying to update default styles (but stay open for let anyone override in a simple way) ... for example on the green color for titles, hr etc I'll define a dedicated color style, but to give a little more color in pages I think that keep them green it would be good, anyway not a big deal to change. What do you think ?

[admwx7]

• CSS precompilers are amazing, keep in mind you could always commit the generated CSS files to the repo so someone that doesn't want to use a precompilers in their project but wants to keep the default stylesheets and manually update them can, but a later discussion.
• Sidebar to the right isn't a bad idea, though it may feel weird since its not overly common, you'd have to play with it to see.
• If you're not going to use a pre-build scaffolding framework like bootstrap or foundation, but still want it to be responsive I highly encourage using flex, it'll save you hours of work and even more in headaches.
• The grails logo and powered by seems overkill in the footer, I've never been a fan of having logos in your footer either, that's more of a closing note/summary of page information above, so things like major navigation points that can be found elsewhere, or the powered by grails link so someone that finishes viewing your page and is now below the fold has a quick link to go find a way to build their own.

On Thu, Dec 24, 2015, 11:12 AM Sandro Martini notifications@github.com wrote:

@rlovtangen https://github.com/rlovtangen hi Ronny, yes at the end I'll merge all scaffold-xxx files in a single file, for now they are good as in your proposal, thank you again :-)

@admwx7 https://github.com/admwx7 hi Austin, I'm taking your suggestions and integrating in my fork of profiles, then generate an empty Grails webapp with them and add some content (any time I do some changes) so it's not a fast process (and I have little time) ... anyway in a few days I'll commit some changes (from my original proposal and then apply your suggestions) and post in GitHUB pages some pages with updated content, as static mockup; then I'll wait for other feedback (for sure it's needed :-) ). Note that for colors and fonts I tried to stay as close as possible to new Grails.org web site, as first impression it would be better to have a similar style/look, but I think we are free to change styles here a little.

A little update on plan (based on pages for first proposal):

• I just updated jQuery to latest stable (2.1.4) and renamed the file to remove the version in the file name, to simplify further updates.
• proposal: zoom pages from mobile, ok
• weight for titles is too thin when shown from mobile
• header, footer, navigation, etc have to be updated, I agree with you: header with logo at left (but with a link to current webapp home page, and maybe with Grails new svg logo) and navigation at right; footer with a darker background and maybe only with a "Powered by Grails" text with a link (only here) to grails.org web site (or maybe only here the new grails svg logo); etc
• the Info menu element is empty just to show a not active menu element, it will be removed
• more progressive degradation of css styles (as you suggested) so maybe sidebar would be visible even with a modern smartphone but only in in large view; use more horizontal space at lower resolutions (like 90% for desktop, up to 96% or 98% with lower resolutions)
• what do you think on moving the sidebar at right (to give it less importance) ?
• update layout with flex-box, I'm not against it but I'd try after other things are fixed ... main concern here is on required browser, as seen here http://caniuse.com/#feat=flexbox ... I think it would be a good solution anyway, what others say ?
• a note on generating well-formed css: some time ago I've seen a demo of Compass (or Sass, don't remember) with an awesome feature to generate css directives depending on diffusion % of browsers ... could be an idea for the future, or for generate/check static css files.

Last, Ronny said that he doesn't like so much the redefinition of base tags, but I think that here we are trying to update default styles (but stay open for let anyone override in a simple way) ... for example on the green color for titles, hr etc I'll define a dedicated color style, but to give a little more color in pages I think that keep them green it would be good, anyway not a big deal to change. What do you think ?

— Reply to this email directly or view it on GitHub https://github.com/grails/grails-core/issues/9467#issuecomment-167138839 .

[rlovtangen]

Styling of h1 is probably ok. What I'm referring to is styles like this:

th {
    background-color: #efefef;
    background-image: -moz-linear-gradient(top, #ffffff, #eaeaea);
    background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0, #ffffff), color-stop(1, #eaeaea));
        filter: progid:DXImageTransform.Microsoft.gradient(startColorStr = '#ffffff', EndColorStr = '#eaeaea');
    -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorStr='#ffffff', EndColorStr='#eaeaea')";
    color: #666666;
    font-weight: bold;
    line-height: 1.7em;
    padding: 0.2em 0.6em;
}

This makes it hard to style a table with e.g. Bootstrap's class="table table-striped". The default styling of th above will affect Bootstrap tables as well, not only the list view of scaffolded pages.

I made a branch that tries to scope the CSS to apply to scaffolded pages only. You can see the result here: https://github.com/rlovtangen/profilerefresh/commit/f7b78f4a48a87e8149c6e09dcf614117f54798ba The CSS could be improved a lot by adding some CSS classnames to the scaffolding templates, but at this time I have just changed the CSS to work with the current scaffolding templates.

I have also added a readme to my repo at https://github.com/rlovtangen/profilerefresh

[rlovtangen]

I think the green headers are legacy from when grails.org used green headers, but grails.org now uses black headers. So if the goal is to look somewhat similar to grails.org, they should probably be black. Looks better as well IMHO.

[rlovtangen]

With regards to upgrade to jQuery 2.1.4: jQuery 2.x is IE9+ only, that's why Grails still ships with jQuery 1.x. Maybe it's time to say goodbye to IE8-support now. There used to be some IE6, IE7 and IE8 fixes in main.css that is now removed, so maybe the core team already decided that the default style should support IE9+ only, in which case upgrade to jQuery 2.1.4 is ok.

[rlovtangen]

a note on generating well-formed css: some time ago I've seen a demo of Compass (or Sass, don't remember) with an awesome feature to generate css directives depending on diffusion % of browsers ... could be an idea for the future, or for generate/check static css files.

Maybe you are referring to https://github.com/postcss/autoprefixer? It will add necessary prefixes (-moz-, -ms-, -webkit- etc) according to current browser usage statistics. Bootstrap has dropped custom prefixes in its source and now relies on using autoproefixer (see http://getbootstrap.com/getting-started/). There is a plugin for Grails 2: http://grails.org/plugin/asset-autoprefixer. Works great with both CSS, LESS and Sass. Doesn't seem to be ported to Grails 3 yet, though.

[smartiniOnGitHub]

Thanks you for latest feedback, I'm currently working on push some changes (you can see small updates in new static pages saved as usual here ; many improvements still are needed there and all the work on scaffold has to be done. I just committed there the test webapp with updated pages and layouts (that I have to backport in Grails web profile, just committed even in my fork of it). During next days I'll continue the work on them, but as you know is a time consuming task, so some patience is still needed :-) . On css precompilers we can see later :-) ... Quick note on jQuery: in profiles there was 2.1.3 already so i only did an upgrade to latest.

@Schlogen Hi, I see that some of the work here has to be put even in the Angular profile (really a great addition, congratulations :-) ) but I think to close this issue I still need 2 / 3 weeks. Be free to contact me directly for more info or to speedup your work if I can help. Thank you.

What do you think on change the link destination of main logo to the home page (as usual in most sites) because now we have a link to grails web site in the footer ?

[rlovtangen]

+1 to have the main logo link point to the home page.

[smartiniOnGitHub]

Hi all, I just committed some changes with first tests with flexbox (really good to simplify layouts) but I still didn't have enough time to look deeply at latest news from Ronny (I'll do during next days) ... so note that scaffolded pages are still to be fixed. Anyway in the meantime you can see static pages generated by updated profiles/test webapp in the usual place: grails3-refresh-styles, for example a copy of its Home Page .

Some changes done:

• changed Grails logo with the new (svg) and change link to Home page of the current webapp
• add a powered by Grails (with link to Grails.org web site) in the footer, so we should be happy :-)
• changed h1 .. h4 tags more in line with a golden ratio proportion (h1 2em , h2 1.78em, h3 1.44em, h4 1.04em or better 1em as a reference, h5 0.78em, h6 0.56em) and give them more weight
• more degradation at different resolutions
• all is proportional to font size
• add styles even for not used names (but commonly used)
• add ordering number 10 by 10 for flexbox, to leave space for other elements if/when needed ... for example for scaffold toolbars (top and bottom) and maybe other elements
• etc

To do:

• add latest Bootstrap and check what happens or what needs to be updated ...
• fix styles with scaffold
• re-generate scaffold pages with updated pages active
• check Grails doc style to better handle space and wrap of text ... is it wanted ?
• add a style (with different fonts etc) for media = print ... is it wanted ?
• see if change scaffold icons, for example with those used by Bootstrap, glyphicons ... but unfortunately their license is not compatible with Apache (only if in bundle with Bootstrap), so these can't be used here ... suggestions/interest in this (but we can discuss/see later) ?
• other ?

References for flexbox: http://www.adobe.com/devnet/archive/html5/articles/working-with-flexbox-the-new-spec.html https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Tell me what you think ... to me seems that we are in the right direction :-) .

[smartiniOnGitHub]

Hi all, other updates/cleanup today, just committed and updated sample pages:

• svg logo is not visible in IE (all versions before edge) ... I have to fix it (for what is possible)
• updated styles so even where there isn't an aside element main content keep all the space, and when there is all is as in the home page
• cleanup old styles and check for no warnings/errors in css directives (now only in scaffold css files)
• updated pages and styles for error pages, and add a container to wrap content (like in other pages)
• restored visibility for footer at lower resolutions and fix its content if inside a ul/li
• normalized colors to 6 hex digits (it's simpler to find/match/replace them) Tell me what you think.

@rlovtangen Hi Ronny, a couple of questions to you:

• in main layout, check if split out header and footer to include or template pages ... what do you prefer ?
• in main_modularized.css, now I can remove the require for message-error.css and move it in errors.css, right ?

Thank you very much. Bye

[rlovtangen]

@smartiniOnGitHub

• Do you mean splitting main.gsp into different files? Depends on how much code there is for the header and footer. With the current code I will probably say it is overkill to split in different files, but I don't have any strong opinions on that.
• No, the styles in message-error.css is used by both error.gsp and scaffolded pages, so it needs to be included in main.css.

[smartiniOnGitHub]

a little update, as usual updated pages here:

• updated and renamed styles to handle a primary and a secondary aside elements (if/when needed) ... done, but keep current name for now (proposal was to change to something like aside-xxx)
• svg logo is not visible in IE (all versions before edge) ... I have to fix it (for what is possible) ... it's like in Grails.org web site, so for me it's enough
• done merge (and updated with my changes) with cssfix styles by Ronny ... done, mostly thanks to work done by Ronny to keep scaffold styles inside common styles
• add scaffold-mobile to simplify overriding values at lower resolutions (the same used in the mobile.css), try and tell me if you like it
• check scaffold toolbars to wrap line is too much elements are present (mainly at lower resolutions) ... ok, all is good
• scaffold list pagination seems ok

Other updates (2016-01-07/08), committed but still not visible in static test pages:

• hi-lite color in Scaffolded Lists, from #E1F2B6 (in HSV: 77, 25, 95) to #D3F2B6 (in HSV: 91, 25, 95) , aligned with main color, but with same Saturation and Value as previous color and other light colors in the page
• flexbox, some note:
  • custom style "main-container" is a flexbox container style, and has been defined to be used for example by the html or body tag but currently it's not used (it's here only just for convenience)
  • ordering of page blocks (order style) could be removed if elements already have the right position in page flow, but it's better to keep them to show its usage and to simplify change/override at different resolutions
• general notes:
  • some styles are defined for some variants of the same name, like "#header, header .header", "#footer, footer, .footer", "nav, .navigation", etc, but only to provide more freedom in defining elements in pages (by id, by standard tag, by custom class); for example header and footer could instead be defined as div but with the right id or custom class (I just tried those custom classes and all works); of course unneeded styles could be removed later. Tell me if this seems an unwanted noise in styles.
  • after brief tests on iPhone 4.x all seems to be good, but more tests on Apple platforms would be appreciated.

Other updates (2016-01-11), committed but still not visible in static test pages:

• to reduce some css noise, removed styles of header and footer div by id
• removed commented styles
• make some test (but not committed) to have even near-empty pages use a minimum height of the page by defining a min-height: 20em; to #page-body / #page-content / .content / etc ... ok, but for best results with current styles it's better to not assign instead to body or html (just for info); note that lower toolbars like action scaffold buttons Edit / Delete currently won't go at the bottom of related container (with flexbox this could be done in a simpler way);
• another test with min-height for "content" for example, wrap contents (title and text) of Bar view inside a div with class="content" and then it shows better (more page used) and the footer is at the bottom (just for info, if useful)
• check styles with postcss-cli: tried with cls && postcss --use autoprefixer --autoprefixer.browsers "> 5%" -r *.css but it needs a minimal Node.js project setup ... I'll do it later
• check styles with an CSSLint (Node.js version) or an online service like csslint ... ok, got some suggestions for further enhancements, for example: remove universal selector, remove !important styles, disallow overqualified elements, and few others ... I'll do in a later release, because some style settings must be updated after these changes

@rlovtangen Hi Ronny, some updates (I think now we are near to final version):

• the idea to split navigation header and footer in includes/templates is main to show in Grails the right way to do this (should be cached in PROD mode, right ?), but I agree that with current content can stay as is (or we can revise later); anyway for readers, here a useful sample to do it
• the question to include message-error.css only in errors.css and scaffold.css using asset tag was to try to do a little cleanup in main.css, but I'm ok even as is
• div for skip-to-content and spinner moved from index.gsp to main layout (main.gsp), is it ok the same (scaffolded pages doesn't seem to use those div) ?
• some scaffold-related questions (could be discussed/done later):
  • all scaffold changes/updates, is it better to open issues in the plugin ? I can do it later ...
  • in scaffold create, to better align label for not required fields with others, why not add a span with two spaces inside, like what is done for required fields ?
  • in scaffold upper toolbar, remove button with link to Home (now in main menu) ? Or maybe enable/disable with a flag ?
  • in scaffold pagination, insert a blank space char so at least it has a content and so the height is like other scaffold toolbars (without hard-coding it)
  • scaffold generated pages, could be wrapped inside a container like in my test pages
  • scaffold generated container for form elements could be updated to use flexbox too (in a later release) but with a vertical flow of elements

After this, last, things to do now are:

• cleanup, merge contents in original/new files (but fewer files than now) and rename main_modularized.css into main.css
• build jar for updated profiles and install in local maven repository (so Grails snapshot can use them), and create a new test webapp (from scratch) and ensure everything is good
• pull request to original profiles repository

Suggestions/feedback ?