What is Reddit's opinion of HTML?

Actually, closing li tags is optional, even in HTML5:

http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

> An li element's end tag may be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element.

Side note, the <i> and <b> tags are not deprecated in html5, only in (long long dead) xhtml2.

See http://www.w3.org/TR/html5/obsolete.html (which notable does not contain <i>) vs http://www.w3.org/TR/html5/text-level-semantics.html#the-i-element (which calls it out specifically as a supported tag).

They definitely do use open source libraries - especially newer companies which wanted to get up and running in a hurry. Older companies may be a bit less trusting of open source, but even the sockets code in Windows, if I recall correctly, is based on BSD sockets.

> For something as simple as an HTML parser...

HTML parsers are not simple! Especially for a crawler, they have to handle as much broken HTML as possible, and even valid HTML needs a big spec.

Because parsing websites is so central to Google's business, I would expect that they maintain their own parser, though it may have been forked from an open source one. They're more likely to use open source code for auxiliary things, where they're not going to get a competitive advantage by writing their own. For instance, Android includes SQLite for apps to store data.

The spec says DOM and Script evaluation is synchronous. If the scripts are at the bottom, the DOM above is available.

HTML5 Spec: >There are three possible modes that can be selected using these attributes. If the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If the async attribute is not present but the defer attribute is present, then the script is executed when the page has finished parsing. If neither attribute is present, then the script is fetched and executed immediately, before the user agent continues parsing the page.

HTML5Rocks: How Browsers Work (Order of Processing)

>Authors expect scripts to be parsed and executed immediately when the parser reaches a <script> tag. The parsing of the document halts until the script has been executed. If the script is external then the resource must first be fetched from the network–this is also done synchronously, and parsing halts until the resource is fetched. This was the model for many years and is also specified in HTML4 and 5 specifications.

It's actually normal ajax request combined with HTML5 history API.

The key here is history API.

It allow developer to change the URL without refreshing the page. Without it you can only change fragment that come after # if you don't want page to refresh.

More than that, it capture browser's Back/Forward event, allowing developer to implement custom action for those action. Mainly, make an ajax call.

I've used this (ajax and history API, never use PJAX library) myself in almost all the site I develop lately. My method are:

Capture internal link request, make it into ajax call and change the url accordingly.
On the server side, see if the request coming in is ajax request or not. If yes, send only page body without the template (header, footer, etc...). If not ajax call, send full page back. This make it work for old browsers without having to change a single line of code.
Do the same for browser's back/forward event.

So far it's working very well without too much effort. Only problem I encounter is, since the page was not refresh, some javascript instances remain and causing inconvenience bugs.

Like when using most of WYSIWYG textarea replacement editor, they tend to use textarea's ID with the instances, and by loading elements without refreshing page the old instances remain creating conflict with new element. This is easily fix by manually destroy the instances after page element change, but still annoying.

No, there is an official HTML5 spec developed by the W3C working group. WebGL is not in it. If anything Google/Firefox are the ones deviating from the spec. That's EXACTLY the behavior that everybody was pissed off at Microsoft for years ago - adding proprietary extensions to the standards.
Chrome and Firefox aren't following the official standard here, and don't even have a majority marketshare - why would they be the "de facto" spec for any reason whatsoever?
Anyone can write OpenGL code and run it on a variety of platforms. Microsoft has no monopoly there. Studios just use Microsoft's DirectX because frankly in most cases the tools are much easier to use and the API is better. They simply made a better product.
WebGL is a security nightmare. It literally allows you to run arbitrary shader code directly on the GPU. It's almost trivial for someone to write an ad or something with WebGL will corrupt and bluescreen every computer that visits a page, and could potentially allow malicious code injection.
Here's a link with just a few of the security problems. Sandboxing doesn't prevent them all.
WebGL also can't (with current hardware) allow anything near the performance of current D3D/OpenGL implementations when you get down to the gritty details. Just because you can hack together a page that runs a 10 year old graphics demo ago or a simple voxel renderer with some shaders on a modern high power desktop CPU doesn't mean you can build Crysis on it, or that you can build anything at all that will run well on an iPad or ARM device.

HTML is a document markup language to layout the structure of a document. The center element does nothing for document structure and is presentation only. Presentation is the domain of CSS.

It's a separation of concerns. It's not "deprecated". It's obsolete! That it's been marked as "obsolete" in HTML5 means browser vendors are also free to remove it at any time, making it break your page without notice.

