Tag Archives: coding

Myths and Realities of Replaced elements in HTML

Replaced Elements in HTML Myths and Realities - YWF (2)

According to official specs, replaced elements are content outside the scope of the CSS formatting model, such as an image, embedded document, or applet. For instance, the content of the HTML IMG element is often replaced by the image that its src attribute designates. Besides, replaced elements often have intrinsic dimensions, such as an intrinsic width, an intrinsic height, and an intrinsic height specified in absolute units. Now, you may have a general description of what a replaced element is, but as a web developer, you have to look deeper about replaced elements.

Replaced Elements in the Real World
To discuss in a full description about the replaced elements, we need to go to a different resource, namely the Rendering section of the HTML Living Standard document. But, when you look deeper, the specs can be confusing. This is because some HTML elements operate as replaced elements all the time, while other do it only in specific circumstances.

Embedded Content
Embedded content is the first category of replaced elements. Embedded content means any element that imports another resource into the document, or content from another vocabulary that is inserted into the document. While these external resources have the intrinsic dimensions that match the requirements of the definition.

Embed, iframe, and video are the main elements in this category. Since they always import external content into your document, these elements are always treated as replaced elements. There are more elements that a bit more complicated that fall into this category only in special circumstances, such as:

  • applet – Treated as a replaced element when it represents a plugin, otherwise it’s treated as an ordinary element.
  • audio – Treated as a replaced element only when it is “exposing a user interface element”. Will render about one line high, as wide as is necessary to expose the user agent’s user interface features.
  • object – Treated as a replaced element when it represents an image, plugin, or nested browsing context (similar to an iframe).
  • canvas – Treated as a replaced element when it represents embedded content. That is, it contains the element’s bitmap, if any, or else a transparent black bitmap with the same intrinsic dimensions as the element.

Images
Images are others elements that treated as a replaced element with the intrinsic dimensions of the image. This category also includes the input elements with a type=”image” attribute.

When the image is not rendered on the page, things get a bit more complicated for several reasons. The <input type=”image”> will be displayed as a normal button.

Default Size of Replaced Elements
We can understand this elements by these three basic rules:

  • if the object has explicit width, height and ratio values, use them;
  • if the object only has ratio, use auto for both width and height while maintaining the said ratio;
  • if none of these dimensions are available:
    – use width: 300px; height: 150px when the viewport is larger than 300px
    – use “auto” for both width and height and a ratio of 2:1 when the viewport is smaller than 300px;

What About the Other Types of Form Controls?
There are many misconceptions about other types of form controls are replaced elements too. After all, these elements are also rendered with a default width and height. In fact, most people consider intrinsic dimensions actually comes from the following line:

Each kind of form control is also described in the widgets section, which describes the look and feel of the control. Another reason why form control looks different from one browser to the next and from one OS to another:

The elements defined in this section can be rendered in a variety of manners, within the guidelines provided below. User agents are encouraged to set the ‘appearance’ CSS property appropriately to achieve platform-native appearances for widgets, and are expected to implement any relevant animations,etc, that are appropriate for the platform.

Conclusion
It is easy to get confused about replaced elements and form controls. But, they are different categories of HTML elements, with <input type=”image”> being the only form control that is a replaced element.

 

4 Tips of Desktop-First Design for Responsive Websites

responsive website

Nowadays, where all attention is in mobile-first design, desktop-first design seems less popular. This is because many designers aim to create responsive design. However, starting from desktop is not the bad. In fact, this design works better if you want to create feature-rich designs. This workflow may not as popular as mobile-first design, but as a web designer, you should know why you also need to put attention on desktop-first design.

The Benefits of Desktop-First
Generally, desktop first is something that everyone made websites up until the responsive era. Today, with so many people talk about mobile first, there are still so many reasons why we have to stick with the desktop approach, especially if you want your site have tons of detailed features on larger screens.

Here are some benefits of the desktop-first ideologies.

  • You get to see all major features at once
  • It lets you imagine all the largest possibilities for your design first
  • It’s the best strategy if your audience mostly uses desktops/laptops

You must think that any modern websites like Twitter puts mobile-first design. However, even Twitter have lots of extra features that come along with the desktop experience. Therefore, you need to create feature-rich websites that depend on a strong desktop design. This is perhaps the biggest benefit of a desktop-first layout. You get to see the site as it should look with all of its accessories. These extras can be removed for smaller screens as you test and find certain features just don’t carry over well.

