Live data from Hacker News

HTML6 Concept

html6spec.com

51–60 of 89 posts

Re: HTML6 Concept

#52

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 might need namespaces for webcomponents purposes probably

Re: HTML6 Concept

#53

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…

You just gave the exact definition of web components!

https://www.polymer-project.org/platform/custom-elements.htm...

Re: HTML6 Concept

#54
post #47

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…

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.

Re: HTML6 Concept

#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.

Re: HTML6 Concept

#57
It seems like there's some conflicting messages in this. At first, the author suggests that getting rid of an attribute and using the tag name is better. But then they immediately suggest the opposite for , , , etc.

Re: HTML6 Concept

#59
On the issue tracker (https://github.com/OscarGodson/HTML6/issues/17#issuecomment-...), it's stated that this "HTML6" is meant for developing applications, not marking up documents. Which strikes me as odd, because he is pushing for semantics but is not targetting the one usage of HTML where it would make sense: Documents.

In apps, I care little about semantics. div-soup all the way, why not? Using non-standard attributes? Sure! As long as the browser behaves as an application platform and only my app has to understand the markup, then doing all this is fine [to me].

But for documents, it's a different thing. I want those to be as accessible as possible. This is the place to use semantic markup. I want to use and similar things because I want search engines to understand my document. But "HTML6" is not meant for this?

So... I can see where the author wanted to go with this, but it just doesn't make sense to me.

Re: HTML6 Concept

#60
post #7

I think the title (and domain name) are a bit misleading: that's not HTML6, because it doesn't appear to be endorsed by anything related to the web standards (Mozilla, W3C, etc). That's MyHTML, sure, but not really HTML6. Funnily enough, at a first glance it looked like a real proposal, then I looked again and it appeared as a joke (I mean ... and are a bit satirical), and then I looked the repo and there's enough is…

I for one was neither mislead by this post nor did I take it as a joke.

I agree with lmm's comment, and clarify a tacit assumption that you're implying: that these ideas are somehow less valid because they aren't associated with a standards body.

It's true you never outright claim that, but you accuse the author first of being misleading, and then of making a joke. In fact this is (clearly) a real, heartfelt attempt to articulate the path one person wants HTML to move in, and I object strongly to any rhetoric that seeks to invalidate this persons views.

Post reply on HN