Not to get too pedantic, but HTML and XML were both descendants of SGML, a markup language from the late 80s.

Strict XML adherence was added to HTML with the creation of XHTML introduced with the HTML 4 specs (I think).

Currently XHTML 5 still lives on.

http://www.w3.org/TR/html5/the-xhtml-syntax.html

In either case HTML has never been strictly XML compliant, as HTML and XHTML have different mime types and parsing semantics

Windows Forms is normally implemented with Win32 API calls. Making such calls from JavaScript code running in a browser is not permitted for security reasons, and may not even be possible if the browser is running on a non-Windows operating system.

Before you can run a Windows Forms application in a browser, therefore, you need an alternative implementation of Windows Forms itself that instead uses the browser's APIs, such as the HTML5 Canvas API, for drawing.

Pretty good, nice start.

If you want some feedback on the HTML:

You are using some deprecated HTML attributes.

Your CSS is needlessly verbose. For example you have font-family: Arial, Helvetica, sans-serif; three times whereas you only have to put it once in your body {}. Every element inherent its parent's styles unless there is another style that takes priority - that's the cascading part of CSS. I hope that makes a little sense here's more info.

Setting a height on the text input causes the text to get cut off in my browser.

It's actually by design, see Implicit submission in the HTML5 recommendation :

> If the form has no submit button, then the implicit submission mechanism must do nothing if the form has more than one field that blocks implicit submission

> [...] an element is a field that blocks implicit submission of a form element if it is an input element [...] whose type attribute is in one of the following states: Text, Search, URL, Telephone, E-mail, Password, Date, Time, Number

So if you get more than one text input, no more enter key for you

I'm sorry, but don't correct something that isn't wrong, the doctype is correct. Yours is wrong

https://developer.mozilla.org/en/HTML/HTML5/Introduction_to_HTML5/

http://www.w3.org/TR/html5-diff/#doctype

As part of both the HTML4 and HTML5 spec, there is the <map> tag, which can contain <area> tags, as defined here.

Back in the bad old days, this was a super popular technique, since it lets you cut down on HTTP requests. It fell out of fashion, but it does still get used from time to time (tagging images on Facebook uses it).

I don't know what you're doing, but no, it's not valid. If that's in the head section, you can't use divs. If it's in the body section, you can't use the rel attribute in link elements.

If it's in the head and you're trying to seperate the code into blocks to make it easier to read, just use an empty line and/or comments. If it's in the body, you'd have to explain what you're trying to do.

It's not AJAX, it's the HTML5 History API (aka pushState) that allows you to manipulate the browser's history object and push/pop history items.

AJAX is often used to load new data to present when adding a new history item, but isn't required for it and isn't used on this page.

They implemented implicit tagging. Paragraphs can only be in the body, and so when you start a paragraph, it implies the end of the head and the start of the body.

Paragraphs cannot contain other block-level elements, so as soon as any other block level element is created, the paragraph self-closes. This means you don't have to specify the end of a paragraph.

Actually paragraphs are slightly more complicated than that. Here're the details:

http://www.w3.org/TR/html5/grouping-content.html#the-p-element

W3C defines it as an obsolete tag: http://www.w3.org/TR/html5/obsolete.html#obsolete

It is also commonly identified as poor UX design. On top of that, the marquee tool is outdated and has disadvantages. If you were to try and print a page with a marquee, it would only print the current viewable text. If you were to really want a marquee, CSS animations or javascript (with a no-js fallback) would be a better solution. With CSS, you could have a print media query fallback to alleviate the issue as well.

However, it is essentially a deprecated tag that will probably eventually be removed.

Yes, there are best practices. They are outlined in the standards. Here's the latest draft of the html5 standard.

> The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts.

> The em element represents stress emphasis of its contents.

Span doesn't have any meaning by itself.

Just use the element that fits best. Neither <i> nor <em> means that the text should be italicized.

The layout contains tabular data. And tables are not deprecated. In fact, this is what they were intended for. Here is a bleeding edge reference if you're too lazy to google RTFM

I thought HTML specifications came from w3.org.

EDIT: Actually, this comment appears in W3 org's HTML5 specs as well.

> Of course you need to open them if you want a head and a body....

Nope. Those elements always exist, even without opening or closing tags. This is a perfectly valid HTML document that contains both an <html> element and a <body> element (and a <head> element, for that matter):

