More HTML elements that almost no one uses (but should!)

[@casperdewith]

1 • ‘shy’ means ‘soft hyphen’ (although I like ‘shy hyphen’ too; never thought of it that way) 2 • The element can be used in codes, links, email addresses - places where you don’t want foreign characters to intervene. A before a punctuation symbol is best, to indicate that the text on the new line belongs to the previous line. For instance: subdomain.bla.tld or [e-mail].

[@MattNeemtEenHapje]

The wbr tag is really nice because it won’t mess up clipboard support because no zero-width characters get copied. The wbr also makes it possible to find text on the page because the user won’t be typing in the functional characters like shy or a zero width space and thus the search successfully matches the text.

[@AntiAtheismIsUnstoppable]

I think it was Liveoverflow who showed a POC of an XSS attack using the base tag. Now, I always use full links, and it is a long time since I did research on this, so it might not be relevant anymore, but just be aware, that when something is being made easier in code with new functionality, for every new functionaly is usually also introduced new ways to do attacks.

[@MrBaupshaw]

As a blind cybersecurity analyst and Python developer who ends up working with Django quite a bit… it’s very nice to see channels which call out the importance of these semantic tag differences and how screen readers interact with them in the DOM. I can’t count the number of times I’ve tried to use enterprise-level web apps that don’t even use basic regions or headings, let alone some of the useful but somewhat less common tags out there. It’s resulted in me quite literally building some of my own front ends for a product or app using their API because their frontend is so devoid of any navigable elements important to screen readers. And companies quite literally don’t care in most every case I’ve tried to report these things as bugs or barriers to using the product. But if these types of things were done in the original development from the start… well the work to restructure the HTML or replace X tag with Y tag is far greater than just doing it from the start. Thanks for emphasizing the accessibility implications of not using the proper tool/tag for the task.

[@clevermissfox]

Since I’ve started learning, I’ve found it mind-blowing how many top level developers and/or teachers that won’t even spend time on basic accessibility best practices. It should have the same level of importance as teaching how to code for someone that doesn’t use assistive technologies. Even just the basics should be baked into every course or if something comes up in the video or article that applies I wish they’d take the time to include without having to search for specific materials so I can try and get bits here, pieces there now piece them together with what I already know. Honestly KP is the first channel or course I’ve found that spends any time taking accessibility into consideration. WDS Kyle too actually. But they’re few and far between without specifically searching for accessibility coding. Go Kevin and Kyle.

[@edwardgray6167]

3:10 to 3:44 is probably the most important part of the video. Yes you can use divs and css to get the right visual style but semantic elements actually improve the experience for screen reader users as well. And they can often be styled in the same way. Would be nice to see a deep dive in to one or two of these elements vs divs, with screen reader output comparison in the video.

[@bertlemoi431]

You may wanna check out this one: kzbin.info/www/bejne/p6OTpp2hgbGao6c. If you're on a Mac or use an iPhone turn on Voice Over and cover the screen in some way and try to browse the web. Or open up OneNote and try to navigate by keyboard

[@edwardgray6167]

@@bertlemoi431 ah yeah I think I watched this when it was released. Thanks for the reminder 😀

[@Coolhwhipmike]

Sometimes, I like that I'm just starting to learn HTML/CSS/JS. The fact that I'm not stuck in my ways or have muscle memory combined with good tutorials and explanations like this video makes me feel like I'm learning everything the "right" way. Until standards change or other new things come out in the future. I think knowing how to make a properly accessible site will help newcomers stand out and help people use our products more efficiently.

[@Brunoenribeiro]

so true...

[@luckymouse1988]

Don't you worry, you'll create your own "muscle memory" and habits along the way 😉

[@pilotgfx]

basically you are saying "i like that i dont know jack shit because in that way at least i dont know anything that isnt true, even though i dont know anything at all"

[@dripcaraybbx]

The people bothered that this is too much to think about are programmers who take on the nuisance of front end so they can call themselves full stacks. I'd like to see more designers step into the "front of front end" role so JavaScript devs can focus on business logic and functionality.

[@Weeniehutnurse]

Yeah I’m being taught to do full stack, but I just want to do only front end and have been taking design classes as well since I mainly want to know that aspect of web design but I still have heavy programming knowledge

[@lucienchu9649]

