Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating Columns with Blocks #219

Closed
georgeolaru opened this issue Mar 9, 2017 · 39 comments
Closed

Creating Columns with Blocks #219

georgeolaru opened this issue Mar 9, 2017 · 39 comments
Labels
Customization Issues related to Phase 2: Customization efforts [Type] Enhancement A suggestion for improvement.

Comments

@georgeolaru
Copy link

With the current mockups UI, you’ll be able to easily rearrange blocks order.

Considering this flow, I’m looking for a solution to create simple two or three grid columns layout.

Not sure if this is the target of the Gutenberg project, but I would love to get a similar feature implemented as I’ve seen so many cases where I need an easy way to create such a layout for pages.

I already built an initial prototype in Invision where you can take a look: https://invis.io/3FAS8VQE8#/222711568_Creating_Columns_-_0

creating columns - 1
creating columns - 2
creating columns - 3
creating columns - 4
creating columns - 5
creating columns - 6
creating columns - 7

@jasmussen
Copy link
Contributor

😍

This is ⭐️ ⭐️ ⭐️ ⭐️ ⭐️ work. STELLAR mockups, I love it. This is exactly the sort of rich layout we're hoping a block-first UI can accomplish.

CC: @melchoyce you'll want to see this for the customization focus later in the year.

For the V1 editor, I'm afraid columns like this is out of scope. That's not a "no" — rather, we need some technical foundations to be solid first, before we commit to the really interesting stuff. But it might be a V1.1, or at the very least something for the customization folks later on in the year. Even before that, it would be good to keep this UI in mind, so that perhaps a plugin can add this even earlier.

Thank you for this!

@jasmussen jasmussen added Design [Type] Enhancement A suggestion for improvement. labels Mar 9, 2017
@simonrjones
Copy link

My feedback would be this starts to turn the editor into a layout tool rather than a content editing tool. Things like responsive design make layout control very difficult in CMSs and IMHO are best left to the theme designer / developer. I could certainly see options like "2-col" but actually dragging dividers to basically allow users to lay content out seems outside the scope of a content editor tool to me.

Not sure if that philosophy is in agreement with how Project Gutenberg sees itself?..

@ellatrix
Copy link
Member

ellatrix commented Mar 9, 2017

I think these are also interesting ideas for galleries. We may not want to keep the current fixed column approach and allow rows to have different amounts of columns. Just like text columns, a good gallery block sounds like something that could become very complex.

@jasmussen
Copy link
Contributor

Not sure if that philosophy is in agreement with how Project Gutenberg sees itself?..

Later in this year, the customizer will be a focus:

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

Columns are very likely to be part of that.

Gutenberg is for writing and laying out a post first and foremost. That's what we have to get right. But the editor is likely to share some DNA with the customizer later on, specifically when it comes to some of the blocks, and controls probably too. As such, this mockup is still helpful for the customization focus.

@melchoyce
Copy link
Contributor

Very elegant solution. Feels a lot better than dropping in a bunch of column blocks, IMO. I can also see the column widths snapping into specific percentages (so 50% / 50%, or 33% / 66%, or 25% / 75%, etc.). Columns will almost certainly be a feature in the updated Customizer :)

@georgeolaru
Copy link
Author

@jasmussen glad you like it — a 1.1 version would be great too :)
@simonrjones extending WordPress further from the default Blog Posts automatically implies the need of multi-column layouts for presentation pages. I would prefer to tackle this feature upfront, rather than letting every developer do it on his own (see the multitude of page builders plugins).
@melchoyce definitely the column widths should snap to specific steps (even if that would be a 6 or 12 columns stepper).

@melchoyce
Copy link
Contributor

I wonder if we can figure out a way to make column snapping theme-dependent. Something we'll want to ponder in the next couple months as Gutenberg progresses.

@georgeolaru
Copy link
Author

There should be a default both in terms of column snapping and for the CSS grid (including responsive part). Then the theme should be able to override them.

We're already working on a plugin integrated into TinyMCE Editor who share some of those behaviors — only that it's not a drag&drop block based, rather a row/column approach. It's called Gridable and it might be worth giving it a try.

@samikeijonen
Copy link
Contributor

+100 from me. I really like the idea of column blocks.

@jasmussen
Copy link
Contributor

Is this a candidate for CSS grids?

https://css-tricks.com/getting-started-css-grid/

