feat(dense): apply dense mode globally or on a DOM sub-tree

[EladBezalel]

In case the user is on mobile we should automatically apply dense mode for every component that supports it,

Each component should supply an api for disabling auto dense and/or we should have a way to disable it on the config phase.

@ThomasBurleson @topherfangio @devversion @crisbeto @clshortfuse @bradrich

CC: @ErinCoughlan @jelbourn

[crisbeto]

I don't think we should have an API for every component, but rather have a single API that allows to pass in an array of included/excluded components on config. E.g.

$mdDense.enable(['list', 'input']);

[devversion]

I'm leaning towards another approach.

It's enabled for mobile devices by default (as you said) and you can disable the "auto dense" in the config phase, instead of disabling for each component manually.

app.config(function($mdDenseProvider) {
  $mdDenseProvider.disable();
  $mdDenseProvider.disable('md-list', 'md-autocomplete')
}

The $mdDense service / provider would just expose a function, which can be used to register an component for the dense mode.

$mdDense.register('md-list', $element)

The register function will handle everything, like changing the .md-dense class on the element, which allows developers to change the dense mode at runtime as well.

At the end you are able to disable dense mode for specific components or all.

Also developers are still able to manually apply the .md-dense class on the given element.

LOL: Kristiyan just posted a similar approach 👍

[clshortfuse]

I had an idea of some sort of defaults povider of sorts. Therefore, you can say, all components of X type should have Y classes by default.

The idea came about with having new suggested defaults for different interactions (autocomplete, date picker, margins) etc.

I also had an idea of using default config "sets" so if you want to use 1.2 with no breaking changing from 1.0, you would use a default set called 1.0. it's the same concept, just expanded, so I can imagine a global variable adding md-dense to all components.

[EladBezalel]

@devversion your approach is exactly what i had in mind! perfect :)
@clshortfuse i think your idea is over engineered..

[clshortfuse]

@EladBezalel With the current density changes being made for other components, there are changes with issue with margins that would break implementations because margins need to be flush to properly match spec. The current implementation have margins at what I would call full (both extra top margin for labels and bottom margins for messages). The newer changes would allow an auto option.

I see branching from @devversion 's idea and expanding it to more a general approach that can be used for more than just density.

For example

app.config(function($mdConfigProvider) {
  mdConfigProvider.density.enable('input');
  mdConfigProvider.density.disable(['select', list]);
  mdConfigProvider.margins.set('input', 'full');
  mdConfigProvider.margins.set('select', 'auto');
}

But also, expand to set all components of a certain type to use a certain attribute.

mdConfigProvider.attributes.set('tabs', 'md-dynamic-height')

Really, it's just not limiting global changes to components to just density.

Also, there's an md-spacing option that is density related, but not an off/on option. It's the spacing between checkbox and its text (36px, 48px, 56px)

[clshortfuse]

Also, just to add, I agree users should be able to toggle density, but "dense mode" is not for mobile users. It's the opposite.

Desktop users use dense mode. Mobile users do not.

When the mouse and keyboard are the primary input methods, measurements may be condensed to accommodate denser layouts.

https://material.google.com/components/text-fields.html#text-fields-style

If you do anything automatically, dense mode should be on and automatically off for mobile users.

[topherfangio]

I agree with @clshortfuse. The "Dense" mode is typically for desktop users (list example):

When the mouse and keyboard are the primary input methods, measurements may be condensed to accommodate denser layouts

The main point being that users on mobile devices need things spread out a bit more so that they can touch them with their fingers.

That said, I think we should definitely allow dense mode on any device/component (that makes sense), but I'm not sure we enable it by default unless the spec specifically talks about modifying density for responsive purposes (like the special case of the AppBar; which ideally is a subset of the Toolbar with an added class, instead of the way it currently applies to all toolbars).

@clshortfuse Is there a particular use-case you can think of for turning dense mode on by default for a desktop user? Off the top of my head, I can't think of an instance where the majority of developers would want it enabled by default.

[clshortfuse]

We are already using a denser than spec checkbox and radiobuttons. They operate at 36px. Spec is 48px/56px (dense / normal). md-menu is dense as well. I think it's better to finish implementing the density options for our components first. Then we can decide what's default and what's not.

[ErinCoughlan]

@topherfangio I wouldn't have dense mode on by default for anyone. The dense mode makes a lot of sense in enterprise apps on desktop. It looks horrible in consumer apps on desktop and doesn't work for mobile (may actually be too small for accessibility purposes). It should be the devs choice whether they want dense mode or not.

[EladBezalel]

After reading what you guys are saying i think you're all right, but i do think we should have a service to enable all components on dense mode at once

[ErinCoughlan]

@EladBezalel agreed, strictly from an API and user story perspective, you should be able to enable it on any section of the DOM. I would love to be able to call $mdDense.useDenseMode('my-root-element'), or something like this, and enable dense mode for any components within that section of the DOM, leaving components outside that alone.

[clshortfuse]

I'm thinking we need some sort of feature detection. Suggesting high density is a mixture of hasTouchSupport being false and isDesktop being true. Density isn't the only thing that benefits from said feature detection. In list (and assumingly dataTable), if you are on a desktop and don't have touch support, checkboxes should be hidden until you hover or focus on a row.

https://material.google.com/components/lists-controls.html#lists-controls-types-of-list-controls