Conventions for Output Code
-
@chris fullmer said:
<br />
Hows it a trick Q? All my books and W3 standards I've read suggest that it should only be <br /> as all tugs must have a closing />.
The HTML 5 spec deprecates <br /> in favor of good old <br>. The silly version was born with, and dies with, XHTML, the one and only HTML that tried to be XML.
-
C'mon guys, decide which one I should use. I build (rather amateur) websites but would like to work correctly.
-
@martinrinehart said:
@chris fullmer said:
<br />
Hows it a trick Q? All my books and W3 standards I've read suggest that it should only be <br /> as all tugs must have a closing />.
The HTML 5 spec deprecates <br /> in favor of good old <br>. The silly version was born with, and dies with, XHTML, the one and only HTML that tried to be XML.
HTML5 comes in XHTML flavour as well. So <br /> still lives if you opt in for the XML version.
-
@gaieus said:
C'mon guys, decide which one I should use. I build (rather amateur) websites but would like to work correctly.
If you use HTML then don't close empty tags, if you use XHTML then you have to close empty tags.
-
@gaieus said:
C'mon guys, decide which one I should use. I build (rather amateur) websites but would like to work correctly.
All the major western browsers have been happy with <br> this century. If your doctype specifies "XHTML strict" you want "<br />". Otherwise the original is preferred.
According to Wikipedia, "HTML 5 is the next advancement of both HTML 4.01 and XHTML 1.0, as development on the next version of the latter has been ceased." (I think I'll go clean up that English.)
-
@thomthom said:
HTML5 comes in XHTML flavour as well. So <br /> still lives if you opt in for the XML version.
According to Wikipedia, "HTML 5 is the next advancement of both HTML 4.01 and XHTML 1.0, as development on the next version of the latter has stopped."
-
Wiki isn't quite accurate. XHTML 1.0 was meant as a transition towards XML based documents. But IE put a fork in that. One of the reasons XHTML 2.0 died.
This sums up XHTML5 vs HTML5 nicely.
http://html5doctor.com/html-5-xml-xhtml-5/HTML5 also gives some flex to <br/> style tags due to its widespread use: http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths
-
One step forwards, two steps back, one step sideways shuffling forwards.
-
@thomthom said:
This sums up XHTML5 vs HTML5 nicely.
http://html5doctor.com/html-5-xml-xhtml-5/For better or worse, the WHATwg decided that XML was a mistake. The current w3c spec (August) is the original, XML-free WHATwg spec. Lawson is about 2 months earlier than the current w3c spec. An earlier version deprecated <br />. It's not even mentioned in the current spec. The formerly dead form, <br clear=...> has been resurrected as "deprecated but must be implemented as follows: ..."
@thomthom said:
HTML5 also gives some flex to <br/> style tags due to its widespread use: http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths
Seems like good thinking, but much forgotten between '07 and today. I'll bet this is followed in practice even if it isn't in the spec. Can you imagine an actual browser shipped without supporting <center>?
But we wander. Back to my original question. I propose the following convention:
As browsers are more predictable in standards mode than quirks mode, Ruby-generated HTML should include a doctype and should be valid for its doctype.
-
hm.. that's interesting. Haven't paid much attention to HTML5 the last few months.
@martinrinehart said:
But we wander. Back to my original question..
Ah, yea. The topic!
Sorry, I often stray away and webdev is one of my major interests so I stray even quicker and further when that topic is even remotely related. 
@martinrinehart said:
As browsers are more predictable in standards mode than quirks mode, Ruby-generated HTML should include a doctype and should be valid for its doctype.
Agree. Since webdialogs must run under the webkit engine and IE the best chance for platform compatibility is following the W3C standards.
When I make webdialogs I do the same as I do when I develop websites. I code to the standards, then to account for IE notoriously bad handling of the standards I add some conditional comments that adds CSS and JS fixes. Most of the time visual quirks in IE is by triggering hasLayout
For better legibility and re-usability, separate CSS and JS their own respective files.
Using HTML validators to detect correct markup is very important. Once a document is invalid there's no way to predict how the different rendering engines will recover and you can not expect cross platform compatibility.
I'm starting to realise that there hasn't been posted any recommendations of best practices when it comes to webdialogs. Coming from a webdesign background I haven't given it much thought.
Advertisement