@simonrjones
Copy link

Thanks for the clarifications on my comments.

CSS grids would be fantastic and are a very good fit for column layouts. However, I am guessing wide browser support is some time away which may be an issue for WP (works today in latest Firefox). Some very good resources on CSS grids over at Rachel Andrew's site and some nice stuff on Jen Simmons site.

One way or another adding columns means CSS as well as HTML, so ideally we need simple and standards-based patterns for this to make it easier for theme developers. This could be encapsulated in code so a default starting point can be defined which can then be overridden (e.g. if someone wants to use Foundation to build their site so needs columns set up in the Foundation way).

@melchoyce
Copy link
Contributor

I good rule-of-thumb I've heard is:

  • Grid for site structure/layout
  • Flexbox for content within that layout

A good article on flexbox vs. grid by Rachel Andrew: https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-grid-or-flexbox/

@georgeolaru
Copy link
Author

Based on the current browser compatibility requirements of WordPress, I think a standard "row+columns" grid as the default system (e.g. Bootstrap or Foundation) would provide the best balance between simplicity and flexibility.

@jasmussen jasmussen added the Customization Issues related to Phase 2: Customization efforts label Apr 20, 2017
@litka
Copy link

litka commented May 10, 2017

I agree that the standard row + columns structure is the way to go.

It would be nice if there was the option to choose the grid system in the WordPress settings:

  • Default
  • Bootstrap
  • Foundation
  • Custom

The Default grid system would include supporting CSS (as part of the TwentyEighteen theme?), while the other options would rely on the theme for CSS. Essentially, WordPress outputs the grid classes and the theme provides the styles.

The custom option would allow you to set the class names for the row and columns. A close UI comparison for what I'm describing is the current permalink settings screen.

@maddisondesigns
Copy link

Multi column layouts are a must-have! At the moment, Gutenberg isn't solving any issue. You still end up with one long column of content. The whole reason page builders are so popular, and why hundreds of thousands of people are using them, is because they provide the ability to easily make multi-column layouts. Without this functionality, you're not providing any reason to use Gutenberg over a page builder plugin.

@westonruter
Copy link
Member

westonruter commented Jun 20, 2017

@maddisondesigns Yes, doing multi-column layouts is planned for V2. The foundational work for them is being done now in V1. In fact, the underlying parser for blocks does support nesting, but it's just that the UI for displaying nested blocks hasn't been implemented yet. See also #428.

@maddisondesigns
Copy link

@westonruter Great to hear that it's being planned. Would love to see it get implemented in V1 though. I'd be confident in saying that this will be one of the first things people complain about, if it gets added to core without being able to create multi-column layouts. At the moment, Gutenberg doesn't do anything that can't be done in the existing TinyMCE. Sure, it certainly looks heaps prettier and has some cool functionality such as being able to move blocks of text up and down easier, but again, this is basically just the same as copying 'n pasting a block of text in TinyMCE. A little more cumbersome, sure, but the end result is the same. I thought the major goal behind Gutenberg was to provide a significant improvement in how you can lay out content, not just to provide a prettier editor. It seems counter-intuitive having a block based interface if you can only have one block per line/row. It obviously goes without saying, I understand the extra work involved,, but I think people would much rather see this kind of functionality when it first rolls out, even if it means not getting added to core for another couple of releases.

@jasmussen
Copy link
Contributor

I appreciate the excitement and urgency to wanting columns. We feel the same urgency. It's not about not wanting columns, it's purely about managing resources at this point. We will get to it, that's absolutely a meta-goal. If only we could snap our fingers and make it happen ;)

@dmccan
Copy link

dmccan commented Jun 23, 2017

Even without columns, Guttenberg is a huge step forward and I am very impressed, but I'd agree that including them is essential for V1 and it would be worth delaying V1 until that feature is ready.

If you add the active installs for the top three page builders and the first page of columns plugins from .org you get more than 1,5 million ... and if you add in premium that is not half of it. The point is that I don't think an editor without columns meets current needs. If Guttenberg is released without columns then I'd imagine a dozen plugins would show up to add them on the first day. Then when added subsequently the user has something to manage.

Guttenberg will be wonderfully disruptive, but I'd urge that the essential building blocks are all in place. +1 to the excitement and urgency.

@khromov
Copy link

khromov commented Jun 24, 2017

