Goal

This issues serves as overview and should help to track progress towards a stable D8 release and discussion on what to keep and what to toss.

Top priorities

  1. Removing Ruby dependency
  2. Removing sass-globbing but allowing it to be added back if needed. (we recommend using Ruby sass if you need globbing, the libsass alternatives are troublesome
  3. Allow for libsass.

Remaining Tasks

These need issues if they don't have one linked:

Settings

  1. Live reload: Replace with Browser Sync (partially done in HEAD)
  2. IE specific stylesheets: May be better to have these hacks in context in the sass files with HTML class prefixes?
  3. Breadcrumbs settings: How much of this functionality is needed? They are a OL list by default in D8.

Styles

  1. .page- and .section- class prefixes

Discussion

Default Styles?

Should we remove some of our default styling to make it more basic?

Libraries

The convention from D8 is to build up libraries of JS/CSS assets and only attach them to the elements that need them.

Propose we follow suit and do this with any component styles we choose to implement (ie. tabs * messages)

Styles

  1. There are a bunch of #id being used, can these be removed?
  2. Rename components to library and elements to components to make some more sense?

Tools

  1. SCSS or SASS syntax?Staying with SASS syntax for launch.
  2. Grunt vs Gulp, should we upgrade to Gulp or remove Grunt?Staying with gulp for launch.

Current look of a Basic unpublished page:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joelpittet created an issue. See original summary.

joelpittet’s picture

joelpittet’s picture

Issue summary: View changes
Bojhan’s picture

I thought the point of Basic is not to provide any styling for those standard elements.

joelpittet’s picture

I think that's right, there are "elements" folder with some styles but they aren't loaded.

Tabs are the only ones that have some style but that may need to be paired down some too.

Was thinking using some bourbon to inline the breadcrumbs, and that's all.

leahtard’s picture

Thanks for getting this started Joel! Here are some thoughts from me:

  • Default styles: Agree that we need some light to get started. The basic page layout have a defined structure when a user first installs.
  • Libraries: I like the idea of have some component specific libraries in place. This will also give people new to this concept something to use as a reference if they choose to build their own.
  • Styles: "There are a bunch of ids being used": Does this mean in the stylesheets? Are we going to go with the "data-bid" approach like we have in the most recent D7 release?
  • Styles: I agree with renaming "components" to "library". I actually had a new proposed folder structure which included that change. I have included below. Interested in thoughts from others :)
  • Tools: I am partial to the SASS syntax but understand that SCSS is becoming more popular. Maybe there is a way we can make this more configurable?
  • Tools: I am feeling good with Grunt right now. Unless Gulp gives us added benefits (I honestly don't know enough about it), I say we stick with that.

Looking forward to moving forward with this. I'll be pitching in wherever I can!

Cheers, Leah

Proposed Folder Structure

base

  • _reset.sass
  • _variables.sass
  • _mixins.sass
  • _typography.sass
  • _buttons.sass
  • _forms.sass
  • _messages.sass
  • _tabs.sass

libraries (formerly components)

  • bourbon
  • neat

components (Formerly elements. Files just showing an example of syntax.)

  • _component1--modifier1.sass
  • _component1--modifier2.sass
  • _block--copyright.sass
  • _block--logo.sass
  • _listing--image-grid-3.sass
  • _menu--main-menu.sass

nodes

  • _content-type--view-mode-full.sass
  • _content-type--view-mode-teaser.sass

layout

  • _layout.sass
  • _layout--header.sass
  • _layout--sidebar.sass

_config.sass
print.sass
style.sass (Only contains imports for folders above. All styles move to base folder.)

joelpittet’s picture

Issue summary: View changes

Got the page/section classes working (a bit of a guess that it's as it should be, please check).

And Browser Sync is working as long as you have caching turned off.

Haven't sorted out how to clear the theme registry, or if we need to. I've got a crazy idea but it will have to be done in a module because I need an alter hook. But going to try to have the page/render cache clear itself with grunt + custom cache tag of the template name.

@leahtard got some of the sass folder structure changes which is great and that's starting to shape up better.

Any ideas on theme registry rebuild?

leahtard’s picture

Hey Joel!

Section classes
I just pushed a small update. I noticed that a path like node/subpage/ would render a body class of "page-node/subpage". I added a str_replace so it would render as "page-node-subpage". This is how D7 Basic is currently being rendered.

Folder structure
I wouldn't mind any thoughts you, or anyone else, has on the new folder structure. I wanted something that worked well with: (1) The SMACSS folder structure and categorization in basic.libraries.yml, (2) Sass compiling with sass-globbing. (3) The ability to work with libraries.

Right now, we have two libraries in place for messages and tabs and I am not happy with how the files are just placed in the sass folder root. They make sense in the components folder but we obviously don't want them compiling to the global components.css. Don't know what is best here?

Theme registry rebuild
I can't say for sure, but I think was initially implemented to address D7 caching while developing your theme. So you wouldn't have to clear cache every time you wanted to see an update. With the new development mode for Twig, is this still needed?

Cheers, Leah

joelpittet’s picture

@leahtard it seems if you put the site in 'dev mode' you don't need the clear cache but if you add new templates or rename them you will want to rebuild the registry. I'd really love if I could find a way we could turn that off/on through the theme or UI someplace.

Ideally we could clear cache and rebuild theme registry all within a drush script or something that could watch the theme for file changes. I think I'll open another issue for that.

Thanks for fixing the section class names!

RE: folder structure. Maybe an examples folder nested in components that's not globbed? or component_examples if you want to **/* it.?

  • joelpittet committed d7a1c7a on 8.x-1.x
    Issue #2608470 by joelpittet: Prep and comment out the clear registry...
joelpittet’s picture

I've commented out the clear registry feature and added the equivelent code stub for it for D8. But it doesn't seem to be working:(

arkjoseph’s picture

For those that enjoy GULP, Ive successfully transitioned to GULP from Grunt and will be posting a github link shortly.

arkjoseph’s picture

@joelpittet - Is there a reason why base.sass does not contain a list of imports all in one file?

Current structure...

  • base.sass -> @import "base/*"
  • component.sass -> @import "components/*"
  • layout.sass -> @import "layout/*"
  • theme.sass -> @import "theme/*"

Proposed structure and slightly more DRY

base.sass ->

  • @import "base/*"
  • @import "components/*"
  • @import "layout/*"
  • @import "theme/*"
arkjoseph’s picture

@leahtard - messaging.sass, print.sass, and tabs.sass.

Does it seem okay to put theme in sass/components/default/

arkjoseph’s picture

Looking into theme registry rebuild solution. if anyone has suggestions on how to implement within basic.theme it would be great.

Thanks!

joelpittet’s picture

@arkjoseph I like that idea in #13 would you mind rolling a patch for that? @leahtard what do you think? I know that's how I do that setup usually.

re #14 print doesn't belong in components but messaging and tabs sure does. Not sure it needs to be in a sub folder.

Rebuild can be tricky, I was thinking of re-inventing that a bit.

We will likely be working on Basic on Friday 4pm PST at the Global Sprint Weekend and Saturday pacific time. Feel free to join us @arkjoseph. Likely going to jump on #drupal-pnw IRC channel.

leahtard’s picture

Hey Guys!

This folder structure is a new approach for me as well. Historically, we compile everything to a single .css file. This was my attempt to use the SMACSS library/folder structure. Am I missing a better way to go about this?

The only reason I complied them to separate files what so we could let sass compile them to separate .css files. This allows us to then utilize the SMACSS structure in the library:

global:
  version: VERSION
  css:
    base:
      css/normalize.css: {}
      css/base.css: {}
    layout:
      css/layout.css: {}
    component:
      css/components.css: {}
    theme:
      css/theme.css: {}
      css/print.css: { media: print }
  js:
    js/modernizr.js: {}

It's the same thing with messages.sass and tabs.sass. We are loading these through libraries to we actually want an individual .css file in the end:

tabs:
  version: VERSION
  css:
    component:
      css/tabs.css: {}

messages:
  version: VERSION
  css:
    component:
      css/messages.css: {}

I have definitely found it hard to wrap my head around this. We could do something with grunt that would move files around but then we are adding that as a dependancy.

I'm looking forward to polishing up the last little bits this weekend :)

Cheers, Leah

joelpittet’s picture

@leahtard actually second thought your new approach seems better for the SMACSS to be aggregated by drupal.

There could be a better way to organize some stuff maybe but I'm in agreement that the D8 way is likely a good approach.

joelpittet’s picture

@arkjoseph I use gulp too;) I'd like to make sure neither are a dependency for using Basic, but I personally wouldn't mind putting both starter files in Basic. As long as we can compile SASS without them both too.

I think the only thing that may cause a dependency lock would be autoprefixer implementation if we go with that.

If the other maintainers would prefer not to support both, I can understand that as well.

arkjoseph’s picture

Jowelpittet, sounds good. Ill see about integrating both starter files as long as the maintainers believe its the right way to go. Although ill be happy to take on this task if its the desire.

With that being said, I think ill need some assistance with grunt as I was having some issues running grunt and globbing but ill post back later with the error.

Apart from that, let me know if theirs anything else I can help out with.

joelpittet’s picture

Leah and I are the most active maintainers at the moment. We'll discuss bigger issues with the others but mostly we just take care of business;). And we'll all be at the sprint this weekend, I think, in the same office.

Use the non grunt way if it's giving you trouble but do share the troubles in another issue and maybe we can help.

johannez’s picture

After a discussion at the coding sprint, we decided to not include the rebuild theme registry feature on every page load in Drupal 8.
Due to the current state of the caching system, we couldn't find a way to do this in the theme without clearing the whole cache and only rebuild the theme registry.

If somebody really depends on this feature for their development workflow and prefers this over "drush cr", we can look into moving this into a separate module where you have more powerful hooks/services available to you.

joelpittet’s picture

Issue summary: View changes

Updated priorities, thanks @johannez

joelpittet’s picture

Issue summary: View changes
joelpittet’s picture

Issue summary: View changes

  • joelpittet committed d7a1c7a on 8.x-2.x
    Issue #2608470 by joelpittet: Prep and comment out the clear registry...
joelpittet’s picture

Status: Active » Closed (outdated)

Hasn't been touched in a while, closing