HTML Tag Decorator incompatible with HTML5 void elements #94

Closed
Trott opened this Issue Feb 5, 2012 · 3 comments

Comments

Projects
None yet
3 participants
@Trott
Contributor

Trott commented Feb 5, 2012

In HTML5, void elements cannot have an end tag. http://www.w3.org/TR/html5/syntax.html#void-elements

This means that if you use an HTML5 doctype and the Tag Decorator to generate your input tags, you will have invalid markup.

You can still get valid markup by calling tag_start() rather than tag() but that seems like a hack and perhaps requiring the user to know too much about the underlying markup. Might a feature like this work a bit better?:

  1. Have a config option as to whether or not we are generating HTML5 markup by default. Simple override mechanism would be a call to Config::set() before generating any markup.
  2. Maintain a list of void elements and react to the config setting appropriately.
@ebollens

This comment has been minimized.

Show comment
Hide comment
@ebollens

ebollens Feb 5, 2012

Contributor

Hmmm, no particularly elegant solution. I'll mess with this after I finish extricating (working on it today).

Contributor

ebollens commented Feb 5, 2012

Hmmm, no particularly elegant solution. I'll mess with this after I finish extricating (working on it today).

@ghost ghost assigned ebollens Feb 5, 2012

@zkhalapyan

This comment has been minimized.

Show comment
Hide comment
@zkhalapyan

zkhalapyan Feb 5, 2012

Contributor

Not my area of expertise, but would it be possible to detect HTML5 support and generate tags accordingly?

Contributor

zkhalapyan commented Feb 5, 2012

Not my area of expertise, but would it be possible to detect HTML5 support and generate tags accordingly?

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Feb 5, 2012

Contributor

The good news there is that there's generally no problem serving HTML5 to pre-HTML5 browsers, as long as the browser is not in quirks mode. And a valid HTML5 doc type will not put browsers into quirks mode. So determining HTML5 safety (as opposed to support) is straightforward.

We have a few options here:

  1. Render only HTML5 no matter what. Older browsers will handle it just fine. Hooray for graceful degradation. We still have this when-to-close-and-when-not-to-close-a-tag issue.
  2. Render HTML5 and older HTML standards. This introduces additional complications.

It might be worth figuring out if we want to move to that first option for 1.3. Forward-looking and all that.

In the meantime, we have the when-to-close-and-when-not-to-close-a-tag issue. I'm unaware of any real-world problems this causes. The only issue I've noticed is that it generates pages that then fail to validate. So the pages are technically incorrect. But the pages still work in the browsers I've tested.

Contributor

Trott commented Feb 5, 2012

The good news there is that there's generally no problem serving HTML5 to pre-HTML5 browsers, as long as the browser is not in quirks mode. And a valid HTML5 doc type will not put browsers into quirks mode. So determining HTML5 safety (as opposed to support) is straightforward.

We have a few options here:

  1. Render only HTML5 no matter what. Older browsers will handle it just fine. Hooray for graceful degradation. We still have this when-to-close-and-when-not-to-close-a-tag issue.
  2. Render HTML5 and older HTML standards. This introduces additional complications.

It might be worth figuring out if we want to move to that first option for 1.3. Forward-looking and all that.

In the meantime, we have the when-to-close-and-when-not-to-close-a-tag issue. I'm unaware of any real-world problems this causes. The only issue I've noticed is that it generates pages that then fail to validate. So the pages are technically incorrect. But the pages still work in the browsers I've tested.

@Trott Trott closed this Mar 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment