Voting starts in March for the Drupal Association Board election.
At present, the only way to configure breakpoints is through config.yml files in a theme's config/install folder. However, those configurations can only be made in the breakpoint YML config files before a theme is installed.
Once a theme is installed, the only way to edit the breakpoints is to use configuration management to export the breakpoint config, edit the file, then import it.
If a theme has a pre-set layout that isn't going to change, and breakpoints have been set up to match how images will be used in that layout, that workflow might be marginally okay.
However, many people working with a site's theme start with a base theme that doesn't necessarily have a specific layout and associated breakpoints. Creating a theme design with layout and appropriate breakpoints for image usage within that theme is an iterative process. Try something with the layout, see if it looks okay, tweak it, check it, and retweak it. Having to export breakpoint config files, edit them and import them within that iterative process would be very cumbersome.
Because we're getting down to crunch time with Drupal 8, right now we aren't going to be able to implement a robust visual interface for configuring breakpoints, as envisioned in:. It's worth taking a look at that issue, as there are some valid comments, but what we need right now is a very simple UI for breakpoint configuration.
The Drupal 7 Breakpoints module do not visually demonstrate breakpoints, even though they do provide an interface to associate a set of media queries together into a group. https://drupal.org/project/breakpoints
While that would allow themers to enter the media queries for a breakpoint group, clone a breakpoint group, edit a breakpoint group, deleted a breakpoint group, etc (all that CRUD), the Drupal 7 breakpoint UI has proven difficult to use. As well, setting up any UI this late in the Drupal 8 cycle may be difficult.
Because we are implementing the current version of the picture element (picture.responsiveimages.org) and supporting that with the Picturefill 2.0 Polyfill (http://ericportis.com/posts/2014/srcset-sizes/), which allows for the new sizes attribute, it is also important for sizes to be able to configured for breakpoints. That is currently being handled in the revised responsive images UI, so we don't need to handle that here. For reference, here is a good article that explains the srcset and sizes UI:
It cannot be emphasized enough that without basic configuration abilities, it will be very, very difficult for anybody to set up responsive images on a Drupal 8 site.
Since a breakpoint UI is out, breakpoints must be configured through another means. Modules and themes can provide a EXTENSION_NAME.breakpoints.yml in their root directory. These are discovered using the plugin system and YAML discovery.
If at some point in the future there was a desire to make a UI for breakpoint groups (in 8.1 or 8.2 for example), it would be possible to implement a module that adds to the definitions using the hook migrate breakpoint settings from an info file to CMI.
Another benefit of this approach is that it would allow breakpoints to be edited in code, rather than in a UI. This is probably an easier workflow, as most media queries for breakpoints with CSS or SCSS files will likely be handled in code by themers as well.
Example breakpoints.yml file
stark.mobile: label: mobile mediaQuery: '(min-width: 0px)' weight: 0 multipliers: - 1x stark.narrow: label: narrow mediaQuery: 'all and (min-width: 480px) and (max-width: 959px)' weight: 1 multipliers: - 1x stark.wide: label: wide mediaQuery: 'all and (min-width: 960px)' weight: 2 multipliers: - 1x
By default breakpoints are placed in a group with the same name as the provider - in the above case that would be 'stark'. Custom groups can be created by adding a group key to the breakpoint definition.
User interface changes
- Breakpoint module has been completely rewritten.
- ResponsiveImageMapping configuration entity storage of mappings has been altered to avoid storing dots in configuration key names
- In changing the ResponsiveImageMapping entity added new methods to make it easier to manage them