Live data from Hacker News

HTML6 Concept

html6spec.com

81–89 of 89 posts

Re: HTML6 Concept

#81
post #43

Earlier quoted context omitted.

Except WHATWG is made of many of the same members as the W3C.

WHATWG is made of a very small subset of the members of W3C. The vast majority of W3C members are not part of WHATWG.

WhatWG are still a lot more diverse than this singular person. 'HTML 6 spec dot com' is misleading.

Re: HTML6 Concept

#82
post #63

Some good ideas here but some terrible ones as well. First, is terrible. We don't need namespaces in HTML (or in XML for that matter, but that's a different story). would be sufficient. Even better, something like this: I do like the idea of not having generic 's everywhere. You can already do this with, for example, Angular. Basically, aside from the pre-defined elements (div, span, input, etc.) I want to just use w…

> We don't need namespaces in HTML (or in XML for that matter, but that's a different story). Bzzt, wrong. How would you propose we allow other document types to be embedded in HTML (like SVG)? Just hope the tag names never collide?

The HTML5 way is to use specialized HTML tags, where everything inside is treated as the other language:

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/svg

https://developer.mozilla.org/en-US/docs/Web/MathML/Element/...

Yes, this is less flexible than XML namespaces. You couldn't do something like XLinks.

Re: HTML6 Concept

#83
post #70
post #67

Namespaces in XML was the biggest mistake in XML.

Care to elaborate? Pretty much every programming language has the concept of "packages", "prefixes", or "namespaces" to logically group components, functions, etc. together. It's only natural to have the same thing in a document format that can contain heterogeneous document types...

Maybe I bring you James Clark (technical lead for XML, among others): http://blog.jclark.com/2010/01/xml-namespaces.html

Namespaces in XML is a foot shooting feature. Sure it has its uses, but still a misfeature.

Re: HTML6 Concept

#84
post #55
post #9

I simply can't imagine anyone wanting to adopt this. It seems like a lot of effort was put into the concept, and there are some great suggestions, but the added bloat goes against adopting the proposed solution.

Like XML, you can just define a default namespace at the beginning, and then you don't have to repeat it in every tag.

The spec itself should define a default namespace, and the examples should use that namespace.

Re: HTML6 Concept

#85
post #11

There's only one thing I want in my future web client, and that's to not have to use javascript. Dart, or compilation in general is not quite the savior i'm hoping for... I want to be able to write C#, or Ruby, or python, and reference it on a page, and for it to run. Gosh that would be great. I wouldn't even mind if its a very limited version of the language. Edit: confused why i'm downvoted... hmmm

Think what kind of nightmare would that be now that web browsers are on phones, tablets and microwave ovens.

This salvation throws away decades of work of thousands of people that made our web browsers and our standards. Not to mention throwing away these decades spenting getting it right.

But if you really want to go there, go ahead, there's Java applets, Flash, Silverlight, Google's NaCl and probably more.

Or, probably better, get out of the browser land and write a freaking app.

Re: HTML6 Concept

#86

This makes zero mention of shadow DOM or web components, which strikes me as somewhat ignorant on the author’s part.

This is an old site. Copyright of the site is 2012. The github repo's first commit[1] predates the first commit of Web Components' draft of Custom Elements[2] by a few months. So, I wouldn't say ignorant but that the Web is catching up to this "spec's" vision. [1] https://github.com/OscarGodson/HTML6/commit/7d58a98b30fe473d... [2] https://github.com/w3c/webcomponents/commit/c60060999073e181...

I stand corrected—thanks!

Re: HTML6 Concept

#87

I hate to shit on people's work[1] on HN because everyone else does it but I earnestly think this will get filed in the same bin as XHTML, aka "no web developer actually cares about this so no one will write it and it will die an awkward, forgotten death." HTML5 did some very important things. Mainly it wrestled back the web from plugins. Hey, remember Flash? Isn't that great! That in 2014 I can say "Remember Flash?"…

>extremely few serious pages left that depend on flash. //

I'll bet of the pages served the [vast] majority depend on flash for display of content and/or advertising.

On the other hand many _sites_ no longer rely on flash in that they offer an alternative HTML5 implementation. But, of the pages served I'd imagine that version is far less commonly presented to the site visitor. I'm thinking YouTube as an example.

http://httparchive.org/trends.php?s=Top1000&minlabel=Nov+15+... shows that in the Top 1000 (however they're judging that) the instances of flash use are down on average from 52 to 34% over the last 4 years. However the average flash amount of flash transferred and the average number of flash items on a page don't show any downward trend.

http://trends.builtwith.com/framework/Shockwave-Flash-Embed shows a different story - look at the whole internet version and they show a precipitous drop around April 2014, what caused that?

Re: HTML6 Concept

#88
post #84
post #55

Earlier quoted context omitted.

Like XML, you can just define a default namespace at the beginning, and then you don't have to repeat it in every tag.

The spec itself should define a default namespace, and the examples should use that namespace.

Filed it: https://github.com/OscarGodson/HTML6/issues/39

Re: HTML6 Concept

#89
post #54
post #47

Earlier quoted context omitted.

What's wrong with namespaces in your opinion?

Who the heck wants to type <html: before every single command? Waste of programmer's time, hard drive storage and bandwidth.

Nobody, but that's not a problem with namespaces. Just a problem that they didn't specify a default.

Treat them like namespaces aka packages aka modules in programming languages and I don't see a downside. Import what you need, allowing defaults. You're able to override terms if you really need to with stacked imports. You're able to use conflicting terms by specifying the namespace. You're able to alias namespaces to convenient short-hand. i.e.:

  
    https://blah
  
Yes writing "html:" explicitly everywhere seems pretty silly. When the domain's primary purpose is writing HTML, that should obviously be the default/root namespace.

But adding support for alternatives on top of that...? Not seeing the evil there.

Post reply on HN