SitePoint Sponsor

User Tag List

Results 1 to 24 of 24
  1. #1
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Post XHTML Cheat Sheet

    Hi.

    Inspired by other cheat sheets I decided to create a printable XHTML cheat sheet myself which is supposed to fit on one single page (in this case it does if you print on both sides of the paper).

    I would like to know if someone has suggestions to improve it or if there are any mistakes (apart from searching for those the sheet is finished so far). Of course I hope that it is useful for some people already.

    Well, my aim was to create a sheet with as much important information as possible without using a lot of space.

    The following is included:
    • all HTML element types (+ short description) and their attributes
    • a list of all deprecated elements (I couldn't add them to the table, because it would have used 3 pages then)
    • all values for the "type"-attribute of <input>
    • all link-types
    • all media-types
    • XHTML namespace URI
    • almost all entities

    Btw, the legend is at the bottom right of the second page.

  2. #2
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    These are not block-level elements: BODY, DD, DEL, DT, FRAME, HEAD, HTML, INS, LI and NOFRAMES.

    (INS and DEL are block- or inline-level depending on the context.)

    These are not inline-level elements: BASE, ADDRESS (it's block-level), LEGEND, LINK, META, OPTGROUP, OPTION, PARAM, SCRIPT, STYLE and TITLE.

    Also, TABLE is a block-level element.

    FRAME is in italic, which according to the footnote means that it must be empty. That's false.

    Entity references shouldn't be used in XHTML, because of non-validating parsers. You could leave the four entity references defined by XML though; amp, quot, lt, gt, and apos (apos doesn't exist in HTML, only XML).

    XHTML uses xml:lang instead of lang (although XHTML 1.0 allows both).
    Simon Pieters

  3. #3
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan
    These are not block-level elements: BODY, DD,DEL, DT, FRAME, HEAD, HTML, INS, LI and NOFRAMES. (INS and DEL are block- or inline-level depending on the context.)

    These are not inline-level elements: BASE, ADDRESS (it's block-level), LEGEND, LINK, META, OPTGROUP, OPTION, PARAM, SCRIPT, STYLE and TITLE.
    Where am I supposed to put them? I would prefer if you said what is and not what it is not.

    Anyway, according to the definitions all of "my block elements" apart from DT (I need to correct that) can be block-level-elements. Most of it is confirmed here as well:
    http://www.w3.org/TR/CSS21/sample.htm

    I know about the problem with DEL/INS but block is more appropriate than inline.
    ADDRESS can be called inline because it may only contain inline elements. But since the stylesheet says "block" I will move it to block elements.

    According to your information there are a lot of not-inline and not-block elements now. So in other words do you suggest to create a 4th category?

    Also, TABLE is a block-level element.
    I know, and I didn't say anything else on my sheet (if you have a look at the description). But it is nonsense to put it below BLOCK if you have a TABLE-category.

    FRAME is in italic, which according to the footnote means that it must be empty. That's false.
    It is not unless you have other DTDs than me.

    Code:
    <!ELEMENT FRAME - O EMPTY              -- subwindow -->
    or
    <!ELEMENT frame EMPTY>
    Entity references shouldn't be used in XHTML, because of non-validating parsers. You could leave the four entity references defined by XML though; amp, quot, lt, gt, and
    You don't have to use them. Nevertheless they exist and can be used, this is why I won't remove them.

    apos (apos doesn't exist in HTML, only XML).

    XHTML uses xml:lang instead of lang (although XHTML 1.0 allows both).
    Thanks, I will add that.

  4. #4
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    Where am I supposed to put them? I would prefer if you said what is and not what it is not.
    Ok. These elements are always block-level: P, H1, H2, H3, H4, H5, H6, OL, UL, PRE, DL, DIV, NOSCRIPT, BLOCKQUOTE, FORM, HR, TABLE, FIELDSET, ADDRESS.

    These elements are always inline-level: TT, I, B, BIG, SMALL, EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, ACRONYM, A, IMG, OBJECT, BR, MAP, Q, SUB, SUP, SPAN, BDO, INPUT, SELECT, TEXTAREA, LABEL, BUTTON.
    Edit:

    SCRIPT is allowed where inline-level content is expected, where block-level content is expected, and as a child of HEAD.


    Other elements are niether block- or inline-level (with exception to INS and DEL which could be the one or the other). They are only allowed in sertain cases and not just where block- or inline-level elements are allowed. For instance, LI is only allowed as a child of OL or UL; STYLE is only allowed in HEAD, etc.
    Quote Originally Posted by Floele
    Anyway, according to the definitions all of "my block elements" apart from DT (I need to correct that) can be block-level-elements. Most of it is confirmed here as well:
    http://www.w3.org/TR/CSS21/sample.htm
    CSS has nothing to do with this. The section in the HTML4 spec says "generally", and there are exeptions to this "rule". For instance, MAP is inline-level but its content model is ((%block;) | AREA)+.
    Quote Originally Posted by Floele
    I know about the problem with DEL/INS but block is more appropriate than inline.
    Why?
    Quote Originally Posted by Floele
    ADDRESS can be called inline because it may only contain inline elements. But since the stylesheet says "block" I will move it to block elements.
    P may also only contain inline-level elements as children. The content model doesn't say whether the element itself is inline- or block-level...
    Quote Originally Posted by Floele
    According to your information there are a lot of not-inline and not-block elements now. So in other words do you suggest to create a 4th category?
    Yes, that category could be called "Other elements", or some such. Or perhaps you don't use categories at all but rather a column with "Where is this element allowed?" which could then say "Where block-level elements are expected", "As a child of OL or UL", etc.
    Quote Originally Posted by Floele
    I know, and I didn't say anything else on my sheet (if you have a look at the description). But it is nonsense to put it below BLOCK if you have a TABLE-category.
    Why? It is still a block-level element that is allowed anywhere where other block-level elements are allowed.
    Quote Originally Posted by Floele
    It is not unless you have other DTDs than me.

    Code:
    <!ELEMENT FRAME - O EMPTY              -- subwindow -->
    or
    <!ELEMENT frame EMPTY>
    Sorry, my bad. But why have you included FRAME in the first place? It's not part of the Strict DTD, and if you want to include things from Frameset and Transitional I don't think everything will fit on one page... ;)
    Last edited by zcorpan; Jul 29, 2005 at 11:37.
    Simon Pieters

  5. #5
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan
    Ok. These elements are always block-level: P, H1, H2, H3, H4, H5, H6, OL, UL, PRE, DL, DIV, NOSCRIPT, BLOCKQUOTE, FORM, HR, TABLE, FIELDSET, ADDRESS.

    These elements are always inline-level: TT, I, B, BIG, SMALL, EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, ACRONYM, A, IMG, OBJECT, BR, SCRIPT, MAP, Q, SUB, SUP, SPAN, BDO, INPUT, SELECT, TEXTAREA, LABEL, BUTTON.
    Ok, now also tell me where you read that

    CSS has nothing to do with this.
    Nevertheless the display-modes of CSS are related to the element-levels in HTML.

    Why?
    Because block-elements usually may contain inline-elements, but inline-elements usually may not contain block-elements.

    Yes, that category could be called "Other elements", or some such.
    OK...but I can't promise that it fits with an additional category.

    Or perhaps you don't use categories at all but rather a column with "Where is this element allowed?" which could then say "Where block-level elements are expected"
    I don't think an additional column fits (although I would like the idea to add more information like that).

    Why? It is still a block-level element that is allowed anywhere where other block-level elements are allowed.
    Because you expect the element "table" to be in the category "table elements" (at least I do). Otherwise the sheet would say that the table-element is not part of the table-elements (isn't that paradox?). It would fit in both categories of course, but I don't have enough space for duplicate items.

    Sorry, my bad. But why have you included FRAME in the first place? It's not part of the Strict DTD, and if you want to include things from Frameset and Transitional I don't think everything will fit on one page...
    I think it does because I already included everything from Strict,Transitional and Frameset. As I said all deprecated elements are no included because that would really be too much.
    However, I just noticed that I should make a difference between Strict and Transitional (there are some non-deprecated attributes (edit and element types not allowed in the Strict version).

  6. #6
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    Ok, now also tell me where you read that
    http://www.w3.org/TR/html4/sgml/dtd.html#block
    http://www.w3.org/TR/html4/sgml/dtd.html#inline
    Quote Originally Posted by Floele
    Nevertheless the display-modes of CSS are related to the element-levels in HTML.
    That would require a separate sheet itself, because there's no real connection between HTML4s %block; and %inline; and CSS's display property. For instance, BR is inline-level that usually has display:block; NOSCRIPT is block-level that (if scripting is enabled) usually has display:none; and so forth. The display property in CSS doesn't change the rules of the markup language.
    Quote Originally Posted by Floele
    Because block-elements usually may contain inline-elements, but inline-elements usually may not contain block-elements.
    Has that anything to do with INS and DEL? I see these elements more frequently used as inline-level elements than block-level elements, but since both are allowed I wouldn't put them in either.
    Quote Originally Posted by Floele
    I don't think an additional column fits (although I would like the idea to add more information like that).
    The entity references do take up valuable space, don't they? As well as the deprecated elements and attributes... [quote=Floele]
    Quote Originally Posted by Floele
    I think it does because I already included everything from Strict,Transitional and Frameset. As I said all deprecated elements are no included because that would really be too much.
    However, I just noticed that I should make a difference between Strict and Transitional (there are some non-deprecated attributes (edit and element types not allowed in the Strict version).
    There are more differences between Strict and Transitional, especially the content model of elements. (For instance, in Transitional it is allowed to have inline-level content in BODY and FORM, while in Strict they must have block-level content.) I think that if you want to include everything, it would be easier to have three separate sheets; one for each flavour. (But I don't see the advantage of having sheets for Transitional and Frameset.)
    Simon Pieters

  7. #7
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...I think I should have had this idea myself


    That would require a separate sheet itself, because there's no real connection between HTML4s %block; and %inline; and CSS's display property. For instance, BR is inline-level that usually has display:block; NOSCRIPT is block-level that (if scripting is enabled) usually has display:none; and so forth. The display property in CSS doesn't change the rules of the markup language.
    This isn't what I wanted to say. I only meant that I used the CSS properties whenever I wasn't sure where to put an element because the HTML Spec says the following:

    By default, block-level elements are formatted differently than inline elements. Generally, block-level elements begin on new lines, ...
    which is the case if you use display:block; Anyway, it doesn't matter anymore now

    Has that anything to do with INS and DEL? I see these elements more frequently used as inline-level elements than block-level elements, but since both are allowed I wouldn't put them in either.
    Now as I have the exact list of block and inline elements I wanted I will create an additional category (also found a way to free up more space).

    The entity references do take up valuable space, don't they? As well as the deprecated elements and attributes...
    Yes, they do....anyway, first of all I have to clean up the inline-block-other-thing.

    There are more differences between Strict and Transitional, especially the content model of elements. (For instance, in Transitional it is allowed to have inline-level content in BODY and FORM, while in Strict they must have block-level content.)
    I just noticed that and already adjusted the sheet. I will let you know when I uploaded the new and corrected version

    I think that if you want to include everything, it would be easier to have three separate sheets; one for each flavour. (But I don't see the advantage of having sheets for Transitional and Frameset.)
    No, that's a bad idea. I did it like that now: All elements and attributes which are deprecated get a *. All elements and attributes which exist in Transitional but not in Strict also get a *. So all things "you should not use" have a *. FRAME and FRAMESET are included anyway, but I think everyone knows that they are to be used with Frameset DTD.

  8. #8
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    Nevertheless the display-modes of CSS are related to the element-levels in HTML.
    Not really. There are default rules that make block-level elements generate block-level boxes, and inline elements generate inline boxes, but that's all. You can change that around any way you like using the display property.

    And as zcorpan said, do not use character entities in XHTML. An XML parser is not required to read the DTD (where the entities are defined) and most don't. There is no guarantee than a character entity other than the five standard ones will work in an XHTML document, and they may very well cause a fatal well-formedness error. Use numeric character references instead.
    Birnam wood is come to Dunsinane

  9. #9
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    Not really. There are default rules that make block-level elements generate block-level boxes, and inline elements generate inline boxes, but that's all. You can change that around any way you like using the display property.
    I know....the only connection I mean is that most block-level HTML elements have the display:block-property in CSS by default (the same applies to inline elements).

    And as zcorpan said, do not use character entities in XHTML. An XML parser is not required to read the DTD (where the entities are defined) and most don't.
    I will keep that in mind, but since at least the browsers know all entities I don't think it is a problem to use them on webpages. In fact I feel not very comfortable replacing the memorable entities by numerical ones but I will think about it :'(

    Btw, the corrected version is uploaded now.

  10. #10
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    since at least the browsers know all entities I don't think it is a problem to use them on webpages.
    I think Safari doesn't support entities for XHTML, and Mozilla will sniff for the public identifier in the DOCTYPE declaration and serve the parser with the external entities if there's a match; it doesn't actually read the DTD like IE does. And if browsers would read the DTD it would slow down the page horribly...

    You can of course use entities on the authoring side, but make sure to convert them to either NCRs or UTF-8 characters before you serve it over the wire. Or you could just type:
    Code:
    data:text/html,&reg;
    ...in the addressbar in your browser and then copy the character to your editor.

    The HTML element in XHTML must have the xmlns attribute. (It is not #REQUIRED in the DTD because it is #FIXED, and you can't specify both fixed and requied in a DTD... The spec says that conforming documents must have the namespace declaration. Omitting it is like using entities; you rely on the DTD, and that sort of defeats the purpose of XML...)

    Otherwise the updated version looks good.
    Simon Pieters

  11. #11
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan
    You can of course use entities on the authoring side, but make sure to convert them to either NCRs
    Never heard of that...what is it?

    Or you could just type:
    Code:
    data:text/html,&reg;
    ...in the addressbar in your browser and then copy the character to your editor.
    That's interesting
    Anyway, I think entities are more comfortable. Maybe I really change them all to numerical ones...

    The HTML element in XHTML must have the xmlns attribute. (It is not #REQUIRED in the DTD because it is #FIXED, and you can't specify both fixed and requied in a DTD... The spec says that conforming documents must have the namespace declaration. Omitting it is like using entities; you rely on the DTD, and that sort of defeats the purpose of XML...)
    Yes, I think adding this attribute is a good idea.

    Otherwise the updated version looks good.

  12. #12
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    Never heard of that...what is it?
    NCR stands for numerical character reference.
    Simon Pieters

  13. #13
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    I will keep that in mind, but since at least the browsers know all entities I don't think it is a problem to use them on webpages.
    I seem to recall that some recent versions of Opera don't support named character entities in XHTML (I'm talking about real XHTML of course, served as an application of XML with the proper namespace).

    I doesn't really matter anyway. You can never guarantee that entities will work will XML. The sooner you start using NCRs the better.
    Birnam wood is come to Dunsinane

  14. #14
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I seem to recall that some recent versions of Opera don't support named character entities in XHTML (I'm talking about real XHTML of course, served as an application of XML with the proper namespace).
    Opera 8.01 (if this is recent for you) supports them.

    Quote Originally Posted by AutisticCuckoo
    I doesn't really matter anyway. You can never guarantee that entities will work will XML. The sooner you start using NCRs the better.
    I still don't like them
    Anyway, I am working on a cheat sheet version which has the numerical ones.

  15. #15
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, I am finished now.

    Standard version: http://cdburnerxp.se/htmlcheatsheet.pdf
    NCR-version: http://cdburnerxp.se/htmlcheatsheet-ncr.pdf

    I hope that everything is OK. If so, I call those sheets "final" for now.

  16. #16
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    I still don't like them
    Niether do I. Although I also dislike entity references... I rather use the real characters as UTF-8.
    Quote Originally Posted by Floele
    I hope that everything is OK. If so, I call those sheets "final" for now.
    Good work!
    Simon Pieters

  17. #17
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan
    Niether do I. Although I also dislike entity references... I rather use the real characters as UTF-8.
    I also like UTF-8 but the problem is that most of the characters are not on my keyboard

    Good work!
    Thanks...and also thanks for your help improving it

  18. #18
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In case you missed my edit in #4, SCRIPT is also allowed where block-level elements are expected and inside HEAD. The DTD puts SCRIPT in %inline because it is always allowed where inline elements are expected but that's not the full truth... Perhaps you don't want to edit the sheet again but SCRIPT fits better in "other elements" IMHO. Sorry.
    Simon Pieters

  19. #19
    Non-Member
    Join Date
    Jul 2005
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    yep i agree

  20. #20
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan
    In case you missed my edit in #4,
    I probably did

    SCRIPT is also allowed where block-level elements are expected and inside HEAD. The DTD puts SCRIPT in %inline because it is always allowed where inline elements are expected but that's not the full truth... Perhaps you don't want to edit the sheet again but SCRIPT fits better in "other elements" IMHO. Sorry.
    I already updated the sheet. I also think that it is better because script and style are together in one category then.

  21. #21
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    Opera 8.01 (if this is recent for you) supports them.
    I know (that's what I'm using!), but I think 7.54 may not have and it's still used quite a lot. The point was that entities are unreliable.
    Birnam wood is come to Dunsinane

  22. #22
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    I know (that's what I'm using!), but I think 7.54 may not have and it's still used quite a lot.
    I am sorry, but (my) Opera 7.54 supports them

    The point was that entities are unreliable.
    Yes, I got that.

  23. #23
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Floele
    I am sorry, but (my) Opera 7.54 supports them
    Even for true XHTML? Well, it was probably an earlier one then, like 7.11 or 7.23.
    Birnam wood is come to Dunsinane

  24. #24
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    Even for true XHTML?
    Yep.

    Well, it was probably an earlier one then, like 7.11 or 7.23.
    Looks like 7.23 doesn't work. But this version is quite old now.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •