Leaderboard

Usually I set the font size in the html or body tags, and then use rem for pretty much everything else. I use em in the rare occasions that the size of an element should definitely dependent on the size of the parent, but usually I want the flexibility to control them independently of each other with rem. When you use em on everything, it's very easy to overlook small differences between the text inside elements and you end up having the same kind of text set in 11.5px and 12px in different places, for instance. As for the base size itself, it depends a lot on the layout. Some layouts account for large screens, and divide into multiple columns. On those cases the base font can usually stay the same though any screen size, and can be set in pixels or em. On more static layouts I normally want the font to grow a bit with the screen width, but not too much (I mean, not proportionally. I want it to grow less and less as the screen becomes larger). For that I use a calc() to create a relation between the vw and the pixels. For instance: font-size: calc(8px + .7vw); And I usually want to define a minimum and a maximum sizes. This can be done with media queries, or simply by using the clamp function: font-size: clamp(15px, calc(8px + .7vw), 20px); This defines that the font grows with the screen width but never becomes smaller than 15px or larger than 20px.

Typography is not a simple topic but I'll try to explain how I use it. But first, the difference between EM/REM. Generally, an EM got it roots in print where it refers to the width of the upper-case M. When css came about, they changed it to refer to a relationship of the parent element. By default, one EM generally is 16 pixels in the browser world. The REM (Root EM) is in relation to the root (usually the HTML definition if no ::root{} is defined) font size as you have defined in CSS. Some inconsistency -- You can use both EM and REM in margin/padding definitions. However, when using EM as the unit in a margin definition it looks only at the current element; It does not refer back up to a parent. This is not the case with REMs. The REM declaration is always looking at the root. // EM html { font-size: 16px; } article { font-size: 20px; } p { font-size: 1.1em; margin-bottom: 1em; } <article> This is 20px. <p>This is 1.1 x 20px. The bottom margin is 1.1em regardless of parent font size setting.</p> </article> // REM html { font-size: 18px; } article { font-size: 20px; } p { font-size: 1.1rem; margin-bottom: 1rem; } <article> This is 20px. <p>This is 1.1 x 18px. The bottom margin is 1 x 18px.</p> </article> The viewport width/height (VW/VH) allows for a 'fluid' scaling. However, the drawback is that smaller devices will not zoom in or out should the font size scale too small. Also, on very wide screens this scaling would likely make the text way too big, to the point of interfering with other content. My method: I define my base font size as 16px (usually the browser default). I also include variables to make future changes very simple. I put my font size break points at the top of my css file (usually after ::ROOT{} ) so that I don't have to go hunting should I need to change something. To avoid the confusion between parent references, I define all font sizes, margins, paddings, widths, etc. in REMs, except for the base ::root{} definition which is in pixels. :root { --fs-norm: 1rem; // defaults to browser's font-size definition --fs-big: 2rem; --fs-hdg: clamp(3.5rem, 10vw + 1rem, 14rem); // This sets the min and max font-sizes and scales in between } @media (min-width: 40rem) { :root { --fs-norm: 1.125rem; --fs-big: 3rem; } } body { font-size: var(--fs-norm); line-height: 1.6; } h1 { font-size: var(--fs-hdg); text-transform: uppercase; } I hope this helps. Like I said, this isn't a simple topic where you can say, "Use x because...". ps. Not a front-end guru so others may have a better reply.

I am used to use rem, the reason => web accessibility => a pixel is not responsive and with some algebra (lol) for fluid typo, the concept is called Poly Fluid Sizing and using tailwindcss utilities? Rule them all with this linear equation definition, which result the font-size : Take a look at this sample: https://codepen.io/neil/pen/agzZVg And give a read to : https://www.smashingmagazine.com/2017/05/fluid-responsive-typography-css-poly-fluid-sizing/ ✌️ Edit: for the rest, everything with a tailwind.config.js, it's so cool: https://tailwindcss.com/docs/grid-template-columns & #arbitrary-values

This week I've been working on something a little different: developing a new site profile in ProcessWire. Actually, I should probably call it an application profile rather than a site profile, as it's not a website profile. Instead it's a profile for an invoicing application in ProcessWire. Though you would install and run it on a web server, but it would be an independent application rather than part of a website... perhaps something you run in a subdirectory, subdomain, or even localhost. This is something I've been wanting to build for awhile—ever since the invoice service I use raised their rates beyond my budget. So I thought I'd build a replacement that I could use, as well as share for others that might have a similar need. I think it might also be a pretty decent PW profile example in general, too. I'd originally considered building it as a Process module but decided not to for a few reasons. Though the biggest one is that a site profile enables the greatest potential for customization and expansion according to each person's needs. Since you can expand upon it by adding your own fields and templates, or editing existing ones, most can really tailor it to their own needs a lot more easily than they could if it were a Process module. Likewise, since the actual invoices (and invoice emails) are rendered from front-end pages, you can customize the look and feel of them to match your brand very easily. (This is something I always wished I could do with the invoice service I've been using previously) This invoice profile requires nothing other than the ProcessWire core. It has no 3rd party or Pro module dependencies. I've got it largely functional at this stage, though will be putting a couple more weeks work into it before releasing it. I'd like to build in the option for clients to pay an invoice with a credit card (via Stripe) for instance. Below are a few screenshots of the work in progress. First is the page-list which shows the current invoices in the system and their status. (click image to view larger) As you can see, there are also pages for Clients and Settings. The client pages contain all the information about each client that invoices can be created for. The Settings page is where you can edit your own company information, logo and billing preferences. Next is the invoice editor. Here we have a repeater for each line item in the invoice. We also have a repeater for payments. All of the totals add up automatically as you type (Javascript added via hooks). They are also calculated automatically at the server side, so that everything stays consistent whether working with the API or in the page editor. (click image to view larger) At the bottom of the invoice editor you'll see a collapsed input for "Invoice action". This is where you can select actions to apply to the invoice. The two we currently have are "Email invoice to client" and "Email invoice to another address". Next up is what we see when viewing the invoice on the front-end. This is just the output of a template file but it is optimized for printing, saving to PDF and sending through email. I've kept it intentionally simple but of course the logo would be replaced with your own and all markup/styles are fully under your control. (click image to view larger) What I plan to add next are payment options, enabling a client to pay by credit card right from the invoice URL or email. What do you think, is this type of PW profile useful to you or someone you know? I've initially built it towards my own client invoicing needs, but I'm curious what other features you would like it to have? Or do you think it's better to keep it simple so that people can more easily take it in different directions? Thanks for your feedback. Have a great weekend!

