Topic Closed

First of all. It is a great plugin. But I have some suggestion for it.

I always get 100% of container width and height for image regardless its values in pixels (600x600)

So I have added section attribute for component wrapper

style: max-width: 600px; max-height: 600px

It give me more reasonable result

May be it must be a default solution in plugin?

3 years ago#9740

juergen
1.4K Posts
51.6K Downloads
16 Plugins
design, web development & visual effects

Hi Lena,

I always get 100% of container width and height for image regardless its values in pixels

Yes, that's how it's meant to be. The plugin output is responsive, therfore the image will always scale up to the section's width. The marker's top and left positions are set in percent in order to adapt to the dynamic section dimensions.

Setting a max-width:600px style to the combo's wrapper, as you did, is the correct solution if you don't want the combo to grow larger than 600px. But you shouldn't need a max-height. The image's height should scale proportionally with the width.

May be it must be a default solution in plugin?

I believe, setting section dimensions – especially those of wrappers – shouldn't be done using a single plugin's dedicated editor. We should consider this to be a separate, general-purpose plugin. Or, even better, a future core system feature.

But it's not trivial.

As you might know, I already implemented a live drag'n'drop height setter in Slider Factory. It's not all bad but has issues.
I recently experimented quite a lot with wysiwyg section sizing but haven't yet found a satisfactory solution that meets all possible different situations' demands.

In my opinion, this is what a live dimensioning tool for sections needs to be a comprehensive solution:

Height: Auto or Fixed (px or % of width, just like Slider Factory. Maybe also vh units). Height syncronisation of sections inside a wrapper, if the latter it's a row.
Support for the upcoming flexbox standard. Overflow management in case section content gets truncated by limited height.

Width: Custom width (in % or pixels), preferably with snapping to the responsive grid. The latter is quite complicated to achieve wysiwyg, because in sophisticated grid layouts, single sections may not only respond up to 4 viewport breakpoints, the responsive grid itself may have other than 12 colums, depending on the grid variables.
Furthermore, we actually can't assume having a Bootstrap grid - there are plenty of older themes without a grid system, here we would have to use Typesetter's very basic built-in grid.
Any CSS grid classes, including custom ones implemented by the theme designer, would have to be declared some way in order to deal with them using Javascript in edit mode. Neither Typesetter nor Bootstrap do have a built-in JS breakpoint management.
And, finally, to set responsive grid classes for different breakpoints live, we would need the webbrowser to support standardized, scriptable viewport size simuilation. To my knowledge this doesn't yet exist at all.

And so on and so forth. It's sort of mind-boggling.

But, if I actually find a solution, I'll certainly let you all know ;o)

3 years ago#9741

Topic Closed

 

News

Typesetter 5.1
8/12/2017

Typesetter 5.0.1 is now available for download. 5.1 includes bug fixes, UI/UX improvements, ... Read More

Over 8 Times Faster Than Wordpress
5/3/2016

We've known for a long time that Typesetter is fast. It's something we take pride ... Read More

More News

creisi productions

Dienstleistungen von creisi productions, Luzern (Schweiz): * Konzeption, Planung und Erstellung Ihres Internet-Auftritts * Betreuung und Aktualisierung/Pflege Ihrer Website * ...

Find out more about our Provider Spotlight

Log In

  Register