1 Hide an element
Yes! you read it right. We can hide an element using HTML. Using the hidden attribute we can hide an element.
Example-...
For further actions, you may consider blocking this person and/or reporting abuse
Few issues:
alignis deprecated so don't use that as support may be patchy.<br>and<wbr>are not the same thing.<br>forces a break whereas<wbr>says "you can break here if you need to" to be used with a particularly long word or if a phrase will make more sense if it breaks at a certain point.Oh and there is a typo as
</br>should be<br/>or just<br>in your example. You don't open and close it as it is a self closing element.And finally the
type="color"is not very good accessibility wise so you will probably want to roll your own or enhance it a lot with WAI-ARIA.Other than that, great tips!
Extra: Perhaps change the item numbers to headings with
##so## 1 Hide an elementas that makes the page easier to navigate for screen readers and it will look better too!Also handy if you are displaying a URL or similar type of string and you want to make sure it breaks at a meaningful/convenient place like a '/'.
+1 to that!
URLs and German (with the beautiful mega long words that break your UI when you try to implement i18n!)...I am sure that is what
<wbr>was designed for, just those two use cases! 😋Nah, pretty sure URLs were an afterthought.
<wbr>was added just for German i18n.Or Dutch. But in the Netherlands many people have the English disease where they write spaces when they should not. Sometimes this unintentionally totally changes the meaning of a sentence. F.e. "zoete witte wijnprofessor".
Niets mis mee.
Is een blanke vinoloog die universiteitsstudentjes wat zijig lesgeeft
You don't get a hyphen though, which you want when you break up a long word. I'd rather use
­here.<wbr>looks more useful for URLS, imo.Don't forget
del/ins. Using elements because of how they are displayed on the browser instead of because of their meaning (semantics) is not a good use of HTML, and can be bad for usability/accessibility too.Now I know why align is not working in my divs ( it is working in the
statements though)
hi ! Thanks for the advice and the feedback.
No problem, could you fix the article to include / adjust things based on the advice?
People who are new may read the article and learn bad practices and never read the comments!
Agree on that ! I will make the adjustments.
can you please remove react and JS tag from your post? they are irrelevant here
Hi Temani! I added those tags so that react js and JS interested folks can also read this article as these points are very basic .
tag should be used to refer to the content and not to attract people. I wanted you to remove them before asking a moderator to do.
I think there is no problem on adding those tags. Also in React, you can use these HTML tags in JSX.
The tags should reflect the content and only the content. The post is only about HTML & CSS. The fact that HTML is related to react, JS, Boostrap, Vue, Angular, etc etc is irrelevant to the tagging system.
As far as I can see the theme is the culprit as the outline is set to 0 on focus.
By default the summary element will receive focus and have a focus indicator and that is the bit where you should add custom focus indicators. Unlike tabs the content of a details element should not be focusable (unless it contains a focusable item of course!).
No need for any WAI-ARIA on this one, the semantics and relationships are built in (a rare unicorn element that pretty much works out of the box!) - although the accessibility tree does look a little strange on this custom component, need to have a look at it on main computer as I can't see what it is doing...but that could be related to the next point:
Also the example doesn't seem to work, it looks like something is going wrong with the
code-samplecomponent and leaking invalid JS into the document.Nice spot @lukeshiru , I hadn't spotted the focus indicators didn't work!
Ah, submitted a report, I haven't used GitHub in years so apologies if the report is poor, plus I can't even remember how to tag it so I will leave that to you 🤣.
Yes I am aware I am a strange developer!
While you can use the
progresselement with JS it's not very useful for most progress use cases without a way of updating the value attribute.Do you mean, "without JS"?
progressis fine without dynamic updates. Imagine something saying, "your profile is x% complete" or "you're on page 9 of 32 of this simple government tax form".I did mean without thanks for the correction. Yes the progress element is still useful without dynamic updates. That's why I said 'most progress use cases'. In my experience (and I expect many other people's) most of the use cases for a progress bar (including the implied use case in the article) is to provide dynamic feedback for an ongoing process.
It is important to note the non-dynamic use cases though so thanks for that. They are definitely semantically meaningful use cases and
progressis the best element for those too.HTML allows this tags (some of them are deprecated, take care) for the use-case of html content generators, such this kind of textareas where you can type, hit bold, new line, italic and so buttons for a user to get a WYSIWYG interface.
If you use them on a different context it may be tricky as forcing some of those statements on a dynamic content will certainly produce undesired output effects depending on the client's viewport.
Thanks Joel! Really appreciate your feedback.
Hi Luke! php and node are complete different things.
But a person who works on ReactJS are assumed he is familiar with HTML CSS.
So, lets leave this tag for now. Interested folks can read this article
I like the simple accordion tip. That may come in handy very soon for me.
Thanks Vinit ! Glad you liked.
I never knew "Accordion" is something that we can achieve through just html. Thanks for the info!
Thanks Suvel ! Glad you found something new through this article.
haha! Thats true Jordan.