Until we might have a native method for migrations, I encourage you to checkout the great RockMigrations module. With the module you can have one or multiple migration files, that handle all the stuff mentioned above, like adding fields, adding templates, creating pages with content and setting roles. As the migrations are file-based they are also version-controllable. It is also a hassle-free setup and very easy. This makes it easy to work on a feature in a different branch which requires to have other fields/template than in the main branch. Now you can switch between branches and always have the required fields and templates. This is a huge time and workflow improvement. @bernhard steadily improves his module, and me and other contributors try to enhance it, or give feedback.

<?php namespace ProcessWire; class TextformatterRockSoftbreaks extends Textformatter { public static function getModuleInfo() { return [ 'title' => 'RockSoftbreaks', 'version' => '1.0.0', 'summary' => 'Textformatter to replace strings by HTML softbreak', ]; } public function format(&$str) { $str = str_replace("---", "&#8203;", $str); $str = str_replace("--", "&shy;", $str); } } There's always the problem of too large words on too small screens... In the past I often did a str_replace in my template file, but when using frontend editing that's no option because you need the original markup in the edited text and the replaced version in the presented markup. Textformatters do exactly that and that's why I build a textformatter for it. Feel free to change the replaced string to whatever you need ? Update: 3 dashes will insert a zero-width-space to make it possible to insert non-dash-softbreaks where dashes would be misleading (eg in mail addresses or in foo/bar which would otherwise result in foo/- bar) PS: If you have better solutions for that problem please let me know!

Hi Bernhard, thanks for sharing! Not a better solution but something that lessens the severity of the whole issue is built into Bootstrap 5: https://getbootstrap.com/docs/5.2/getting-started/rfs/ which is a separate project so not tied to bootstrap: https://github.com/twbs/rfs/tree/v9.0.6 Using RFS means that there is less need for hyphenation but still there is, of course. Also, RFS makes it easier to adapt other values on the fly, if needed. I have not yet installed the module (I will, when I have the time) but 3 dashes look odd to me. I would rather use only one character for that (underscore, maybe). So, if you could make it configurable that would be great, I think. (If it is not yet configurable, perhaps...)

Hi @Robin S and wow, thanks a lot for your answer and this greeat explanation! funny enough, i've written a lot of modules for customers using this $page->of() function to allow validation of values submitted with a front end form to create pw pages but never had to deal with displaying images in the back end, thanks to you i won't be surprised when it happens ? and thanks for the snippet too, cleaner and more pw like than my concatenation ? one more day i will go to bed a little less dumb ?? have a nice day

UPDATE!! A new version with CAPTCHA support can be downloaded at https://github.com/juergenweb/FrontendForms It is early stage, so everyone is invited to test it - not recommended on live sites at the moment. Please report errors and ideas directly in Github. Thanks Jürgen

This isn't anything specific to this module - it's just the effect of output formatting being on or off. Unfortunately there is no general documentation page explaining the idea of output formatting but the $page->of() docs gives you some info. The rule of thumb is that output formatting is on in the frontend and off in the backend, particularly in a situation where field values are going to be saved like in the page editor. You can set the formatted value of a single image field to be a Pageimage but when output formatting is on it will always be a Pageimages array. So in FieldtypeRuntimeOnly you need to specifically ask for the formatted value of the field: $image = $page->getFormatted('squareimg'); if($image) { // ... }

Thanks in advance for releasing it for free! While I am pretty sure it will serve as good example (which I can't wait to learn form) and as a solid base to build upon, I wish there was a way to upgrade site profiles, similar to module upgrades.

Dear beta testers, thanks for your help! PAGEGRID is now available here:

There's also a paid pro module "FormBuilder": https://processwire.com/store/form-builder/

you will find all you need in this forum thread https://processwire.com/talk/topic/2089-create-simple-forms-using-api/

For me it was the opposite ? Bootstrap always needed those weird row-wrappers which is totally strange to me. Maybe I didn't understand it correctly but defining the rows via row wrapper in the markup?? How should that work if I need eg 1 item per row on mobile and 3 items per row on desktop? In UIkit that's as simple as this: <div class="uk-grid-width-1-1 uk-grid-width-1-3@m" uk-grid> <div>foo</div> <div>bar</div> <div>baz</div> <div>foo</div> <div>bar</div> <div>baz</div> </div> 12-column-grid? Did you see this? https://github.com/uikit/uikit/issues/217#issuecomment-31829807 ?

So I guess it should be possible to use UIkit + https://github.com/twbs/rfs/tree/v9.0.6#installation ? ? Maybe @gebeer could show how that could be added to the postcss workflow of RockFrontendTailwind? If you need another plus for UIkit be sure to check out their JavaScript framework: https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md It's really great because you can add custom JS very easily and manipulate all the great UIkit components or use helpers like addClass() or util.each(array, () => { ... }); etc! Another plus might be the great integration of RockFrontend and some additional components that I put there: https://github.com/baumrock/RockFrontend/tree/main/uikit @rick thx!

I am using a SASS mixin which renders REM out of given PX values. So when designing my layouts you typically have px based font sizes. Then when developing the website I want to make use of rem instead of px. Calculating each value can be time consuming and it might be confusing cause rem is relative to the base font size. @function calculateRem($size) { $remSize: $size / 16px; @return #{$remSize}rem; } @mixin fontSize($size) { font-size: calculateRem($size); } @mixin lineHeight($size) { line-height: calculateRem($size); } This however is not responsive in the way that the font size adjusts to the viewport. I like to have control over my font sizes so I hard code - for example headlines - fitting the four big breakpoints: large desktop, desktop, tablet, mobile. Yes it is a bit of work... For big, prominent title headlines (over background images for example) I often use vw or vh as font height. That makes the fontsize fluid but it can give you some weird "inbetween" values. So you have also have to make small adjustments based on breakpoints to make sure it looks good everywhere. This however looks promising. It seems to combine REM and VW. I recently upgraded to Bootstrap 5 and totally overlooked this new feature (by the way I am still thinking about switching to UIKit3 but for other reasons but this is another point for bootstrap).

That's one of the very rare cases where I thought a full module (github + modules directory) would be overkill ? Thx, very interesting! I'll start a topic in devtalk!

I've been successfully using Dark Reader for years, with these settings (Filter+ is need for my Mac so that coping text still results in the original colors, not the changed ones of the view):

@Pete ? A dark-mode could be available to view the forum ? iam near 40 and my eyes need more obscurity ??‍♂️?

Would definitely be interested in testing and purchasing PageGrid

@Bacelo did you find any solution back then? @Roope I'm using PW 3.0.200 and it looks like the module is stuck somewhere in the process. Script is not added automatically. When I add it manually it does not find anything in the document. So with script added manually and using $sanitizer->emo($string) it find the email and replace it completly with a noscript tag.

Just to clarify: the png format has no quality loss. But the GD lib has massive issues in resizing dark image parts. With such dark images, you must set the imagesizer defaultGamma option to -1 !! If your server supports imagick, you can activate the ImageSizerEngineIMagick, that is part of processwires core. (Under modules core).

Since PW >= 3.0.105 you can easily use the following hook. $wire->addHookBefore('InputfieldSelect::render', function($e) { if ($e->object->name != 'myfield') return; // quick exit if fieldname doesn't match $restrictedIDs = array(); // array of option values to be modified, page IDs in case of pagefield $optionAttributes = array_fill_keys($restrictedIDs, array('disabled' => 'disabled')); $e->object->addOptionAttributes($optionAttributes); }); Related commit: https://github.com/processwire/processwire/commit/07ab8ef9fcefff6a97c688599fb08fb0d462332e#diff-79808b1661a74c0668ee6157537ae478R390