<!DOCTYPE html> <title>A valid HTML document</title> <p>This is a valid HTML document.

Check with a validator or read the specification if you don't believe me.

This behavior has also been added to iOS5 (the placeholder text disappeared on focus in iOS4), which leads me to think Chrome was influenced by that implementation. (Note that it's not in the latest WebKit nightly, a base they share)

Here's the spec from the W3C:

> User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string and the control is not focused (e.g. by displaying it inside a blank unfocused control).

It seems clear to me that this means this:

if(!empty && !focused)

But now iOS5/Chrome are revising the interpretation of the spec to this:

if(!empty)

I'm not denying that stripping tags might be possible, but it's certainly extremely complex. For example, HTML5 says <div id=">"> is valid (with appropriate closing tag, ofc), which would break the niave regex used in the OP.

I don't know if you're trying to be funny, or what, so I'll assume you're criticizing my response.

When you want to build a parser for any kind of language, one of the first things you want to do is understand the specs, official and unofficial, around the language. It tells you what rules and implementation challenges you will need to tackle, even if you are not sure exactly how you will accomplish that. And if there are things you don't understand, then you know what to study in preparation for writing a parser.

Second, reading the HTML 5 spec is really useful. It's much more detailed on how to parse HTML documents. See it right here.

Notice how there are these lists of steps to follow? Sounds like an algorithm to follow. Kind of convenient, huh? So maybe instead of complaining, it can be helpful to read...

So when I say read the spec, please actually try it.

They really shouldn't get it wrong because it's defined in HTML5 specification. What I understand, it's not meant to validate emails perfectly but more to be practical and stop user errors and typos.

Throw <center> into the w3c validator, you get:

> Validation Output: 1 Error > The center element is obsolete. Use CSS instead.

Not sure what your source is, but it is incorrect. Another document states:

> The elements in this section are not to be used by Web developers. User agents will still have to support them and various sections in HTML define how

Then the W3C defines obsolete as:

> An obsolete element or attribute is one for which there is no guarantee of support by a user agent. Obsolete elements are no longer defined in the specification, but are listed for historical purposes in the changes section of the reference manual

I added the bold. So if the element is not defined in the spec, and <center> is not in HTML5, it isn't a valid tag

I use an HTML5 Doctype just because it's cleaner. I don't bother with the new elements such as article and aside but I'm not averse to calling my <div>s article or aside. I use CSS3 in a backwards compatible way - I'm happy to add shadows and rounded corners but if you look at my sites in IE8 they'll still function.

Adding an extra script to use the new elements, like the default theme of Wordpress does, is too much for me, though.

Also it's not a bad idea to keep up with what's been deprecated - basic things like the <a name=""> to link with a hash tag is replaced with the much smarter id. Here's a list http://www.w3.org/TR/html5-diff/#changed-elements and deprecated elements follow.

Here's the spec, here's what it says:

> The method and formmethod content attributes are enumerated attributes with the following keywords and states: > > * The keyword get, mapping to the state GET, indicating the HTTP GET method. > * The keyword post, mapping to the state POST, indicating the HTTP POST method. > > The missing value default for these attributes is the GET state.

Is there another bit of it I'm missing?

This is wrong. <link> is a void element which:

> only have a start tag; end tags must not be specified for void elements.

And a little further down the page:

> [The '/' character] has no effect on void elements
I think he put the linked file as the JS on JSFiddle - at least the content of it makes sense for what he's trying to do.

According to the HTML5 specification for form action:

> The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces.

This means any posts recommending action="" are recommending invalid HTML5. Either omit the action attribute or make it a valid non-empty URL.

I also recommend $_SERVER["REQUEST_METHOD"] == "POST" to see if the HTML method is equal to some value. You are checking that the request method is equal to some value; what does $_SERVER["PHP_SELF"] mean? It's just not as descriptive.

>Do you know why your FORM tag has an attribute called “method”? Because you’re calling a method on a web server, like a method on an object in OOP. Did you know there are other methods besides GET and POST? There’s HEAD and OPTIONS and PUT and DELETE.

It's important to point out that the form element does NOT accept methods other than "get" and "post" in the method attribute. HTTP does, but the HTML form element doesn't. If you try to use something different, browsers will just default to "get".

> no self-closed HTML tags, such as <br />

Isn't the "br" tag always self-closed?

edit: Just checked the br element according to W3, the "br" tag doesn't have a close tag. I am used to XHTML style and always self-close the "br" tag.

The event summary section says that when the ended event fires, "currentTime equals the end of the media resource; ended is true." I believe this means that currentTime will be the last valid time for the video.

> You close a single element with no content directly in its tag, like <br/>. That explicitly shows that it's empty and you don't have to look for a close somewhere else.

That's not exactly correct. In HTML 5, the self-closing syntax is allowed only for "void elements" that can't have content anyway (br, img, etc), and "foreign elements" (<http://www.w3.org/TR/html5/syntax.html#start-tags>). You can't close a div that way, for example, and Firefox actually treats <div/> as an opening tag.

No, it won't. Or shouldn't, according to the standard:

> The href attribute on a and area elements must have a value that is a valid URL potentially surrounded by spaces.

source: w3.org

Just to provide a little more detail, this issue concerns HTML. This is from the HTML5 spec:

>The disabled content attribute is a boolean attribute.

>A number of attributes are boolean attributes. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

>If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.

>The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

Firstly, what's your source for legend being deprecated? See http://www.w3.org/TR/html5/forms.html#the-legend-element

Secondly, fieldset is nothing like form: form describes a form in its entirety, whereas fieldset defines part of a form that makes sense on its own, or, "a set of fields".

For example, a registration form may have some inputs for name, email, etc. then some fields for payment details and a few more for notification preferences. These may be defined as three fieldsets in the form so, semantically, they stand on their own as discrete sections of the broader form.

At least data- and ng- are actually emitted html, not some server directive thing.

(And I have a problem with ng- since afaik, it's not supported by html5. Only attributes with the data- prefix is guaranteed to be preserved.

http://www.w3.org/TR/html5/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

Line 32, Column 55: Bad value checkbox for attribute type on element input. <input type="checkbox" id="show-menu" role="button">

Checkboxes cannot be a button (role="button"), rather it should have role="checkbox" - http://www.marcozehe.de/2013/04/24/easy-aria-tip-6-making-clickables-accessible/ and https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_checkbox_role

And then there is no such thing as a <or> element. Regardless of how or where you define it, if it is not specified in the formal HTML specification then it is not valid

how? multiple ID attributes? you definitely ~~can't~~ shouldn't add space separated IDs onto a single ID attribute, the way you can with classes:

> The value must not contain any space characters.

http://www.w3.org/TR/html5/dom.html#the-id-attribute

Tables can contain a caption element. While the base description refers to the caption simply as being the title for the table, the example on the w3 site show it being used for a more full description.

Just sayin’ this but there are ending tags that can be omitted and quotation marks on attributes are optional in most cases and it’s 100% “valid” HTML.

Looks like others have helped solve this problem. But, it looks like you're using arcane tags and attributes (at least you didn't use <blink> ;P). It's a lengthy read, but take a look at W3 Recommendations for HTML4 for more current standards. And, for even more current HTML standards(?), see their HTML5 page. Hopefully by using current standards, your instructor won't accuse you of witchcraft and apostasy of abandoning ancient HTML standards he seems to hold dear. Hopefully instead, he'll even give you extra credit.

> It allows me to very easily add stuff in the JavaScript and have it drawn without messing around with html layout.

You can do something similar with DOM manipulation. For each button you want, rather than painting pixels onto your canvas, append an element to some container. For your color buttons, you can set the backgroundColor style property appropriately. For your size buttons you might change the size of a background image.

By drawing buttons on a canvas, you're essentially passing up using a GUI framework. It's like using OpenGL to create an interface in Java when you could just use Swing. DOM manipulation will provide you with a more consistent interface. Buttons will actually look like buttons. Standard feedback like changing color or cursor when hovered over will be there without any extra work on your part. You'll be able to easily change how things look from an external CSS file. You can add a tooltip by just setting the title attribute. You'll get keyboard accessibility for free. Users can modify things client-side through userstyles and userscripts.

If you go with a canvas, you'll have to engineer all this stuff yourself (if you want it). You'll be mixing presentation, content, and behavior together in your JS, which is yucky. If you're looking for a challenge, I guess you could do it your way :)

EDIT: There's also that handy HTML5 color input type that you would theoretically be missing out on in the future.

>using CSS selectors to select your own HTML5 attribute that isn't part of the HTML5 spec, I would expect inconsistent results.

Have some resources.

>orrr you could stop trying to be fancy and class it like the rest of us :)

This is an exercise of "can I" rather than "should I". I'm trying to gain more understanding of future specs so that I'm prepared when they're more ready for prime-time.

Thanks. In what circumstances is not encoding those a problem?

I can't see any transition in the HTML5 tokenizer spec for U+0028 or U+0029, and the only transition for U+0023 is in "&#...;" which is handled by http://www.w3.org/TR/html5/tokenization.html#tokenizing-character-references

Is the problem with my handling of CSS styles or URLs?

> when in conflict, which one should win?

In general, the rule of thumb that has got most mindshare is that the metadata closest to the data wins. In this case, that means the media type supplied by the HTTP response containing the JSON.

In this particular instance, the HTML 5 specification clearly delegates responsibility for this decision to Media Type Sniffing, which discourages sniffing:

> WARNING! Whenever possible, user agents SHOULD NOT employ a content sniffing algorithm.

It is certainly possible in this case. There doesn't seem to be any overwhelming compatibility benefit to doing so - how many developers do you think are actually serving legitimate JavaScript as application/json?

Furthermore, the actual sniffing rules defined by that document do not allow sniffing for application/json. So any way you look at it, treating application/json as executable JavaScript is wrong.

From the HTML5 Spec for boolean attributes:

> If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.

So what JQuery is doing here is correct if you consider the attribute without a value being an empty string or setting it explicitly to an empty string, both of which are valid in HTML (not XHTML, though).

In other words:

are all valid, but calling .attr("checked") will yield different values: "", "", and "checked" respectively. Technically, I believe this is correct, but I think it would be nice if they all returned "checked" for the sake of consistency. If the attribute were invalid (say, checked="blerg") I would just return the invalid value "blerg". I assume that the logic for .prop("checked") would remain the same, whatever it may be.

As I said in my original post, I don't think what they're doing is necessarily wrong and maybe it's better. It's just what I would've done, but maybe I suck. Who knows?

This is HTML5 because it uses the multiple attribute and the Drag'n Drop API (part of HTML5: http://www.w3.org/TR/html5/dnd.html) and probably some things from the File API.

And it's XMLHttpRequest Level 2.

Well, this is modern.

Just a note to chime in, while I don't use <menu> in this context (I agree it was originally intended for use in form elements, and I'd interpret it as inspired for web applications http://www.w3.org/TR/html5/interactive-elements.html#menus), it's reasonable to use ANY tag for a subjective interpretation on semantics.

For a young user, starting out, I wouldn't steer them into an interpretation debate. Teach them what the spec was for, as they get advanced (like, as it sounds, some of us here), we can wade into those waters.

And just like you said, skeww, Hixie said it was fine but he did not: "<Hixie> <menu> really is intended for drop-down menus (type=toolbar) and context menus (type=context), the list state (no type attribute) is basically only allowed for historical reasons "

But he concluded: "[03:11] <Hixie> <nav> is the important thing to have in your DOM if you have a navigation list"

This is akin to me saying it's perfectly acceptable to use span tags as a neutral design element in my code, avoiding conflicts in semantics, but that doesn't necessarily mean it's a best practice. Gray area, I agree - it's not 100% wrong, but I could also argue <footer></footer> can fly my header, and it would be open to debate as well:).

