search

ucla-oarc-mobile / mwf

UCLA Mobile Web Framework
http://mwf.ucla.edu
Other
86 stars 25 forks source link

HTML Tag Decorator incompatible with HTML5 void elements #94

Closed Trott closed 6 years ago

Trott commented 12 years ago

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 commented 12 years ago

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

zkhalapyan commented 12 years ago

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

Trott commented 12 years ago

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.