I'd like to challenge the notion of "needing" support for complex layouts in Gutenberg.

The proposed combination of columns and nesting is a rabbit hole that won't end until the user experience is really bad for people actually writing content. Any "full-fledged" page builder is testament to this.

Not everyone builds layouts with page builders, and having that sort of page structure in the database is very problematic. It'd be much better to focus on having a good API for extending Gutenberg and be very cautious about adding complex features to the core of Gutenberg.

@dmccan
Copy link

dmccan commented Jun 24, 2017

@khromov - It looks like you may be replying to my comment. I'm advocating columns, not complex layouts, nesting, or a full page builder. I sometimes need columns when writing content. I refuse to use shortcodes, so I have two choices: create nested divs by hand, which is a horrible user experience and a great distraction to actually writing content, or use a page builder, which is usually overkill. I think that using columns is very common, perhaps more common than embedding a video.

In any event, my understanding is that columns are on the roadmap. I'd like to see them in V1 instead of V2. Like you, I appreciate that care is being taken to lay a good foundation.

@jasmussen
Copy link
Contributor

jasmussen commented Jun 24, 2017

One of the aspects of "columns" to keep in mind is that it's not just a matter of desktop layouts. It's having a system that scales from mobile to desktop.

Is it column-count in CSS? If we used that it would be very easy to create someting responsive quickly, but then you wouldn't be able to lay out content in the column you wanted at specific breakpoints.

Is it CSS Grid or flexbox? Then we'd want to make sure that users had proper responsive options so results were predictable across devices, and not only that but we'd want to let WordPress themes know about these features so it could adapt accordingly.

We know we want columns. In fact 3rd party plugins can build column blocks today. But it's a complicated feature with a slew of aspects that need to be properly in place for it to work, and without more contributors on the project, it's unlikely to happen in V1.

@dmccan
Copy link

dmccan commented Jun 26, 2017

@jasmussen - Yes. I appreciate that columns are on the roadmap and perhaps there will be some insights from the gallery block that will help.

@mor10
Copy link
Contributor

mor10 commented Jul 2, 2017

This feature should be built with modern layout tools in mind. Creating unnecessary containers to create column layouts now will limit our ability to use modern technology in the future.

For simple one-dimensional layouts like columns, we can use either flex or grid. I lean toward grid for the simple reason that while we're just talking about columns today, down the road users will want more advanced grid control so we should lay the groundwork now.

As for browser support, both flex and grid have broad support across modern browsers and fall back cleanly in older browsers. It is also relatively straight-forward to provide fallbacks for older browsers.

I strongly discourage adopting a classic framework approach of nesting elements to make this work. It will result in legacy cost almost immediately and hinder future layout work.

Adopting grid here opens the door to unexplored territory where layouts are concerned. I'll try to find time next week to write up something more comprehensive about what's possible here. In the meantime, this is relevant: https://rachelandrew.co.uk/archives/2017/07/01/you-do-not-need-a-css-grid-based-grid-system/

@Kelderic
Copy link

Kelderic commented Jul 6, 2017

