Improve Variable Names

The current default minLineHeight is 1.33 and default maxLineHeight is 1.25. Unusual to have a min greater than the max. Maybe a typo?

It is confusing and probably requires elaboration. In this case the min/max refers to the state of the width so you get more space the smaller the type, less for large. I’d love to merge in an edit if you wanted to make it. A related feature request is the ability to transpose the min/max values in the event someone would want to do that for some reason. As it is now only one way works.

…

On Feb 12, 2019, at 3:37 PM, Mihira Jayasekera ***@***.***> wrote: The current default minLineHeight is 1.33 and default maxLineHeight is 1.25. Unusual to have a min greater than the max. Maybe a typo? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Ah, I see -- I can understand the desire to transpose these, as sometimes longer line-lengths can benefit from greater line-height (leading) so the eye can more easily distinguish between lines when moving from the end of one line to the beginning of the next.

So ~~min and max~~ values for font-size, line-height, and grade are all ~~dependent~~ calculated based on container width, right? I'll call these former three attributes 'dependent attributes'. From an API perspective, what if you simply handled transposing based on whether the min or max value of these dependent attributes is larger? That is, if max > min, the relationship to container width is direct; if min > max, it's inverse.

I think the variable naming for minFontSize and maxFontSize (and all the other dependent attribute mins and maxes) might need to change to something like minWidthFontSize and maxWidthFontSize to make this clearer. A bit wordy, but much clearer, I think. (And this would also address my confusion about minLineHeight and maxLineHeight.)

These sound great. Would it be smart to support both versions of the variable names for some time before phasing the old ones out?

…