Hit me up on twitter.com/bradyjfrey if you gents would like to chat more, you can find my portfolio of sites around for interpretation and example if you'd like. Great discussion!

In your example, you can't use more than one #name. Which is fine for a single bio page for example. But if you have a list of people, you can't just use #name again, all IDs have to be unique so a #name can only be used once. So now what do you do with 100 list items that all have names that need styling? You could make each one unique, like #name1, #name2, etc like an insane person. OR you can just make all the names in that list as .name so you can just do

.name{font-weight:bold; color:red}

instead of

#name1,#name2,#name3,#name4{font-weight:bold; color:red}

I honestly have no idea how you could make a website without using classes until now? Have you just been using ID for everything?

Edit: http://www.w3.org/TR/html5/dom.html#the-id-attribute

Dude. It is 100% treated the same as a <div> element is in XHTML, as was the purpose of the compatibility for HTML5. It is semantic markup only.

You are misreading the spec. It is not the footer element within <section> or <article> it is the footer element within A section.

3.2.7.3 Strong Native Semantics of the W3C Specs for HTML5 designates that

> footer element that is not a descendant of an article or section element.

assumes a

> 'contentinfo' role

It's 'Permitted Parent Elements' are:

> Any element that can contain flow elements

<section> and <article> are flow elements and when a <footer> is inside one it represents the footer of that section, but it does not need to be inside one.