Strongly agree that one should not know everything in mind in details, but at least, he or she should know sth helpful is out there. When he or she needs it, there is a solution.

[@1414fritz]

11:13 I did not know that, could be useful for pop-up or multi-step form! A small addition for fieldset, by adding the attribute "disabled" you can easily disable all fields inside the group.

[@SeanGoresht]

might seem useful, but it probably defeats the purpose of semantic markup that could be afforded by actually breaking up chunks of a long word intentionally with s; I think the latter would be more readable -- especially in our use case, where we have long file and folder paths where we expect only the last part to show as opposed to the first (text-overflow: ellipsis). Cool to know exists, though.

[@KevinJTurner]

For the record, I would totally support a element

[@grizzlythresher7140]

The base tag honestly sounds like something which could be SO useful in the right circumstances. Especially if you've got some funky file structures and want to keep Some semblance of order. Thanks for the great vid!

[@Wolfeur]

hyphenation CSS rule ⇒ automatic, no extra content, BUT limited control ­ ⇒ shows hyphen, manual control, BUT creates extra text content ⇒ manual control, no extra text content, BUT no hyphen symbol

[@anti5895]

This is why I prefer Svelte over everything else, because by using Svelte I can once again be able to write plain HTML as the way it should be. Svelte also prioritize user accessibility by default. In return, you start to respect HTML once again. User accessibility is hard, but necessary. Those who saying that these semantics are "too much" is just hiding their laziness.

[@latmos6142]

Thanks for doing these videos! I'm a strong believer in the fact that the web should be for everyone, and that includes desktop and mobile, but also people that need special accessibility features, as well as people that just browse the web in different ways (print, keyboard, etc). I really dislike when people just brush of semantics as something that isn't important, and that it's too much of a hassle to learn. Most times, it's people with a background in backend development that dislike it. To that I just say that they're lazy, and that's about it. I find it fun to try to understand how someone else might experience my code (and frankly, I think that's what every designer should find fun as well even though it comes with some unfun things) and finding a solution to a problem through logic and design is really what I like about front-end development. I just hope new comers are going to keep informing themselves through this kinds of videos, because they definitely should! Anyway, thanks again for this video! I think that it is needed!

[@ChrisLocke1969]

Agree 1000%. Ive been a dev for 25+ years, and nothing has trashed the web more than not following proper web standards. It is only the standards that make the web work in the first place.

[@omegaman7377]

I disagree. The Explorer browser was the main source of trash. Fancy html tricks are no use if the browser is unable to used them.

[@ChrisLocke1969]

@@omegaman7377 you sur, are wrong. Fancy tricks? 🤣🤣🤣

[@DM-vu6he]

It's not shilling if it's your own. Keep up the great work, you've earned some confidence in self promotion imo 🎉

[@octothorpe12]

Given the semantic meanings behind these elements, I am kinda surprised screen readers don't inherently add something similar to what you've added (ex: start of stricken text) for these situations. Having to do it manually makes it harder for the dev as they've got to do 'extra' work, but also it leaves room for the tag to be misused from a semantic perspective (ex: like using divs as buttons when there's a perfectly good button element). I should do some more research on this, as it's kinda my wheelhouse.

[@jamisonr]

If you use a framework like Angular, then FIELDSET almost certainly is pretty common as it is the easiest way to disable a set of form fields. The base is helpful when composing components from all over but you need their content to point to an area different than where the component is defined (basically an extension of really strange folder layout)

[@ViorelMocanu]

Excellent content, as always! :) Keep it up, Kevin! The semantic web needs more content like this, to make these elements public and highlight their use cases.

[@rebelshadowrm]

Thank you for this. I love the deep dive into obscure tags, perhaps I'll never find a use-case, but more knowledge is more power in anything.

[@Ostap1974]

For my taste the s:before/:after-trick is bit overextending, that screen readers should actually handle themselves. Aria generally suggests against such hacks, smilar to using wrongly writtern aria-labels to improve the sound one can hear.

[@erikjansson1790]

I agree. If isn’t expressed in some way by a screen reader, we should submit that as a bug in the screen reader.

[@danielbardsley5574]

Thanks so much for this! The base element is something I’ve needed for about 2 years! But now I know. Your a legend and a great inspiration! Never change!

[@clevermissfox]

What’s your use case for needing is for so long ? I’m also curious if you have a nav with a menu , do those li’s/a’s get directed to base as well? I’m guessing so if even the style sheet in the head does. Curiouser and curiouser.

[@chad.765]

It’d be awesome to have a summary video of all the organizational elements from this and your other videos pulled into one to give us an all-in-one rundown of all of the div alternatives. I just started using section after one of your previous videos and I’m hungry for more

[@marklnz]

Just on how you added the ::before and ::after content for the element to help users who are using screenreaders....surely with the element being part of the HTML spec, the semantic meaning is relevant to the user, so any screenreader worth the name should actually interpret it correctly for their users??

[@KevinPowell]

You'd think so ... could be that there was a lot of misuse of certain things? I don't 100% know for sure.

[@pioleonardo]

I love the way you explain things Kevin. It is all suddenly clear to me when you mentioned screen readers.

[@DaVince21]

I don't get the "it makes HTML less readable" argument. I'd argue that adding classes and id's when you don't need to make the HTML less readable. Also, the closing tags are easier to relate to the opening tag if they're not just a stack of /divs. Not using elements you don't know is a weird argument too. That just doesn't fly in programming. Oh I don't know these methods in this API, so let's never use them.

[@Mark-ne4ik]

Please do a video on the element. I rarely see it used.

[@bryanmyers9977]

I'm so glad it learned about base because I have a really nice use case for it. Imagine locally editing html that is usually residing on a CMS and uses relative links to load assets stored on the same CMS. You pull the HTML down you insert that element in the head and boom all your relative links are now absolute and will work.

[@fluente]

I use a lot when a designer insists on breaking lines in weird places within a heading or a paragraph. But then I have to replace all spaces in that string with the html entity for whitespace in order for wbr to work. So on larger screens it doesn’t break at all, but on mobile it breaks where the designer expects it to. Previously you’d need dedicated elements for each viewport and then set media queries to display them accordingly I think?

[@brandonbennett3767]

3:10 Accessibility is VITAL to some people who need to use the internet. I use to work as an Software accessibility specialist at the university I attended. I knew one student that would take 4 HOURS to complete a basic math assignment that would take the other students 20 MINUTES. Here's an example to help you know what visually impaired people have to go through when visiting an inaccessible website. Imagine you are blindfolded and walking through a house you've never been in before. You have the added help of someone guiding you and telling you what's in all the rooms. Every thing in the house has a label, but the guide can only read what's on the label. As you're walking through the house the guide keeps saying "Here's a room. And here's a room. Over here we have a space, and right beside it we have a nice area." The guide is doing his job exactly as he's supposed to, but you are so mad, confused, and can't find anything. It's the same thing whenever a screen reader uses a website. and are often IGNORED by screen readers, so many times an important part or aspect of a website is missed entirely. When we use the proper HTML like Kevin is talking about, it literally makes your website BETTER for everyone, not just those with disabilities. It even improves SEO! To the people who think "Oh that will be a lot of overhead to do" or "That's a lot of extra work that is useless", you are being incredibly selfish. You're putting the extra work on people with disabilities, and that is infuriating. www.w3.org/WAI/videos/standards-and-benefits/ kzbin.info/door/U6ljj3m1fglIPjSjs2DpRA

[@daveturnbull7221]

This prompted me to go have a reead of the HTML elements reference on MDN. As a result I learned that you can have multiple footer tags on a page - I always thought it was only one, while it is actually one per sectioning content or sectioning root. By using the appropriate html tag I can then quite easily style various parts of my document in different ways whereas before I would have been defining different css classes for that. Reading the MDN pages for several of the elements it came to me that by using the most relevant html tag not only will the page be more easily accessed by those who use assistive technology but it will also be clearer to future me when I need to do revisions/updates.

[@ushruff]

I love how over time the "f r o n t e n d f r i e n d s" in the intro has gotten slower and slower xD

[@JimKernix]

I looked at every HTML tag to see how they would display in a markdown file, excluding the obvious ones like nav, section, etc. I wanted to style my GitHub README files to be visually easier to read. The ones I found that I use when appropriate are kbd for highlighting a keyboard key, sup and sub for super and sub-script, and samp for monotype font for things like code or code output. also like details + summary, and dl with dt and dd.

[@dannyt503]

samp? Markdown has code support built in. Use back ticks. This is `inline md code` ``` This is an md code block ``` ```js // This is specifically a JS code block ```

[@JimKernix]

@@dannyt503 I know all of that

[@DarenC]

Being semantic, I'd have assumed screenreaders would announce as struck out. Interesting to see there's apparently a need to give them some assistance. (But then I also thought was current, so what do I know? 🤣)

[@danielsummers1973]

ins and del have some interesting attributes - cite and datetime - that can make them even more informative. Some linters even flag the absence of a datetime as a problem.

[@lawrencedoliveiro9104]

11:22 That’s true of all form elements (fields, buttons etc): they can all individually take the ID of the form to attach them to.

[@JDalmasca]

One issue with fieldset and legend though: they do have some minor styling issues (at least, in some browsers) where they ignore certain CSS applied to them.

[@k_botadra]

BASE ELEMENT SOLVES ONE OF THE PROBLEMS I WAS TRYING TO SOLVE THANKS * immediately hopping to my workstation *

[@EskoLuontola]

I've used base since forever when saving random web pages to local disk. Put the the original URL of the web page to the base element, and all images and links will work when you open the html file from local disk.

[@StefanH]

It's ridiculous how often web devs push back on accessibility. Do your job properly

[@jsperafico]

What is the benefit of having a div to wrap the fieldset? What will be the implication to do it on the form itself?

[@mattwilcoxuk]

"Just use DIV" ... "Why yes, I always hammer in screws. I just use a hammer. It always works. Sometimes I write 'screwdriver' in pen on the hammer though, so I can style my hammer to look like a screwdriver."

[@jporfirio]

I think fieldset just changed my life

[@abebrosiczki637]

I think I found my new Coding YT teacher.. 👏😀

[@ChrisShawUK]

On the S tag, you shouldn't need to do all that CSS stuff about start/end stricken should you? Surely the screen reader should implement this?

[@thedacian123]

VERY INTERSTING!Looking forward seeing data definition list tags eg dd/dl!

[@dave6012]

➕1 to semantic usage. Even for standard users as well. For example, and button and a link can be programmed to do the same thing, but you lose certain right-click functionality, such as “open link in new tab”. This has bitten us at my job in a dashboard, so it happens more often than we think.

[@codernerd7076]

Another great but also really helpful video! If you looking for topics to make videos about here maybe is something 'forms' not so much the functions of the form but the html and css style and most importantly the topic everyone skips... ♿️ One KZbin search on accessibility and forms came up with years-old videos it seems one topic that many just skip completely when talking about forms in general. A video like this would help a lot of developers and most importantly make the web a little bit better for people that got disabilities. 😉

[@peterlistig2020]

8:25: writing "&ampshy;" instead of "­" hurts me in places I did not know I had

[@skabeche81]

Those developers saying it's enough with divs are lazy and bad developers who don't understand how HTML is, don't listen to them, all HTML tags are there for a reason

[@omegaman7377]

But you can't trust the browser to use it properly. Hack with span and div are hacks. But they are working better most of the time.

[@skabeche81]

@@omegaman7377 we don't longer live in 2006, modern browsers are trustful in terms of HTML code, I can not think any reason right now where you should use a hack, as I said, HTML tags are there for a reason

[@dvdsvtlk]

Just an important note: fieldset doesn't support flexbox, at least not in Blink-powered browsers.

[@web-projektmanager]

What happend to your logo opener? No more initials now that we know what it looks like? : ) and beside of this -> a big thank you for all our tipps and tricks!

[@henrywu7982]

I used to old price and new price, so it isn’t a good practice?

[@KevinPowell]

I can see an argument for that as well. I personally think makes more sense, since the old price is relevant information... but you could also argue it's been deleted and replaced by new content.

[@henrywu7982]

@@KevinPowell thank you

[@hagopderderian6824]

I have question for you Kevin... is Working as frontend developer almost same as fullstack? if not whats the difference

[@LeonKorteweg]

Wow I learn something new every video I watch from you. Thanks so much 🙌🏻

[@the-real-tridder]

These are tools to use. I would expect a good craftsman to use the right tool for the job. Thanks for the tools!

[@WolfgangKeim1]

Base would have helped me 3 months ago. Thanks for the information.

