icebergblue

Semantic HTML

With the rise of JavaScript frameworks and design tools, writing semantic code has been on the decline. Front end developers and designers no longer pay attention to HTML. The tools guide us to write code. So why use semantic HTML at all?

Semantic HTML has so much built-in power with no extra work. Before we delve into that, let's answer the most basic of questions, what is semantic HTML? Semantic HTML basically tells both humans and web technologies "the meaning of the tag". It allows us to understand the intent of the content. It helps separate the presentation from the structure of the page. Lets take a look at a few examples to help understand.

<p> paragraph tag

If you inspect the code on this page, you will see we are separating each thought into a p tag, as we would when writing in English. Copy writers, can write in any text editor like MS Word, and HTML writers can then place the content in a p tag. The web technology will take care of the rest. Built-in formatting, layout, and design will be applied. It will also apply some basic accessibility to indicate that the content is text. Designers can further enhance the design by applying CSS to make paragraphs look different than other content on the page.

<button> button tag

Most HTML writers have automatically adopted the frameworks example code in which each button serves only to handle JavaScript function calls instead of using them as they were intended. Button elements have three built-in type attributes that will cause them to behave differently for a given scenarios. The two most used:

1. Stand alone
2. Forms

A button, not wrapped in a form, can only have one type attribute associated to it; type="button". If the type attribute is omitted, you are calling the button type="button" implicitly, and a button will do nothing unless a click event is attached. Many developers reading code samples either assume that buttons don't have any specific types attached to them, or that the only attribute that makes them work is a onclick event. Either way, using buttons properly can give you built-in powers especailly when used in forms.

In forms, the three type attributes are:

• a form submission (type="submit")
• a form reset (type="reset")
• a function call (type="button" with onclick event)

When buttons are placed in forms, they do some very powerful things, such as submitting the form they're in. When the button is pressed the form will be passed to the back-end, which takes care of the validation and submission to persist the data. You can also have the form take care of validation messages like success or failure. The type="submit" attribute of the button will work the same way on any web enabled device, including screen readers.

Similarily, the reset button will have the power of clearing a form of all its data. This is great when you want to allow a user to have a clear form to add data. It also has accessibility built-in which works on any web enabled device.

With type="button", or the type is omitted, it will work as a stand alone button loosing some of its built-in powers. However all three cases can have JavaScript attached, which may work differently on specific web enabled devices. That is why it's best to add the type explicitly, to ensure consistency.

<a> anchor tag

The redirection part of the anchor tag is applied when you use the href attribute. Using href="#" or href="javascript:void(0)" also breaks semantic meaning of an anchor. In this case, use a button with a onclick event to handle your intention.

By simply understanding the intent of your HTML, you can create a more meaningful website for both humans and machines. You will have built-in power that web enabled devices will put into play to have fully accessible site so that everyone will benefit.

Why Svelte/Sveltekit should be your next modern JavaScript framework

As developers working on the Lego Storage App in both SvelteKit and React/Next.js, we embarked on a journey to understand and document the differences between these two modern JavaScript frameworks. This article is targeted at UX professionals who possess an understanding of design code and development code, delving into how their preferred way of working aligns with the features of each framework.

For those with a development background, you may lean toward using frameworks such as React, while those with a designer background may prefer Svelte/SvelteKit.

Here's what we found:

1. Svelte over React for Design Code
Svelte wins over react for writing HTML, CSS and Accessibility code. Svelte pages closely resemble classic .html pages where you separate HTML, CSS, and JavaScript code. You need to follow a simple rule of putting any specific code into its respective code tag.
Styling code will reside in a <style></style> tag anywhere on the page.It closely refelects the way embedded styles work on a traditional HTML page. You apply your CSS classes as normal, calling your style classes using class="". You can also place style="" to have inline styles.

Each .svelte page can be viewed as a single web component. This means that each component will have it's own CSS that cannot be used by another web component. However, the framework gives you the ability to use :global to allow other components to use the style.

Scripts will be placed in <script> tags. If you are using typescript, svelteKit allows you to use <script lang="ts">. It also gives you the ability to apply script code as modules, that can be used on a single .svelte page.

The HTML is web-standard HTML 5 code. You don’t have to place it in a JavaScript function to have it render on the page (you do with React JSX). Place your code on the page exactly like building a static HTML page. Also, you are not restricted to having a single HTML element in a return function which is a requirement of React JSX pages.

Developers who focus on interaction or data can write code that go into <script> tags, or on separate .js/.ts pages. When design and interaction need to be mixed, use double curly braces {{}} to apply reactive code to your HTML.

In React, designers who focus on HTML and CSS need to understand JavaScript because the power of React comes from JSX. JSX requires your HTML to be placed in a JavaScript return function.

Applying styles or classes might seem simple, but you need to know how to use them. You can’t just put style="" or class="" in your HTML elements, as they won’t work. Instead, you need to know that style has to be placed in single curly braces {}, double curly braces {{}}, or quotation marks "", depending on how you want to write the code.

If you simply want to place a string, place your code in quotation marks "". If you declare a variable that is a string, place your code in double curly braces {{}}. If you place your code in an object, place your code in single curly braces {}. As you can see, React makes design work slightly more complicated.

