This is a follow up task to #1734642: Move breakpoint module into core . Please refer to http://drupal.org/node/1803874 first. Some decisions need to be made before a standard issue summary can be created. With the addition of breakpoints to core it needs to be decided if a theme will inherit the breakpoint definitions of its base theme(s?) and the rules by which multiple breakpoint definitions will merged into the operating set. So questions are:

1) Should breakpoints inherit? Probably, but you might think twice. Actually, you might argue that inheritance 'by specification' is built into breakpoints.

2) Define the cascade rules? How are conflicts resolved? How do you handle rules on non-existing elements? What about name collisions?

3) If a theme has a chain of base themes, should all the breakpoint definitions cascade up? If a sub-theme is a specialization of a base theme, should that specialization be reflected in a sub-theme of a sub-theme? Or should only the base base theme be inheritable?

4) What about naming collisions in groups? Do you merge or replace?

I think there are more issues to be discussed but I wanted to get this started. A patch is not possible until the inheritance rules are defined.

Comments

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
CreditAttribution: jwilson3 commented

For a front-ender's POV who is not totally up-to-speed on the Breakpoint module's implementation, can you clarify what is meant by "inheritance" here? Are you talking about grouping various separate CSS files (from parent themes, and potentially core Drupal) together under a single breakpoint directive inside a <style> tag in the header.

Keep in mind that we have to deal with both preprocessed (aggregated) css, and raw css files.

I'm imagining something like this for the raw css files, (and I might be missing the point but):

<style type="text/css">
@media screen and (max-width: 740px) {
  @import "/path/to/drupal/core/module/somemodule/mobile.css";
  @import "/path/to/parent_theme/mobile.css";
  @import "/path/to/mytheme/mobile.css";
  /* Additional imports up to 31 or whatever the IE limit is */
}
</style>

What other kind of inheritance for breakpoints is there?

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented

As in a sub-theme's automatic inheritance of resources from a base theme, ie breakpoint definitions/files. This may not be necessary because the breakpoint module, as designed, allows a themer/module writer to explicitly specify breakpoint definitions from ANY other module or theme. So why automate what might be a black hole to an unsuspecting themer/module writer? Possibly to insure inexperienced themers build responsive themes out of the box? It might even be appropriate to attach this feature to an on/off switch so that experienced themers can ignore this element of base themes.

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented
Issue summary: View changes

Add reference to documentation for breakpoint module.

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented
Title: Make BREAKPOINTS inheritable » Make BREAKPOINT resources inheritable

Modified title to make more sense.

attiks’s picture

attiks CreditAttribution: attiks commented

As it is right now, each theme can define a config/subtheme.breakpoints.yml file defining the theme specific breakpoints. This file is theme specific and there's no inheritance. The same goes for config/subtheme.breakpoint_groups.yml

If/when #1067408: Themes do not have an installation status is solved, it might be that the base theme is enabled as well and the breakpoints from the base theme will be imported as well. And you should be able to use the base theme breakpoints inside your config/subtheme.breakpoint_groups.yml file

Example of subtheme.breakpoint_groups.yml

group1:
  label: Mix breakpoints
  breakpoints:
    - mobile // Coming from config/subtheme.breakpoints.yml
    - theme.basetheme.wide // Coming from config/basetheme.breakpoints.yml

If you mean by inheritance that the system will allow you to use wide and it will autmoatically scan your subtheme and if not found all base themes, than it will be hard, since AFAIK CMI doesn't has support for it.

Regardless of all technical problems, if don't think it's a good idea to mix this, I think we need a workflow for creating base themes and clarify that a base themes should define their own .breakpoints.yml file to avoid problems. Non-experienced people creating a base theme (I'm thinking omega, zen, adaptive themes, ...) probably will follow instructions insde a README file, if those themes add that people should copy and rename the .breakpoints.yml file, they should be able to manage this.

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented

I don't see any problem with adopting this policy as long as it is well documented in multiple places(documentation for breakpoints, sub-themes, base themes and general themeing). The additional coding could only make drupal more fragile. Also base themes should probably duplicate their breakpoint files in their sample sub-themes(eg. Zen's starterkit).
I'm not sure breakpoints are going to be easy for inexperienced users. Good, complete, examples will be sorely needed.

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented
Issue summary: View changes

Fix reference.

RainbowArray’s picture

RainbowArray
she/her
Primary language English
Location Twin Cities, Minnesota
CreditAttribution: RainbowArray commented
Issue summary: View changes

Breakpoints only make sense in the context of the layout as defined for a particular theme.

So if somebody creates a subtheme from a base theme, it's probably a good idea to either provide a breakpoints.yml file in the stater folder for a sub theme or to give guidance to make sure to copy that over in the README. However, the README should also point out that if the layout is changed on the sub theme, then the breakpoints.yml file should be updated accordingly.

What's the best way to resolve this issue. Create a documentation page for theme developers? Put instructions in Bartik's README as an example for other theme developers?

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented

The only documentation I have found so far is Working with breakpoints in Drupal 8, which needs more work. I looked at the themes which currently declare themselves D8 compatible and only found three that declare breakpoint configurations. There is no documentation about the breakpoint files within the themes. A interesting note is that 2 of those seem to have copies of the auto generated breakpoint group yml files included in their upload.

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented

After more research and testing, it seems to me that as long as a base theme is enabled its breakpoint group definition will be available on the admin/configuration/picture mapping form. However it wont be available for selection on the 'manage display' form until it is configured. So it looks like this comes down to a documentation issue, and inheritance is moot since any configured breakpoint group is available for use by any theme.

dcrocks’s picture

dcrocks CreditAttribution: dcrocks commented
Status: Active » Closed (works as designed)

As designed, any breakpoint group is available to any theme via a responsive_image mapping file. Therefore so long as a base theme is enabled, its breakpoints are available to any other theme, including a child theme. If an administrator spends a little time poking around they will be able to figure this out, though better documentation is preferable. So this becomes a non-issue. I am closing this under the assumption documentation will be improved under a different issue.