Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
(I'd like this to be the definitive community wiki. I seeded it from my own answer to this question.)
Specify Everything
A lot of cross-browser issues amount to this: you didn't specify something, and different browsers make different assumptions. Therefore:
Declare a valid doctype
Your doctype tells the browser what rules you'll be using in your code. If you don't specify, the browser has to guess, and different browsers will guess differently.
In my experience, a "strict" doctype makes IE behave better (enables things like CSS :hover selectors on divs in IE7).
This article gives good background on doctypes.
Use Web standards
Avoid browser-specific markup, or only use it when its failure in other browsers won't be significant to the site experience.
Validate your HTML and CSS
You don't have to get everything perfect, but validation is good feedback. As Jeff said:
Knowing the rules and boundaries helps you define what you're doing, and gives you legitimate ammunition for agreeing or disagreeing. You can make an informed choice, instead of a random "I just do this and it works" one.
Imagine you opened a paragraph tag and never closed it. If you then open a list tag, did you mean it to be inside the paragraph or not? Validating will help you catch that, close the tag, and eliminate ambiguity.
Consider a CSS Reset
Different browsers assume different baseline CSS rules. You can help them all to act the same by explicitly ironing out the differences up front. Eric Meyer, who wrote CSS: The Definitive Guide, uses this reset. Another popular choice is YUI Reset CSS.
Use a Javascript library for DOM interactions
Whenever your Javascript needs to work with elements on your page, it's best to use a library like jQuery, Prototype, or MooTools. These libraries are used by many thousands of developers, and they take most of the inconsistencies between browsers' interpretation of Javascript, deal with those internally, and give you a consistent set of commands that just work. Trying to find and work around all these inconsistencies yourself is a waste of time and likely to create bugs.
Test in multiple browsers, deal with IE last
Test in multiple browsers as you go. Generally, you'll find that non-IE browsers behave similarly and IE is a special case - especially if you follow the advice above. When necessary, you can add IE hacks in a separate stylesheet and only load it for IE users.
Quirksmode.com is a good place for hunting down random browser differences.
Browsershots.org can help show how your page will be displayed in an assortment of browsers and operating systems.
Fail Gracefully
No site will look perfect in every browser that exists. If a user doesn't have Flash, or Javascript, or advanced CSS, etc, you want your site to be usable anyway. Design with that in mind:
Check the bare HTML
Try loading your site with bare HTML - no styles, no scripts. Are menu options available? Does primary content precede secondary content? Is the site usable, even if ugly?
Consider test-driven progressive enhancement
Described in this article, this technique uses javascript to check if a browser has a given capability, such as support for a given CSS property, before using it on the page. It is unlike browser sniffing because it tests for features rather than a specific browser.
Use a library like jQuery abstract away the differences in the DOM, AJAX and JavaScript.
Make sure you're keeping HTML, CSS and Javascript in separate files as much a possible. Mixing structure, presentation and behavior in your HTML file just makes finding and fixing problems harder.
Use Firebug in Firefox for:
Debugging/stepping through your JS.
Seeing how your stylesheets are being interpreted and hacking them up on the fly to see how to fix your problem.
See how many calls you are making for remote resources and how long they take.
Profile your code.
Chrome and IE8 have similar tools built-in that can be used for the same thing.
Opera and Safari (and IE) have Firebug Lite.
Use CSS Reset on start of your stylesheet...
You can get one here...
Validate your code by w3c ...
You can validate your code here by page link or simply copy paste page element
My #1 rule is use a strict doctype. HTML or XHTML is fine, but using the strict doctype removes pretty much every browser quirk there is, especially in IE7+.
Imagine you opened a paragraph tag and never closed it. If you then open a list tag, did you mean it to be inside the paragraph or not?
Actually you can't put any other block tags inside a <p> tag, that's why the spec allows you to omit the closing tag. If you start a list without closing a paragraph, then the paragraph is implicitly closed. And the validator won't complain.
That's not to say you shouldn't close tags, because it generally makes code easier to skim (you don't need to remember the above rules).
Consider programming you web-site's UI using Google Web Toolkit. With GWT you write all code in Java programming language which GWT then cross-compiles into optimized JavaScript that automatically works across all major browsers.
I think using best practice is the way to go, progressive enhancement is designing with the user in mind and needs to be done with all designers. I believe that a lot of testing on browsers is a good way to ensure proper content is being displayed, many developers over look this.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
It's a well known fact that browsers will accept invalid HTML and do their best trying to make sense out of it. If you create a web page containing only the following code:
<html>
<head>
<title>This is bad HTML</title>
<body>
<h1>Bad HTML</h2>
<p>This is a paragraph
</body>
then you will get a webpage parsed in a way that will show an acceptable view. Whether it is what you meant or not, depends on each browser's understanding of your mistakes.
This, to me, is the same as if Javascript could be written like this:
if (some_var == 1) {
say_something("some text');
else {
do_something_else();
// END OF CODE
which, a Javascript compiler written with the same effort to make sense out of invalid code could proably parse as you meant - or make its own sense but run it after all.
I've seen several articles and questions regarding the question "Is it even worth it writting valid HTML?", which present several opinions on the pros and cons of writting valid HTML. However, what this really makes me wonder is:
Why are browsers accepting invalid HTML in the first place?
NOTE: The following questions are not more questions, but a way to give context to the only question I'm asking here:
Why aren't browsers strict?
Why don't they reject with errors invalid code, just like any other programming language? (not that I'm calling HTML a programming language, but you get the point)
Wouldn't that force all developers to write HTML code that will be interpreted exactly the same in any browser?
If browsers refused to parse invalid markup, wouldn't that effectively result in valid markup everywhere and from anyone wanting to publish content in the web?
If this comes from historical reasons and backward compatibility, isn't it time already to change when we already see sites like adsense.google.com refusing compatibility with IE < v10?
EDIT: Those voting to close this question, please reconsider. This is not a broad question neither is a opinion based one. It's a very specific question on a very specific subject, completely related to the programming world and that can definitely be answered with a real answer by those who actually know it. Thanks.
"Why are browsers accepting invalid HTML in the first place?"
For compatibility reasons, and in the case of newer browsers, because HTML5 dictates an algorithm for parsing even invalid documents.
Earlier HTML specifications were ambiguous on many situations,
such as what happens when the wrong tag is seen, or inconsistent nesting of
tags, such as <b><i></b></i>. Even so, many documents "just work" because some earlier browsers ignore unexpected tags or even "correct" incorrect nesting.
But now the HTML5 specification includes a much less ambiguous algorithm for parsing HTML documents. Note that the algorithm includes points where "parse errors" can occur. But these parse errors usually don't stop a modern browser from displaying an HTML document, although the browser is free to display parse errors in its developer tools if it chooses to:
[U]ser agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification. [Emphasis added.]
But again, no modern browser, to my knowledge, aborts parsing a document this early because of parse errors (barring extraordinary situations, such as running out of memory).
On the adsense.google.com situation: This probably has nothing to do with invalid HTML, but rather, perhaps, because IE9 and earlier's DOM support is not sufficient for adsense.google.com's needs.
I don't know why they allowed it from the start, but here is why they cant switch now: Legacy Support. If a browser forced strict html, huge parts of the internet would just break, and yes some people would update their code, but some pages would just be lost. There is no incentive for browsers to do this because it would seem to the consumer that browser just doesn't work on some pages and would switch to another that still supports less optimal html.
Basically because it was allowed from the beginning, now it has to be allowed now.
To avoid opinion-based answers, this type of question requires an answer based on an authorative reference with credible and/or official sources.
The following excerpts are quotes from W3C Validator Help & FAQ that addresses Why are browsers accepting invalid HTML in the first place? and some other demonstrated concerns related to that.
About Markup
Most pages on the World Wide Web are written in computer languages
(such as HTML) that allow Web authors to structure text, add
multimedia content, and specify what appearance, or style, the result
should have.
As for every language, these have their own grammar, vocabulary and
syntax, and every document written with these computer languages are
supposed to follow these rules. The (X)HTML languages, for all
versions up to XHTML 1.1, are using machine-readable grammars called
DTDs, a mechanism inherited from SGML.
However, Just as texts in a natural language can include spelling or
grammar errors, documents using Markup languages may (for various
reasons) not be following these rules.
[...]
Concepts
One of the important maxims of computer programming is: "Be
conservative in what you produce; be liberal in what you accept."
Browsers follow the second half of this maxim by accepting Web pages
and trying to display them even if they're not legal HTML. Usually
this means that the browser will try to make educated guesses about
what you probably meant. The problem is that different browsers (or
even different versions of the same browser) will make different
guesses about the same illegal construct; worse, if your HTML is
really pathological, the browser could get hopelessly confused and
produce a mangled mess, or even crash.
That's why you want to follow the first half of the maxim by making
sure your pages are legal HTML.
[...]
Validity might not mean quality, and invalidity might not mean poor quality
A valid Web page is not necessarily a good web page, but an invalid
Web page has little chance of being a good web page.
For that reason, the fact that the W3C Markup Validator says that one
page passes validation does not mean that W3C assesses that it is a
good page. It only means that a tool (not necessarily without flaws)
has found the page to comply with a specific set of rules. No more, no
less. This is also why the "valid ..." icons should never be
considered as a "W3C seal of quality".
Unexpected browser behavior might mean that they actually don't accept invalid markup
While contemporary Web browsers do an increasingly good job of parsing
even the worst HTML “tag soup”, some errors are not always caught
gracefully. Very often, different software on different platforms will
not handle errors in a similar fashion, making it extremely difficult
to apply style or layout consistently.
Using standard, interoperable markup and stylesheets, on the other
hand, offers a much greater chance of having one's page handled
consistently across platforms and user-agents.
[...]
Compatibility problems
Checking that a page “displays fine” in several contemporary browsers
may be a reasonable insurance that the page will “work” today, but it
does not guarantee that it will work tomorrow.
In the past, many authors who relied on the quirks of Netscape 1.1
suddenly found their pages appeared totally blank in Netscape 2.0.
Whilst Internet Explorer initially set out to be bug-compatible with
Netscape, it too has moved towards standards compliance in later
releases.
[...]
Relying too much on 3rd party tools
The answer to this one is that markup languages are no more than data
formats. So a website doesn't look like anything at all! It only takes
on a visual appearance when it is presented by your browser.
In practice, different browsers can and do display the same page very
differently. This is deliberate, and doesn't imply any kind of browser
bug. A term sometimes used for this is WYSINWOG - What You See Is Not
What Others Get (unless by coincidence). It is indeed one of the
principal strengths of the web, that (for example) a visually impaired
user can select very large print or text-to-speech without a publisher
having to go to the trouble and expense of preparing a separate
edition.
My question is similar to what this poster is asking:
What are the concrete risks of using custom HTML attributes?
but I want to know what can happen if I use custom elements and custom attributes with the current html specs (html 5).
Example
<x a="5"> abc </x>
Visually I see no issues in any browser. js works:
x = document.getElementsByTagName('x');
alert('x has attribute a=' + x[0].getAttribute('a'));
css works too:
x{
color: red;
}
x[a]{
text-decoration:underline;
}
Possible Risks include
Backward compatibility. In particular, IE8 and below won't understand your tag, and you'll have to remember to write document.createElement('x') for all your new elements.
Semantics - having your html machine-readable may not be your goal, but there may come a time when it needs to be parsed in a moderately useful fashion.
Portability & maintenance - there are plenty of current html tags that almost certainly do what you want them to do. At some point, someone else may have to look after your code. Is there anything to be gained from having them spend time learning what all your new tags are for?
SEO - don't take the risk of a penalty just because it's something you can do..
For completeness, there are justified reasons to do it though. If you can demonstrate your new tag improves the semantics of your page (your example of 'x' obviously doesn't) and you can think of some use-case where your page will be machine-parsed by your own process, then go for it.
The only issue I can think of is that other applications, including search engines, won't recognize your custom elements and properties, so they won't know what to look for or how to use them which is a decided disadvantage for SEO. Other applications trying to access your content, including RESTful apps, will not know either without you telling the app developer.
This was always listed as one of the disadvantages of XML/XHTML but here we are again, back full circle to where we should have been in the first place, the use of XML on the web ... but I digress.
The main reason custom elements were frowned upon in the past is because browsers don't know what to do with them and there was no standardised way of telling them what they are.
What are the risks of using custom HTML elements in HTML5 without following standardisation?
Browsers will handle them differently:
Some browsers may ignore the elements and pretend they're not there; <x>, I don't know what <x> is, lets get rid of that.
Some browsers may attempt to convert the element into something else; define a <tab> element and a browser may think you've mis-spelled <table>, for instance.
You'd have to handle what the element is supposed to do across a large range of devices; just because it works on your PC doesn't mean it works on your phone, or your TV, or your e-reader... or your WiFi-powered fridge...
The good news is that there is some new documentation being written up to allow developers to define their own custom elements in a standardised way. Custom Elements, as it's titled, gives both developers and browser vendors the know-how to allow developers to implement and script custom elements in a way which will work across all supporting browsers... or that's the idea, anyway.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
It's a well known fact that browsers will accept invalid HTML and do their best trying to make sense out of it. If you create a web page containing only the following code:
<html>
<head>
<title>This is bad HTML</title>
<body>
<h1>Bad HTML</h2>
<p>This is a paragraph
</body>
then you will get a webpage parsed in a way that will show an acceptable view. Whether it is what you meant or not, depends on each browser's understanding of your mistakes.
This, to me, is the same as if Javascript could be written like this:
if (some_var == 1) {
say_something("some text');
else {
do_something_else();
// END OF CODE
which, a Javascript compiler written with the same effort to make sense out of invalid code could proably parse as you meant - or make its own sense but run it after all.
I've seen several articles and questions regarding the question "Is it even worth it writting valid HTML?", which present several opinions on the pros and cons of writting valid HTML. However, what this really makes me wonder is:
Why are browsers accepting invalid HTML in the first place?
NOTE: The following questions are not more questions, but a way to give context to the only question I'm asking here:
Why aren't browsers strict?
Why don't they reject with errors invalid code, just like any other programming language? (not that I'm calling HTML a programming language, but you get the point)
Wouldn't that force all developers to write HTML code that will be interpreted exactly the same in any browser?
If browsers refused to parse invalid markup, wouldn't that effectively result in valid markup everywhere and from anyone wanting to publish content in the web?
If this comes from historical reasons and backward compatibility, isn't it time already to change when we already see sites like adsense.google.com refusing compatibility with IE < v10?
EDIT: Those voting to close this question, please reconsider. This is not a broad question neither is a opinion based one. It's a very specific question on a very specific subject, completely related to the programming world and that can definitely be answered with a real answer by those who actually know it. Thanks.
"Why are browsers accepting invalid HTML in the first place?"
For compatibility reasons, and in the case of newer browsers, because HTML5 dictates an algorithm for parsing even invalid documents.
Earlier HTML specifications were ambiguous on many situations,
such as what happens when the wrong tag is seen, or inconsistent nesting of
tags, such as <b><i></b></i>. Even so, many documents "just work" because some earlier browsers ignore unexpected tags or even "correct" incorrect nesting.
But now the HTML5 specification includes a much less ambiguous algorithm for parsing HTML documents. Note that the algorithm includes points where "parse errors" can occur. But these parse errors usually don't stop a modern browser from displaying an HTML document, although the browser is free to display parse errors in its developer tools if it chooses to:
[U]ser agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification. [Emphasis added.]
But again, no modern browser, to my knowledge, aborts parsing a document this early because of parse errors (barring extraordinary situations, such as running out of memory).
On the adsense.google.com situation: This probably has nothing to do with invalid HTML, but rather, perhaps, because IE9 and earlier's DOM support is not sufficient for adsense.google.com's needs.
I don't know why they allowed it from the start, but here is why they cant switch now: Legacy Support. If a browser forced strict html, huge parts of the internet would just break, and yes some people would update their code, but some pages would just be lost. There is no incentive for browsers to do this because it would seem to the consumer that browser just doesn't work on some pages and would switch to another that still supports less optimal html.
Basically because it was allowed from the beginning, now it has to be allowed now.
To avoid opinion-based answers, this type of question requires an answer based on an authorative reference with credible and/or official sources.
The following excerpts are quotes from W3C Validator Help & FAQ that addresses Why are browsers accepting invalid HTML in the first place? and some other demonstrated concerns related to that.
About Markup
Most pages on the World Wide Web are written in computer languages
(such as HTML) that allow Web authors to structure text, add
multimedia content, and specify what appearance, or style, the result
should have.
As for every language, these have their own grammar, vocabulary and
syntax, and every document written with these computer languages are
supposed to follow these rules. The (X)HTML languages, for all
versions up to XHTML 1.1, are using machine-readable grammars called
DTDs, a mechanism inherited from SGML.
However, Just as texts in a natural language can include spelling or
grammar errors, documents using Markup languages may (for various
reasons) not be following these rules.
[...]
Concepts
One of the important maxims of computer programming is: "Be
conservative in what you produce; be liberal in what you accept."
Browsers follow the second half of this maxim by accepting Web pages
and trying to display them even if they're not legal HTML. Usually
this means that the browser will try to make educated guesses about
what you probably meant. The problem is that different browsers (or
even different versions of the same browser) will make different
guesses about the same illegal construct; worse, if your HTML is
really pathological, the browser could get hopelessly confused and
produce a mangled mess, or even crash.
That's why you want to follow the first half of the maxim by making
sure your pages are legal HTML.
[...]
Validity might not mean quality, and invalidity might not mean poor quality
A valid Web page is not necessarily a good web page, but an invalid
Web page has little chance of being a good web page.
For that reason, the fact that the W3C Markup Validator says that one
page passes validation does not mean that W3C assesses that it is a
good page. It only means that a tool (not necessarily without flaws)
has found the page to comply with a specific set of rules. No more, no
less. This is also why the "valid ..." icons should never be
considered as a "W3C seal of quality".
Unexpected browser behavior might mean that they actually don't accept invalid markup
While contemporary Web browsers do an increasingly good job of parsing
even the worst HTML “tag soup”, some errors are not always caught
gracefully. Very often, different software on different platforms will
not handle errors in a similar fashion, making it extremely difficult
to apply style or layout consistently.
Using standard, interoperable markup and stylesheets, on the other
hand, offers a much greater chance of having one's page handled
consistently across platforms and user-agents.
[...]
Compatibility problems
Checking that a page “displays fine” in several contemporary browsers
may be a reasonable insurance that the page will “work” today, but it
does not guarantee that it will work tomorrow.
In the past, many authors who relied on the quirks of Netscape 1.1
suddenly found their pages appeared totally blank in Netscape 2.0.
Whilst Internet Explorer initially set out to be bug-compatible with
Netscape, it too has moved towards standards compliance in later
releases.
[...]
Relying too much on 3rd party tools
The answer to this one is that markup languages are no more than data
formats. So a website doesn't look like anything at all! It only takes
on a visual appearance when it is presented by your browser.
In practice, different browsers can and do display the same page very
differently. This is deliberate, and doesn't imply any kind of browser
bug. A term sometimes used for this is WYSINWOG - What You See Is Not
What Others Get (unless by coincidence). It is indeed one of the
principal strengths of the web, that (for example) a visually impaired
user can select very large print or text-to-speech without a publisher
having to go to the trouble and expense of preparing a separate
edition.
When users visit my website, they don't care about how perfect or how much standard the page is coded. They only care about whether it works or not.
There are tags that are deprecated but have consistent behavior throughout all major, minor, and very minor browsers. They work now and will work in the future. (I'm not talking about optional tags like <marquee> and <blink> which will probably be removed in the future since their non-existence doesn't break pages.) The tags I'm talking about are for example:
<center> (used by google.com homepage, yes and it's May 2014)
<body bgcolor=, alink=, vlink=, link= (all used by google.com)
<font size= (also used by google.com)
If my HTML generator produces tags like <body bgcolor=black>, it is guaranteed to work for near 100% of users.
If it instead produce CSS like background:black;, it will be supported by lesser users compared to <body bgcolor=black>. (Start with https://superuser.com/q/732669/78897 and https://superuser.com/q/447269/78897, though I'm sure they are not the only ones in the whole world.)
Bear with me, this is a real question based on a true problem. Exactly what are the real disadvantages of having these tags as output?
Potential disadvantages include the following:
1) Your customer might actually care about how standard the code is. Maybe not now, but in the future. Maybe for questionable reasons, but still.
2) Deprecated constructs do not always work consistently. For example, align=center attribute set on a table may have different effects depending on browser mode. This is a relatively weak argument, though, since the browser practices have been described rather well in HTML5 CR and you can manage the potential problems. (Besides, even CSS settings may work inconsistently.)
3) There is no guarantee that deprecated features will be supported by all future browsers. On the other hand, the same applies to standard features. In practice, very few features that have been defined in HTML specifications have actually been removed from browsers. (Regarding tags, I think basefont is the only case.) All the examples mentioned, and also marquee, have been described in HTML5 CR as “obsolete” but still well-defined, and according to HTML5 CR, browsers are expected, and partly required, to support them all.
4) Your colleagues (designers/developers/...) may regard your code (and you) as old-fashioned, non-semantic, and whatever.
5) Code maintenance and development may be more difficult. If you have 1,000 pages with <body bgcolor=black> and the customer says they want a somewhat different background color, you would need to edit each page. This argument is, however, weaker than it seems to be. First, how often do such things actually happen? Second, if the pages have actually been generated using suitable tools, perhaps you just need to change the value of one parameter and regenerate them (or just let servers do that, if the pages are dynamically generated). Third, if you have a link element on all pages, referring to basic style sheet for the pages, as you normally should, you just need to add one rule to that style sheet. It is easy to override presentational HTML attributes with CSS.
To summarize, the practical arguments against your approach are rather weak. The most important arguments relate to coding style and principles.
I've added some more disadvantages:
Another disadvantage of using those tags is site bandwidth. When you put in html center, bgcolor and similar tags every time browser needs to load the whole content even if on every page those tags are the same or even if user visited this site many times. But when you place design in css file browsers may cache those files (especially when you set headers properly) so they only load html and images (if no cache is set).
One another thing is that if you decide to redesign the site/style new elements, it's much easier to put changes only in CSS files. It's possible in future you won't be doing those changes on your own or other companies/freelancers will be doing them and it will be much easier for them to make changes in the site. So the site will be cheaper to maintain.
In addition if html / php code is poor (or site is very complex) and many "visual conditions" appear in many files (for example on one page you decide to use one colour and you put it in HTML, on the other another colour) and something goes wrong it will be much easier to find the problem because you may simple cut some css and check where's the problem.
The disadvantage is when one of the major browsers chooses to get rid of the deprecated tag in a future release.
The advantage of using CSS over tags is that you can change the whole web site look and feel in a simple move.
Consider people that require larger font sizes. Colour blindness and also enable the most use of screen readers.
Even those consistent behaviour tags may be removed from browser. What if you would like to create HTML5 website? Then you will need to learn everything from scratch and change literally everything for your website to make it work because you never know if those tags will be supported in HTML 5 in future or only in older HTML documents
CSS provides easier maintenance, for one; client decides they want some elements aligned left instead of center? Change your css rule and poof, you're done. But if you're using old-school valign and such? Get ready to go change every single instance of that in the file(s).
As far as I understand, the only real advantage of HTML5 semantic markup is for search engines and web crawlers to interpret the document better.
Since intranet applications have nothing to do with search engines or web crawlers, what are the advantages of using semantic markup in HTML5?
There is no straightforward example to point out, but the website (even intranet) can be consumed by different user agents (on different devices).
You are probably familiar with Skype (and the iOS Safari) making phone-number-like words clickable. In the future I can easily imagine mobile browsers being smarter to assist the user in completing tasks on the page, like importing a clearly indicated contact to the address book.
Screenreaders for blind people?
While there is not a whole lot of immediate benefit for non-disabled people, it is still good practice. Does your company not have any externally facing sites? If it does, do those people not look at internal page code? Good practices spread just like bad ones.
see also: http://en.wikipedia.org/wiki/Semantic_HTML
Simply said there the only rule you have to follow if you create your html documents is that it is valid html, otherwise you will have the problem that the browser would try to correct your broken syntax which may result in defects of the visual representation of your content.
In modern browsers you can use display to given any element - with some limitations e.g. with input element - the same visual look and behavior then any other element.
So if you ask what are the advantages of using semantic markup in HTML5 you should ask, why to use any of the semantic markup if it is possible to have the same result using css.
The short answer is, no one will stop you if it is your own project where you are responsible to - except the client that probably gives you requirements.
It is similar to asking: Language xyz provides comments and there is a syntax for doc-comments, but why should I use them?.
Using the semantics wisely increases the readability and thus maintainability. You are not required to use every possibility of semantics at all costs.
Using them will help you to get into the code again if you haven't looked at it for a longer time, e.g. to distinguish between the elements that encapsulate logical parts and elements that are used for styling. Especially if you use a template engine to create your code or to search for certain elements in multiple files.
Even if you are now the only one who works on the code it may happen that if the project grows that you need other people to work on the code. Or for the situation, you for some reason are not available, someone else needs to maintain your code, a good markup is essential.
Using the correct markup and additions like WAI-ARIA is not only essential for handicapped people, but also allows the browser to recognize the meaning of elements, allowing to e.g. improve the keyboard navigation. Especially in a productive environment where you need to type much, it is often faster to navigate with keyboard then using a trackpad or a mouse.