Nowadays, we can use HTML5 to make apps, as in android, in firefox os, iPhone, Blackberry and others. But, I heard that HTML is a Markup language, not for programming.
Even with App features, HTML continues to being only a markup language?
Programming languages have certain features, like branching, looping, that sort of thing, that HTML5 lacks. HTML5 defines markup for some interactive features, but the markup is almost entirely static (there's some interaction implied in the definition of select elements and such). A lot of "HTML5" features you hear about aren't HTML5 at all, but rather things you can do with JavaScript (a programming language) in a modestly-capable browser.
HTML5 is increasingly taking over (or has taken over) the role of defining both the structure of web pages and the API to interacting with them from a programming language. That used to be quite separate, in the DOM specs, but a lot of that is now being folded into the HTML5 specification. But again, that's just defining APIs. The actual coding using those APIs requires (in almost all cases) an actual programming language.
Short Answer: No.
Long Answer: No, it isn't. HTML as defined by the standard is just a markup language, exactly as it was in its previous versions.
But what does that mean? It means that it is supposed to structure your data allowing you also to define semantics with the use of markers, but it cannot process or modify your data as you would do using a programming language. Also it has no concept of input or output as is the case in programming languages​​, where you get an input to analyze and produce an output.
By the way HTML5 is coming out alongside a wider interest for the web and also stronger technologies (such as newer versions of javascript and css) which make new web applications even more powerful and limitless.
Please, read this great resource to learn more about HTML5.
HTML5 is considered a technology.
Yes, there is 5th release of HTML markup language but probably you didn't mean that.
HTML5 is more considered to be a technology including HTML,CSS3 and javascript and most of all their support in tools like browsers. So as a matter of fact it can be considered as something that requires programming.
Programming do not means Turing Complete Language. It's a linguistic problem, programing means to plan something, and this Html does very well.
program (n.)
1630s, "public notice," from Late Latin programma "proclamation, edict," from Greek programma "a written public notice," from stem of prographein "to write publicly," from pro "forth" (see pro-) + graphein "to write" (see -graphy).
The meaning "written or printed list of pieces at a concert, playbill" is recorded by 1805 and retains the original sense. The sense of "broadcasting presentation" is from 1923.
The general sense of "a definite plan or scheme, method of operation or line of procedure prepared or announced beforehand" is recorded from 1837. The computer sense of "series of coded instructions which directs a computer in carrying out a specific task: is from 1945.
The sense of "objects or events suggested by music" is from 1854 (program music is attested by 1877). Spelling programme, established in Britain, is from French in modern use and began to be used early 19c., originally especially in the "playbill" sense.
source
Related
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.
I am creating an article about programming. If I am using C#, for example, I am a C# programmer and I am programming using C#. How about HTML? If HTML is not a programming language, and it is a markup language, what is the correct verb applicable to a person coding in HTML? Is it just coding?
Edit 2:
Wow, apparently you can call HTML/CSS a programming language because HTML5/CCS3 is Turing-Complete by by accident (for first link, check comments).
Main Answer:
"How about HTML?" I take the stance that to be programming, the language has to be Turing Complete. So in my definition you can't be a Regex programmer. The more lean definition is that it needs variables & control statements, as simple as having an 'if' and a 'branch' instruction. So as you point out, pure HTML is not a programming language. But HTML in the real world isn't just html text files!
I would call an HTML user a HTML Techonologist or HTML author but if someone said they were a HTML coder or even a programmer, I wouldn't bat an eye or try to correct them. I don't think many people write plain HTML and the moment one adds Javascript or allows pages to be generated by PHP, python, or anything else it crosses the programming language definition. (edit 2: The moment you add CSS3 it becomes Turing Complete and thus a 'real' programming language)
Edit 1:
I like an answer I found about why 'real programmers' are so defensive over reminding people HTML/CSS is not 'real programming'. The OP's question dealt with what to call HTML authors but this question comes up because 'real programmers' are so firm in making a distinction between their work. I like this quote from Kramli (linked before)
There are times when the difference between programming languages and other languages really does matter. Quite often, however, we can all communicate perfectly effectively when just lump them all in together.
You have three questions...
Q1: I am a C# programmer and I am programming using C#. How about HTML?
A1: I am coding in HTML
Q2: If HTML is not a programming language, and it is a markup
language, what is the correct verb applicable to a person coding in
HTML?
A2: Verb = Coding, But I think you are looking for the term Coder
Q3: Is it just coding?
A3: Yes
HTML is a markup language, hence the name HyperText Markup Language.
You are effectively the modern day equivalent of a typesetter in the print industry.
If you have minimal input in the page creation process then you're probably a Coder, however if you have significant input into page layout, then the job role is normally referred to as being a Web Designer. If you're writing lots of scripts (in say PHP, Python, Ruby, Perl or whatever your least worst option is) to produce the pages in a reasonably professional manner, then you can award yourself the wonderful title of Web Developer :-)
If you devote some thought as to how all these scripts are going to hang together, and how users are going to interact with your site, then you can claim to be an Analyst. :-)
In the Internet, job roles are quite fuzzy; personally I consider myself a mix of all of the above, concentrated more on the Developer/Analyst side as whilst I understand the technical aspects of HTML and CSS, I don't have the appreciation of good design and presentation to fully claim being a Designer in a professional context.
I also suggest you read the answers to the related questions on the right of this page...
As with any language - be it musical, programmatic, mathematical,hyper text or anything in between - as a content creator you are a writer.
Specifically for a mark up language (such as HTML) you are annotating a document with tags that are separate entities from the text between them, and so could be considered an Editor, Author, or Designer because you are generally directing the content of a page.
Differences arise with HTML compared to writing technical documents using, for example, DITA. Where as a DITA document has its architecture and tags, it does not necessarily require a style sheet to be displayed. HTML on the other hand is normally consumed through a web browser so requires CSS transformation to be shown in a readable fashion. For this reason, formatting becomes as important as content and people writing HTML and CSS as a combination are referred to as Web Designers.
If you begin throwing in programming languages such as PHP or JScript you will be referred to as a Web Developer, but developer and designer are often interchangeable between the two options.
what is the correct verb applicable to a person coding in HTML?
coding is a process that involves using programming language. since HTML is not a programming language you can use writing instead of coding. as simple as that.
No, HTML is not a programming language. The "M" stands for "Markup". Generally, a programming language allows you to describe some sort of process of doing something, whereas HTML is a way of adding context and structure to text.
If you're looking to add more alphabet soup to your CV, don't classify them at all. Just put them in a big pile called "Technologies" or whatever you like. Remember, however, that anything you list is fair game for a question.
HTML is so common that I'd expect almost any technology person to already know it (although not stuff like CSS and so on), so you might consider not listing every initialism you've ever come across. I tend to regard CVs listing too many things as suspicious, so I ask more questions to weed out the stuff that shouldn't be listed. :)
However, if your HTML experience includes serious web design stuff including Ajax, JavaScript, and so on, you might talk about those in your "Experience" section.
Everyone is now talking about HTML5, i dont really understand what is the difference between it and the normal .xhtml
could you please solve some of my doubts:
What are the differences?
What are the advantages and disadvantages?
Is HTML5 considered a markup language or an scripting language?
What are the differences?
HTML 5 is just the next version of HTML. It takes HTML 4 and adds more stuff to it (while throwing out a few bits that shouldn't be used and changes the rules on how to parse it (to what browsers have been doing for the last decade anyway)).
What are the advantages and disadvantages?
It lets you do more stuff.
It doesn't have any disadvantages (other than that the new stuff isn't well supported yet).
Is HTML5 considered a markup language or an scripting language?
It is a markup language with a bunch of DOM APIs.
I guess the confusion is that HTML4 and HTML5 don't do much (on their own). You need javascript and css and that is when the party really starts.
When people are talking about HTML5 I guess they are talking about HTML5+ CSS3 + Javascript (compared to HTML4 + CSS2 + Javascript).
For a good example of the adventures you can have in the new world check this out:
http://slides.html5rocks.com/
Remember this isn't using .NET or PHP or any thing, its "just" HTML5 + javascript + css
pro
fancy new options
more elements to better define your content
video without flash
con
not supported by all browsers
Not a lot of good quality docs available (yet)
And it is still a markup language as it has no dynamic elements in it that are scriptable.
basically html5 is just like html, with some extra tags added,
like the canvas element for drawing, the video and audio elements for media playback, some new content specific elements, like article, footer, header, nav, section. it has also better support for local offline storage. and also some new form controls, like calendar, date, time, email, url and search
So actually not much you couldn't do earlier with some JavaScript (or jquery, as some people like to call it now :p), but it's designed to make those (nowadays) common tasks a lot easier
What are the differences?
See HTML5 differences from HTML4
What are the advantages and disadvantages?
That's going to depend to a certain extent on what you're trying to achieve, but it might help to understand the rationale behind the spec. Basically, backwards compatibility is one of the main goals so, if you avoid using any of the new features like video or canvas, there should be no disadvantages over the previous standards.
Is HTML5 considered a markup language or an scripting language?
From the WHATWG FAQ:
HTML5 is a new version of HTML4,
XHTML1, and DOM Level 2 HTML
addressing many of the issues of those
specifications while at the same time
enhancing (X)HTML to more adequately
address Web applications. Besides
defining a markup language that can be
written in both HTML and XML (XHTML)
it also defines many APIs that form
the basis of the Web architecture.
Some of these APIs were known as "DOM
Level 0" and were never documented
before. Yet they are extremely
important for browser vendors to
support existing Web content and for
authors to be able to build Web
applications.
I'm looking into HTML5 and I'm puzzled why it goes so easy on well-formedness.
<div id="main">
<DIV ID="main">
<DIV id=main>
are all valid and produce the same result. I thought with XHTML we moved to XML compliant code at no cost (I don't count closing tags as a cost!). Now the HTML5 spec looks to be written by lazy coders and/or anarchists. The result is that from the start of HTML5 we have two versions: HTML5 and the XML compliant XHTML5. Would you consider it an asset if C would suddenly allow you to write a for construct in the following ways?
for(i = 0; i < 10; i++) {
for(i = o; i < 1o; i++) { // you can use "o" instead of "0"
for(i = 0, i < 10, i++) { // commas instead of semicolons are alright!
Frankly, as an XHTML coder since many moons I feel a bit insulted by the HTML5 spec.
Wadya think?
Steven
edit:
Mind the "wadya": would you as a customer accept a letter with "wadya" written instead of "What do you"? :-)
HTML 5 is not an XML dialect like XHTML is.
What made HTML so popular was the fact that it tolerated mistakes, so just about anyone could write an HTML page.
XHTML made it much more difficult and it didn't get widely adopted. At the same time, further development of HTML/XHTML stagnated, so an industry group formed up, the WHATWG who started work on the next generation of HTML and decided to revert to a non XML standard for HTML 5.
Since XML is stricter than HTML, you can always write your HTML to be XML compliant. Make sure attributes are in lower case, use value delimiters, elements have closing tags and use correct XML escaping where needed.
HTML was never intended to convey media, and therefore never intended
for any kind of marketing or merchandising. HTML was only intended to
convey text and to provide some sort of descriptive structure upon the
text it was describing. The people originally using HTML professors and
scientists who needed the ability to describe their communications in
more depth and line breaks and quotes would allow. In other words HTML
was only intended to be a document storage mechanism. Keep in mind
there were no web browsers at this time.
HTML was first made popular with the release of the web browsers.
Initially web browsers were just text parsers that provided a handy GUI
for navigating the hyperlinking between documents, but this changed
almost immediately. At this time there was still no actual standard for
HTML. There was the list of tags and a description of mechanisms
initially created for HTML, which along with an understand of SGML, was
all that was required to create an HTML parser.
With web browsers came the immediate demand to extend HTML in ways HTML
never intended. It was at this point that the inventors and original
users completely lost control of the web. Tags were added, such as
center and font, and tables became the primary mechanism for laying
things out on a page instead of describing data. Web browsers supplied
a media demand completely orthogonal to the intentions of HTML.
Marketing people, being what they are, care very much for the appearance
and expressive nature of communications and don't give a crap for the
technology which makes such communication possible. As a result parsers
became more lax to accommodate the incompetent. You have to understand
that HTML was already lax because there were no standard parsing rules
and SGML, due to being so very obtuse, encourages a lax nature outside
of parsing instruction tags.
Its not that these early technology pioneers were stupid, although its
easy to argue the contrary, they simply had other priorities. When the
web went mainstream there was an immediate obsession to conquer specific
business niches in this new medium. All costs were driven towards
marketing, market share, traffic acquisition, and brand awareness. Many
web businesses operate today with similar agendas, but today's web is
not a fair comparison. In the 90s marketing was all that mattered and
technology costs were absolutely ignored. The problem was so widespread
and the surge of investment so grand that it completely defied all
rational rules of economics. This is why there was an implosion. The
only web businesses that survived this crash were those that confronted
their technology costs up front or those who channeled investment monies
into technology expenses opposed to additional marketing expense.
http://en.wikipedia.org/wiki/Dot-com_bubble
After the crash things changed. Consider the crash good timing, because
although it was entirely driven by bad business decisions, foolish
investments, and irrational economics there was positive technology
developments going on behind the scenes. The founders of the web were
completely aware that they had lost all control of their technology.
They sought to solve this problem and set things straight by creating
the World Wide Web Consortium (W3C). They invited experts and software
companies to participate. Although solving many of the technology
problems introduced to the web by marketing drivin motivations was a
lost cause many future problems could be avoided if the language were
implemented in accordance with an agreed upon standard. It was during
this time that HTML 2 (the first standard form of HTML), HTML 3, and
HTML 4 were written.
At the same time the W3C also began work on XML, which never intended to
be a HTML replacement. XML was created because SGML was too complex. A
simple syntax based upon similar rules was needed. XML was immediately
written off by marketing people and was immediately praised by data
evangalists at Microsoft and IBM. Because the holy wars around XML were
trivial, insignificant, and short lived compared to such problems
plaguing HTML XML's developement occurred at rocket speed. Almost
immediately after XML was formed the first version of XML Schema was
formed.
XML Schema was an extradinary work that most people either choose to
ignore or take for granted. An abstration model for accessing the
structure of HTML was also standardized based upon XML Schema, know as
the Document Object Model (DOM). It is important to note that the DOM
was initially developed by browser vendors to provide an API for
JavaScript to access HTML, but the standard DOM released by the W3C had
nothing to do with JavaScript directly.It quickly became obvious that
many of technology problems plaguing HTML could be solved by creating an
XML compliant form of HTML. This is called XHTML. Unfortunately, the
path of adoption from HTML to XHTML was introduced in a confused manner
that is still not widely understood years after clarification finally
occurred.
So, there was a crash and leading up to this period of economic collapse
there were some fantastic technology developments. The ultimate source
of technology corruption, the web browsers, were finally just starting
to innovate around adoption of the many fantastic technology solutions
dreamed up at the W3C, but with the crash came an almost complete loss
of development motivation from the browser vendors. At this time there
was only really Netscape, IE, and Opera. Opera was not free software,
so it was never widely adopted, and Netscape went under. This
essentially left only IE and Microsoft pulled all their developers off
IE. Years later development on IE would be revived when competition
arose from Firefox and when Opera adopted free licensing.
About the same time that browsers were coming back to life the W3C was
moving forward with development of XHTML2. XHTML2 was an ambitious
project and was not related to XHTML1, which created much confusion.
The W3C was attempting to solve technology problems associated with HTML
that had been allowed to fester for long and their intentions were valid
and solid. Unfortunately, there was some contention in the XHTML2
working group. The combination of failed communication on how and why
to transition from HTML to XHTML in combination with the unrelated
nature of XHTML2 and its infighting made people worry.
The marketing interference that allowed the web to crash regressed with
the web crash, but it did not die. It was reviving during this period
as well. Let's not forget that marketing motivations give dick about
technology concerns. Marketing motivations are about instant
gratification. All flavors of XHTML, especially XHTML2, were an
abomination to instant gratification. XHTML2 would eventually be killed
for a single draft was published. This fear and disgust lead to the
establishment of separate standards body whose interests were aligned
with moving HTML forward in the nature of instant gratification
silliness. This new group would call itself WHATWG and would carry the
marketing torch forward.
The WHATWG was united, because their motivations were simple even if
their visions of the technology were ambitious, essentially to make it
easier for developers to make things pretty, interactive, and reduce
complexity around media integration. The WHATWG was also successful,
because the web began to contract since the crash. There were fewer
major players around and each had a specific set of priorities that were
more and more inalignment.
The web is a media channel and its primary business is advertising.
Web businesses that make money from advertising tend to be significantly
larger than web businesses that make money from goods or services. As a
result the priorties of the web would eventually become the priorities
of media and advertising distribution. For instance why did JavaScript
become much faster in the browser? The answer is because Google, an
advertising company, made it a priority to release a web browser that
was significantly faster at processing JavaScript. To compete other
browsers would need to become 20 to 30 times faster to keep up. This is
important because JavaScript is the primary means by which advertisement
metrics are measured, which is the basis of Google's revenue.
Since HTML5 is a marketing friendly specification it allows a lax
syntax. Browser vendors are economically justified to spend more money
writing more complex parsing mechanisms against sloppy markup, because
it allows more rapid developement by which media is published so as to
allow deeper penetration of advertising. This is economically qualified
because all of the 5 major web browsers available now are primarily
funded from advertising revenue. Unfortunately, this is nothing but
cost for anybody else that want's to write a parser and is limiting or
harmful to any later interpretation of structured data. The result is
a lack of regard for the technology and the rise of hidden costs with
limits upon technology innovation within the given medium.
This is why HTML syntax continues to be shit. The only solution is to
propose an alternate and technologically superior communication medium
that technologically emphasizes a decentralization of contracting market
concerns.
For natural parsing the quotes aren't necessary in the first place.
Regarding case, HTML elements are reserved regardless of case; for example, you can't define your own DiV or Div.
HTML is a markup language where speed and simplicity is a greater priority than consistency.
While arguable, this matters greatly to search engines; documents with quoted attributes and any kind of error are very expensive to process. It's funny -- the quoted example in HTML docs has 'be evil' in quotes; as to say that, not using quotes is not being evil.
Better that the spec allows it then it forbids it, everyone does it anyway, and browsers have to error correct.
XHTML never really took off, not least because MSIE never supported it (pretending it is HTML by sending a text/html content type not withstanding).
Honestly, your question answers itself. "We have two different specs." Each spec addresses a different level of conformance, and they do so for a reason. As much as we might loathe the notion of "backwards compatibility," it's a burden we have to bear, and HTML5 is far better at maintaining it than XHTML5 will ever be.
I was reading O'Reilly's Learning XML Book and read the following
HTML was in some ways a step backward.
To achieve the simplicity necessary to
be truly useful, some principles of
generic coding had to be sacrificed.
... To return to the ideals of
generic coding, some people tried to
adapt SGML for the web ... This proved
too difficult.
This reminded me of a StackOverflow Podcast where they discussed the poorly formed HTML that works on browsers.
My question is, would the Internet still be as successful if the standards were as strict as developers would want them to be now?
Lack of standard enforcement didn't hurt the adoption of the web in the slightest. If anything, it helped it. The web was originally designed for scientists (who generally have little patience for programming) to post research results. So liberal parsers allowed them to not care about the markup - good enough was good enough.
If it hadn't been successful with scientists, it never would have migrated to the rest of academia, nor from there to the wider world, and it would still today be an academic exercise.
But now that it's out in the wider world, should we clamp down? I see no incentive for anyone to do so. Browser makers want market share, and they don't get it by being pissy about which pages they display properly. Content sites want to reach people, and they don't do that by only appearing correctly in Opera. The developer lobby, such as it is, is not enough.
Besides, one of the reasons front-end developers can charge a lot of money (vs. visual designers) is because they know the ins and outs of the various browsers. If there's only one right way, then it can be done automatically, and there's no longer a need for those folks - well, not at programmer salaries, anyway.
Most of the ambiguity and inconsistency on the web today isn't from things like unclosed tags - it's from CSS semantics being inconsistent from one browser to the next. Even if all web pages were miraculously well-formed XML, it wouldn't help much.
The fact that html simply "marks up" text and is not a language with operators, loops, functions and other common programming language elements is what allows it to be loosely interpreted.
One could correlate this loose interpretation as making the markup language more accessible and easily used thus allowing more "uneducated" people access to the language.
My personal opinion is that this has little to do with the success of the Internet. Instead, it's the ability to communicate and share information that make the internet "successful."
It hurt the Internet big time.
I recall listening to a podcast interview with someone who worked on the HTML 2.0 spec and IIRC there was a big debate at the time surrounding the strictness of parsers adhering to the standard.
The winners of the argument used the "a well implemented system should be liberal in what it accepts and strict in what it outputs" approach which was popular at the time.
AFAICT many people now regard this approach as overly simplistic - it sounds good in principle, but actually rarely works in practice.
IMO, even if HTML was super strict from the outset, it would still have been simple enough for most people to grasp. Uptake might have been marginally slower at the outset, but a huge amount of time/money (billions of dollars) would have been saved in the medium-long term.
There is a principle that describes how HTML and web browsers are able to work and interoperate with any success at all:
Be liberal in what you accept, and conservative in what you output.
There needs to be some latitude between what is "correct" and "acceptable" HTML. Because HTML was designed to be "human +rw", we shouldn't be surprised that there are so many flavours of tag soup. Flexibility is HTML's strength wherever humans need to be involved.
However, that flexibility adds processing overhead which can be hard to justify when you need to create something for machine consumption. This is the reason for XHTML and XML: it takes away some of that flexibility in exchange for predictable input.
If HTML had been more strict, something easier would have generated the needed network effect for the internet to become mainstream.