It’s easy to consider dynamic features more like an afterthought with a mobile-first approach. But, you’re treating these features as the primary display method with a desktop-first approach, then choosing to remove them as needed.

No one is better than other, so you can try both of them to see what you prefer. Working from smaller area or starting from desktop then working smaller.

Supporting All Browsers

Handling browser support is the trickiest part of desktop-first design. In fact, it is reasonable for all mobile browsers to basically support the same features as desktop browsers. The main difference can be seen not in HTML/CSS support, but rather in touch-based support.

So, it is important to consider how the different browsers work, what they support, and how to handle the user’s touch-based input when moving from desktop to mobile. A few good rules to consider while scaling down your desktop-first design:

  • Increase body text size so links are easier to tap
  • Make tappable elements larger
  • Add JavaScript libraries that support swipe motions

Graceful Degradation
Graceful degradation is a process that builds all your website’s top features with everything you want on the site, and then if other browsers can’t support them you revert to fallback methods. A common example of this tactic is the removal of dropdown sliding menus for mobile. However, rather a change in user experience, this isn’t strictly graceful degradation. On the other hand, you’re searching for JS functions or CSS3 properties that literally cannot be supported in a certain browser.

When Desktop Takes Priority
After all, you can think about designing a site where desktop takes priority over mobile. If the mobile experience can be incredibly simple but the desktop experience needs to be detailed and dynamic. But, you also should have a plan for the mobile site with at least a vague idea in mind of how it’ll look.

 

5 ways for Creating Better, Faster and More Optimized WordPress Websites

Creating better faster and more optimized wordpress websites

There are always new updates in WordPress, so that every developer should learn the latest optimization practices.  But, mostly seasoned developers focus on what they are good at. Then, neglect or don’t have time to learn the latest optimization practices. If you happen to be one among those kinds of web developers, you need to read the following tips. This article can help you create better, faster and more optimized WordPress sites.

  1. Switching Hosts Isn’t Always a Quick Fix

If you think that switching hosts will automatically fix certain problems, you may need to reconsider your opinion. In fact, you still experience some code issues or compatibility problems with specific plugins even though you have changed your host. A managed host will provide as much assistance as they can, but won’t debug an issue with a bad plugin or code for you. Therefore, you need a WordPress developer to dig into it and make a determination as to what the issue is. In fact, to solve these problems, many hosts provide third-party partners and developers.

  1. Don’t Try Editing Your Code

To avoid WordPress sites go down, you need to make sure that no one is editing a PHP file directly from the appearance editor in the dashboard. But, how? You can use the following code in your wp-config.php file, removing the edit_themes, edit_plugins, and edit_files capabilities for all users. This method will prevent users to hack away at the code and break the site.

define(‘DISALLOW_FILE_EDIT’, true);

Take this process one step further to update themes or install plugins and remove the functionality for clients to update. Place the following code in your wp-config.php file to restrict these capabilities.

define(‘DISALLOW_FILE_MODS’, true);

  1. Don’t Cut Corners on Your Themes and Plugins

WordPress might be the foundation of your site, but the themes and plugins are also important elements. Therefore, you need to choose your plugins carefully. Do a little research and look for its ratings and reviews beforehand.

Recent research even shows that nearly 50% of the plugins in the repository haven’t been updated in over 2 years. This makes these themes and plugins are easy to get infected with malware. Another thing to be on the lookout for is a bundled plugin that should be updated. This surely will cause a huge problem for WordPress users who buy things via online marketplace. On the other hand, this method will open a wide chance for hackers and site owners are extremely vulnerable.

  1. Watch Your Admin AJAX Calls

Inspect any plugins that may utilize AJAX, for instance, the WordPress Heartbeat API uses /wp-admin/admin-ajax.php to run AJAX calls from the web-browser. Mostly these kind of files occurs during  traffic spikes, CPU load, and can bring your site to a crawl.

If you find there are 3rd party plugins that utilize admin-ajax.php, make sure that everything runs in the correct way. Besides, you can figure out what plugins might be causing it by looking at the HTTP POST request action and quickly determine, based on its name. However, AJAX does load after the page loads.  So, this is not always a bad thing to see this in a speed test.

  1. Ensure PHP 7/HHVM Compatibility Before Jumping on Board

Nothing can beat PHP7 and HHVM when it comes to boosting WordPress performance. But, before you are tempted to use these programs, you need to make sure that your site is compatible with the program. This means before you are upgrading from PHP 5.6 to 7, you need to test all functionalities of your WordPress site in a staging environment or locally to ensure there aren’t any compatibility issues.