The complication doesn’t end there. CSS properties need to use their JavaScript equivalent property names. For example, a designer who doesn’t know that the JavaScript property name for background-color is backgroundColor would need to research it. Newer developers or designers may need help with this.

React also requires you to close all your tags as XML elements (<img /> or <br/>), use lowercase syntax for all HTML elements, and capitalise the first letter of any web component you create.

Our choice for design work is SvelteKit as there is a clear distinction between HTML, CSS and JavaScript code, as well as how to get interactions and reactive code to work. There are also less rules that a designer or new programmer need to know.

2. React or SvelteKit for front end work depending on role
React allows you to connect to a variety of other frameworks, with Next.js being one we frequently work with. React’s infrastructure provides great flexibility, allowing you to work with as little or as much React code as needed to get interaction and API working. This flexibility is particularly beneficial when you are unsure about how to future-proof your project. You can start small with only a few React components and grow as your app grows.

However, such flexibility requires careful planning. Understanding the limitations of any framework, including SvelteKit, is important. Not having a plan as to how the framework works today can cause problems in the future. For example, if your team primarily consists of developers with many years of JavaScript experience and less focus on HTML design work, React would be your preferred choice due to its larger community.

On the other hand, if your team is fairly new to JavaScript, or highly focused on design code with a high level of HTML and CSS, you may want to go with SvelteKit.

Since our site is focused on UX design, we prioritise accessible semantic HTML, which can be a bit more difficult to implement for designers in React. While the rules are straightforward, there are quite a few of them to remember, and applying them can present a bit of a learning curve.

SvelteKit is much more contained. Its unique approach to compiling code allows for code separation, enabling developers to work as they would with HTML, CSS, and JavaScript. However, understanding the syntax can create a learning curve since it doesn’t use standard JavaScript. Reactive code can be written using JavaScript with function calls and callbacks, or $: which is unique to SvelteKit. It may take some time to get used to SvelteKit’s unique implementation. Using DOM elements can be restrictive as you can only use window or document objects limited to certain functions.

Our choice is a tie, but if you come from a design background you may prefer Svelte/SvelteKit. If you're able to understand it's unique way of writing code, the code compiled at the end is standard HTML, CSS and JavaScript.

3. React for API work
SvelteKit can become challenging to understand when building back-end code. The placement of <script> tags in a .svelte page, .svelte.js/.svelte.ts page, or .js/.ts page can cause confusion. Newer users need to have a solid understanding of JavaScript and its application.

When we first started with SvelteKit, connecting to a MongoDB database was quite difficult. SvelteKit’s method of loading data through JavaScript involves having code loaded in a load function. However, when you want to make multiple calls to different tables, understanding the timing and placement of the calls wasn’t as straightforward as it is in React.

In React, you have .js or .jsx pages where you can place all your JavaScript. It’s fairly straightforward. You also use JavaScript in a straightforward manner. As the code is built at runtime on the browser, window and document DOM elements are applied with ease. The window and document elements are not readily available in SvelteKit. You can only use them in certain instances.

Our choice for data and API work would go to React.

4. React for Testing
Svelte compiles your code, which results in some of it being converted when rendered on the browser. This makes design testing a bit challenging since the code doesn’t map exactly as it’s written, especially when debugging CSS. SvelteKit will add CSS classes that are not clearly indicated when you’re writing the code.

Although this doesn’t cause any significant issues with the file size, the speed of DOM changes, or the complexity of the rendered code, debugging CSS can slow down when new classes are introduced. If you use the browser debugger, you need to modify the selector to find it in your code. It’s not a one-to-one match of your CSS and the classes you applied to an element. If you’re new to design code, it could be a learning curve. Understanding how the CSS works may require some research, as answers may not be readily available online.

On the other hand, React offers a simpler debugging process. If you run the same code in React, the debugger will display code that closely reflects the code you wrote, making debugging much easier.

Our Choice for testing design work is React as it closely resembles the code you wrote.

5 React for community support
React boasts a large user base compared to Svelte. The React community can provide assistance with every aspect of implementing the framework. From UI elements to complex JavaScript patterns that can be applied to APIs, you can find resources for almost anything.

On the other hand, Svelte, while fairly new, has a growing community. Many users are transitioning to Svelte, appreciating its ability to allow everyone to contribute to the project, regardless of their roles or programming levels. The Svelte community continues to grow as more users, like us, are finding Svelte to be a compelling alternative to more popular frameworks.

Conclusion
If you are an individual or a team of designers and developers whose main duties involve writing HTML, CSS, and JavaScript, and you have experience with all three web languages, you might want to consider using React with any of the available backend adaptors. React’s flexibility, use of commonly known JavaScript versions, ease of componentization, and scalability can provide a better development experience.

On the other hand, if you are a designer or a front-end developer with some knowledge of JavaScript or looking to rapidly build a componentized website, SvelteKit might be the solution for you. The code is separated so that you don’t need to mix HTML, CSS, and JavaScript together, allowing you to focus on the web language that you know best.

We love SvelteKit for its separation of code, ease of use once you get the hang of the syntax, how the framework compiles code, and its speed in development.

In conclusion, while SvelteKit is much better for designers, React is much better for developers. The choice between the two depends on your specific needs and expertise.