You are 100% wrong.

EDIT:

Go ahead and read the actual spec for me and pay especially close attention to the examples, particularly the one that says:

> Here is an example which shows the footer element being used both for a site-wide footer and for a section footer.

Or where it says:

> When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.

Just wanted to quote you here too:

> Stop spreading this crap.

When in doubt, always read the spec:

>The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

And you have a lot more there than just navigation links.

You may enjoy reading this six-year old article from the HTML5 Doctor

HTML for one:

>The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.

--

>There are no other restrictions on what form an ID can take; in particular, IDs can consist of just digits, start with a digit, start with an underscore, consist of just punctuation, etc.

http://www.w3.org/TR/html5/dom.html#the-id-attribute

Am I not? See http://www.w3.org/TR/html5/syntax.html#optional-tags:

> An li element's end tag may be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element.

> you will probably use divs more than any other element.

Not if you are following the spec.

http://www.w3.org/TR/html5/grouping-content.html#the-div-element > Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.

I'm not sure this is possible with CSS alone .. but should be relatively straightforward with a little bit of javascript ..

Something like: var videoElem = document.getElementById('video');

videoElem.addEventListener('play', function() { this.style.opacity = 1; });

videoElem.addEventListener('pause', function() { this.style.opacity = 0.85; });

I have not tested the above, but that should be the general idea.

See: http://www.w3.org/2010/05/video/mediaevents.html and http://www.w3.org/TR/html5/embedded-content-0.html#mediaevents

Having a pseudo-attribute in CSS like you describe seems like it may not be a bad idea, I just don't think it exists (yet) ..

http://www.w3.org/TR/html5/document-metadata.html#charset

Sorry, it's actually 1024 :p

> The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document.

Just to give some background, there is a specification for HTML (and javascript). I believe all of what you have mentioned is on the spec, meaning that chrome/webkit was quicker to implement features than say firefox/IE, but these features will be brought and are considered standard functionality of a browser.

I really don't think you can fault them for having standard features implemented.

That posts contains various flaws. The most important flaws to me are:

HTML spec states, that "method" takes an enumeration of "get" and "post" (mapping to HTTP methods GET and POST=. Of course, we (hopefully) live in a free world and can change it to whatever we like. But that would not be HTML conform.

Also the blog post states that we don't bother to logically structure URLs and even speaks of path parameters ("URL parameters" in the post). Yes, that is right. We should not enforce an URI structure onto the clients, because URIs should be opaque. Logical structure is applied by the implementation (a framework, the developer or an author). For whoever uses a resource, the logical structure should be not important. Our browsers follow this principle. And this principle is important, so we can change the endpoint implementation (which may change URIs).

And he blames us for not using response codes (404 vs 410). Well, that is just an implementation detail. If I want my clients to know that a resource is gone (or has moved), I have to provide that feature. And I do not do that if there is no benefit for the users of my resources. So the blog post's argument is a flawed generalization.

html5 doctype:

8.1.1 The DOCTYPE

A DOCTYPE is a required preamble.

DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.

A DOCTYPE must consist of the following components, in this order:

A string that is an ASCII case-insensitive match for the string "<!DOCTYPE". One or more space characters. A string that is an ASCII case-insensitive match for the string "html". Optionally, a DOCTYPE legacy string or an obsolete permitted DOCTYPE string (defined below). Zero or more space characters. A ">" (U+003E) character. In other words, <!DOCTYPE html>, case-insensitively.

from: http://www.w3.org/TR/html5/syntax.html#the-doctype

TLDR; you don't use sections for everything, div isn't obsolete or going anywhere anytime soon.

> The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.

https://html.spec.whatwg.org/multipage/semantics.html#the-section-element

http://www.w3.org/TR/html5/sections.html#the-section-element

EDIT: I believe facebook uses preprocessors for most of their code, and really wouldnt advise to review their source code as it being "done right", they do "whats right" for them and their users.

We don't really implement this ourselves; it's done by the browser since we mark the field as required. Unfortunately, Safari doesn't seem to yet support that.

I've created an entry on the issue tracker.

No worries. Glad it resolved the issue for you.

I should correct the above code noting that the 'type' attribute on MIME types is redundant in HTML5, so that should just be:

It's worth brushing up on the HTML5 spec if you're not familiar with it. It may seem a boring read now, but it will save to time and issues in the future. Plus you'll run into these things anyway if you need to validate your code.

http://www.w3.org/TR/html5-diff/

Also, it's best to place your JS before the closing body tag, not after the opening one, as shown in the example Bootstrap templates linked above.

It's defined to be purple in the HTML5 standard as a default.

Both the user (by creating a config file somewhere) and the website (by adding its own stylesheet) can override that.

Here is the precise definition of HTML5. And, no, there is no mention of JavaScript included anywhere in the specification.

HTML5 is nothing more than the newest major version of HTML.

HTML 5 players meaning browser specific implementations of the HTML5 spec.

MP4 is pretty widely supported, obvious exceptions being Opera and Chromium. Also the Firefox implementation relies on the OS or hardware since Firefox didn't license MPEG-4. Thus it's not supported (AFAIK) on Mac.

H.264+AAC/MP4 if probably the best guess if you had to pick one combination of codec/container, but there are a few edge cases. It's super annoying and everyone should just implement webm so we can just call it a day.

> Just to be clear, the seemingly malformed garbage above is 100% standards compliant. How HTML is parsed is clearly defined. As far as HTML5 compliant parsers are concerned, this is perfectly valid markup.

That doesn't appear to be true in these examples:

The HTML 5 specification states:

> > Attributes must be separated from each other by one or more space characters.

Also, checking it with the W3C validator flags the lack of a space as a syntax error.

Where did you look it up at? The specification itself clearly states "It's not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.". Exactly what your example is is a parenthetical use.

Right you are about browser tolerance, however the case here has been clearly defined and <html> start and close tags are very much optional.

w3.org regarding html4: ><!ELEMENT HTML O O (%html.content;) -- document root element -->

>Start tag: optional, End tag: optional

w3.org regarding html5

>* An html element's start tag may be omitted if the first thing inside the html element is not a comment.

>* An html element's end tag may be omitted if the html element is not immediately followed by a comment.

Content types are determined heuristically by sniffing the contents of a file for identifiable attributes, the doctype tag would be one of these but it's not necessarily going to be placed on a pedestal above any other html elements for this purpose.

Google actually omit html tags (among others) as a form of optimization.

form.elements.<name> will return a NodeList if there are multple form elements with the same name, so loop over them and get the value of the first checked one:

function getRadioValue(form, name) { var radios = form.elements[name] for (var i = 0, l = radios.length; i < l; i++) { if (radios[i].checked) { return radios[i].value } } }

Fiddle: http://jsfiddle.net/insin/L5Ksc/

At some stage, you should just be able to use .value on the resulting NodeList, but I don't know what the browser support story is on that one: http://www.w3.org/TR/html5/infrastructure.html#radionodelist

It would also be nice to use FormData here, but again: browser support.

It's nonsense. Either he doesn't know what he's talking about or you misunderstood him.

This is correct. HOWEVER

the </tr> can be omitted if "A tr element’s end tag may be omitted if the tr element is immediately followed by another tr element, or if there is no more content in the parent element." - Source W3C
This is not valid HTML5. "Tables should not be used as layout aids. Historically, many Web authors have tables in HTML as a way to control their page layout making it difficult to extract tabular data from such documents." - W3C, 5^th paragraph

Don't include the href attribute, and instead do <a>...</a>. The html4 spec explicitly states you can do this. This is reinforced in the current revision for the html5 spec.

html4: > Authors may also create an A element that specifies no anchors, i.e., that doesn't specify href, name, or id. Values for these attributes may be set at a later time through scripts.

html5: > If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents.

Video controls are in, although I suppose Mozilla adds some features, like saving a given frame to disk.

I don't know if I should be happy that browsers must provide a media player or it would be better to just provide access to codecs though.

There are new input types such as color for color pickers. Unfortunately, browsers have not been implementing this part of the spec very quickly.

>... there are a lot of closing tags that are optional in the HTML spec.

And not only closing tags, but also starting ones. Even <html> is optional, at least in HTML5 spec.

For example: this is valid HTML5 code.

HTML5#optional-tags

Bullshit.

http://www.w3.org/TR/html5/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements http://www.w3.org/TR/html4/struct/global.html#h-7.5.5

There is no mention of this in the specs. I also highly doubt your claim on SEO, but I would love for you to prove me wrong.

Exactly, is sad how often web developers forget the doctype producing inconsistent behavior, just because one single line of HTML.

http://www.w3.org/TR/html5/syntax.html#the-doctype

I'm equally amazed by the developer saying it won't work in IE in the title of the post, just like that, decreasing the target audience just for the fun of it, after all the hard work has already been done.

>Autosuggest

Uhm I hate to tell you something.

>So although it may not be the first rule, it certainly does not go against the rules.

It absolutely goes against the rules, as i mentioned the first rule is to use native elements whenever possible. Web practices ignore that in favor of slightly prettier stuff, at the cost of re-engineering the wheel.

> They do say have a say on what the standards

Here are the standards http://www.w3.org/TR/html5/. Other than the intro page to HTML, please give me an example where w3schools refers to w3c.

Let's look at W3school's page for tables vs MDN's.

Ah thanks google for using crap code <3

EDIT: Not sure why I am being downvoted. The screenshot shows it is using <font> to make the logo. Google is using HTML5 for the page. Reading the spec, <code>font</code> is an obsolete tag. So by definition, it is bad code

> html standard is being developed further

hmm, HTML5 was made official just under two years ago: http://www.w3.org/TR/html5/.

>For now there may be no real purpose

There is, but a lot of browsers have not implemented them yet.

Flash isn't in the spec, but the APIs for interoperation with flash are:

http://www.w3.org/TR/html5/embedded-content-0.html#the-embed-element

Which is the same as CDMs. Content decryption modules are not in the spec, only the APIs to communicate with them are.

> A separate document is published to document the differences between the HTML specified in this document and the language described in the HTML4 specification. HTML5-DIFF

<code>i</code> and <code>b</code> are not deprecated, they're full-fledged elements just like strong and em. They just have a different purpose.

Um. You know that computers run the internet and computers run on exact specifications, don't you? You are going off on this guy yet you say things like

>You're not supposed to use deprecated <i> tags

Where did you ever get that idea?

I was going to explain to you, in more detail, where you seem to be misunderstanding about block level elements inside paragraphs but, you made this little post, so I can see trying to introduce you to the reasons behind what /u/dhdfdh is talking about, and why he's right, won't do any good cause you just want to wing it, go on your own, and follow your dream, instead of following what the browser vendors wrote down in the specifications as to how their browsers work.

In case you need a list of who wrote those specifications, the editors are:

Ian Hickson, Google, Inc.
Robin Berjon, W3C
Steve Faulkner, The Paciello Group
Travis Leithead, Microsoft Corporation
Erika Doyle Navara, Microsoft Corporation
Edward O'Connor, Apple Inc.
Silvia Pfeiffer

along with help from Mozilla, Opera and about 200 other member companies.

Apparently, you think you know better they they. Good luck with that.

Show a browser a <ul>, it'll expect to find it populated with <li> elements. Throwing anything else in there as a child might work for you, but it will most likely cause trouble down the line. You should read up some, it's worthwhile.

http://www.w3.org/TR/html5/grouping-content.html#the-ul-element

The end tag is optional. To quote the spec:

> A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element.

Hmm... I glanced at them and I'm stumped as to why it behaves differently on jsfiddle than it does on codepen...

I made a simple version of what you're doing to troubleshoot the href attribute issue (http://codepen.io/anon/pen/GpxzLo) and I'm guessing it's breaking because "href" isn't a required attribute of an <a> tag, but if it's defined it must have a valid URL - http://www.w3.org/TR/html5/links.html#hyperlink. If you leave href off, the animation works. But if you have an empty href attribute, the animation doesn't work.

There are three "row grouping" elements that can contain rows:

<thead>
<tbody>
<tfoot>

All of your <tr> must go into one of those three elements.

however, if you don't want to declare a <tbody>, you don't have to. The browser will make one for you. And that's the problem that you're having.

So, change your ruleset to:

/all table rows/ .ordrehistorikk tr { border-bottom: 1px solid black; }

or

/only table rows in the tbody/ .ordrehistorikk tbody tr { border-bottom: 1px solid black; }

What is Reddit's opinion of HTML?
From 3.5 billion Reddit comments

➔ HTML website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

EDIT:

What is Reddit's opinion of HTML? From 3.5 billion Reddit comments

➔ HTML website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

EDIT:

What is Reddit's opinion of HTML?
From 3.5 billion Reddit comments