[@jamisonr]

Back in the 90s everyone used FRAME and FRAMESET for layouts, now those tags aren't even supported! Maybe a video on tags that were and are no longer. Like a "history" series ...

[@_rohit_s]

I've one problem ? I made a table but using div grid and all have fixed column size templates grid .table-header is sticky , table-row have borders .on small screen resolution scrollbar coming in x-axis but when I scroll the border not coming ... Why this is happening do you know

[@harshthosar8600]

0:20 @KevinPowell, the logo looks different, is this some easter egg?

[@KevinPowell]

I'm having some issues with my encoding when I'm exporting videos for some reason :\

[@AbhinavKulshreshtha]

In strikethrough example, is this appropriate context, S::before {content: "original price"} S::after {content: "discounted price"} . Is there a way to test screenreader on normal browser?

[@KevinPowell]

Yup, just open one up. Windows has Narrator, Mac has Voice Over. They take some getting used to though. I'm not 100% sure about your question though, be worth asking around for people who use screen readers more regularly what they'd expect.

[@AndreDike]

Kevz you are a legend!!!

[@abebrosiczki637]

Just when I thought I already mastered HTML..

[@luckylukeskywalker]

I just learned about the base tag during some research lately and the wbr you could kind of use in every word anyway (there should be some auto wbr parent p tag or something)?! But let's see what the others are.

[@danielk7774]

Del and ins come up BIG in legal papers

[@TheMetalMag]

Amazing u’re the css king

[@deatho0ne587]

My issue with some of the HTML tags you showed in this one and the previous, one is they are not conducive to a changing website based on different languages or different words. For example, the strikethrough for a sale is nice, but maybe it is not on sale? (yes it can be coded through JS, but then it is not pure HTML)

[@gabiold]

If it is not on sale, then write the text "not on sale", or "sold out" somewhere close to the price, in the appropriate language the website is displaying with. If you want to show the last price it was sold on, then just display that exact text, not just "Price" with a strike through value. These things are easily doable these days, there is no excuse for not making clear, dynamic content. Striking through the price without additional information is confusing, even for people with vision. Why is it striken trough? The price is invalid? Changing? Is it not sold anymore?

[@deatho0ne587]

@@gabiold I am not disagreeing with you. I am just saying that he is trying to make it seem like you could just use it without some JS or CSS and it is not the only tag. Example are great tags, but if you want to do it on a specific word you have to change the HTML in some way shape, or form if it is multiple languages or dynamic.

[@gabiold]

@@deatho0ne587 All HTML tags display somewhat primitively when not decorated with CSS, and todays website will be boring at best or non-functional at worst if there is no JS to make it somewhat interesting. Most of the HTML tags could be replaced with div/span, or heck, even span isn't necessary, because you can display a div as inline too. But that would be atrocious. There are this much tags which are just inline or block elements essentially with some default style because it makes the code more readable for a developer first (you name your variables in JS as well, isn't it?), then make it readable for visually impaired people too. Different tags wouldn't give you a functional website out of the box, but removes some extra work, like defining aria roles and help understanding the nested mess of someone else's boxes. Even way easier to code (and later read) an tag than a . I am not claiming that it will solve your business logic too. It won't. It just helps to do it better, faster.

[@deatho0ne587]

Yes, which is what I am saying they are not a be-all-end solution. We are just talking past each other.

[@lesalmin]

I totally agree with you. I'm just too lazy to utilize that variety of elements :-)

[@vipulpawaskar]

Can we get some more information on tabIndex -1 0 1 accessibility point of view, starting from address bar.

[@sogeman]

Is the s tag even worth it if a screen reader can't handle it without extra css?

[@DaVince21]

I think so, because it gives the text the semantics needed for screen readers to implement it in the future.

[@petropzqi]

This is great. Please consider do a video about WCAG

[@yousafnadeem5458]

Can You please make a video on counter increments of CSS

[@fylip22b]

Bonjour. Merci pour le partage de ces éléments. Philippe P.

[@RajShekhorcoder]

Awesome my life with your channel. Thanks

[@valeriousmonk654]

Great series

[@quicktastic]

Has Codepen replaced VS Code as the editor of choice?

[@KevinPowell]

For quick demos, yes. Not for doing actual work though :)

[@quicktastic]

@@KevinPowell Yeah, I went an checked out their site after watching your video and found it really handy for instant results when trying to test or develop something so I see it is perfect for your instructional videos. Thanks for the response. :)

[@charliecalunsag2384]

Thanks sir, this is very useful im a i.t student but i dont know how to use/role the other elements

[@mhcbon4606]

HTML is awesome. But semantic is a loosely shareable concept. works well sometimes. smells hard in other situations. To bad we need JS to get a really powerfull descriptive language (react etc)

[@Imperial_Squid]

Nope, however strongly you emphasise it, I still refuse to hear anything but friend and friends 😂💜

[@oldgamer1299]

I don't see these on the periodic table.....

[@alvinray9080]

spelling in graphic?

[@KevinPowell]

oops, thanks!

[@lawrencedoliveiro9104]

8:07 “&ampshy;” looks wrong: it should be entity reference

[@lawrencedoliveiro9104]

“&am

[@lawrencedoliveiro9104]

p;”

[@lawrencedoliveiro9104]

followed by reg

[@lawrencedoliveiro9104]

ular tex

[@lawrencedoliveiro9104]

t “shy;”: “&am

[@Durakken]

you kept using the term "relevant". It does not remove the relevancy of the text. It says that the information is no longer the case or that the task has been accomplished, not that it is non-relevant.

[@cintron3d]

GitHub devs seeing this like, oof, better fix that.

[@selozty]

what a nice guy

[@gledianlalushllari9577]

I'm hearing lots of praise for tailwind, what do you think about it?

[@GriffinAndThings]

I love elemetns

[@adrianrios8597]

Hello, when will you translate your videos into Spanish?

[@KevinPowell]

At the moment, I can't dub old videos, I can only have it for new ones. I'm in early-access for the trial that KZbin is running, so it's a bit limtied at the moment with what we can do. Hopefully in the future I can update my old ones as well!

[@adrianrios8597]

@@KevinPowell Hello Thank you very much for answering, I really like your videos and I always learn from them, but sometimes I have a hard time understanding the language. It would be great if all your videos are dubbed into Spanish. I will wait for them, thanks.

[@ZipplyZane]

Very recently I read that had been removed from HTML5.

[@DaVince21]

Where'd you read that? MDN doesn't say anything about it.

[@gg-gn3re]

Still no mention of an actual useful one like ?

[@hyscoar9068]

The thumbnail spelt Elements wrongly hahaha

[@novanoskillz4151]

wait you’ve been saying frontend friends all this time????

[@Mabi19]

Oh hey, your intro is broken again.

[@yxshv]

Again weird intro

[@shapelessed]

No, we don't. And at the end of the day we're gonna end up with a div soup anyways because components and wrappers and all of that.

[@KevinPowell]

With grid, I find there's much less need for that... and you can still use the correct semantic element within the structure you're building with divs (that is the purpose of divs anyway)

[@manusoftar]

The problem I see with your argument is that there is no statistical data that would show that there is SO MANY people using screenreaders instead of just looking at a website as you would normaly do (reading by yourself) that doesn't justify the extra "effort" to use all these elements when you can simplify the code and your work by using the most common elements. Of course there are some element you just can't avoid because recreating their functionality through js and css would be a pain in the b, like inputs, for example. But for "regular" containers well... you can just use divs or spans. OMG!!, that BASE element actually defeats all the porpouse of using relative links... if you want to point your links to a specific website just use a God damn absolute url... if not, use a RELATIVE path which is RELATIVE to the website where it is placed, thats the point of a RELATIVE url to be RELATIVE...

[@2eanimation]

but the link is relative to base(MAYBE that's why it's named like that), so everything is good :) For your first paragraph, you don't have to put effort in learning like what, 10-20 extra elements. If your site is destined to be used by everyone maybe you should run the extra mile though. We have wheelchair ramps although the majority of people can walk. We have structured ground and clicking/beeping traffic light switches for blind people although the majority of people can see. That's more effort than learning 20 extra tags and still, we as a community go through all of this. Most people use main, nav, header, footer, aside, ... although a div would work just fine. At some point, it even helps you as a dev => putting something in header vs "which div was it again?". Back to , why use anyways? just use a div and slap an onclick-handler on that mf. Same story for p and headings. No more css-resetting as divs have neither margins nor paddings by default. Divs all the way, baby! I'm not blind or otherwise impaired, but I think I would be utmost grateful for everything that helps me exploring the world at least a little bit easier.

