Salesforce Development

Sorry to Interrupt: Troubleshooting and Debugging Lightning Components [VIDEO]

I had the opportunity to present Sorry to Interrupt: Troubleshooting and Debugging Lightning Component Issues at the London’s Calling 2018 Salesforce community event.

This was the first delivery of a session that I also gave at Snowforce 2018 and Southeast Dreamin’ 2018, and will give at Forcelandia 2018 in August.

I also recorded a Pluralsight Play by Play with Don Robins on the subject that will be available in June of 2018.

Let me know what you think.

Handle DOM Events Raised by Base Lightning Components

Buntysmum / Pixabay

Base Lightning components, introduced with the Winter ’17 release, provide developers with granular and reusable “out of the box” components that can be used to render HTML for everything from navigation menus, to form fields, to data tables, and many other UI patterns in between.

The primary value add of base Lightning components is that they apply the Salesforce Lightning Design System (SLDS) styling to the HTML that is output when the components render.

Another value add is that many of the base Lightning components raise events that can be handled within your component hierarchy.

By now you should realize that the Lightning Component Framework is an event driven architecture, and how you manage events is a critical aspect to Lightning application design.

Thankfully, raising and handling events from base Lightning components is in itself fairly straightforward and handles many of the use cases requiring events to be raised from user interaction.

What I have found in my own development experience is that there are certain edge use cases where the events raised by base Lightning components do not go far enough.

This doesn’t mean we need to throw the baby out with the bathwater and abandon base Lightning components in favor of hand writing all custom HTML and JavaScript, however.

It just takes a deeper understanding of how events are raised and handled to find an elegant solution that incorporates base Lightning components and a minimal amount of custom HTML.

I would like to propose a simple solution for when you run into situations where you need a more robust set of events than what are raised by base Lightning components, and provide some background on “how” and “why” this works.

A Common Pattern: Onfocus and Onblur

One of the things that I have noticed with the architecture of base Lightning Components is that many of them share a common pattern in the way in which they raise events.

While some base Lightning components do not raise any events of their own, many components in the lightning: namespace have event attributes that can be used to raise and handle events within the component hierarchy.

Of the base components that do raise events, such as <lightning:input>, <lightning:select>, <lightning:button> and others, share the same two component event attributes: onfocus and onblur.

The focus event is raised when an element is in focus – meaning a user has clicked on or tabbed to that particular element.

blur is the opposite of focus. When an element is currently in focus and the user then clicks on or tabs to a new element, the blur event fires on the previously focused element while the focus event fires on the newly focused element.

The focus and blur events are typically associated with HTML elements such as <select>, <input> and <a>, but it is important to note that the onfocus and onblur event attributes for base Lightning components do not raise the focus or blur Document Object Model (DOM) events.

When a base Lightning component includes the onfocus or onblur event attributes in its definition, what it actually raises is an event that is custom to the Lightning Component Framework and can only be handled by another Lightning component.

Beyond Blur: Additional Base Lightning Component Event Attributes

Most of the components that raise the focus and blur events will also raise another complementary event specific to the way in which a user interacts with the component itself.

For example, in addition to the onfocus and onblur event attributes, <lightning:button> can raise a third event called click by including the onclick event attribute with a reference to a controller function.

This is because the expected interaction with the <lightning:button> component is for a user to click on it.

The <lighting:select> component, which displays a picklist of options, raises a third event called change by including the onchange event attribute in the reference to the component.

Again, this is because the expected interaction with <lightning:select> is for a user to select an option from a dropdown list, and if the newly selected value is different from the previously selected value, that may be of significance from a UX perspective and require the firing of an event.

Remember, when base Lightning components fire events, they are not DOM events – they are component events raised by the Lightning Component Framework.

While they may not be DOM events, they follow a similar propagation pattern in that the events “bubble up” through the component hierarchy and can be handled by any component in the ancestry starting from the component that fired the event all the way up to the root (top level) component. We’ll cover the concept of bubbling a little later to understand how all of this works.

The reason why it is great that Salesforce provides these event attributes for base Lightning components is because the focus and blur DOM events do not bubble and must be handled by event listeners defined at the level of the specific HTML element that raises the event.

In contrast, using the onfocus and onblur Lightning component events enable the events to be handled by a parent Lightning component that references a JavaScript function in its local controller.