My concern with this is that it locks users into one specific type of HTML structure. All themes will have to then adapt to support this structure. Is it nested divs? Nested sections? Do we use floats for backwards compat (because lots of sites need that. Win7 still has a huge marketshare, which means IE11 still does as well, and IE11 doesn't play well with flexbox), or go with flexbox/grid for the future. Do we give users the option to change (and then get back into them having to know CSS)? This could get dangerous quickly.

@gschoppe
Copy link

This is a great example of why Gutenberg data simply shouldn't be stored as raw HTML... if it were stored in a standards-compliant method, like mobiledoc, then columns would simply be objects, and rendering them would be easily overridable by any theme. If themes wanted to use a legacy structure, like row/col, they could. If they wanted to use grid, they could. if they wanted to use flex, they could. If they wanted to use whatever tech comes next, they could. A true object storage method would make content future-proofed. HTML + Comments just cant.

@alaarihan
Copy link

+1 this feature is very important to everyone .

@ckluis
Copy link

ckluis commented Sep 29, 2017

I'm getting ready to redesign a big B2B website. Right now it uses Divi and I would love to be able to use Gutenberg for the redesign or I'll be stuck with Divi again for a number of years.

If columns aren't addressed - we'll be forced to continue with the a "non-WordPress" approach to building our WP-site. I'm also curious if Gutenberg will include a few "page layout" presets to override incompatible themes and include base layouts.

@radogado
Copy link

Grid based on Flexbox, please. Not CSS Grid, because it requires container CSS update for any changes. Flexbox will work by just adding blocks. Thanks.

@hedgefield
Copy link

Absolutely would love this feature. Great discussion here, looking forward to seeing how it develops.

@mhenrylucero
Copy link

I love this. Especially the ability to resize the columns. I specifically like the fact that you can control layout. I don't think this is a weakness at all. It's exactly what I've been wanting in Gutenberg and frustrated that I can't do already, given that so many other similar tools offer this feature.

@mhenrylucero
Copy link

So I just updated the Gutenberg plugin, and tried to mess with columns in it. I created a new post and added a column layout block, and tried to increase it using the slider. Every time I try to do this, it displays the error: "This block has encountered an error and cannot be previewed."

@jasmussen
Copy link
Contributor

Thanks for the bug report, @mhenrylucero — I've opened a separate ticket for it #3710.

@aduth
Copy link
Member

aduth commented Feb 8, 2018

#3745 was merged earlier this week, which partially implements the proposal here.

From what I can tell, the remaining tasks are largely improved UX around rearrangement of blocks into columned layouts, am I correct? Am I correct in assuming this would be better suited for the Customization focus following an initial merge proposal?

@jeffpaul jeffpaul added this to the Future milestone Feb 8, 2018
@mtias
Copy link
Member

mtias commented Mar 7, 2018

Going to close this which will remain as a reference for further improvements in customization.

@mtias mtias closed this as completed Mar 7, 2018
hypest added a commit that referenced this issue Nov 2, 2018
…roid-symlink

Use a temporary symlink to parent wpandroid
ntwb pushed a commit that referenced this issue May 31, 2020
gziolo pushed a commit that referenced this issue Dec 18, 2020
* chore(package): update stylelint to version 7.0.0 (#83)

* fix: Deprecated `no-missing-eof-newline` rule. Use the new `no-missing-end-of-source-newline` rule instead. (#84)

* fix: Fixed font-family-name-quotes` test warning message in `values.js`. (#85)

* feat: Add `property-no-unknown` rule. (#86)

* Update install instructions to add `--save-dev`

* chore(package): update stylelint to version 7.2.0 (#87)

* chore(package): update AVA to version 0.16.0 (#88)

* chore(package): update eslint-config-stylelint to version 4.0.0 (#89)

* chore(package): update ESLint to version 3.0.0 (#90)

* feat: Add `at-rule-no-unknown` rule. (#91)

* feat: Add `selector-class-pattern` and `selector-id-pattern` rules. (#92)

* Prepare 9.0.0

* Merge branch 'master' of github.com:ntwb/stylelint-config-wordpress

* feat: Add SCSS preset config (#96)

* feat: Add SCSS preset config

* fix: Include README.md and scss.js in package.json files list

* test: Add initial SCSS tests

* Prepare 9.1.0

* Prepare 9.1.1

* refactor: Use ECMAScript 8/2017, use async/await instead of returning a promise and move css code out of tests to individual files

* feat: Use ECMAScript 8/2017

* refactor: Use async/await instead of returning a promise and move css code out of tests to individual files

* chore(package): update dependencies (#100)

https://greenkeeper.io/

* chore: Add NodeJS 7 to Travis & AppVeyor CI test matrix's (#102)

* chore(package): update stylelint to version 7.5.0 (#103)

* chore: Add NodeJS 7.x changelog note

* feat: Add `selector-no-empty` rule. (#104)

* chore(package): Update `eslint-plugin-ava` to version 4.0.0 (#105)

* fix: SCSS: Dissalow `@debug` at-rules.

* fix: SCSS: Add `scss/selector-no-redundant-nesting-selector` rule.

* Update ava to the latest version 🚀 (#109)

* chore(package): update ava to version 0.17.0
* refactor: Include path to test fixtures

https://greenkeeper.io/

* chore(package): update npm-run-all to version 4.0.0 (#111)

https://greenkeeper.io/

* Update eslint-config-stylelint to the latest version 🚀 (#110)

* chore(package): update eslint-config-stylelint to version 6.0.0
* refactor: Update tests per latest `eslint-config-stylelint`

* chore: bump minimum NodeJS requirement to 6.9.1 and drop NodeJS 4.x (#118)

* chore: Drop NodeJS from Travis CI

* chore: Drop NodeJS from AppVeyor

* chore: Bump minimum NodeJS requirement to 6.9.1

* chore: Update remark and remark plugin packages (#120)

* Update ava to the latest version 🚀 (#112)

* chore(package): update ava to version 0.18.0

https://greenkeeper.io/

* chore: update ava to version 0.19.1

* Updated and removed deprecated stylelint rules for 8.0 (#116)

* Updated and removed deprecated stylelint rules

* Removed deprecated unit test

* chore: Add require NodeJS 6.x LTS changelog note

* chore: Update changelog for changes made in #116

* refactor: Switch from AVA to Jest for tests. (#122)

* tests: Fix `media-query-list-comma-space-before` tests

* refactor: Switch from AVA to Jest for tests.

* chore(package): update stylelint to version 7.10.1 (#123)

* chore(package): update stylelint-scss to version 1.4.4 (#124)

* chore(package): update eslint to version 3.19.0 (#125)

* refactor: Switch from eslint-plugin-ava to eslint-plugin-jest. (#126)

* refactor: Switch from eslint-plugin-ava to eslint-plugin-jest.

* docs: Add changelog entry for switch from eslint-plugin-ava to eslint-plugin-jest

* Fixed: Added `stylelint-scss` plugin @if/@else placement rules. (#127)

* fix: Ignore proprietary `DXImageTransform.Microsoft` MS filters (#128)

* docs: Update CHANEGLOG

* Merge branch 'master' of github.com:ntwb/stylelint-config-wordpress

* feat: Prepare `10.0.0` release.

* fix: Remove stylelint v8 deprecated rule `rule-non-nested-empty-line-before` from SCSS config. (#130)

* feat: Prepare `10.0.1` release.

* fix: Add `@import` to `ignoreAtRules` option in `at-rule-empty-line-before` rule for SCSS config (#131)

* feat: Prepare `10.0.2` release.

* chore(package): update eslint-plugin-jest to version 20.0.0 (#134)

* chore(package): update jest to version 20.0.0 (#135)

* docs: Update docs to reflect the new repository home

* docs: Update docs to reflect the new repository home at https://github.com/WordPress-Coding-Standards

* chore: Update changelog noting repo location change

* fix: Add `declaration-property-unit-whitelist` rule to enforce unitless `line-height` values. (#133)

* fix: Include CSS config `at-rule-empty-line-before` options in SCSS config. (#139)

* Fix: Allow `px` units in `line-height` values for the `declaration-property-unit-whitelist` rule. (#140)

* feat: Prepare `11.0.0` release.

* Updated README section links (#141)

* chore: Add NodeJS v8 to Travis CI build matrix (#143)

* chore: Switch from Node.js "current v7.x branch to v8.x for AppVeyor CI (#145)

* chore: Drop Node.js v7.x branch from Travis CI (#146)

* refactor: Switch to shared `recommended` config from `eslint-plugin-wordpress` for ESLint configuration. (#147)

* refactor: Switch to shared `recommended` config from `eslint-plugin-wordpress` for ESLint configuration.

* chore: Use `git://` protocol

* chore: Include a commit hash

* chore: Update ESLint to version 4.1.0

* chore: Update ESLint to version 4.x

* refactor: Update indentation per updated ESLint version 4.x `indent` rule.

* chore: Add a `dry-release` npm task (#149)

* chore: Move ESLint config from `package.json` to `.eslintrc.json` file. (#152)

* chore: Use the latest npm for all Node.js Travis CI jobs

* chore: Add npm 5's `package-lock.json` file

* chore: Add Greenkeeper support for npm 5.x's `package-lock.json` file.

* tests: Add Jest snapshot tests

* tests: Update Jest snapshots

* chore(package): update stylelint to version 8.0.0

* fix: Add initial support for long comments in headers of WordPress theme `style.css` files. (#151)

This change allows for longer comments in themes header:
• URLs longer than 80 characters
• Descriptions longer than 80 characters
• Tags longer than 80 characters

Fixes #150.

* tests: Add some bbPress Jest snapshot tests.

* tests: Update Jest SCSS tests to use SCSS config

* tests: Update Jest SCSS test snapshots

* tests: Add some BuddyPress Jest snapshot tests.

* chore: Use the `runInBand` flag for Jest Travis CI jonbs

* tests: Update snapshots

* tests: Update tests to account for new rules introduced in `stylelint-config-recommended`.

* chore: Add `stylelint-config-recommended` extend base configuration from it.

* docs: Update CHANGELOG with `stylelint-config-recommended` changes

* docs: Remove the styleguide from the repo.

We should have one canonical source of truth and not try to maintain two instances.

https://make.wordpress.org/core/handbook/best-practices/coding-standards/css/

* refactor: Use `scss/at-rule-no-unknown` in `scss` shared config.

* feat: Prepare `12.0.0` release.

* chore(package): update remark-cli to version 4.0.0

* chore: Update `package-lock.json`

* chore(package): update remark-preset-lint-recommended to version 3.0.0

* chore: Update `package-lock.json`

* fix(package): update stylelint-scss to version 2.0.0

* chore: Update `package-lock.json`

* chore: Add `stylelint-find-rules`

* chore(package): update stylelint-find-rules to version 1.0.1

Closes #168

* chore: Update package-lock.json

* chore: Updated `stylelint` peer dependency version to `^8.0.0`.

* chore(package): update jest to version 21.0.0

* chore: Update `package-lock.json`

* chore(package): update eslint-plugin-jest to version 21.0.0

* chore: Update `package-lock.json`

* tests: Remove Jest snapshots (#176)

* docs: Update CHANGELOG

* Use toHaveLength() in tests

Not only does it check the length of something is exactly a certain integer, it also checks that the length property exists in the first place.

Addresses lint issues identified at https://www.bithound.io/github/WordPress-Coding-Standards/stylelint-config-wordpress/e2bbe0d9c867cc95da6de5b3bff2a73742135fb6/files#failing

* chore: Remove Greenkeeper lock file configuration from `.travis.yml`

* chore: Remove `package-lock.json`

* chore: Add `package-lock.json` to `.gitignore`

* chore: Add `.npmrc` file to prevent npm creating a `packake-lock.json` file.

* chore(package): update jest to version 22.0.0

* chore: update `.editorconfig` per upstream WordPress' `.eitorconfig`

See https://core.trac.wordpress.org/browser/trunk/.editorconfig

* chore: use tabs for indentaion in `package.json` per WordPress coding standards

* chore: use tabs for indentaion in `.eslintrc.json` per WordPress coding standards

* chore: use `* text=auto` in `.gitattributes`

* chore(package): update remark-cli to version 5.0.0

* chore: standardize Jest tests

* chore: add commitlint

* chore: bump minimum Nod.js required version to `8.9.3`

* test: improved `no-duplicate-selectors` tests

* feat: update `stylelint` to `9.1.3`

* chore: updated `stylelint-config-recommended` to `2.1.0`

* chore: updated: `stylelint-scss` to `2.1.0`

* feat: update `selector-pseudo-element-colon-notation` to use `double`

* feat: prepare `13.0.0` release

* fix(package): update stylelint-scss to version 3.0.0

* docs: update changelog

* test: add SCSS tests for _extends_ shared configs

This test ensures that the rules included in the _shared configs_ inherited by this SCSS _shared config_ via the `extends` option are in actual fact included.

The `stylelint-config-wordpress/scss` shared config _extends_ the `stylelint-config-wordpress` shared config, which in turn _extends_ the `stylelint-config-recommended` shared config.

* docs: update changelog

* test: standardize invalid tests warnings test name verbiage

* test: use Jest snapshots for invalid tests

This change simplifies the maintainence of the invalid CSS and SCSS tests

* feat: the `/scss` config now extends `stylelint-config-recommended-scss`

* feat: update `stylelint` to `9.2.0`

* docs: add basic _extends_ shared config references

* Update to node 10 in .travis.yml

* Drop Node.js v9.x

* Update appveyor.yml

* chore(package): update @commitlint/cli to version 7.0.0

* chore(package): update @commitlint/config-conventional to version 7.0.1 (#203)

Closes #201

* chore(package): update npmpub to version 4.0.1

Closes #204

* feat: update stylelint to `9.5.0`

* chore: update ESLint to `5.4.0`

* chore: update Jest to `23.5.0`

* chore: update `eslint-plugin-jest` to `21.21.0`

* chore: update `npmpub` to `4.1.0`

* chore: update `npm-run-all` to `4.1.3`

* chore: update `stylelint-find-rules` to `1.1.1`

* chore: update remark presets: • `remark-preset-lint-consistent` to `2.0.2` • `remark-preset-lint-recommended` to `3.0.2`

* feat: update `stylelint-scss` to `3.3.0`

* chore: add `npm-package-json-lint`

* chore: add `@wordpress/npm-package-json-lint-config`

* chore: update `package.json` property order

* feat: Prepare `13.1.0` release (#208)

* chore(package): update husky to version 1.1.2 (#210)

Closes #209

* chore(package): update remark-cli to version 6.0.0 (#211)

* chore(package): update eslint-plugin-jest to version 22.0.0 (#212)

* Update stylelint-find-rules to the latest version 🚀 (#213)

## The devDependency [stylelint-find-rules](https://github.com/alexilyaev/stylelint-find-rules) was updated from `1.1.1` to `2.0.0`.
This version is **not covered** by your **current version range**.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

* chore(package): update stylelint to version 10.0.1 (#215)

Closes #214

* chore: update @commitlint

* chore: update `stylelint-config-recommended` to v2.2.0

* chore: update `stylelint-scss` to v3.6.0

* chore: update devDependencies

* feat: prepare `14.0.0` release

* chore(package): update husky to version 2.2.0

Closes #219

* chore: update `husky.hooks` config in `package.json`

* chore(package): update @wordpress/npm-package-json-lint-config to version 2.0.0

* chore(package): update husky to version 3.0.1

Closes #227

* test: fix type in snapshot test

* chore(package): update @commitlint/cli to version 8.0.0

* chore(package): update @commitlint/config-conventional to version 8.0.0

* chore(package): update remark-cli to version 7.0.0

* chore(package): update packages to latest versions

* chore(package): restore peerDependencies stylelint versions

* chore(node): bump minimum Node.JS to LTS version 10.x

* ci: use `npm test` to include lint tasks in CI jobs

* docs: nocapital_S_dangit

* chore(package): update npmpub to version 5.0.0

* fix(package): update stylelint-config-recommended to version 3.0.0

* chore(package): update stylelint to version 11.0.0

* chore: update `peerDependencies` for stylelint 11.0.0

* docs: update changelog

* docs: fix stylelint removed compat version

* Update stylelint-config-recommended-scss to the latest version 🚀 (#238)

* Update eslint to the latest version 🚀 (#233)

* chore(package): update eslint to version 6.3.0

* chore: add `ecmaVersion: 2015,` to `parserOptions` ESLint config

* docs: update changelog

* chore: bump dependencies

* chore: add Node.js v12 to Travis CI test matrix, remove 8.x, min 10.x

chore: add Node.js v12 to Travis CI test matrix

* feat: prepare `15.0.0` release

* Merge pull request #241 from WordPress-Coding-Standards/update/find-rules

chore: update `stylelint-find-rules` to 2.2.0

* Update npm-package-json-lint to the latest version 🚀 (#242)

Update npm-package-json-lint to the latest version 🚀

* Use `@wordpress/scripts` (#231)

Use `@wordpress/scripts`

* chore: update `stylelint` to 12.0.0

* chore: update `stylelint-scss` to 3.13.0

* chore: update `stylelint-config-recommended-scss` to 4.1.0

* chore: update `husky` to 3.1.0

* chore: update `remark-cli` to 7.0.1

* chore: update `@wordpress/scripts` to 6.0.0

* Fixed: `selector-class-*` regex to account for numerals, case de… (#247)

Fixed: `selector-class-*` regex to account for numerals, case detection, and ensure kebab-case

* ci: add Windows to Travis CI (#248)

ci: add Windows to Travis CI

* chore: remove AppVeyor (#249)

chore: remove AppVeyor

* feat: prepare `16.0.0` release

* test: update comment fof scss-invalid test to eslint-jsdoc warnings

* feat: prepare `16.0.0` release

* fix: npm script temp workaround

* Merge pull request #251 from WordPress-Coding-Standards/greenkeeper/@wordpress/scripts-6.1.1

chore(package): update @wordpress/scripts to version 6.1.1

* Revert "fix: npm script temp workaround"

This reverts commit e409112e0e8f3965993e3f1b3a6ecc3c8ffdc8e0.

* Update husky to the latest version 🚀 (#252)

Update husky to the latest version 🚀

* Merge pull request #255 from WordPress-Coding-Standards/greenkeeper/stylelint-13.1.0

Update stylelint to the latest version 🚀

* Merge pull request #254 from WordPress-Coding-Standards/greenkeeper/@wordpress/scripts-7.0.0

Update @wordpress/scripts to the latest version 🚀

* chore(package): update @wordpress/scripts to version 7.1.2

* chore(package): update stylelint-scss to version 3.14.2

* chore(package): update stylelint-config-recommended-scss to version 4.2.0

* chore(package): update husky to version 4.2.3

* chore(package): update @commitlint/cli to version 8.3.5

* chore(package): update @commitlint/config-conventional to version 8.3.4

* Merge pull request #256 from WordPress-Coding-Standards/greenkeeper/remark-cli-8.0.0

Update remark-cli to the latest version 🚀

* Merge pull request #258 from WordPress-Coding-Standards/greenkeeper/remark-preset-lint-recommended-4.0.0

Update remark-preset-lint-recommended to the latest version 🚀

* Merge pull request #257 from WordPress-Coding-Standards/greenkeeper/remark-preset-lint-consistent-3.0.0

Update remark-preset-lint-consistent to the latest version 🚀

* Merge pull request #260 from WordPress-Coding-Standards/greenkeeper/@wordpress/scripts-8.0.1

* Merge pull request #264 from WordPress-Coding-Standards/greenkeeper/@wordpress/scripts-10.0.0

chore(package): update @wordpress/scripts to version 10.0.0

* chore: update `stylelint-scss` to 3.17.2

* feat: prepare `17.0.0` release

* refactor: rename `stylelint-config-wordpress` to `stylelint-config`

* refactor: rename `stylelint-config-wordpress` to `@wordpress/stylelint-config` in `package.json`

* refactor: remove `@commitlint` from `@wordpress/stylelint-config`

* refactor: remove `husky` from `@wordpress/stylelint-config`

* refactor: trim npm package keywords from `@wordpress/stylelint-config`

* refactor: remove `.editorconfig` from `@wordpress/stylelint-config`

* refactor: remove `npmpub` from `@wordpress/stylelint-config`

* refactor: remove `eslintConfig` from `@wordpress/stylelint-config`

* refactor: remove `remarkConfig` from `@wordpress/stylelint-config`

* refactor: remove `remark` from `@wordpress/stylelint-config`

* refactor: remove `engines` from `@wordpress/stylelint-config`

* refactor: remove `prettier.config.js` from `@wordpress/stylelint-config`

* refactor: remove `.gitattributes` from `@wordpress/stylelint-config`

* refactor: remove `.gitignore` from `@wordpress/stylelint-config`

* refactor: remove `.travis.yml` from `@wordpress/stylelint-config`

* tests: refactor tests in `@wordpress/stylelint-config`

* chore: add `.stylelintignore` for _invalid_ scss test fixtures in `@wordpress/stylelint-config`

* Revert "chore: add `.stylelintignore` for _invalid_ scss test fixtures in `@wordpress/stylelint-config`"

This reverts commit 05ab441.

* chore: add `.stylelintrc.json` for test fixtures in `@wordpress/stylelint-config`

* tests: update Jest snapshots in `@wordpress/stylelint-config`

* docs: update `docs/manifest.json` for `@wordpress/stylelint-config`

* chore: update `@wordpress/stylelint-config` package description

* chore: remove `devDependencies` from `@wordpress/stylelint-config`

* chore: remove package `scripts` from `@wordpress/stylelint-config`

* chore: remove superfluous `.stylelintignore` from `@wordpress/stylelint-config`

* chore: add Lerna `publishConfig` to `@wordpress/stylelint-config`

* Update Jest snapshots

* Backfill release dates in changelog

* Update package author

* Update readme

* Update comment to use renamed package name

* Rename tests to match other packages

* Remove stylelint `^10.1.0`, `^11.0.0`, and `^12.0.0` as peer dependency.

Co-authored-by: greenkeeper[bot] <greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Harley Oliver <[email protected]>
Co-authored-by: Heather B <[email protected]>
Co-authored-by: Gary Jones <[email protected]>
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Dominik Schilling <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Customization Issues related to Phase 2: Customization efforts [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests