Jump to content

Community

Rikki

Invision Community Team
  • Posts

    24,342
  • Joined

  • Days Won

    79

Reputation Activity

  1. Like
    Rikki got a reaction from KVentz in 4.5 CSS Changes for developers & designers   
    4.5 introduces some changes to CSS, so I wanted to provide an overview of those and how they might affect you.
     
    IE11
    Firstly, we've completely dropped support for IE11. This means you'll start to see newer CSS methods being used that IE11 does not support. 
     
    Atomic classnames
    One thing you'll notice as you read on is we're moving towards using atomic classnames for utility styles. What does that mean? Basically, each classname is just a convenience helper for applying one particular style. You build how an element looks and behaves by applying multiple classnames. 
    While this is slightly more verbose in the HTML, it's also much clearer and avoids having to create mutant selectors that exclude certain elements. If you see an element with ipsBorder_top, it's obvious what it does. Don't want a top border? Just remove that class.
    Another benefit is that it allows more precise control over how styles are applied at different device sizes, because individual styles can be modified. Want a top border on desktop, but not phones? ipsBorder_top sm:ipsBorder:none will do the job - no crazy selectors or additional media queries necessary.
     
    Class prefixes/modifiers
    Wait, what's that sm: bit in the atomic classname example above? That's a new naming convention you'll see which controls at which breakpoints the style is applied.
    Unprefixed (e.g. ipsBorder_top). Applies to all devices, desktop and smaller. md: (e.g. md:ipsBorder_top). Applies to tablets and smaller. sm: (e.g. sm:ipsBorder_top). Applies to phones only. sm and md prefixes take priority over the desktop classname. This means you provide the desktop classname but can override it for tablets and/or phones by also adding an md: or sm: classname. For example, ipsPadding_top:double sm:ipsPadding_top:half applies double top padding on desktop, but only half top padding on phones.
    You'll also see modifiers on some classes (as in the example above), for example ipsPadding:half. ipsPadding is saying 'apply padding to all sides', and the ':half' modifier makes it a smaller amount.
     
    BEM classnames for modules
    While we're using atomic classes for global utility styles, we're moving towards BEM for module-specific classes. BEM is simply a naming convention, so it doesn't have too much impact on you - you'll just see a new structure for new classnames that should be easier to understand. 
     
    Note: We haven't rewritten our CSS framework with the atomic classname, class prefix/modifier or BEM approaches. Don't worry - 90% of the classes you're used to will be the same. I just wanted to point out that going forward, new classes will follow these paradigms.
     
    CSS Variables & calc
    We're now making use of CSS variables (also known as CSS custom properties). Check out this MDN article if you aren't familiar with them. This enables us to define some values in one place but use them throughout the product - and it allows you to change the value in one place if you wish to do so for your theme. Most of our CSS variables are defined at the top of global.css in the CSS framework, but you'll also see some other local variables defined in other places. Variables are simply used by wrapping the name in the var() function, e.g. var(--positive-light). 
    You'll see some variables named --sp-1 and so on. This is our new 4px spacing scale. In 4.5 and going forward, when we style elements we'll generally be using one of these values for widths, heights, borders, spacing etc. to keep everything consistent. You should do the same for elements you create.
    We're also making use of calc(). This is another CSS function that allows math operations to be done. Instead of having to hardcode numbers for positions, sizes etc., we can now use calc() to do it for us based on some other values (often CSS variables).
    CSS Variables for theme settings
    We are deprecating the usage of the {theme} and {hextorgb} tags for color-type theme setting keys (but not for non-color settings or when you need to pass a specific hex code in).
    Instead, color-type theme settings will automatically have a CSS variable created for them, named --theme-setting_key, where setting_key is the key of the setting as defined in the AdminCP. The variable will be a triplet representing the color, for example 255, 255, 255. Therefore, this value can be used with both the rgb and rgba CSS color functions.
    Here's an example. If in the past you'd wanted to use the area_background theme setting in your CSS, you'd do background: {theme="area_background"}. Or if you want some opacity, you'd do background: {hextorgb="area_background" opacity="0.2"}.
    In 4.5, the correct way of using these will be: background: rgb( var(--theme-area_background) ) and background: rgba( var(--theme-area_background), 0.2 ) respectively.
    We're doing this now because it will open up some exciting functionality in future. To be clear, any existing usage of {theme} and {hextorgb} will continue to work fine in 4.5, but we encourage you to move over to the CSS variable approach.
     
    Hardcoded hex values
    In 4.5 we have largely removed all hardcoded hex colors from our CSS files, and adjusted styles to use theme setting values instead. This will make it much easier for admins to fully colorize their theme without hardcoded colors messing things up. I encourage you to update your app's CSS to follow this approach.
     
    Font sizes
    We've moved font sizes to a fixed scale. These have been implemented as theme settings so they are customizable. However, rather than use the theme setting value directly, you should make use of the new {fontsize} plugin. This plugin ensures the global scale is applied to any values passed in, allowing 'large print' versions of themes to be easily created. You should use the {fontsize} plugin for font sizes both when you use one of the theme settings and when you use specific pixel values (e.g. {fontsize="72"} - for 72px text)
    When used with the {fontsize} plugin, the type scale keys are:
    x_small (12px) small (13px) medium (14px) base (16px) large (18px) x_large (20px) 2x_large (24px) 3x_large (30px) 4x_large (36px)  
    Flexbox
    While we've used flexbox in some places in previous versions, 4.5 makes much wider use of it and also introduces a new family of classes. If you aren't familiar with flexbox, I highly recommend this CSSTricks article for a primer on it. Essentially, instead of positioning elements using floats/clears/etc., flexbox treats the container as a flexible box with properties for controlling how elements inside of it as laid out.
    4.5 has a number of new classes that are essentially just convenience for the usual CSS rules.
    ipsFlex (sets element to display: flex) ipsFlex-ai:start, ipsFlex-ai:center, ipsFlex-ai:end, ipsFlex-ai:stretch (ai - values for align-items property) ipsFlex-as:start, ipsFlex-as:center, ipsFlex-as:end, ipsFlex-as:stretch (as - values for align-self property) ipsFlex-jc:start, ipsFlex-jc:center, ipsFlex-jc:end, ipsFlex-jc:around, ipsFlex-jc:between (jc - values for justify-content property) ipsFlex-fd:column, ipsFlex-fd:row, ipsFlex-fd:column-reverse, ipsFlex-fd:row-reverse (fd - values for flex-direction property) ipsFlex-fw:wrap, ipsFlex-fw:nowrap, ipsFlex-fw:wrap-reverse (fw - values for flex-wrap property) ipsFlex-flex:10 - sets flex-grow: 1 and flex-shrink: 0 ipsFlex-flex:11 - sets flex-grow: 1 and flex-shrink: 1 ipsFlex-flex:01 - sets flex-grow: 0 and flex-shrink: 1 ipsFlex-flex:00 - sets flex-grow: 0 and flex-shrink: 0  
    All of these classes have md and sm prefixed versions too, and this opens up the possibility of having different layouts on different device sizes in a way that's much easier than the hoops you'd have to jump through before. For example, to create some elements that show as a row on desktop but collapse to a column on mobile, you'd just apply ipsFlex ipsFlex-fd:row sm:ipsFlex-fd:column. The sm:ipsFlex-fd:column class overrules the ipsFlex-fd:row class on mobile, adjusting the layout. (Note: flex-direction: row is the CSS default direction anyway, so you can actually leave out ipsFlex-fd:row - it's implicit. I included it in the example for clarity.)
     
    Padding/margin
    We've added new spacing classes for padding and margin, to allow for atomic classnames, device prefixes and modifiers.
    ipsPad, ipsPad_double, ipsPad_half, and all of the ipsSpacer_* classes are now deprecated. You'll still see them in our templates and they'll still work in yours, but don't use them in any new work - you should use the updated classes below.
    The padding classes are now named ipsPadding:
    ipsPadding, ipsPadding:none, ipsPadding:half, ipsPadding:double - apply padding to all four sides ipsPadding_vertical, ipsPadding_vertical:none, ipsPadding_vertical:half, ipsPadding_vertical:double - apply padding to top and bottom ipsPadding_horizontal, ipsPadding_horizontal:none, ipsPadding_horizontal:half, ipsPadding_horizontal:double - apply padding to left and right ipsPadding_left, ipsPadding_left:none, ipsPadding_left:half, ipsPadding_left:double - apply padding to the left side (RTL aware) ipsPadding_right, ipsPadding_right:none, ipsPadding_right:half, ipsPadding_right:double - apply padding to the right side (RTL aware) ipsPadding_top, ipsPadding_top:none, ipsPadding_top:half, ipsPadding_top:double - apply padding to the top side ipsPadding_bottom, ipsPadding_bottom:none, ipsPadding_bottom:half, ipsPadding_bottom:double - apply padding to the bottom side These classes have md and sm prefixed versions too, allowing you to apply different padding depending on the device size.
    One side note here: with the old padding classes, padding was simply halved on phones with no opt-out. That's not the case with the new family - if you want half-padding on mobile on an element, you should apply sm:ipsPadding:half in addition to the normal ipsPadding class, for example. This gives you much more control than you previously had.
    Margins follow basically an identical pattern to padding, with the same variation of classes, except the name is ipsMargin.
     
    Gaps
    Another new family of classes is ipsGap. These classes are used when you want spacing between elements. In the past, you'd have to use :last-child or :first-child to exclude an element, or loop over the elements in the template to leave off a class. If elements wrapped to a new line, putting spacing between the lines was tricky too.
    ipsGap solves this by applying even spacing between elements, then applying a negative margin on the whole container to bring it back to the starting position.
    The classname is followed by a modifier, which is a number from our spacing scale, e.g. 1 is 4px spacing, 2 is 8px spacing and so on.
    ipsGap:1 (1-5 available) - applies both horizontal and vertical spacing around each element in the container ipsGap_row:1 (1-5 available, as well as 0 to remove) - applies vertical spacing on each element in the container Notice ipsGap_row also supports the :0 modifier. This allows you to have horizontal-only spacing - simply apply ipsGap:1 ipsGap_row:0.
    Be aware that using both ipsMargin (or custom styles that apply a margin) and ipsGap on the same element can cause issues. You may want add a wrapper element to handle your margin in this situation.
     
    Borders
    We've also added a class family to add light grey 1px borders to elements - used commonly as dividers between some parts of the page.
    ipsBorder - apply border to all sides ipsBorder:none - remove border from all sides ipsBorder_vertical - apply border to top and bottom ipsBorder_horizontal - apply border to left and right ipsBorder_top, ipsBorder_bottom, ipsBorder_left, ipsBorder_right - apply border to a particular side These classes have md and sm prefixed versions too, to control borders shown on each device size. This is particularly useful if you apply a border to a flex child which is in a row on desktop but a column on desktop, for example - you will be able to easily control which side the border appears on once collapsed.
     
    "Pull" class
    To better display content areas on mobile, a class named ipsResponsive_pull has been added which 'pulls' a box on the left and right sides on small devices. It's intended to be used on boxes (normally with the ipsBox class) that you want to take up the whole screen width on mobile, allowing better usage of the available screen space.
     
    Template changes
    We've worked to keep template changes as minimal as possible, but in an update the size of 4.5 there are still quite a number of changes. Whether these impact you will depend on if you've modified the template (for theme designers) or rely on a particular selector for theme hooks (for developers).
    One area that has received fairly big changes is the post/comment templates. We have redesigned the headers and footers of these templates and moved some elements into a separate parent element on mobile devices.
    As usual, full template changes will be available once we've released betas.
  2. Thanks
    Rikki got a reaction from Adlago in Underscore@1.8.3 - libraries with known security vulnerabili   
    This will be updated in the next release, but note that the security vulnerability would not impact us due to the way we use the library.
  3. Like
    Rikki got a reaction from Jordan Invision in Option to allow guest posting   
    You can already either allow guests to post, or use a simple 'post before registering' approach that allows people to post their message and then complete the signup process later.
    Typically allowing guests to post isn't a great idea, but the option is there should you want it.
  4. Like
    Rikki got a reaction from Linux-Is-Best in Option to allow guest posting   
    You can already either allow guests to post, or use a simple 'post before registering' approach that allows people to post their message and then complete the signup process later.
    Typically allowing guests to post isn't a great idea, but the option is there should you want it.
  5. Like
    Rikki got a reaction from Unienc in [Theme Designers] Create parent theme easier   
    We have an outstanding bug open whereby child themes don't inherit new theme settings that are added to a parent, but aside from that, child themes should pretty much work as you describe, including custom CSS.
    When we build multi-brand themes in-house, we tend to add the 'master' brand styles to custom.css, then don't edit that in the child theme at all - let it inherit so that it's always up to date. If there are any styles used that we actually want to be branded, we use CSS variables for those. Then create separate CSS files in the child themes that have any styles specific to that brand, and also set our brand-specific CSS variable values.
    So something like
    /* custom.css in parent theme */ .someTitle { font-family: ...; font-size: 30px; color: var(--branded-title, #000); } /* sub.css in a child theme */ :root { --branded-title: #ff0000; }  
  6. Like
    Rikki got a reaction from Jimi Wikman in [Theme Designers] Create parent theme easier   
    We have an outstanding bug open whereby child themes don't inherit new theme settings that are added to a parent, but aside from that, child themes should pretty much work as you describe, including custom CSS.
    When we build multi-brand themes in-house, we tend to add the 'master' brand styles to custom.css, then don't edit that in the child theme at all - let it inherit so that it's always up to date. If there are any styles used that we actually want to be branded, we use CSS variables for those. Then create separate CSS files in the child themes that have any styles specific to that brand, and also set our brand-specific CSS variable values.
    So something like
    /* custom.css in parent theme */ .someTitle { font-family: ...; font-size: 30px; color: var(--branded-title, #000); } /* sub.css in a child theme */ :root { --branded-title: #ff0000; }  
  7. Like
    Rikki reacted to Arantor in CKEditor 4 end of life - alternative editor consideration   
    That wasn't what killed SMF 2.1 - but that's a debate for somewhere else (perhaps we can continue this on TAZ?)
    I know no-one suggested it. I was getting in ahead of the otherwise-inevitable suggestion because no doubt someone was going to suggest it with crystalised examples of 'why you shouldn't'.
    Even CKEditor has written articles explaining the rationale for dropping aspects of the browser 'helping' before reimplementing the functionality on its own because browser support for this is frankly awful.
    I would actually suggest that the entire concept of trying to do it is somewhat a fool's errand. Google Docs is actually moving away from using HTML to render docs going forward because as far as they're concerned, they've reached the limit of what can be done and that ripping it out and doing something different is actually viable.
     
    What it ultimately comes down to is which audience you're actually trying to target. The majority of commenters in threads don't really need particularly rich editing. You need the basics, sure, and some richer elements like quote handling, as well as some functionality for embedding media with *some* choices to make formatting. But the vast majority of *replies* do not need to be delightfully rich in content because the general nature is that commenters in threads are doing a different kind of content creation to topic creators.
    Now, topic creators - and by extension with things like IP Pages, IP Blogs, and related 'opening posts' where you expect and want richer media options - and where CKEditor isn't actually a poor fit. Neither is Gutenberg, incidentally. They all have their foibles, and you're picking the least worst choice for your situation.
    All of the suggestions on the table are reasonable alternatives for some subset of the target market - the question is whether you care most about the creators and giving them all the options, or the commenters on content.
    I also think this is a complex case because the people who are responding in this thread are going to be predominantly the content creator types, who will obviously want richer and more interesting content creation tools - rather than being the much-larger segment of people who will simply interact on the forum.
    I find it interesting that after decades, we're still looking at the core posting experience and going 'Hmm... that's not quite right'.
    Tell you what I'd do at this point: I'd make it pluggable and let users decide what they want to use, since they all interchange raw HTML at this point, why not just let the site admins pick which one(s) they want to use - allow for CKEditor 5 for admins, and I dunno, QuillJS for regular users? (Quill has the advantage that it's deliberately set up to have a limited surface area and focus on what it offers rather than trying to be rich and detailed)
    The only pain points then become interoperability with existing tools and things like drag and drop. But it's an idea to throw out there.
  8. Thanks
    Rikki got a reaction from Linux-Is-Best in 4.5 CSS Changes for developers & designers   
    4.5 introduces some changes to CSS, so I wanted to provide an overview of those and how they might affect you.
     
    IE11
    Firstly, we've completely dropped support for IE11. This means you'll start to see newer CSS methods being used that IE11 does not support. 
     
    Atomic classnames
    One thing you'll notice as you read on is we're moving towards using atomic classnames for utility styles. What does that mean? Basically, each classname is just a convenience helper for applying one particular style. You build how an element looks and behaves by applying multiple classnames. 
    While this is slightly more verbose in the HTML, it's also much clearer and avoids having to create mutant selectors that exclude certain elements. If you see an element with ipsBorder_top, it's obvious what it does. Don't want a top border? Just remove that class.
    Another benefit is that it allows more precise control over how styles are applied at different device sizes, because individual styles can be modified. Want a top border on desktop, but not phones? ipsBorder_top sm:ipsBorder:none will do the job - no crazy selectors or additional media queries necessary.
     
    Class prefixes/modifiers
    Wait, what's that sm: bit in the atomic classname example above? That's a new naming convention you'll see which controls at which breakpoints the style is applied.
    Unprefixed (e.g. ipsBorder_top). Applies to all devices, desktop and smaller. md: (e.g. md:ipsBorder_top). Applies to tablets and smaller. sm: (e.g. sm:ipsBorder_top). Applies to phones only. sm and md prefixes take priority over the desktop classname. This means you provide the desktop classname but can override it for tablets and/or phones by also adding an md: or sm: classname. For example, ipsPadding_top:double sm:ipsPadding_top:half applies double top padding on desktop, but only half top padding on phones.
    You'll also see modifiers on some classes (as in the example above), for example ipsPadding:half. ipsPadding is saying 'apply padding to all sides', and the ':half' modifier makes it a smaller amount.
     
    BEM classnames for modules
    While we're using atomic classes for global utility styles, we're moving towards BEM for module-specific classes. BEM is simply a naming convention, so it doesn't have too much impact on you - you'll just see a new structure for new classnames that should be easier to understand. 
     
    Note: We haven't rewritten our CSS framework with the atomic classname, class prefix/modifier or BEM approaches. Don't worry - 90% of the classes you're used to will be the same. I just wanted to point out that going forward, new classes will follow these paradigms.
     
    CSS Variables & calc
    We're now making use of CSS variables (also known as CSS custom properties). Check out this MDN article if you aren't familiar with them. This enables us to define some values in one place but use them throughout the product - and it allows you to change the value in one place if you wish to do so for your theme. Most of our CSS variables are defined at the top of global.css in the CSS framework, but you'll also see some other local variables defined in other places. Variables are simply used by wrapping the name in the var() function, e.g. var(--positive-light). 
    You'll see some variables named --sp-1 and so on. This is our new 4px spacing scale. In 4.5 and going forward, when we style elements we'll generally be using one of these values for widths, heights, borders, spacing etc. to keep everything consistent. You should do the same for elements you create.
    We're also making use of calc(). This is another CSS function that allows math operations to be done. Instead of having to hardcode numbers for positions, sizes etc., we can now use calc() to do it for us based on some other values (often CSS variables).
    CSS Variables for theme settings
    We are deprecating the usage of the {theme} and {hextorgb} tags for color-type theme setting keys (but not for non-color settings or when you need to pass a specific hex code in).
    Instead, color-type theme settings will automatically have a CSS variable created for them, named --theme-setting_key, where setting_key is the key of the setting as defined in the AdminCP. The variable will be a triplet representing the color, for example 255, 255, 255. Therefore, this value can be used with both the rgb and rgba CSS color functions.
    Here's an example. If in the past you'd wanted to use the area_background theme setting in your CSS, you'd do background: {theme="area_background"}. Or if you want some opacity, you'd do background: {hextorgb="area_background" opacity="0.2"}.
    In 4.5, the correct way of using these will be: background: rgb( var(--theme-area_background) ) and background: rgba( var(--theme-area_background), 0.2 ) respectively.
    We're doing this now because it will open up some exciting functionality in future. To be clear, any existing usage of {theme} and {hextorgb} will continue to work fine in 4.5, but we encourage you to move over to the CSS variable approach.
     
    Hardcoded hex values
    In 4.5 we have largely removed all hardcoded hex colors from our CSS files, and adjusted styles to use theme setting values instead. This will make it much easier for admins to fully colorize their theme without hardcoded colors messing things up. I encourage you to update your app's CSS to follow this approach.
     
    Font sizes
    We've moved font sizes to a fixed scale. These have been implemented as theme settings so they are customizable. However, rather than use the theme setting value directly, you should make use of the new {fontsize} plugin. This plugin ensures the global scale is applied to any values passed in, allowing 'large print' versions of themes to be easily created. You should use the {fontsize} plugin for font sizes both when you use one of the theme settings and when you use specific pixel values (e.g. {fontsize="72"} - for 72px text)
    When used with the {fontsize} plugin, the type scale keys are:
    x_small (12px) small (13px) medium (14px) base (16px) large (18px) x_large (20px) 2x_large (24px) 3x_large (30px) 4x_large (36px)  
    Flexbox
    While we've used flexbox in some places in previous versions, 4.5 makes much wider use of it and also introduces a new family of classes. If you aren't familiar with flexbox, I highly recommend this CSSTricks article for a primer on it. Essentially, instead of positioning elements using floats/clears/etc., flexbox treats the container as a flexible box with properties for controlling how elements inside of it as laid out.
    4.5 has a number of new classes that are essentially just convenience for the usual CSS rules.
    ipsFlex (sets element to display: flex) ipsFlex-ai:start, ipsFlex-ai:center, ipsFlex-ai:end, ipsFlex-ai:stretch (ai - values for align-items property) ipsFlex-as:start, ipsFlex-as:center, ipsFlex-as:end, ipsFlex-as:stretch (as - values for align-self property) ipsFlex-jc:start, ipsFlex-jc:center, ipsFlex-jc:end, ipsFlex-jc:around, ipsFlex-jc:between (jc - values for justify-content property) ipsFlex-fd:column, ipsFlex-fd:row, ipsFlex-fd:column-reverse, ipsFlex-fd:row-reverse (fd - values for flex-direction property) ipsFlex-fw:wrap, ipsFlex-fw:nowrap, ipsFlex-fw:wrap-reverse (fw - values for flex-wrap property) ipsFlex-flex:10 - sets flex-grow: 1 and flex-shrink: 0 ipsFlex-flex:11 - sets flex-grow: 1 and flex-shrink: 1 ipsFlex-flex:01 - sets flex-grow: 0 and flex-shrink: 1 ipsFlex-flex:00 - sets flex-grow: 0 and flex-shrink: 0  
    All of these classes have md and sm prefixed versions too, and this opens up the possibility of having different layouts on different device sizes in a way that's much easier than the hoops you'd have to jump through before. For example, to create some elements that show as a row on desktop but collapse to a column on mobile, you'd just apply ipsFlex ipsFlex-fd:row sm:ipsFlex-fd:column. The sm:ipsFlex-fd:column class overrules the ipsFlex-fd:row class on mobile, adjusting the layout. (Note: flex-direction: row is the CSS default direction anyway, so you can actually leave out ipsFlex-fd:row - it's implicit. I included it in the example for clarity.)
     
    Padding/margin
    We've added new spacing classes for padding and margin, to allow for atomic classnames, device prefixes and modifiers.
    ipsPad, ipsPad_double, ipsPad_half, and all of the ipsSpacer_* classes are now deprecated. You'll still see them in our templates and they'll still work in yours, but don't use them in any new work - you should use the updated classes below.
    The padding classes are now named ipsPadding:
    ipsPadding, ipsPadding:none, ipsPadding:half, ipsPadding:double - apply padding to all four sides ipsPadding_vertical, ipsPadding_vertical:none, ipsPadding_vertical:half, ipsPadding_vertical:double - apply padding to top and bottom ipsPadding_horizontal, ipsPadding_horizontal:none, ipsPadding_horizontal:half, ipsPadding_horizontal:double - apply padding to left and right ipsPadding_left, ipsPadding_left:none, ipsPadding_left:half, ipsPadding_left:double - apply padding to the left side (RTL aware) ipsPadding_right, ipsPadding_right:none, ipsPadding_right:half, ipsPadding_right:double - apply padding to the right side (RTL aware) ipsPadding_top, ipsPadding_top:none, ipsPadding_top:half, ipsPadding_top:double - apply padding to the top side ipsPadding_bottom, ipsPadding_bottom:none, ipsPadding_bottom:half, ipsPadding_bottom:double - apply padding to the bottom side These classes have md and sm prefixed versions too, allowing you to apply different padding depending on the device size.
    One side note here: with the old padding classes, padding was simply halved on phones with no opt-out. That's not the case with the new family - if you want half-padding on mobile on an element, you should apply sm:ipsPadding:half in addition to the normal ipsPadding class, for example. This gives you much more control than you previously had.
    Margins follow basically an identical pattern to padding, with the same variation of classes, except the name is ipsMargin.
     
    Gaps
    Another new family of classes is ipsGap. These classes are used when you want spacing between elements. In the past, you'd have to use :last-child or :first-child to exclude an element, or loop over the elements in the template to leave off a class. If elements wrapped to a new line, putting spacing between the lines was tricky too.
    ipsGap solves this by applying even spacing between elements, then applying a negative margin on the whole container to bring it back to the starting position.
    The classname is followed by a modifier, which is a number from our spacing scale, e.g. 1 is 4px spacing, 2 is 8px spacing and so on.
    ipsGap:1 (1-5 available) - applies both horizontal and vertical spacing around each element in the container ipsGap_row:1 (1-5 available, as well as 0 to remove) - applies vertical spacing on each element in the container Notice ipsGap_row also supports the :0 modifier. This allows you to have horizontal-only spacing - simply apply ipsGap:1 ipsGap_row:0.
    Be aware that using both ipsMargin (or custom styles that apply a margin) and ipsGap on the same element can cause issues. You may want add a wrapper element to handle your margin in this situation.
     
    Borders
    We've also added a class family to add light grey 1px borders to elements - used commonly as dividers between some parts of the page.
    ipsBorder - apply border to all sides ipsBorder:none - remove border from all sides ipsBorder_vertical - apply border to top and bottom ipsBorder_horizontal - apply border to left and right ipsBorder_top, ipsBorder_bottom, ipsBorder_left, ipsBorder_right - apply border to a particular side These classes have md and sm prefixed versions too, to control borders shown on each device size. This is particularly useful if you apply a border to a flex child which is in a row on desktop but a column on desktop, for example - you will be able to easily control which side the border appears on once collapsed.
     
    "Pull" class
    To better display content areas on mobile, a class named ipsResponsive_pull has been added which 'pulls' a box on the left and right sides on small devices. It's intended to be used on boxes (normally with the ipsBox class) that you want to take up the whole screen width on mobile, allowing better usage of the available screen space.
     
    Template changes
    We've worked to keep template changes as minimal as possible, but in an update the size of 4.5 there are still quite a number of changes. Whether these impact you will depend on if you've modified the template (for theme designers) or rely on a particular selector for theme hooks (for developers).
    One area that has received fairly big changes is the post/comment templates. We have redesigned the headers and footers of these templates and moved some elements into a separate parent element on mobile devices.
    As usual, full template changes will be available once we've released betas.
  9. Thanks
    Rikki got a reaction from The Old Man in 4.5 CSS Changes for developers & designers   
    We only automatically convert colors primarily because they make the most sense as CSS variables. CSS variables also have to be valid CSS values, so we can't easily convert all theme settings into CSS variables. If you only use a theme setting in a couple of places, it probably won't be worth making it a CSS variable - just use the theme setting as before.
    You are correct that the font size plugin converts to px. If you need other units, simply use them directly, or make them a CSS variable - but you can't pass the CSS variable into the font size plugin like your example. Instead just use them directly; assuming the value of your theme setting was "3rem", you could do font-size: var(--theme-your_setting);.
    For your last example, remember the variable value has to be a valid CSS value. So the --theme-my_line_margin_top variable should include the % symbol - you can't concatenate it like you've done.
    Based on the examples you've described, I would just continue using your theme settings as before.
     
     
  10. Like
    Rikki got a reaction from SeNioR- in Add editor backend review (WYSIWYG code review)   
    Important note: Don't enable this setting for any untrusted groups (e.g. regular users).
  11. Like
    Rikki got a reaction from marklcfc in [IPS 4.6] User hovercard - Removed "last visited" field?   
    This will be back in the next build 🙂 
  12. Meow
    Rikki got a reaction from Linux-Is-Best in Add editor backend review (WYSIWYG code review)   
    Important note: Don't enable this setting for any untrusted groups (e.g. regular users).
  13. Like
    Rikki got a reaction from Unienc in Add editor backend review (WYSIWYG code review)   
    Important note: Don't enable this setting for any untrusted groups (e.g. regular users).
  14. Agree
    Rikki got a reaction from mcartemon2we23 in [IPS 4.6] User hovercard - Removed "last visited" field?   
    This will be back in the next build 🙂 
  15. Thanks
    Rikki got a reaction from Jordan Invision in [IPS 4.6] User hovercard - Removed "last visited" field?   
    This will be back in the next build 🙂 
  16. Thanks
    Rikki got a reaction from Unienc in [IPS 4.6] User hovercard - Removed "last visited" field?   
    This will be back in the next build 🙂 
  17. Thanks
    Rikki got a reaction from aXenDev in [IPS 4.6] User hovercard - Removed "last visited" field?   
    This will be back in the next build 🙂 
  18. Like
    Rikki got a reaction from Linux-Is-Best in MS IE warning   
    Just to note, we did list this change in the deprecation section for 4.5. We always recommend reviewing the release notes, especially for major releases.
  19. Agree
    Rikki got a reaction from Linux-Is-Best in MS IE warning   
    Even Microsoft will not support IE11 (or legacy Edge) in any way from next year, including in its own products like Teams. Other major sites like Twitter are starting to drop any support too. It won't be long until you'll struggle to use the web on IE11. Technically we have not supported it for a long time, but because we held back on modern CSS features, it still mostly worked. For 4.5, we decided now was the time to press ahead with improvements and drop support ourselves.
    By dropping support, we've been able to use newer CSS features that benefit designers (and therefore site owners), simplify our theme (with more improvements to come), and we'll also be able to begin the process of modernizing our javascript.
    If your community has a significant percentage of IE11 users due to your audience, you may prefer to stay on 4.4 (though that, understandably, has drawbacks too). If you're just an individual IE11 user, I would strongly suggest using a newer browser - literally any of them would be a better choice. 
  20. Like
    Rikki reacted to Dll in Inconsistent widths within topics   
    I understand this is configurable, but it makes no sense that the default behaviour  of the software is to have a different page width for posts within topics based on whether it has less than or greater than 3 pages. Obviously, having a topic summary when there are just a few posts makes little sense, so I get the reasoning but it makes for a very inconsistent ui, which displays a lack of planning or consideration around what is actually best for the user, readability of topics and so on.
    Has anyone looked into whether having the sidebar or not makes any difference in terms of the readability, the time spent within topics or anything along those lines?
  21. Like
    Rikki got a reaction from DawPi in Silly stuff what I noticed with IPS 4.6.0 CA1.1 - part 1   
    @opentype Fixed the duplication when dragged (in 4.6, so won't show up here immediately)
    @DawPi Fixed
  22. Agree
    Rikki got a reaction from Jon Erickson in Requesting support?   
    You can also email support@invisionpower.com 🙂 
  23. Agree
    Rikki got a reaction from SeNioR- in JQMIGRATE - will it be finally fixed?   
    Yes, this isn't a bug per se. Jqmigrate is a tool that allows us to polyfill some APIs that changed in the latest jQuery releases, without having to make large changes to our own code immediately. Think of it as a compatibility layer. The logging you see simply indicates when Jqmigrate has needed to polyfill some behavior.
  24. Like
    Rikki got a reaction from Daniel F in JQMIGRATE - will it be finally fixed?   
    Yes, this isn't a bug per se. Jqmigrate is a tool that allows us to polyfill some APIs that changed in the latest jQuery releases, without having to make large changes to our own code immediately. Think of it as a compatibility layer. The logging you see simply indicates when Jqmigrate has needed to polyfill some behavior.
  25. Like
    Rikki got a reaction from AlexJ in Need more granularity for notification settings   
    We investigated this and it turned out to be a bug whereby daily/weekly digests were not disabled when the link was clicked. The fix will be in the next release 🙂 
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy