Tag Archives: programming

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 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.

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.


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.

Introduction of Cross-Site Scripting (XSS) Vulnerability & How to Prevent It?

What is the Cross-site Scripting (XSS) Vulnerability & How to Prevent it

As a web developer, you may know XSS as Cross-site Scripting. It is a way of bypassing the SOP concept. An attacker could easily insert his own HTML code whenever HTML code is generated dynamically, and the user input is not sanitized and is reflected on the page. In this case, the web browser will still display the user’s code since it belongs to the website where it is injected.

The attacker could easily interject JavaScript code which would run under the site’s context. By this way, the attacker can access other pages on the same domain and read data like CSRF-Tokens or the set cookies.

The attacker can use the cookies which typically contain session identifier information, and use it in his own browser and login to the web application as the victim. Another way is by reading private information from the pages, such as read CSRF tokens and makes requests on behalf of the user.

Impacts of the Cross-site Scripting Vulnerability

There are many impacts of an exploited XSS vulnerability. It ranges from Session Hijacking to the disclosure of sensitive data, CSRF attacks and more. The attacker can impersonate the victim and take over the account by exploiting a cross-site scripting vulnerability. It might even lead to code execution on the server if the victim has administrative rights. But it will depend on the application and the privileges of the account. To get more information on how a XSS vulnerability was used in a successful attack can read about the apache.org jira incident .

Preventing XSS Vulnerabilities

The most important thing in preventing cross-site scripting vulnerabilities is to apply a context dependent output encoding. In some cases it might be enough to encode the HTML special characters, such as opening and closing tags. In other cases, URL encoding is necessary if it is correctly applied.

Moreover, your inbuilt XSS filter, even in your most modern web browsers should not be seen as an alternative to sanitization. However, they cannot catch all kinds of cross-site scripting attacks. As a result, this will prevent some pages from loading correctly. Since the idea is to minimize the impact of existing vulnerabilities, a web browser’s XSS filter should only be a “second line of defense”.