hestenet → credited konfuzed → .
hestenet → credited konfuzed → .
hestenet → credited konfuzed → .
hestenet → credited konfuzed → .
Almost all 'credited' contributions on the associated accounts seem to be simply saying yes the core 11 change works on automated patch issues.
Searched around more, and maybe gluing a list and https://www.drupal.org/project/easy_responsive_images → together might help reduce work
TLDR: yes, a glue module or recipe to provide common aspect ratios and breakpoint combinations with generated responsive image styles not connected to any theme would be good
Fuller info:
I tried to think of this holistically for many possible site use cases, so I asked a designer who understands a bit about performance with images to look at a spin up of Drupal CMS responsive images for feedback:
- They liked the list of aspect ratios but would include 21:9 as a target
- Based on naming, they'd expect an XL size as they target 1980px for HD displays when they reuse content on full screen news and events walls and they often spot check key graphics at 4-5 sizes (supports sizes not being tied to a theme)
- Asked if all images got generated for all these styles as that freaked their design side out
After mentioning you can place a focal point on an image to influence resizing they breathed easier, but had a good side question as to whether you can tag an image as to what aspect ratios it can be recut. Different issue for later...
Then I showed them the default (blank) page for Responsive Image Styles on a new core site. First question "where's the list of aspect ratios to choose from?"
I asked a bit more and their expectations were to see a list of aspect ratios to select as allowable, as many of the graphical brochure sites often have a very much reduced set of art production targets -- 3:2 for call out boxes, 16:9 or 21:9 for heroes, square in stories. And they would want no others allowed to reduce issues that editors could cause in their design. They'd prefer a 'use this set of aspect ratios' then generate just those, but having a full set and removing those you don't want used was fine if it meant they didn't have to go create any themselves.
References for breakpoints is compiled elsewhere for us at https://blog.logrocket.com/css-breakpoints-responsive-design/ but for this, having a choice between bootstrap/tailwind/whatever vs just a xs sm md lg xl xxl whatever set makes sense -- making it a chose your own system widths could be nice and in which case an ECA setup for choosing or defining a set to generate against could be nice, but for expediency a set and go seems prudent for now
Since this module generates the anchor links dynamically after a page load, I don't see how we'd get a Drupal block that would be of any use.
Are you thinking instead finding all the anchors on the page and creating a dynamic page-only block to render? That would be possible, but highly targeted based on your theme layout.
I suppose maybe a script which generates almost a table of contents for the anchors and takes an existing block or area to inject that array back out could be possible. Is that more of what you were thinking?
I am working on the vetted security status to get this module marked for security coverage. In the mean time, I'll run a few more tests and code reviews to make sure the stable release really is ready.
konfuzed → made their first commit to this issue’s fork.
konfuzed → made their first commit to this issue’s fork.
pameeela → credited konfuzed → .
hestenet → credited konfuzed → .
konfuzed → made their first commit to this issue’s fork.
hestenet → credited konfuzed → .
Having now run into this conflict while testing a new recipe-based installation, there really seem to be 4 types of configuration imports that are targeted and we should help make it explicit what group of configuration will be brought in:
- none -- just activate the module, whether to avoid conflicts or because it's not needed due to nature of the module
- required / basic install config files -- could be handled by a keyword of 'default' or 'required' to just get the files in the config/install directory
- all aka "*" -- that pulls in config/install and config/optional
- explicit selection of files for any reason
I think common usage makes "*" much easier to read as a "yes I really mean everything in all of the module's config directories" easier on the mental processing and expected outcome.