Tag Archives: programmer

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.

 

The 4 Most Used Programming Languages

The-4-Most-Used-programming-languages_ywf

Nowadays, software developers are in high demand. This makes good developers are hard to find, yet they have the luxury of choosing from more than one job offer. So, what makes a ‘good developer’? A good developer should at least know some of the following skills. If you wish to become a good web developer, make sure you have mastered below skills.

  1. C#

C# is designed to be relatively easy and straightforward which makes it incredibly popular among developers and employers alike. C# is primarily used to develop web, mobile and enterprise applications while supporting imperative, functional and object-oriented paradigms.

Above all, there are two reasons why C# developers are terribly needed. First, it is because of its flexibility and usability. Second, it is firstly developed by Microsoft to build apps on the Microsoft platform.  So, it surely will fit in most common Microsoft IT infrastructure, which many companies have set in their system.

  1. PHP

PHP is another popular option; it’s an open source, server-side scripting language. In fact, PHP have powered millions of websites across the world, including high-profile sites such as Facebook and Wikipedia. Moreover, PHP is a language that is so popular that is used extensively in WordPress.

Over the years, PHP’s popularity has increased and there are no signs that this demand will slow down. That is why many companies will offer high salary for getting a good PHP talent.

  1. Java

Java is one of the oldest language programs that are favorable among developers. Because it is relatively easy and versatile, Java has become an attractive proposition for corporations and developers. Besides, it has many users, many existing applications and such a vast ecosystem.

Furthermore, Java is a stable language which makes the job market shows sustained hunger for developers in this field.

  1. JavaScript

Another language program that has gained everlasting popularity is JavaScript. It’s a versatile, object-orientated programming language that is built into most major browsers, including Firefox and Safari. Even though, JavaScript has been around for years but it can manage to hold its own against the existence of so many new languages. In fact, many regard it as one of the need –to-know language to help further a career. With so many developers have acquired this language, you need to double your work to stand out from the crowd.

Best Practices for API Error Handling

Best-Practices-for-API-Error-Handling

As a web developer, we all don’t want to see Error codes in an API response, neither do you. When it happens to you, it can mean one of two things — there was something wrong in your request or your handling that the API simply couldn’t parse the passed data, or the API itself has so many problems. In either situation, traffic comes to a sudden end, and we start trying to discover the cause and solution for that.

Although being unpleasant, errors, whether in code form or simple error response, are incredibly useful. Error codes are probably the most useful diagnostic element in the API space.

Today, we’re going to discuss about the importance and the usefulness of error responses and handling approaches. There are some common error code classifications the average user will encounter, as well as some examples of these codes in action that you need to know.

The Value of Error Codes
As explained above, error codes are surprisingly, but incredibly useful. Error codes in the response stage of an API are essential in communicating failure from a developer to a user. This stage is a direct communication between client and API. It’s considered as the most important step towards informing the user of a failure, as well as boosting the error resolution process.

An error comes randomly and sometimes it’s beyond our knowledge. That’s why error responses are the only constant, consistent communication that we, as the user, can rely on when an error has occurred. Error codes can both clarify the situation, as well as communicate the intended functionality.

For example, an error code such as “401 Unauthorized – Please Pass Token.” You understand the point of failure in that response, especially that the user is unauthorized. However, you also figure out the intended functionality, which means that the API requires a token, and that token must be passed as part of the request in order to obtain authorization.

With a simple error code and resolution explanation, you have already identified the cause of the error, as well as the intended functionality and method to fix that error. It is very useful, especially for the amount of data that is actually returned.

HTTP Status Codes
Before we deeply discuss about error codes and what makes a code good, we need to sort out the HTTP Status Codes format. These codes are the most frequent status codes that the average user will encounter, not only in terms of APIs but also in terms of general internet usage. Although there are other protocols and have their own system of codes, the HTTP Status Codes dominate API communication, and vendor-specific codes tend to be derived from these ranges.

  • 1XX – Informational

The 1XX range has two basic functionalities. First, in the transfer of information concerning the protocol state of the connected devices — for example, 101 Switching Protocols is a status code noting that the client has requested a protocol change from the server, and that the request has been approved. The 1XX range also elucidates the state of the initial request. For example, 100 Continue, notes that a server has received request headers from a client, and that the server is waiting for the request body.

  • 2XX – Success

The 2XX range notes a range of successes in communication, and combines several responses into specific codes. The first three status codes excellently determine this range, like 200 OK means that a GET or POST request was successful, 201 Created indicates that a request has been brought to completion and a new resource has been created for the client, and 202 Accepted shows that the request has been accepted, and that processing has begun.

  • 3XX – Redirection

The 3XX range is all about the status of the resource or endpoint. When this kind of status code is sent, it confirms that the server is still accepting communication, but that the contacted point is not the accurate point of entry into the system. 301 Moved Permanently denotes that the client request did reach the correct system, but this request and all future requests should be managed by a different URI. This is very convenient both in subdomains and in moving a resource from one server to another.

  • 4XX – Client Error

The 4XX series of error codes is probably the most well-known because of the famous 404 Not Found status, which is a prominent marker for URLs and URIs that are formed in the wrong way. However, other more useful status codes for APIs are in this range.

414 URI Too Long is a common status code, indicating that the data pushed through in a GET request is too long, and should be changed into a POST request. Another common code is 429 Too many Requests, which is used for rate limiting to note a client is attempting too many requests simultaneously that their traffic is being rejected.

  • 5XX – Server Error

The 5XX range is reserved for error codes notably related to the server functionality. Whereas the 4XX range is the client’s responsibility (meaning that it is a client failure), the 5XX range explicitly notes failures with the server. Error codes such as 502 Bad Gateway, which marks the upstream server, has failed and that the current server is a gateway, further reveal server functionality as a method of showing where failure is transpiring.

Making a Good Error Code
With a strongly-built comprehension of HTTP Status Codes, we can start analyzing what actually makes for a good error code, and what makes for a bad error code. Quality error codes not only convey what went wrong, but also why it went wrong.

Excessively obscure error codes are very inconvenient. Imagine that you are trying to make a GET request to an API that manages digital music inventory. You’ve submitted your request to an API that usually accepts your traffic, you’ve passed the correct authorization and authentication credentials, and you think the server is ready to respond.

You send your data, and receive this kind of error code: 400 Bad Request. Without additional data and without more information, what does this mean? It’s in the 4XX range, so you know the problem was on the client side, but it doesn’t explain and solve anything, other than “bad request.”

This explains that a “helpful” error code is not as helpful as it should be. We could easily make that same response helpful and clear with less effort. Good error codes must pass three essential criteria in order to be functional, such as:

  • An HTTP Status Code, so that the source and realm of the problem can be confirmed with ease;
  • An Internal Reference IDfor documentation-specific notation of errors. In some cases, this can substitute the HTTP Status Code, as long as the internal reference sheet inserts the HTTP Status Code scheme or similar reference material.
  • Human readable messagesthat conclude the context, cause, and solution for the existing error.

From this discussion, we can conclude that error codes are useful if inserted with messages conveying what goes wrong and why it goes wrong, topped off with the human readable messages emphasizing the solution that we can take and do to handle it. That way, we can effortlessly handle it when future errors occur spontaneously.