search

OscarGodson / HTML6

A spec to HTML6
http://html6spec.com
169 stars 25 forks source link

[idea html6] empty end tags #15

Open philandy opened 11 years ago

philandy commented 11 years ago

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.

OscarGodson commented 11 years ago

How does it know which tag to close and in what order?

OscarGodson commented 11 years ago

Yikes, thats impossible to read. Can you use code blocks instead?

https://help.github.com/articles/github-flavored-markdown

OscarGodson commented 11 years ago

I've been thinking about this for awhile, and wouldnt mind it being an option I guess, but HTML and XML were meant to be super readable. It's meant to be easy for humans to read, but still parseable by computers. For example:

<f><bar><c><a></><foo></></></></>
<f><c><a></a><foo></foo></c></bar></f>

The one above takes me a minute to actually figure out where each end tag closes. Even on multiple lines it isn't as clear:

<f>
  <bar>
    <c><a></><foo></></>
  </>
</>
<f>
  <bar>
    <c><a></a><foo></foo></c>
  </bar>
</f>

And 99% of HTML is not handcrafted. You may write a template, but the template will generate some markup, you may compress it, and even more commonly the tabbing will be all messed up from pulling in blocks of HTML from different. Something like:

    <f>
<bar>
<c>
<a>

</>
   <foo></>
</>
</>
   </>

Make 30 lines of that and matching and counting tags is impossible. You still have to know you need a closing tag and you still need to know how many. Just saves a few characters of typing

philandy commented 11 years ago

Well there's two ways to write code then:

<html>
<...

and

<html>
...
</html>

If you write code the second way, you might prefer using empty tags.

Additionally, if there ever arises a useful coding point to bring 2 or more sets of html together or closing something unknown off, this abstract structure may become useful. Let me see if I can find an example of someone using scripts because they needed to work around not having this (like closing off a block in C style coding).

philandy commented 11 years ago

I just found http://www.oreillynet.com/xml/blog/2008/01/the_design_goals_of_xml_1.html

When this idea came up, they considered it a question of clarity vs shortness for typists. Clarity always won in this battle when TBL was working on XML.

I am not pushing an argument for the removal of closing tags. I believe the empty tag could be useful as a supplement in some way.

https://en.wikipedia.org/wiki/Abstraction

Further, abstraction. Removal of the concept of named from tag leaves the tag by itself. In this light </> could mean closing all tags. It could also mean closing the closest previous unclosed tag. Perhaps:

</ type="">

Adding a type attribute might offer some further control.

</ type="all">

This would close all tags regardless of markup hierarchy. It could also be useful for ending control in XML trees. I suggest this be default. Perhaps everything after this is guaranteed unparsed.

</ type="first">

This would close the first tag within a branch, thus closing all branches at the level.

</ type="last">

This would close the previous tag. I suggest this not be default and to be used only when necessary. Requiring this clarity eliminates the point of poor unclear design.

</ id="style and script">

Perhaps there could be uses for css and javascript.

</ name="end">

Perhaps there could be a need to link to directly after a block.

leoj3n commented 11 years ago

Personally I'd only use "empty end tags" to close elements that have no nested elements within. So for one-liners.

philandy commented 11 years ago

Joel, would you use specifically:

</ type="last">

There is a clarity issue with:

</>

Also, I updated the original post to reflect this.

leoj3n commented 11 years ago

The syntax doesn't change the fact that I'd implement "empty end tags" as one-liners.

</ type="last"> is obtuse compared to </p>, </div>, etc...

Any use cases having to do with fixing gated code won't fly; get access and fix the problem upstream.

philandy commented 11 years ago

Joel, I disagree. </> is unclear and useless for one liners (that can easily grow exponentially). If </ type=""> is obtuse then it's arguable that <whatever whatever=""> is as well.

Also, this is not about gated code, this is about making some instances of dynamic code simpler. I agree if this were to be used by someone who was having an issue with gated code, that's doing it wrong.

cshaa commented 11 years ago

My opinion: </> - could be </ type=""> - dirty

philandy commented 11 years ago

I had another thought.

Oscar, what are the new limits of </html> in html6? That on its own might resolve some interesting dynamic situations.

m93a, what would type=" " actually do?

cshaa commented 11 years ago

type="" was an example, it means type="last" and other possible types. But </>, meant as close last element (as a SHORTTAG in SGML def), would be great for one-line not-nested elements. And not hard to understand for parsers.

philandy commented 11 years ago

m93a, I disagree on many levels now (but I used to agree with the logic). I'll re-explain and more:

  1. Tags work together. <a> and </a> whenever there is a need for a closing tag. Imagine a </any> tag to close any other tag. So you would have <html></any>. This feels debased, and further there is no definition for <any> (of which you could argue that some tags do not need to be closed, but then I could argue XHTML). </any> = </> for the purpose of closing obvious tags.
  2. So, you've sacrificed clarity, added complexity, and broken older browsers for a few bytes of compressed space.
  3. Dynamically built html could benefit from an abstract closing tag. With it, there's a chance at richer container file structures. A simple example: head.html, body.html, foot.html.
  4. SGML has these, but HTML does not. Why?
cshaa commented 11 years ago

1,2) For one-liners, as Joel said, its clear and easy to understand. Example:

<article>
 <text>Ahoj, jak se máš? Hola, ¿qué tal?</>
 <definition>Sum borin text hier</>
</article>

3) Can you explain it? I don't understand... 4) HTML4 was a subset of SGML but browsers did not include these OMITTAGs, SHORTREFs, NETs and SHORTTAGs because it was just too much work. In those times, the main standards were made by IE and Mozilla.

philandy commented 11 years ago

m93a,

  1. When those 1 liners grow, only a good syntax highlighter will save you. Not everyone understands this concept, and as Oscar pointed out many times html is generated rather than hand-coded.
  2. Refer to the new second example in my original post for something simple.
  3. This does not explain where we are today, but is useful for historical thinking. The reason is when the architects were building XML, they introduced a new guideline to the web-foundation design process: being clear.
cshaa commented 11 years ago

3) Why do you use </html> in your example? It would be easier (cleaner, more user- and parser-friendly) to write the real name of elements you are closing and make parsers understand that in HTML5 was this code:

<a><b>something</a>

equal to this:

<a><b/>something</a>

but in HTML6 it has changed to this

<a><b>something</b></a>

It would break old OMITTAG and programmer would have to use NESTC (self-closing tag) For definitions, see: http://en.wikipedia.org/wiki/SGML

philandy commented 11 years ago

m93a, I am closing each namespace description. Now, I could use a typical layout if it's a static page if there is no need for further disambiguation, but then we're talking about html5 and I have no say so there. I updated it to reflect a pickle in html5.

OscarGodson commented 11 years ago

Just want to say it's really awesome to read your guys' comments about this stuff :smiley:

cshaa commented 11 years ago

@philandy Ok but you could just use DOM createElement in your "dynamic" example. I think it would be even faster. @OscarGodson Yeah :)

philandy commented 11 years ago

@m93a: Option 1: Use JavaScript to invoke the API. Option 2: Use HTML6. Well, both can have their place! HTML6 would be the more logical choice in this example since creating the HTML involves no change while the site is loaded.