oscargodson / html6

A spec to HTML6

Hey @nat 👋

html6's Issues

JavaScript

What about inline JS? In the documentation there is no mention of it. I think that <js:script> or <js:inline> would be good. And what about importing scripts in the html:body? There is a hole in the docs.

[idea html6] CSS redesign

In the past, I've considered the purpose of CSS heavily. I love what it can do, but what if CSS was incorporated into HTML as if it were a template instead of something alien as the term style implies. The terms template and style(sheet) could become synonyms of sorts.

Bear in mind as you read this, media queries is an issue Oscar and I have been discussing.

Example (external html6 reference): <html:style src="file.css" />

Example (html'd css file):

<html:style>
    <style:html width="100%">
        <style:body width="100%">
            <style:h color="red" mark="blue" />
        </style>
    </style>
</html>

Repo to work on this: https://github.com/philandy/HTMLStyle

Self-closing tags

I think HTML6 should use more of XML's self-closing tags - eg. <script src="s.js" /> would be great. Of course this is not the best example because it's a file import - can be done using <html:include /> or something like that. But I think you understand me. Older HTML versions had single tags and double tags but there was no way to recognize them.

Lol, the author here is such a whiny little kid.

I make a topic here: #45

Claiming that this guy has no idea what he's doing. For example, he wants to re-invent HTML 5 (the wheel) and say:

html:html

should be the new HTML syntax? LMAO. That's just horrible coding mechanics. Let's make the HTML tag 5 CHARACTERS longer!!! Haha, that makes absolutely no sense.

Also, he claims that it's XML when it's not. What he is referring to is 'Namespaces', which is a system XML took on years ago, and not specific to XML. Then, he closes my topic claiming 'Closing because of trolls'.

The hypocrisy is atonishing because if you look at the main page: 'I've since moved onto starting my own company called Piggybank and I wont be updating this anytime soon.' Then why the FUCK are you here replying to posts within seconds? Sit the fuck back and leave HTML and W3's future alone you are NOT needed. People like you give a bad name to programmers / site enthusiasts.

Why?

I can immediately see multiple reasons against the adoption of this spec, but none in favor.

• It is a more verbose, less informative dialect than HTML5
• It encourages the use of non-canonical tags, which would promote inconsistency
• video appears to be the default type for media tags which is counter-intuitive at best, and possibly redundant
• it seems "media" should be thought of as replacing the "object" tag rather than the img/picture, video, and audio tags

Please provide some idea as to why this would in any way be beneficial.

Attribute Quotes should be required and we should either pick Double Quotes or Single as a standard

Two things:

1. Quotes should be required around attributes, like this:

<div class="hello"></div>

2. Second, we should pick either double " or single '. I would think double makes more sense, since people tend to use single quotes in JavaScript.

Thoughts?

Creating links with attribute

I've been reading MathML specification and found that all the elements can have a href attribute and become a link. It would be great to have something like this in html.

Before:

<list>
 <item><html:a href="http://foo.com">Item1</html:a></item>
 <item>Item2</item>
</list>

After:

<list>
 <item html:href="http://foo.com">Item1</item>
 <item>Item2</item>
</list>

It's just an idea but I thing it's a great step towards removing another annoying HTML tag to learn (¡viva las simplicaciónes!)

Needs table of contents

Web Components

Serious question. What exactly does this accomplish that the Web Components spec doesn't solve?

I think you're trying to solve a problem that has already been solved by a lot of very smart people.

I'm going to be very blunt, and I'm sorry if this hurts anyone's feelings, but you need to stop wasting your time. This problem has already been solved and this solution will never be adopted.

Lol, worse syntax I've ever seen.

"html:html"

LMAO Really? This html6 syntax has got to be a joke and you should pull down your site. Don't try to re-invent the wheel.

Missing source element

In html5 there is a <source> element which is missing in html6. Where has it gone?
Also, we should introduce the media attribute on <source> (see <picture> element draft).

Microformats and html6 semantic again

I'm trying to make microformats feel like a part of html6. This would solve our problems with semanticity.

Here's the gist: [link]

Then vote for/against the idea: [link]

Thanks :)

