[Proposal] Section Grid: one-up-tablet

[meganthecoder]

I'd like to bring back @ryanmparrish 's idea of .section.one-up-tablet. This would be a new addition to our grid system that would allow authors to specify that they want one-up on tablet. An example would be:

The proposed name is one up tablet but alternate names could be:

• tablet one up
• tablet full width (Though I don't like this as much because it could be confused with the grid width.)

For some background context, the resource center style faas forms get squished on tablet:

When we addressed this for bacom, we opted for a solution in our consumer repo for various reasons, but this suggestion would be useful now that we have other consumers with similar needs.

Code: stage...methomas/one-up-tablet
Test Page: https://methomas-one-up-tablet--milo--adobecom.hlx.page/drafts/methomas/one-up-tablet

Please let me know your thoughts. Thanks!

[ryanmparrish]

I like this suggestion and think its needed. The only thought I have is since we are mobile-first we inherit viewport styles scaling up. Traditionally we have implied this with the -up suffix. That indicates that view is for VP and up. Id say if this 'only' targets tablet we label it as such. one-up-tablet-only. The pattern naming convention purposes has been device last, so keeping that convention seems to make sense. Anyhow, just a few thoughts. Looks good, thank you for raising this convo.

[meganthecoder]

Logically that makes sense but it doesn't seem very intuitive to me. Authors are used to using two up and getting two up on desktop. It'll be something new to learn to have to add one up for tablet/mobile and two-up-desktop for desktop.

one-up-tablet seems simpler but I understand the desire to think this through as a system.

@mokimo @overmyheadandbody @chrischrischris @rgclayton Do you have opinions?

[JasonHowellSlavin]

It's interesting that these styles are using max-width instead of min-width which may be where there is some naming convention conflict. To my mind, when using exclusively min-width media queries, a device-only will seem to always need the larger sized device's styles as well, i.e. tablet-only would necessitate desktop-only in order to preclude desktop from inheriting styles meant for tablet.

I think one-up-tablet makes sense, but I can see why only may be desired. It looks like mostly these are for just FaaS as well at the moment.

[rgclayton]

this isn't only for tablet, it's for tablet and mobile.

I think if this is the thought process then one-up-tablet is confusing. I would not assume that affects the mobile viewport because the name specifically calls out "tablet".

[rgclayton]

Wouldn't you then say. one-up, two-up-desktop or whatever the ups is on desktop VP?

This makes more sense to me too.

Authors are used to using two up and getting two up on desktop.

Right, but what we are doing here is involving a specific override for desktop, and the naming helps identify that. I would argue this is more intuitive than assuming one-up-tablet works for both mobile and tablet.

We either prefix/suffix the up with a breakpoint (mobile, tablet, desktop) identifier or we need to create a syntax that visually represents each breakpoint so authors can set accordingly.

Something along the lines of:
one-up | two-up | four-up <-- mobile, tablet, desktop
one-up | four-up <-- short hand for mobile AND tablet getting one-up. Desktop getting four-up.

Or maybe:
(one-up, two-up, four-up)
(one-up, four-up)

Are we at the point that we need a more complex grid system that can more easily handle this and possibly more? There are some POC's in the works but haven't been prioritized.

[rgclayton]

Sorry, doing some looking and more thinking...

I see what you're saying but on a basic level, this isn't only for tablet, it's for tablet and mobile. All ups are effectively one-up on mobile so saying "tablet only" seems a little confusing.

I understand what you are saying now. Our current grid system defaults make this a little confusing.

[meganthecoder]

We discussed this on slack and agreed that my proposal was ok to move forward. PR here: #2122

We're also leaving open the option to build out more of a viewport-based system in the future.

Thanks for the participation!