"type=whatever" in HTML6, or any HTML

[maxw3st]

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.

[FRickReich]

Definately a Good thought. I am Not too Fond about non. Standards

Von meinem iPhone gesendet

Am 07.01.2013 um 18:50 schrieb Max West notifications@github.com:

Consider that when you create a URL reference or meta tag, whatever type you're referencing is information contained in the URL. Like

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.

— Reply to this email directly or view it on GitHub.

[OscarGodson]

I like this. I'll probably remove all the types later.

As for:

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.

That's a totally different topic :) you should file another ticket. In short tho, tabbing is already broken on most sites. You probably want to tab through <a>s generally now or form elements. This would still work exactly the same. You can't tab to <div> anyway. As a blind person would you rather hear about a <calendar> element or a <div> element? You can also still add title attributes and stuff to each element.

[maxw3st]

Gottcha, I wasn't sure exactly how the blind compatibility worked I guess. From what you're saying semantic tags would be much better than divs. It would make site content tags much more useful to the blind. I guess the reason I still like div's is that the new HTML tags all seem to add tons of hidden padding and margins that screw–up layout. So, unless it's a situation where I have lots of room for white–space, I don't use the section, article, and aside tags. If they were as layout flexible as div's, I'd use them.

On Mon, Jan 7, 2013 at 3:40 PM, Oscar Godson notifications@github.comwrote:

I like this. I'll probably remove all the types later. As for:

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.

That's a totally different topic :) you should file another ticket. In short tho, tabbing is already broken on most sites. You probably want to tab through s generally now or form elements. This would still work exactly the same. You can't tab to

anyway. As a blind person would you rather hear about a element or a

element? You can also still add title attributes and stuff to each element.

— Reply to this email directly or view it on GitHubhttps://github.com/OscarGodson/HTML6/issues/4#issuecomment-11970574.

Max West

They'd work exactly like putting <calendar> would work now if you just make a normal HTML5 doc. They're an empty, styleless node such as a span or div. Things like <html:p> would have padding because they're part of a the spec, but random elements you make wouldn't.

[maxw3st]

Yes, but header, nav, section, aside, and article aren't random empty tags. And, they do add a lot of space around the 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 above, 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.

[leoj3n]

@maxw3st browser default styles on default tags have always existed. That's why reset style sheets came into existence, to cancel these defaults out which are often inconsistent between the major browsers. @OscarGodson is creating a polyfill for both client and server, depending on your preference, to allow you to specify a custom combination of tags that ultimately get parsed into what today's browsers can handle. Either way your issue is unrelated and easily remedied with a reset style sheet. Hope this makes sense.

[maxw3st]

Another way to handle it, without a bloated reset, is just to use semantic class names in div tags. Div's are reliably free of padding, and margins inserted by rendering engines. It allows me to control content down to the pixel (or more accurately ¼ em these days). It also saves me hours of aggravation dealing with browser related positioning problems. Each seems to have it's own idea of what padding and margins any given element needs.

I've learned the hard way to start off with a wild–card declaration that sets padding, margins and borders to 0, and set my default font size. That way I know if something's not showing up where I want it, I can move it against a known baseline at least.

My current project has been causing me problems precisely because I allowed myself to use someone's RWD framework. At this point it's all but completely disabled (the framework that is). It's got at least a page of nothing but reset in the CSS. At some point I'll strip that out, along with the rest of his code. It's yet another example of how using a header tag gives a header bar that's twice the height it needs to be. I've managed to narrow it down to what I want, but it was a major waste of time battling the hidden padding and height it auto–created when an image and text were added between the tags.

[OscarGodson]

@maxw3st I'm still not convinced that those tags you listed are the culprit. Sounds more like line-height or something of your <p> tags :) as in my other ticket, I'd love to see a gist so we can figure it out.