PS: What are microformats, you ask? See this.

Class'n'ID shortand

When i was writing an page, I got an idea. Probably it's not good for HTML, I just wanted to know your "humble opinion" :D

My idea is following:
If you think about it, class and id aren't normal attributes. There can't be two elements with equal id value. And css is in fact parsed as an array of attributes, not a single string attr. So why do do this:
<b id="bold1" class="mark foo">quz</b>
If you can do this:
<b#bold1.mark.foo>quz</b>

It is really close to CSS.
P.S.: Maybe it looks strange when it is plain text but with some syntax highlight, it will be better.
P.P.S.: Or we can implement only a shortand for id.

without further adieu -> "ado"

"without further adieu"

Not the French word for goodbye, but "ado" - trouble or difficulty.

HTML-6 looks ugly. Uglier than HTML-5

I personally don't like (In fact I hate) the XML based syntax of HTML.

QML (https://www.youtube.com/watch?v=_6_F6Kpjd-Q, http://qt-project.org/doc/qt-5/qtqml-index.html) for example, a long time ago used to have a XML based syntax as well, however, nowadays QML looks more like jSON and honestly speaking is much more readable. Kivy, a python framework for Mobile Apps (http://kivy.org/#home, http://kivy.org/docs/gettingstarted/rules.html) has followed the same philosophy as QtQuick/QML (http://qt-project.org/doc/qt-5/qtquick-index.html) for the User Interface as well.

I don't know why HTML is still too old school.

I know it is going to be challenging to all of a sudden change the syntax but I reckon it completely worth it. At least for the client side web developers it is going to be heaps easier to read and write the User Interfaces.

// File name = main.html
import main.js
import main.css
from model import nav, slider as nav_model, slider_model
from delegate import nav, slider as nav_delegate, slider_delegate

Html
    name: house_keeping
    title: "True HTML6++ Sample"
    meta.title: "Page Title"
    meta.description: "This is an example of HTML6++ with namespaces"

Body
    Header
        id: page_header
        width: 100%; height: 200

        Image
            id: logo
            src: "images/logo.png"
            alt: "This is a logo"

        Navview
            model: nav_model
            delegate: nav_delegate


    Content
        Sliderview
            model: slider_model
            delegate: slider_delegate
            speed: 27
            effect: fadein_fadeout


        Article
            h1: "This is my main article head"
                h2: "This is my sub head"
                p: "This is a paragraph"
                p: "This is a paragraph"

        Article
            h1: "A cool video!"
                h2: "Pay attetion to the media elements"
                p: "This is a paragraph"

                video
                    src: "vids/funny-cat.mp4"
                    autostart: true
                    controls: standard

                p: "Man, that was a stupid cat."


    Label
        id: footer
        text: "This site is © to Oscar Godson 2009"




// File name = model/nav (Fetch it from a database and make it dynamic instead)
ListModel
    Item
        menu_name: "Cats"
        menu_link: "/cats"
        active: true

    Item
        menu_name: "Dogs"
        menu_link: "/dogs"
        active: false

    Item
        menu_name: "Rain"
        menu_link: "/rain"
        active: false



// File name = delegate/nav.html (Delegate describes how each item in the view looks like)
Anchor
    text: menu_name
    link: menu_link

    if active:
        class: active




// File name = model/slider (Fetch it from a database and make it dynamic instead)
ListModel
    Item
        source: "cats.png"
        caption: "Funny cats are awesome"

    Item
        source: "dogs.png"
        caption: "Wild dogs are aweful"

    Item
        source: "rain.png"
        caption: "Where is my rain coat?"



// File name = delegate/slider.html (Delegate describes how each item in the view looks like)
Rectangle
    class: slider

    Image
        src: source
        alt: caption

    Label
        text: caption

use role="a", role="text" to display a link, input:text

we should use role attribute to display a custom tag like an anchor or like text input

Renaming the language and namespace

As said in #17, renaming this repo to NML (namespace markup language) or NHTML would (namespace hypertext markup language) would be more accurate. To make the web-writing faster, the html namespace could be renamed to n - that's short enough :)
And the html:html would be n:root (or n:html to keep the tradition?)

Html:YourMakingMoreWorkForUs

I LOVE the idea of not having to use divs for everything and being able to write out exactly what we want:

<hereComesMyComplaint>
Why in the world do we need the "html:" call on everything? Isn't it redundant and adding more work for us?

Here's a link today:

<a href="simple.com">It's simple!< /a>

Here's the proposed HTML6 way:

<html:a href="notsimple.com">More unnecessary work< /html:a>

Why complicate things unnecessarily?

</hereComesMyComplaint>

Html6

Have crawlers hidden in my app

Needs server side polyfill

Node.js most likely

Idea

How about no more css (or at least less of it)!

Like this:

<color type="#0000">

something like that

Adding Syntax section

Here, in the HTML6 documentation, there is nearly no desc. of the syntax - only a reference to HTML5 and the Section 4 - Tag types. But full documentation has to include it.
Here's a list of syntax articles:

• what is a tag, what are attributes
  • tag in layman's terms
  • tag types [PARTIALLY]
  • attributes in layman's terms
  • normative description of tag
  • normative description of attributes
  • regular expersion
• namespaces (+how to include)
• how to parse wrong code

At this point we don't know anything about namespaces. Will there be something like xmlns? Or will they be included in doctype like this: <!DOCTYPE html,form>? And what languages to use to define new namespaces?

A more orthogonal HTML

What could be great is if the HTML spec was based on a small set of tags which had clearly defined and predictable behaviour.

You could you could have the <html:div> tags implemented by the browser and the higher level tags implemented by those low level ones.
For example

<html:li> </html:li> could be implemented using my probably awful syntax language(pasl)

<html:li>
     <html:div>
          <html:media type="image" src="dot.png"></html:media>[content]
     </html:div>
</html:li>

with [content] being replaced with the content of the tag.

I'm not sure how feasible this is, but it sure would be nice and would make for a far simpler browser implementation, more uniformity across browsers as well as a more flexible language in general.

Thoughts?

No CSS pseudo class selector support

It's impossible to use CSS pseudo class selectors. That's excruciatingly limiting.

Current CSS spec does not account for this tag selector syntax

This issue encompasses #39 and #37, being that this has overreaching side effects for the CSS spec as well.

Since tag names are valid selectors, I'm not sure a selector like html:body { background: black } would be properly accounted for via the CSS 2.1/3 specs, let alone properly parsed by the various browser implementations that would consume this. XSLT handles this for XML, though I'm not a fan of how robust that particular syntax is.

Tags should be closed in html6

A tag like

<html:link src="js/main.js" title="Main Script" type="text/javascript">

Does not communicate developer intent. Is the next tag a child of <html:link> or a peer?

Simply closing the tag with one additional, JUST ONE, just one extra, keystroke simplifies parsing of the document and sends an extremely clear message. Simplifying the document structure should also lead to improved render times, as browsing engines don't have to look ahead and make all sorts of guesses.

<html:link src="js/main.js" title="Main Script" type="text/javascript" />

New "semantic" tags

I'm leaving this here at your request. It really relates more to HTML5 and some of the new semantic tags. In response to your comment from the bottom of the type="someSortOfMedia" issue. I got off track onto an ARIA related thought.

Header, nav, section, aside, and article aren't random empty tags. And, they do add a lot of space around content I put in them, that has nothing to do with any padding, line-height, or margins I've marked up. I've messed with them several times. The browsers are adding box padding, or borders, or margins, or line-height, or something, that's almost impossible to override. It messes up layout. So, like I said previouisly, I don't use the tags unless I know I have lots of room to give them. Like header for instance. That usually works ok because it'll create a header that's about the right height.

On a current site, I had to give up on using the nav tag for my main navigation links because it was generating just too much vertical size for the element. I'm using a div instead, and it works fine now.

[Question] HTML6 vs. x-tag-elements?

What's the relatedness between this and x-tag-elements by Mozilla?

"type=whatever" in HTML6, or any HTML

Consider that when you create a URL reference or meta tag, whatever type you're referencing is information contained in the URL. Like: link rel="stylesheet" href="somewhere/nested/style.css" medial="all"

That href gives you the file type, which tells the browser (or client device) what parsing, rendering, or codec is needed.

The same is true of media. An image file src reference tells you whether it's a jpg, png, svg and so on. A video is going to have a file type that triggers the appropriate codec to render it, and so will an audio file.

just a thought.

Also, if everyone's busily coming up with there own tag names, no matter how nicely semantic that may be, what about ARIA and those who need to access things according to a doc map? Are they going to be reduced to having to tab through every tag on a page? The wide open semantic idea is great for developers. But it leaves a universe where there is no standard from which to set a tag hierarchy that allows the handicapped to filter a document, and search out the info they're after.

No need for master branch

The publish.sh script and master branch are redundant. Why not set gh-pages as the default branch and get rid of master?

Why html:button element?

HTML6 spec:
"(...) the <html:button> tag allows you to create a button for user interaction on a page."

What is it for? As far as I know, the only native feature of this element is the disable attribute. Why won't we add disable to html:a? A developer could just apply appearance: button on it.

[idea html6] empty end tags

The "empty" closing tag allows for a strong level of abstraction. There are 3 different types right now. It allows strong control over unknown markup structures.

Generic pseudocode example:

<html:?> <!-- we may not know what this tag is due to dynamic design -->
        <html:body>
                <html:?>
                        <html:unclosed><!--this tag is not closed properly-->
                                <html:p>
                                </ type="last"><!--this would close the p tag-->
                                <html:?>
                                        <html:?>
                                        </ type="last"><!--but this should be the real reason to use </ type="last"> -->
                                </ type="first"> <!--this would close all tags at this level and only this level-->
        </html:body> <!--would have to close body tag properly-->
</> <!--default this would close all previous tags -->
This line and beyond would not appear in the document or at least does not appear as HTML.

Specific pseudocode example (problem existing in html5):

<!DOCTYPE html>
<html>
    <head>
        <script>
            n = random(1,2);
            if (n=1) write "<div>";
            if (n=2) write "<p>";
        </script>
    </head>
    <body>
        <!--What tag can I use to close the script output?-->
    </body>
</html>

As you can see in the specific example, unless you add more scripting, there is no tag that can currently resolve the situation. This is where </> could come in. Discussion needs to take place regarding how this could work fluidly with the DOM tree (the type attribute I suggest may need to be replaced by a level or family attribute).

If we focus on using the level attribute, there are 3 that DOS uses with directories:
</ level="."> would represent the same level.
</ level=".."> would represent the level above.
</ level="\"> would represent all levels.

I am unsure how to properly represent a family attribute. However, there may be something to being able to close siblings (or other same level tags) properly, such as browser incompatibilities or tags that function closed or opened but could play havoc on validators (and even worse, parsers).

Assuming for now we only work with the concept of levels, similar to DOS, levels below would have already been resolved because we have come back up somehow, such as you would have to close a div to be back in the body. Alternatively, there is no current tag that lets you traverse backwards within html to a lower level unless html6 works with the DOM API at some point and I don't foresee that happening.

It should be some another ways to improve the web.

To add more semantic to tags is correct decision. "class" attribute use very often to markup documents. But I think that idea to ressurrect this old fashioned standart (HTML) to life in future is not so good. This technology was good in 80s, but now it's just an constraint that makes developers limit their possibilities to make cool apps, because a stack for develop web application is just go out of date.

Yes, you try to make in modern, to allow use in to build nice looking pages, but it's some delusion. It's not data presentaion language (because we still have the tags that works as visual layout elements, with not too much of semanics) and it's not a visual markup one (because it lacks of some sort of tags to define containers, grids and other stuff required to build layouts - we just need use CSS for that instead build-in HTML capabilities). So, what is it so it doesn't solve problems to represent data or to markup difficult page layouts?

I think that the better way is to add some safe protocol to load web-apps images (application) published as byte code to VM sandbox in the browser (by URI) and then execute it. So we can use many an many ways to build this byte-code in way, that developer decide is the best for him. We could use any languages (prodcedural, functional or declarative ones) to publish web-apps for this VM. No more limits to designers, programmers and users to improve web in way they want. No more large-scale consortiums to decide what tags are good for us. Just rewrite any compiler to build required byte-codes and use it to draw pixels or text-blocks or games, on the screen....

I hope that backward compatibility and other "good" features won't make developers to stay on place for decades.

Promotional matterials

I have made up a sort of promo for HTML6. It's a bit brainwashing but you may like it.

---

Imagine...
Imagine that the world is a place where you can do anything you want.
Imagine that there is a specification for all the people, no matter what they want to do.
Imagine you've got it all in your hands.
Imagine HTML6

---

English is not my native language so that there may be some mistakes. It's only a draft.

Anchors should be anchors, links should be links, and includes should be includes.

Everyday terminology refers to the semantic <a> element as a "link" OR an "anchor", giving the tag a double meaning.

Specs refer to a "link" as what everyday terminology refers to as an "include".

This is a serious barrier of entry for anyone trying to learn HTML. "I've been told links are what take you to new documents my whole life, but why are they something completely different in HTML land?", students ask. "Because the HTML gods made it so", I tell them.

Everyday peoples understand the (HUGE) difference between a website "link" and an "anchor". It's an easy concept, conceptually. However, once they get into HTML, real-world understanding doesn't map to the reality ( cough poorly invented conventions cough ) of HTML-fairytale-land.

I've always had this question, but figured there was some mystical force at work that justified such idiotic terminology. After exploring the deepest caverns of HTML I can finally put that myth to rest, and take a stand against this retardation!

A ludicrous proposal: a "link" actually be what normal people understand a "link" to be. This means <html:a> or possibly <html:anchor> will only be used for ANCHORS and <html:link> will only be used for LINKS in the true sense of the term. Now that <html:link> is taken, we must endow a new term for the inclusion of source files; I propose <html:include>.

Please poke holes in this philosophy if you can, because from where I sit it seems sound; but perhaps I missed one of those secret underground passageways that leads you to the bonus level where there's flying pigs and this all makes sense.

PS: "HTML6" seems like a splendid idea, regardless of if my points are valid.

Needs client side polyfill

Standardize on the default namespace of 'html' and use it in all your examples

If this is a serious project: nobody is going to even entertain <html:a>. Make the namespace that html is the prefix for the default namespace (without any extra markup, unless you want to override the default namespace), pointing to the DTD for your proposed html6, and make the examples on html6spec.com actually use the default namespace. Otherwise I don't think this is going to get any serious attention.

Merging HTML6 with SVG and MathML

It would be nice to make a HTML6-style documentation for SVG, GraphML and MathML.
Eg. MathML is useful but not very practical. We could add math prefix to this spec and remove those ms from the begining of the tag names and math from the attribute names.

Cleaner meta tags

Allow more than one meta name to share the same value.

<html:meta types="description, twitter:description, og:description" value="This is an example of description for Google, Twitter, and Facebook">

Fix HTML6

Make most of the tags 5 letters longer! YEAH!

HTML.next

According to the W3C in a HTML5 FAQ, new HTML features are introduced to the HTML.next list.

http://www.w3.org/html/wiki/FAQs#Will_there_be_an_HTML6.3F
http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML.next

What are the plans for this HTML6 to follow that HTML6?