[@DaVince21]

The base element is actually super useful because it allows you to redefine the root as a subdirectory, allowing you to use / without referring to the domain's top level. Very useful for webapps that live in a subdirectory.

[@DaVince21]

Additionally, there are more reasons to write semantically. For example, defining nav blocks allows software to quickly separate the navigation out if you wished. And search engines get a better idea of the purpose of the website and its contents. Bots would be about to filter out everything but the articles or other specific desired content. Your CSS has an opportunity to become more obvious, although I'd say CSS is already pretty elegant by using the very short . and # characters anyway. I also just think it makes the code more readable as there are fewer attributes strewn around.

[@Coolhwhipmike]

I use a screen reader often. I don't need it, but hearing the words helps me to focus on what I'm trying to understand. And I don't do this for a living but I'm not sure how using semantic tags is more work. Isn't it basically just typing a different word? Using nav instead of div doesnt seem like a big deal to me. And in the end it's just a video about HTML, no reason to get so fired up.

[@mareksawinski8225]

Accessibility is not that important as every KZbinr who wants to be cool, modern and progressive says it is. This is just virtue signalling. There are tonnes of projects and domains, which do not require any accessibility at all. For instance B2B / back-office projects aimed for certain known group of users. I have yet to find any project manager, who will happily say YES to accessibility when he or she is given increased estimate. Of course there are projects, which require accessibility features, but this is NOT base case scenario in a real world. This is always a business decision based on trade-offs. In real world, less than 1% of potential users in most cases do not justify accessibility development cost. Instead of learning accessibility developers should focus on that which is really important i.e. learning fundamentals. In most cases accessibility knowledge is nice to have, not must. Don't be fooled, think for yourself.

[@diablo.the.cheater]

In a lot of countries accesibility is not an option, but is obligatory by law and you can get fined or even go to jail(depends of the country) if you do not comply. HTML elements are there for a reason, use them

[@mareksawinski8225]

@@diablo.the.cheater Yes, that is true. But (and this is very big but), this obligation refers only to certain products (i.e. transportation, front facing apps only), which are only small part of potential range of domains one can work on. Again, this is business decision. Also, I'm not saying that one should not use some HTML elements and always use divs or whatever. Semantic HTML is important in my opinion (accessibility is not only using semantically correct tags BTW). I'm saying that there are many potential things developer could learn. Accessibility development is just not that important in grand scheme of things, contrary to popular believe. A lot of this is motivated by empty virtue signalling.

[@MrBaupshaw]

The problem with this is that you never know who future users of an app will be. I’m blind and do security pen testing and threat hunting, general analysis and build automation tools in Python (sometimes with some modest to more involved front ends. The barriers I face in the workplace are not due to my own technical ability, but because of the lack of forethought put in by lazy or budget-obsessed PMs who don’t consider the future state of the app or it’s user base. There’s a very popular vulnerability scanning product that is virtually unusable; and I have to constantly bug other team members to kick off scans given its command-line interface is not capable of everything tbe UI is. Our incident tracking system is also not accessible, so I’m out of the loop there. I’ve been placed as the lead on the rollout or configuration of a new product only to jump on the first zoom call and embarrassingly drudge through an inaccessible UI and have to ask another team member to be in the driver’s seat for the screenshare. You are certainly correct in that just using semantic tags isn’t all of accessibility but it it is the 80/20 rule: 20% of the work nets 80% of the benefit. Aria labels are also pathetically easy and gets you much closer. But not even these two simple, low-cost low-effort things are being done by large enterprises and well funded teams. Just because none of your employees, end users, or customers are using a screen reader today doesn’t mean that they won’t in the future, and it’s this lack of concern and forethought that irks me. there’s not a day I don’t have to fight through and waste time on working with an inaccessible product instead of doing more valuable, profitable, fulfilling work for my employer. Cyber is mostly command line tools hence why I’ve found my niche here, but I still rely on a lot more than just the command line to work.

[@napsarefornerds4344]

I had a great use for the other day with two long words separated with a slash. verylongwordone/verylongwordtwo in a heading, and added the after the slash.