Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
This is a question I was wondering about for some time now, but couldn't quite find what I looked for on google.
What I'm wondering is, has there been any competitive markup language to X/HTML, that was essentially supposed to do the same job as HTML, but:
is rendered directly (without actually being compiled down to x/html)
is not just using a borrowed HTML-alike syntax (yes, I'm aware of SGML, which is widely known as the precursor of modern HTML)
The other thing is, I can see why HTML is popular: Its syntax is very easy to learn, no (overly awful) hidden black magic, it's a straight away markup language that does exactly what it says on the tin.
When people think of markup languages, they usually think of HTML. Markdown is compiled to HTML, so is every wiki syntax semi-language. But there has got to be someone (or some company) who had a similar idea, and thusly tried to create a markup language that would fulfill similar, if not the same requirements.
I find it kind of hard to believe that there has never been any competitive markup language. Or has there really never been any?
1) TeX
2) http://en.wikipedia.org/wiki/List_of_document_markup_languages
Well, there’s Rich Text Format which, although as far as I know never developed to be written by hand, nevertheless is human readable:
{\rtf1\ansi{\fonttbl\f0\fswiss Helvetica;}\f0\pard
This is some {\b bold} text.\par
}
On the other hand, there’s PostScript which, while also being a Turing-complete programming language, is used to mark up documents.
%!PS
/Courier % name the desired font
20 selectfont % choose the size in points and establish
% the font as the current one
72 500 moveto % position the current point at
% coordinates 72, 500 (the origin is at the
% lower-left corner of the page)
(Hello world!) show % stroke the text in parentheses
showpage % print all on the page
I’m sure there are more languages in the same vein. Looking for related articles on Wikipedia, InterPress comes up, for instance.
You might find http://www.w3.org/MarkUp/historical interesting.
There are loads of other document formats and markup languages but they don't really compete directly with HTML as such. Any potential competitor would have to overcome the fact that HTML (+CSS+JS) has become a sort of "universal language for everything" (i.e. it runs on everything, everywhere).
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.
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 last year.
Improve this question
When creating close buttons, usually for a card of some sort, I often find the need for some visual symbol resembling the cross/multiplication symbol we all associate with closing things.
In most cases, I find myself preferring to use the HTML entity.
×
But I've seen use of the "regular" x key on a traditional EN keyboard. As well as SVGs like those available at Feather and Hero Icons, so on.
What I would like to ask is whether there is a recommended option amongst these, and why? And if not, which option is most widely supported and/or most performant?
Thanks
Some background below, not necessary to read:
The Entity felt the best bet for me, for a while. I was a fan of having to load or package one less asset into my app, however small, if I had the opportunity. This and, I'd assumed that what is the "x" key on my keyboard might mean different things and be different codes to different encoders across the wider world. ×(;) will only ever be ×(;). That's my hope anyways. That said, I've noticed some issues with what appears to be irremovable padding of that entity; whitespace above and below the character which grows rather large as the font size increases. As a result CSS cursor effects fire prematurely, at a point where the cursor is significantly (visibly) far from the symbol proper. That and the inability to adjust the equivalent of the 'stroke-width' property for that symbol have me wondering if these newfangled SVGs, and all the unique features they bring, might be the best choice here regardless. `
Based on my experience (as this seems like an opinionated topic), I don't think there is a recommended best practice. In the beginning, to achieve a working state, I would use a capital X since it's universally supported. Later on, the use of a SVG would be a good option primarily because SVGs are easily scaled for any device and are supported practically universally.
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.
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 9 years ago.
Improve this question
Is anyone familiar with (traditional Western) musical notation code for HTML?
I am interested in (I guess) markup code being used in a standard capacity ("work in progress" or "de facto" would be ok) in HTML or XHTML, perhaps in the web. The closer to the actual semantics, the better: that is markup alphanumeric writing of musical notes (A, B, C...) that renders in the traditional way as a stave and the musical notes and marks over it, and perhaps some lettering below in songs.
I am aware that music notation characters have already been encoded and that there is some work being done in "Music Markup Language" in XML.
But when I have inspected the code for musical scores in webpages (and even epub files), all there was in them were linked images. It would help me just inspecting the code in webpages that used a semantic approach: I have been unable to locate any. It seems a bit odd that such an old and widespread notation system has not found its way in HTML.
(I am not a musician, that is a sort of research for a relative of mine who is herself a musician.)
EDIT TO MAKE IT MORE PRECISE:
The industry standard in (Western traditional notation for) music writing and editing seem to be Finale and Sibelius. Musescore is a well known open source alternative, and all of them are compatible by adhering to Music XML.
To narrow down, I would be interested in existing software:
-usable in an HTML or XHTML environment
-that displays in good quality scalable traditional music writing
-that is standards based (to avoid proprietary software to process the code)
-that uses a code notation that is as platform-free as possible to be compatible with major (Western) music editors (eg, Music XML)
One idea would be to produce a notebook containing several musical pieces (scores) for personal use in mobile devices, that can be read and used by musicians; an individual piece should be able to be exported (through a semantic code) for sharing with others [who might be interested in making their own modifications/arrangements]. I would like it to be HTML-based to achieve total platform independence.
The best solution, I have been able to device is having the (1) Music XML code, (2) using a music editor to import it, (3) produce SVG, (4) insert the SVG within an HTML/XHTML framework. The code and the SVG require to be linked in some manner (though a db or a link within the document).
This is perhaps too specific, I would be interested in any experience or idea to accomplish tha HTML epub notebook.
http://vexflow.com/ looks nice and plays with HTML5 well, otherwise you can check out http://www.alphatab.net/
These sorts of things output images or canvas elements, not actual markup, since musical notation doesn't fit the 'block' style of HTML well.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So as the title suggests, im interested / curious about how much does HTML 5 outlining help boost SEO in general.
there are alot of tutorials and explanations as to what HTML5 will do for XYZ, and alot of how-tos but for some of the pluses that HTML5 currently(and future) brings, there isn't a clear mention(that i know of) as to how much better it will/or curently make things.
I work in a...normal team i guess in where we have dedicated graphic designers, coders, programmers etc and part of this team of course are the SEO guys.
Now MANY websites show (under the document outline tool) that many designers/developers are using HTML5 but when you look at their document outline, its all over the place and even have unnamed sections in their outlines.
my guess is that, theyre just using the regular DOC type of HTML <!DOCTYPE HTML> and rolling with it instead of typing the long/massive doctype and everything therein etc...
but that said, and as oppose to the regular "old" rules and debates of H1 tags etc...
Since many of HTML5s features are already in play, and most current browsers supporting them(at diff levels), does it hurt when having a semi messed up, unnamed sections in your outline hurt?
Overall, if i convert my page from html of old to new HTML5 standards and proper outlining etc, will it make my standings better?
in a simple question, FOR EXAMPLE, if my current page rankings are say 5/100 on google,
will implementing a better, newer doc outline with HTML5 bring me higher, say 3/100 or even 1/100.
You are under the wrongful impression that formatting of the code, or use of standards has something to do with how search engines rank your page. This isn't actually the case.
What does happen with semantic tags/classes/ids, validating documents, and standards compliant markup is make it a lot easier for search engines interpret the page properly.
The content, at which levels / order and importance (say with the header tags) mark how relevant it is, and a properly formed document only helps in recognizing the different sections, but has no inherent effect on how well its ranked.
In the end though SEO is slightly guessing how smart the search engine algorithms are, one might for instance assume that Google has some sort of consideration of grading an HTML4 markup page vs HTML5. Since HTML5 is more recent, it's likely to get some leverage over HTML4 markup since HTML4 is outdated.
There is no boost from using HTML5. Semantic markup helps SEO but the version you use, or format (as in microformats) does not. It's the content that gets ranked, not your markup.
I'm not sure what outlining means. Do you intent to verify that your document doesn't have untitled sections like in this article?
Which is your question:
Does Google like HTML5 more than other HTML's?
Does Google like valid HTML5 more than other valid HTML's that don't have valid HTML5 structre (i.e. messy or untitled sections)?
This is just my gut feeling but I'm guessing it doesn't matter what HTML you use. This article indicates code validity is not an issue in page ranking. Here it says Doctype isn't even registered by Google. (Just a couple of links, don't know how realiable they are.) It makes sense thought. PageRank algorithm can't really (again just my gut feeling) be so simple that would put a lot of weight on the validity of code or the used HTML language. Unique content, locality, links to other quelity sites etc. are far more important then few missing title tags or the fact source code is written using the latest HTML specification. Where would it end? Should PHP pages rank better than "pure" HTML. Is JavaScript an boosting factor or not? What JS library would be the most important one?
Sorry if I'm splitting hairs but used technology shouldn't matter, content should. (Don't really know if only content should matter thought...)