Thought on

Rethinking Semantic Markup

This idea came to me when I saw the HTML structure of instant articles. They specify that the structure of instant articles must adhere to their standards, and the structural representation is quite clear. Within that, I discovered many HTML tags I hadn't noticed before, such as address, figure, caption, and summary.

Out of curiosity, I looked up the documentation and found that many semantic tags are already supported by mainstream browsers, and the specifications are clearly outlined. However, many websites still express structure using div + class. While some areas might use header, I believe there are more appropriate semantic tags that could be utilized. This would not only reduce unnecessary class naming but also enhance HTML readability and SEO. Most importantly, we would be writing standards-compliant HTML.

Moreover, W3C has been promoting semantic tags in HTML5, such as nav, header, dd, and dt, while eliminating or discouraging the use of meaningless tags like b, font, and center.

The biggest advantage of semantic markup lies in accessibility. Most screen readers optimize their output for specific tags. For example, an <a> tag will be read as hyperlink, using li will announce the current list and its position, and <main> will indicate the main content, among other benefits. These advantages stem from using semantic tags.

However, with the diverse use cases of UI, it's unlikely that every scenario can be handled by existing tags. For instances like tab switching, dialogs, dropdowns, and tooltips, semantic tags won't suffice. In such cases, you can refer to aria-* and role attributes to inform the reader about the purpose of the elements.

Thoughts on Class Usage

Semantic CSS

After using classes for so long, I revisited the specifications and discovered W3C’s description of class attributes.

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. - W3C

Although there are no strict regulations on class usage, it is encouraged to use classes to express the content of elements rather than their presentation. This implies that class names like col-md-*, which are purely presentational, are actually discouraged in W3C specifications. However, if we follow this reasoning, it would mean that all CSS-in-JS practices would need to be completely rethought. CSS modules hash all classes, and styled-components do the same. The benefit of using hashing is to prevent naming conflicts and minimize the size during production builds, which can be quite significant when there are many elements on the HTML page.

Why Adhere to Standards?

1. Standards are established through extensive research and discussion by committees, providing guidelines for consistency.
2. Browsers have typically optimized these components for display across different devices.
3. These standards usually represent best practices.
4. Why should we write non-standard webpages just to save development time?

<!-- Element Display -->
<div class="margin-b-10">

</div>

<!-- Content -->
<div class="user_info">

</div>

This is my understanding.

As for why this situation arose, it might be due to the early days of web development when CSS support was poor. Balancing semantics and presentation was challenging, which led to the emergence of purely stylistic tags like center and width. However, we are no longer in those restrictive times. We should move toward a more semantic era, and this is also what W3C promotes.

Grid Systems Are Awesome!

I admit that grid systems are incredibly useful. In practical scenarios, there are instances where layouts cannot be expressed semantically. However, according to the definition of semantics, in order to write cleaner and more readable HTML, we may eventually need to remove grid systems. This will be a significant undertaking, but given the current structure of many main sites, the sooner we start, the better!

• Using Susy
• @include @extend

Page Visibility API

This allows you to determine whether the user is focused on the page. In many situations, we want to minimize unnecessary requests or operations when the user is not focused on the webpage (for example, when they switch to another application or tab). Facebook, for instance, only prompts you with notification sounds when you return to the page.

A common scenario is during video playback. If the user leaves the page, we can automatically pause the video, and it will resume when they return.

Looking Back at JavaScript Event Propagation

Recently, I revisited the Rhino book to clarify concepts that I didn't fully understand before. There are so many JavaScript libraries online that we may have forgotten about native JavaScript. While high levels of abstraction are inevitable as technology progresses, understanding how things work internally is beneficial and will give us a clearer concept when writing code!

JavaScript Event Propagation

JavaScript event propagation mainly consists of two types: bubble and capture, with most propagation occurring via bubble. So, what is bubble? After the event handler registered on the target element is triggered, the event starts to "bubble up" (excluding certain specific events) and then triggers the handlers registered on ancestor elements. This phenomenon ascends to the document and eventually reaches the window.

In practical applications, we often see:

$(".abc").on('click', e => {
	
});

$(".ass").on('click', e => {
	
});

$(".asass").on('click', e => {
	
});

Scattered event registrations in different corners make maintenance difficult and finding code lacks a unified entry point, complicating debugging. Thus, we can utilize the bubbling feature of JavaScript events to register events uniformly at the document level. jQuery's on method's second function provides event delegation, as shown below:

$(document).on('click', '.sass', e => {
 
});

This approach not only reduces scattered event registrations but also unifies the entry point. To add new events, you just need to expand the document. We can also write HTML this way:

	<a class="js_action" data-action="foo"></a>
	<a class="js_action" data-action="bar"></a>

  var actionList = {
  	foo: function() {},
  	bar: function() {}
	};
	$(document).on('click', '.js_action', e => {
		if (typeof actionList[e.target.dataset.action] === 'function') {
			actionList[e.target.dataset.action]();
		}
	});

In this manner, to add a new event handler, you simply add it to actionList. With the use of extend, it’s even possible to write it outside of actionList, significantly improving extensibility.

So, why do so few people use capture? The main reason is that older versions of IE do not support it. Moreover, event capturing is only applicable when using addEventListener. Event capturing works a bit in reverse, starting from the ancestor and proceeding downwards until the event handler of the event's parent element is invoked, at which point the handler registered on the event target itself will never be called.

Event Cancellation

We often see methods like e.preventDefault(). In older browsers, this is not supported, but we can use some trickier ways to perform cancellation.

function cancelDefault(event) {
	var event = event || window.event;

	if (event.preventDefault) event.preventDefault();
	if (event.returnValue) event.returnValue = false;
	return false;
}