These component events are powerful and handle most use cases for firing events directly from base Lightning components based on specific user interactions, but how does it work if you want to handle events other than focus, blur, change or click?

Base Lightning Components and DOM Events

What happens when you want to handle DOM events such as keyup or mouseover from a <lightning:input> component? How can you handle the dblclick event for a <lightning:formattedText> component?

Well…in a nutshell, you can’t. Why? Because there are no attributes defined for these events in base Lightning components.

Lightning components only support events explicitly listed in the documentation. If <lightning:input> only lists onfocus, onblur and onchange as event attributes, then those are the only events that it raises and can be handled by the parent component.

Not to worry, though. There is a solution if you want to handle DOM events that are not explicitly supported by base Lightning component event attributes.

Handling DOM Events Raised by Base Lightning Components

To handle an event that is not supported for a given base Lightning component, you simply need wrap the component in a containing HTML element. This will typically be a <div>, and you will handle the DOM event there.

For example, if you want to handle the dblclick event when a user double clicks the mouse on a <lightning:formattedText> component, simply wrap it in a <div> and include the ondblclick event attribute in the reference to the containing <div> as illustrated:



<div ondblclick=“{!c.myDblclickEventHandler}”>
    <lightning:formattedText value=“Double click on me!“ />
</div>


Why does this work?

To understand why this works, you first have to understand something called “bubbling.”

The concept of bubbling is fairly straightforward. When an event that supports bubbling is fired from an HTML element, that event can be first be handled by the actual element raising the event if it has a handler defined for the event.

Note: Not all events support bubbling. As mentioned previously, the focus and blur events do not bubble.

If the HTML element raising the event has not added a listener for the event, or if it does handle the event but does not explicitly stop bubbling by referencing the stopPropagation() function on the Event object, the event will bubble to the parent element of the element that raised the event.

Following the same pattern, the event will continue to raise its way through the DOM tree starting with the parent HTML element and continuing until bubbling is explicitly stopped or the event reaches the root of the HTML document without being handled.

How Does DOM Event Propagation Apply to Base Lightning Components?

Earlier we mentioned that base Lightning components do not support the raising of DOM events, only component events that are raised and handled within the Lightning Component Framework itself.

So what does DOM event bubbling have to do with base Lightning components?

The answer is simple if you think about what base Lightning components actually do – base components exist to simplify the process of generating HTML for UI elements that implement SLDS for you automatically.

Rather than having to hand write all of the HTML and CSS to implement SLDS prototype components such as buttons or form input fields, base Lightning components allow developers to control the styling and behavior of the rendered output by setting attribute values in the definition of the base component.

Base Lightning components, in turn, render HTML elements with references to CSS classes defined in the SLDS external stylesheet.

For example, the following reference to a base Lightning component:

<lightning:input name="mySampleComponent" label="This is a sample lightning:input component" />

Renders the following markup:


<div class="slds-form-element lightningInput" data-aura-rendered-by="5:0" data-aura-class="lightningInput">

    <label class="slds-form-element__label slds-no-flex" for="3:0" data-aura-rendered-by="7:0">

        <span class="" data-aura-rendered-by="9:0">

        This is a sample lightning:input component

        </span>

    </label>

    
<div class="slds-form-element__control slds-grow" data-aura-rendered-by="11:0">

        <input class="slds-input" type="text" id="3:0" style="" data-aura-rendered-by="12:0" name="mySampleComponent">

    </div>


</div>

To break this down, at the core of the rendered output we have an HTML <input> element that is contained by a <div> element. We also have a <span> element, which is the child of a <label> element.

The containing <div> element for the <input> as well as the <label> element are themselves wrapped by a top-level containing <div>.

That’s a lot of nesting! This complex output is simplified by the use of the <lightning:input> component, but how does this apply to raising and handling DOM events?

How Does This Work?

Let’s say that we want to handle the focus event for the <lightning:input> base Lightning component in the previous example. This would be simple because <lightning:input> has an event attribute called onfocus.

All we would need to do in order to handle focus is include the onfocus attribute and reference a controller function like this:

<lightning:input onfocus=“{!c.myFocusEventHandler}” />

Because focus is a component event, we could get information about the component that raised the event by using the getSource() method on the Event object in our controller function:

myFocusEventHandler : function(component, event, helper) {

    var sourceComponent = event.getSource();

    // Additional logic

}

Simple enough, right?

So now let’s say we wanted to handle the keyup event that gets raised from the <input> element when a user presses and releases a key on the keyboard.

When this event is raised we want to call a function to check whether the user pressed the “tab” or “enter” keys.

How do we do that since onkeyup is not listed as an event attribute in the documentation for <lightning:input>?

This is where we want to wrap our base Lightning component with an HTML element such as a <div> and have the containing element handle the event.

Remember, most DOM events support bubbling. In this example, the keyup event will be raised by the HTML <input> element generated by the <lightning:input> component when it is rendered.

The keyup event will not be handled by the <input> element itself, nor will it be handled by the <div> that contains it or the top-level <div> rendered by the component.

It will bubble up to our wrapper <div> and we will handle the keyup event there by calling the controller function referenced in the onkeyup event attribute.

Here’s what this would look like in your custom component markup:


<div onkeyup=“{!c.myKeyupEventHandler}”>

    <lightning:input name="mySampleComponent" label="This is a sample lightning:input component" />

</div>

Handling the DOM Event

When we handle raised events that are native to the Lightning Component Framework, we get access to more robust event handling functionality, such as getting access to the component that raised the event by using event.getSource().

Unfortunately when we raise and handle DOM events like we are doing here, referencing event.getSource() will return an ‘undefined’ value.

So how do we get information about the raised DOM event? This is where we have to know a little bit of JavaScript.

When we raise and handle DOM events using JavaScript, we get access to a number of properties on the Event object that provide references to the HTML elements involved in the firing and handling of the events:

event.target references the HTML element that actually fired the event. In our use case, event.target will reference the <input> element where the keyup event occurred.

event.currentTarget references the HTML element that is currently handling the fired event. In our use case, event.currentTarget will reference the <div> that we used to wrap the <lightning:input> component.

Additional Considerations for Using event.target and event.currentTarget

Learning how to use event.target and event.currentTarget for DOM events and event.getSource() for component events will enable you to design a robust event-driven architecture in your custom Lightning components.

So why not just use event.target and event.currentTarget to handle all events, including DOM events and Lightning component or application events?

You can thank Locker Service for throwing cold water on that idea. event.target and event.currentTarget are not available when handling Lightning component events because of Locker Service restrictions.

Without going into the gory details, Locker Service wraps each Lightning component in a secure document that renders the HTML for that component within a virtual DOM.

Using event.target or event.currentTarget would essentially allow you to reach into the DOM for the source component, breaking encapsulation.

Also note that event.target and event.currentTarget are properties of the Event object – not methods. As such, you do not need to append () to the property name – if you do you will experience a JavaScript error.

Additional Resources

CSS Primer for Lightning Developers: CSS Units for Length Measurement

CSS supports an assortment of units for measuring length. Some units are absolute, some are relative to the length of other values.

Length is expressed as a number value followed by a unit of measurement, an example of an absolute value being 16px, or a relative value being 1em.

Absolute Length Units

Absolute length CSS units are used to represent fixed, physical lengths. Some units, such as the px and pt unit, are relative to physical lengths. The px unit can also be relative to the output device, where 1px can equal one device pixel. The pica, or pc unit, is relative to pt units even though it is considered an absolute length.

Absolute lengths are great to use when you know the exact dimensions of where your content will be output, such as a printer, but for Lightning Components and Applications, you will be better suited to use relative units more times than not.

This is because there is no way to anticipate the pixel density of the devices that will be interacting with your components, and your goal as a Lightning developer is to create responsive applications that are agnostic to the device in which they are displayed.

Absolute lengths can be measured by the following units:

  • mm – One millimeter
  • cm – One centimeter (equivalent to 10mm)
  • in – One inch (equivalent to 2.54cm)
  • px – One pixel (equivalent to 1/96 of an inch)
  • pt – One point (equivalent to 1/72 of an inch)
  • pc – One pica (equivalent to 12 points)

Relative Length Units

Relative length CSS units are used to represent lengths relative to other length values. This allows you to easily make elements smaller or larger than reference elements without having to hardcode specific length values.

Relative length units, for all intents and purposes, break down into two categories – units that are relative to a font size, and units that are relative to the viewport size.

Units Relative to Font Size

The most commonly used relative units calculate length based on the font size of an element. Other more esoteric units calculate length based on the size of specific characters within a font.

The units relative to font size include:

  • em – This is the most common relative unit and the one you should become most familiar with, as it will help you create the most scalable layouts for your components. For any property other than the font-size property itself, em is a multiple of the font-size of the current element, with 1em being equivalent to the font-size of the current element. For example, if the font-size of an element is 10px, then 1em would equal 10px, 0.5em would equal 5px, 2em would equal 20px, and so on. If no font size is specified, 1em is equal to 16px, or 12pt.
  • rem – Very similar to em, the rem unit is also a multiple of font-size, but instead of being relative to the current element (or the parent element in the case of the font-size property itself), rem calculates length relative to the root element of the HTML document. If you prefer to have everything in your components scale perfectly from a single value rather than from cascading values, rem may be a better option for you than em.
  • ex – This is one of the esoteric units mentioned above, and it is not commonly used. Known as a typographic measurement, ex is relative to the x-height of the current font – literally the height of the “x” character contained in the font. If there is no “x” character, ex defaults to 0.5em.
  • ch – Another fairly esoteric unit that is not commonly used, ch is similar to ex in that it is a typographic measurement, but in this case it is based on the width of the “0” (zero) character of a font.

If an em unit is used on the actual font-size property, the value is calculated based on the inherited font-size of the parent element.

Units Relative to Viewport

While having units relative to the percentage of the viewport (the visible area of a document in a browser) makes logical sense for specifying length values for elements that make up the layout of a page, in practical terms these units have not been widely adopted and I am only going to give them a brief mention for the sake of reference:

  • vw – The “viewport width” unit. 1vw is the equivalent of 1% of the viewport width
  • vh – The “viewport height” unit. 1vw is the equivalent of 1% of the viewport height
  • vmin – The smaller of the vw or vh values
  • vmax – The larger of the vw or vh values

CSS Primer for Lightning Developers: Background Properties

There are a number of CSS properties that you can use to style Lightning Components by filling the background of HTML elements with colors or images.

A background consists of the total size of the element, which includes any padding and border spacing, but not margin spacing.

Background properties include:

  • background-color
  • background-image
  • background-position
  • background-attachment
  • background-repeat

background-color

The background-color property specifies the color that is used for the background of an element.

Possible values include:

  • A supported color name such as red, green, or blue
  • An RGB value such as rgb(255,0,0), rgb(0,255,0), or rgb(0,0,255)
  • A hexadecimal value such as #ff0000, #00ff00, or #0000ff
  • transparent – Sets the background color to transparent. This is the default value.
  • inherit – Inherits the background-color value from the parent element
  • initial – Sets the background-color value to its default

background-image

The background-image property specifies one or more images to be used for the background of an element.

When a background-image is specified, it is placed at the top-left corner of the element and repeated vertically and horizontally by default. You can use the background-position and background-repeat properties to change this behavior.

Possible values for background-image include:

  • url – A comma-separated list of URLs for images to be used for the background of an element
  • none – No background image will be used. This is the default value.
  • inherit – Inherits the background-image value from the parent element
  • initial – Sets the background-image value to its default

background-position

When a background-image is specified, it is placed at the top-left corner of the element by default. The background-position property overrides this default value and specifies the starting position of the background image in relation to the containing element.

Values for the background-position property are defined in relation to the horizontal position and the vertical position of the background image.

Possible values for background-position include:

  • left top – Left horizontal position / top vertical position
  • left center – Left horizontal position / center vertical position
  • left bottom – Left horizontal position / bottom vertical position
  • center top – Center horizontal position / top vertical position
  • center center – Center horizontal position / center vertical position
  • center bottom – Center horizontal position / bottom vertical position
  • right top – Right horizontal position / top vertical position
  • right center – Right horizontal position / center vertical position
  • right bottom – Right horizontal position / bottom vertical position

If only one value is specified, the other will default to “center.”

x y – The horizontal and vertical position expressed as an absolute or relative measurement unit such as px, pt, em, or rem. The position is measured from the top left corner, which is represented by the value 0 0.

It is possible to mix position values and percentage values.

x% y% – The horizontal and vertical position expressed as a percentage of the horizontal or vertical size of the containing element. The position is measured from the top left corner, which is represented by the value 0% 0%. The bottom right corner is represented by the value 100% 100%.

If only one value is specified, the other will default to 50%.

  • inherit – Inherits the background-position value from the parent element
  • initial – Sets the background-position value to its default

background-attachment

The background-attachment property specifies whether a background image should have a fixed position, or if it should scroll within a containing element.

Possible values for background-attachment include:

  • fixed – The background image is fixed and will not scroll with the element
  • scroll – The background image scrolls with the element. This is the default value.
  • local – The background image scrolls with the contents of the element
  • inherit – Inherits the background-attachment value from the parent element
  • initial – Sets the background-attachment value to its default

background-repeat

The background-repeat property specifies whether a background image will be repeated.

Possible values for background-repeat include:

  • repeat – The background image will be repeated horizontally and vertically. This is the default value.
  • repeat-x – The background image will be repeated horizontally
  • repeat-y – The background image will be repeated vertically
  • no-repeat – The background image will not be repeated
  • inherit – Inherits the background-attachment value from the parent element
  • initial – Sets the background-attachment value to its default

CSS Primer for Lightning Developers: Font and Text Properties for Typography

There are a number of properties that you can use to apply styling to the type and appearance of text in your Lightning Components and Applications.

Font properties can be used to define the typeface, boldness, size and other attributes of the text that you display to your users.

Text properties focus on aspects of styling such as text alignment, spacing and color.

Font Properties

The most common font properties include:

  • font-style
  • font-variant
  • font-weight
  • font-size
  • font-family

font-style

For all intents and purposes, the font-style property is primarily used to specify whether or not text should be displayed in italics.

The possible values for the font-style property include:

  • italic – Displays the text in italics
  • oblique – Displays the text in a leaning manner – similar to italic, but not as widely used
  • normal – Displays the text normally
  • inherit – Inherits the font-style value from the parent element

font-variant

Similar to font-style, the font-variant property is narrow in scope and is used to specify whether or not text should be displayed in small-caps.

The possible values for the font-variant property include:

  • small-caps – Converts all lowercase letters to uppercase letters, but in a smaller font size than any letters that were originally capitalized
  • normal – Displays the text normally
  • inherit – Inherits the font-variant value from the parent element

font-weight

Another property with a narrow scope, font-weight is used to specify whether or not text should be displayed using a bold weighting.

Unlike font-style or font-variant, however, font-weight is an interesting property in that its possible values correspond to a scale to which is applied to the text weighting.

The font-weight property is also dependent on the specific typeface used, as some typefaces only support a limited number of values.

The possible values for the font-wight property include:

  • 100, 200, 300, 400, 500, 600, 700, 800, 900 – Numeric font weights for typefaces that support more values than the standard bold or normal
  • bold – Displays the text in a bold font weight – equivalent to the numeric value of 400
  • normal – Displays the text using a normal font weight – equivalent to the numeric value of 400
  • inherit – Inherits the font-weight value from the parent element
  • bolder – Selects the next higher available font-weight value for a typeface than its parent element
  • lighter – Selects the next lower available font-weight value for a typeface than its parent element

font-size

The font-size property is used to manage the size of text, an important aspect of defining the styling of your Lightning Components and Applications.

The font-size property can be defined with values that are expressed as either absolute or relative units of measure. CSS measurement units are covered in another post.

If a font-size is not specified, the default size for text in browsers is 16px, or 1em.

font-family

There are two types of font families that can be used as values for the font-family property: generic font families and specific font family names.

Generic font families include:

  • Serif – fonts that include a small line at the end of a stroke in the letter
  • Sans-Serif – fonts that do not include a serif at the end of strokes
  • Monospace – each letter in the font takes up the same amount of horizontal space
  • Cursive – fonts with connected letters or strokes that sometimes resemble handwriting more than print typography
  • Fantasy – Decorative fonts that typically have a playful element to them

Examples of common specific font family names (grouped by their corresponding generic font family) include:

  • Times New Roman, Georgia, Century, Lucid and Trajan (Serif)
  • Arial, Helvetica, Verdana, Droid Sans and Tahoma (Sans-Serif)
  • Courier, Consolas, Andale Mono, Lucida Console and Monaco (Monospace)
  • Comic Sans MS, Lucida Handwriting and Zapf Chancery (Cursive)
  • Copperplate Gothic Bold, Haettenschweiler and Playbill (Fantasy)

If multiple fonts are specified for the font-family property using a comma-separated list, a browser will read the values from left-to-right and apply the first font that it supports.

Always start with the font you most want to use, and then follow with increasingly generic substitute options to ensure that the browser will be able to find a font that it supports.

If a font name consists of multiple words, such as Times New Roman, you must wrap the font name in quotes.

For example:


p {

    font-family: "Times New Roman", serif;

}

font shorthand

While some of the above properties (font-variant in particular) may seem slightly esoteric, there is method to the madness of including them with other commonly used font properties.

The reason why it’s important to know about these individual font properties is that there is a shorthand property simply called font that enables you to consolidate a number of properties into a single property, and it requires values for all of the properties we just talked about.

The properties that can be set using the font shorthand property, in order and separated by whitespace, include: font-style, font-variant, font-weight, font-size/line-height, and font-family. The font-size and font-family properties are required, all others will simply apply default values if they are not explicitly defined.

An example of using the font shorthand property:


p {

    font: italic bold 12px Helvetica, Tahoma, sans-serif;

}

Text Properties

Common text properties include:

  • text-align
  • text-decoration
  • text-transform
  • text-indent
  • line-height
  • letter-spacing
  • word-spacing

text-align

The text-align property can be used to horizontally align text in an element. Possible values include:

  • right – Horizontally align text to the right of a container
  • center – Horizontally center text in a container
  • left – Horizontally align text to the left of a container
  • justify – Stretch text to fill all of the available space in a container so that all lines are of equal width, similar to columns in a newspaper
  • inherit – Inherits the text-align value from the parent element
  • initial – Sets the text-align value to its default

While it is primarily used for aligning text, the text-align property can apply to any inline content that is contained in a block element such as a span or div.

text-decoration

The text-decoration property applies decoration to text, typically in the form of a line below, above or through the text.

Possible values include:

  • underline – Draws a line under text
  • overline – Draws a line over text
  • line-through – Draws a line through the center of text (i.e. a strikethrough)
  • none – Does not apply decoration to text (the default value)
  • inherit – Inherits the text-decoration value from the parent element
  • initial – Sets the text- decoration value to its default

text-transform

The text-transform property is used to control the capitalization of text.

Possible values include:

  • uppercase – Converts all characters to uppercase
  • lowercase – Converts all characters to lowercase
  • capitalize – Capitalizes the first character in each word
  • none – Does not transform text and leaves it as-is (the default value)
  • inherit – Inherits the text-transform value from the parent element
  • initial – Sets the text-transform value to its default

text-indent

The text-indent property is used to specify the indentation of the first line of text contained in an element.

Possible values include:

  • Length – A numeric value expressed as an absolute or relative measurement unit such as px, pt, em, or rem. The default length is 0.
  • % – A value expressed in terms of the percentage of the containing element
  • inherit – Inherits the text-indent value from the parent element
  • initial – Sets the text-indent value to its default

Negative values are allowed for length – the first line of text would simply be indented to the left.

line-height

The line-height property specifies the height of each line of text contained in an element, which determines whether lines appear closer together or farther apart from each other.

Possible values include:

  • Length – A numeric value that represents a fixed line height, expressed as an absolute measurement unit such as px or pt
  • Number – A numeric value that represents a multiple of the current font size
  • % – A value expressed in terms of the percentage of the current font size
  • normal – Applies a normal line height. This is the default value.
  • inherit – Inherits the line-height value from the parent element
  • initial – Sets the line-height value to its default

letter-spacing

The letter-spacing property specifies the amount of spacing between characters in a line of text.

Possible values include:

  • length – A numeric value expressed as an absolute or relative measurement unit such as px, pt, em, or rem. The default length is 0.
  • normal – Does not add space between characters. This is the default value.
  • inherit – Inherits the letter-spacing value from the parent element
  • initial – Sets the letter-spacing value to its default

Negative values are allowed for letter-spacing – characters would simply overlap if a negative value was applied.

word-spacing

The word-spacing property specifies the amount of spacing between words in a line of text.

Possible values include:

  • length – A numeric value expressed as an absolute or relative measurement unit such as px, pt, em, or rem. The default length is 0.
  • normal – Does not add space between characters. This is the default value.
  • inherit – Inherits the letter-spacing value from the parent element
  • initial – Sets the letter-spacing value to its default

Negative values are allowed for word-spacing – words would simply overlap if a negative value was applied.

Page 1 of 9

  • 1
  • 2
  • 9