Logical Float and Clear

[Antonio-Laguna]

Fixes #575

[Antonio-Laguna]

Caught this

[Antonio-Laguna]

@romainmenke If you agree with this I'll release this and include it with Preset Env 8 so it handles that.

I'm wondering if we should massage these options from postcss-preset-env. If you're developing with this, this becomes a nuisance. I was thinking about a couple of paths:

• Language option. We have a global option that accepts predefined values which then translate the options into the plugins:
  • Latin
  • Hebrew
  • Arabic
  • Japanese
  • Chinese
• Be more specific such as what Logical accepts but I'd love for this to also take care of postcss-logical-viewport-units #780

[romainmenke]

Looks great!
Thank you for this refactor 🙇

[Antonio-Laguna]

@romainmenke thanks for the review! I've also updated the issue templates as suggested. Note that tests will fail here since I haven't modified PostCSS Preset Env to remove this but I thought it to be acceptable.

[romainmenke]

I'm wondering if we should massage these options from postcss-preset-env. If you're developing with this, this becomes a nuisance.

I am not sure about this :)

I like what we have now because we can't really polyfill logical:

• using different and more abstract config avoids confusion with browser behavior
• the available config options can never be wrong or inaccurate

For example a config that allows users to set Hebrew might cause users to expect it to do more than it is capable of.

On the other hand I don't like that the options are highly technical and I don't think users should have this level of understanding of the feature.

Can we fix this with documentation alone?
Maybe a dedicated page that would cover all plugins?

This can include "recipes" with more details than would be possible through better plugin options alone. Users can then just copy/paste what applies to their project.

---

I did update the other plugin to match the options here.

At first I didn't, because it didn't make much sense in isolation, but I prefer having the ability to streamline config for postcss-preset-env. If all plugins take the same input we can use shared options and also only need to explain it once :)

[Antonio-Laguna]

For example a config that allows users to set Hebrew might cause users to expect it to do more than it is capable of.

My thinking was something along the line of logicalLanguage (or something like that) that's just explained. While documentation helps I think it can't get simpler than setting up a language. The only reason I don't like that is that's not consistent with the more technical part of the plugin aspect.

Dedicated pages are (IMHO) missed, especially on a monorepo setup.

At first I didn't, because it didn't make much sense in isolation, but I prefer having the ability to streamline config for postcss-preset-env. If all plugins take the same input we can use shared options and also only need to explain it once :)

I'm not 100% sure what you mean here, you mean having blockDirection and inlineDirection at postcss-preset-env level? If so, I assume we just pass the options down blindly? (so they're validated at plugin level rather than at plugin-pack level)

[romainmenke]

My thinking was something along the line of logicalLanguage (or something like that) that's just explained. While documentation helps I think it can't get simpler than setting up a language. The only reason I don't like that is that's not consistent with the more technical part of the plugin aspect.

Is there a list of all languages that have a block/inline direction that differs from latin?
If this list is too long it might be a reason not to do this.

I do agree this would be the simplest for users because they know which language they are working in and they know (intuitively) how it should flow.

My main concern is that users would be confused when setting logicalLanguage.
It would not really make their project work perfectly for that language. It would only affect inline and block flow direction.

Dedicated pages are (IMHO) missed, especially on a monorepo setup.

true 🤔

I'm not 100% sure what you mean here, you mean having blockDirection and inlineDirection at postcss-preset-env level? If so, I assume we just pass the options down blindly? (so they're validated at plugin level rather than at plugin-pack level)

Yes exactly :)

So that users do not have to configure this 3 or more times or even worse, each time with different option keys and values.

This can also be namespaced (logical : { blockDirection: ... })

[Antonio-Laguna]

Is there a list of all languages that have a block/inline direction that differs from latin?

Vertical seems to be:

Chinese
Japanese
Korean
Mongolian

RTL:

Arabic
Hebrew
Farsi
Urdu

I don't know if we would be missing something here and I agree this is a long list

So that users do not have to configure this 3 or more times or even worse, each time with different option keys and values.

That's exactly my concern. I like your idea.

[romainmenke]

Given how few people use these plugins directly I think it would also be fine to only make this convenient in postcss-preset-env.

A functional API might be neat :

postcssPresetEnv.languageToLogicalConfig('Farsi')

returns :

{
  inlineDirection: ...,
  blockDirection: ...,
}

const postcssPresetEnv = require('postcss-preset-env');

const yourConfig = {
	plugins: [
		postcssPresetEnv({
			logical: postcssPresetEnv.languageToLogicalConfig('Farsi')
		})
	]
}

The name would require some bikeshedding.
But it provides some convience to users who want this without make the plugin options too complicated :

const yourConfig = {
	plugins: [
		postcssPresetEnv({
			logicalLanguage: 'Farsi',
			inlineDirection: 'bottom-to-top', // does this throw?
		})
	]
}

[Antonio-Laguna]

I love the functional API!

I think that renders unnecessary the need to pass the last example?

postcssPresetEnv({
	logicalLanguage: 'Farsi',
	inlineDirection: 'bottom-to-top', // does this throw?
})

I think you can either customize yourself the logical setting or rely on the result from languageToLogicalConfig. Thoughts?

[romainmenke]

I think you can either customize yourself the logical setting or rely on the result from languageToLogicalConfig.

I agree :)

[romainmenke]

LGTM!