On Feb 12, 2019, at 4:20 PM, Mihira Jayasekera ***@***.***> wrote: Ah, I see -- I can understand the desire to transpose these, as sometimes longer line-lengths can benefit from greater line-height (leading) so the eye can more easily distinguish between lines when moving from the end of one line to the beginning of the next. So min and max values for font-size, line-height, and grade are all dependent on container width, right? I'll call these former three attributes 'dependent attributes'. From an API perspective, what if you simply handled transposing based on whether the min or max value of these dependent attributes is larger? That is, if max > min, the relationship to container width is direct; if min > max, it's inverse. I think the variable naming for minFontSize and maxFontSize (and all the other dependent attribute mins and maxes) might need to change to something like minWidthFontSize and maxWidthFontSize to make this clearer. A bit wordy, but much clearer, I think. (And this would also address my confusion about minLineHeight and maxLineHeight.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

I think supporting both sets of variable names would make sense for a short time, maybe with a deprecation warning in the console if the old names are being used? If following semantic versioning, maybe you'd only drop support for the previous variable names with a major release (or first public release)?

(Full disclosure: I have no experience releasing JS packages, so I don't know what best practices would be!)

I think supporting both sets of variable names would make sense for a short time, maybe with a deprecation warning in the console if the old names are being used? If following semantic versioning, maybe you'd only drop support for the previous variable names with a major release (or first public release)?

You are absolutely correct. "Breaking Changes" are only allowed when releasing major versions. (1.x.x -> 2.0.0) And since this is a change to the public API of the software it is considered a breaking change.

It is indeed common to release the "new and improved" version side by side with the old solution. In this case a deprication notice is a good idea. (Just a console warning if the old variable name is used.)

Deprication notices should also be placed in documentation; and it is a good idea to mention what the new solution would be so users can pick up on that right away.

Once you are ready to release the next major version you can strip out all of the depricated parts of the software as well as the documentation. To help existing users upgrade their code it is a good idea to release an upgrading (from 1.x to 2.x) guide. Which would cover all of the depricated parts and what they are replaced with.

Hope this helps!

Hey @tinymachine, are you up to working on either of those two things (renaming the variables or adding ability to transpose the values)?

We have this old issues about transposing the values. I'll reference this discussion there.

I created an initial public release.

Hi @theorosendorf - sure, I'll give it a shot! (Might not get to it until the end of the week.) BTW thank you for sharing this project!

My pleasure @tinymachine! I hope you enjoy using it as much as we have.

Hey @traviskochel, what's the protocol here? Should we add @tinymachine as a collaborator, or...?

@theorosendorf Even if they're not a collaborator, people should be able to submit pull requests, and then you'll get an alert to review and merge it in. This is probably the standard approach.

Adding them as a collaborator will allow them to push changes directly to the repository without being reviewed. This would be useful if they're making lots of changes and you trust them.

Your call though. I'm fine with anything.

No need for collaborator status but thanks for the consideration, @theorosendorf!

K, thanks @traviskochel, and thanks for the help @tinymachine!

UPDATE: Oops, realized I can easily figure this out on my own without parsing the formulas just by checking the resulting line-heights!

Hi @theorosendorf and @traviskochel -- I'm making progress on updating the variable names and updating the calc() function to handle transposed min/max values. I want to make sure, though, that I'm respecting the relationship between the width-dependent attributes and the container's width.

Is the relationship between line-height and container width linear? It looks like font-size and variable grade are linearly related, but I'm struggling to parse the line-height (calcleading) calculations:

textblock/src/textblock.js

Lines 45 to 62 in 567a0e3

    
           var minld   = tb_minw / tb_minl; 
        
           var maxld   = tb_maxw / tb_maxl; 
        
           var fontsizevariation = tb_minf + ((tb_maxf - tb_minf) / (tb_maxw - tb_minw)) * (msr_width - tb_minw); 
        
           var calctypesize = fontsizevariation; 
        
           var leadingvariation = minld + ((maxld - minld) / (tb_maxw - tb_minw)) * (msr_width - tb_minw); 
        
           var calcleading  = msr_width / leadingvariation; 
        
           var gradevariation = tb_ming + ((tb_maxg - tb_ming) / (tb_maxw - tb_minw)) * (msr_width - tb_minw); 
        
           var gradeMath = Math.max(Math.min(gradevariation, tb_ming), tb_maxg); 
        
           var variableGradeSettings = '"wght" ' + gradeMath; 
        
           return { 
        
             fontSize: Math.min(Math.max(calctypesize, tb_minf), tb_maxf), 
        
             lineHeight: Math.max(Math.min(calcleading, tb_minl), tb_maxl), 
        
             fontVariationSettings: variableGradeSettings 
        
           }

If it's linear, that's great. (Though it does seem at odds with this statement in the readme: "Textblock gives you the control you need for setting systems like modular scales".)

Thanks for any light you can shed on the line-height calculations!

Yeah, it’s linear. And yes, a modular scale for a single type style in responsive terms could follow a non-linear scale (in effect, easing over a cubic bezier [a future-future enhancement that I have some ideas for]). But the term modular scale refers to the relation of size and space between static elements, i.e. the heading is X/a, the subhead is Y/b, the body Z/c.

…

On Feb 20, 2019, at 5:01 PM, Mihira Jayasekera ***@***.***> wrote: Hi @theorosendorf <https://github.com/theorosendorf> and @traviskochel <https://github.com/traviskochel> -- I'm making progress on updating the variable names and updating the calc() function to handle transposed min/max values. I want to make sure, though, that I'm respecting the relationship between the width-dependent attributes and the container's width. Is the relationship between line-height and container width linear? It looks like font-size and variable grade are linearly related, but I'm struggling to parse the line-height (calcleading) calculations: https://github.com/glyphic-co/textblock/blob/567a0e3354f8c02469f2dc7c5f7c9f041a341f3e/src/textblock.js#L45-L62 <https://github.com/glyphic-co/textblock/blob/567a0e3354f8c02469f2dc7c5f7c9f041a341f3e/src/textblock.js#L45-L62> If it's linear, that's great. (Though it does seem at odds with this statement in the readme: "Textblock gives you the control you need for setting systems like modular scales".) Thanks for any light you can shed on the line-height calculations! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQNuWO1uW3WCllq-3MZ4lk6SV-Gzm07ks5vPcWmgaJpZM4a4Aaz>.

Thanks for the clarification, @theorosendorf, and for the explanation about modular scale (yes, I was indeed conflating that with easing curves!).

	var minld = tb_minw / tb_minl;
	var maxld = tb_maxw / tb_maxl;

	var fontsizevariation = tb_minf + ((tb_maxf - tb_minf) / (tb_maxw - tb_minw)) * (msr_width - tb_minw);
	var calctypesize = fontsizevariation;

	var leadingvariation = minld + ((maxld - minld) / (tb_maxw - tb_minw)) * (msr_width - tb_minw);
	var calcleading = msr_width / leadingvariation;

	var gradevariation = tb_ming + ((tb_maxg - tb_ming) / (tb_maxw - tb_minw)) * (msr_width - tb_minw);
	var gradeMath = Math.max(Math.min(gradevariation, tb_ming), tb_maxg);
	var variableGradeSettings = '"wght" ' + gradeMath;

	return {
	fontSize: Math.min(Math.max(calctypesize, tb_minf), tb_maxf),
	lineHeight: Math.max(Math.min(calcleading, tb_minl), tb_maxl),
	fontVariationSettings: variableGradeSettings
	}