SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 26
  1. #1
    SitePoint Guru team1504's Avatar
    Join Date
    May 2010
    Location
    Okemos, Michigan, USA
    Posts
    732
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    showing different html source based on browser

    I am having some serious issues with firefox & opera not accepting styles on html5 elements.
    I am looking everywhere for help and I can not find any myself, so I am turning to the different forums of sitepoint-- my favourite place for web help, discussion, and pretty much everything els.e

    Anyway, In short, I have a site that I am working on in html5 that has some styling to some of the html5 elements. However, in firefox and opera the styling doesnt work and these elements will appear to be gone or disappear.

    When those parts are written in html4 with ids and classes to refer to them specifically then the styling works in all modern-browsers, but I would like to use as much html5 as I can.
    Is there anyway I can display one version of html if the browsers is chrome/safari and display another if it is not those browsers?

    I have a more detailed explnation and a link to the code in content here:
    http://www.sitepoint.com/forums/show...57#post4735257

    I have asked for some help using scripting languages in said sub-forums, but I was wondering if there is any way one could do this in html, even though html is a tag language and not a logic-language, or if anyone here knows any solutions to this issue.

    I would greatly appreciate it.

    Thanks in Advance and Best Regards,
    Irfan Mir.

  2. #2
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As Paul mentioned in that other thread, you need to set the display to block. Remember, all html elements make up an inline string without style rules. Only browser configuration or its internal style sheet makes certain elements otherwise (cf. lynx.cfg to [path to Firefox]/res/html.css). To demonstrate, mv html.css html.css.orig, and view a page in Firefox. (mv is rename in the common inferior os )

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  3. #3
    SitePoint Guru team1504's Avatar
    Join Date
    May 2010
    Location
    Okemos, Michigan, USA
    Posts
    732
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Thank you Gary.
    Especially for this:
    Remember, all html elements make up an inline string without style rules. Only browser configuration or its internal style sheet makes certain elements otherwise (cf. lynx.cfg to [path to Firefox]/res/html.css). To demonstrate, mv html.css html.css.orig, and view a page in Firefox.
    It helped me in understanding what paul did.

    so, when there are default styling for certain elements, that css reset sheets aim to remove, come from the browser not the element being used in the code itself?

  4. #4
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ... come from the browser not the element being used in the code itself?
    Correct. The html says nothing at all about rendering the content; only about what the content is.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  5. #5
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Remember, all html elements make up an inline string without style rules.
    I can certainly think of a few html elements that are not related to string in any way shape or form.

    Quote Originally Posted by gary.turner View Post
    Only browser configuration or its internal style sheet makes certain elements otherwise (cf. lynx.cfg to [path to Firefox]/res/html.css).
    That's pure eccentricity

    A css declaration of display: block; on a <div> element from the html.css file doesn't really make the <div> element a block level element! It seems you are implying just that. If so...

    html.css is just another external css file. If I make another css file and in it I put display: inline; for <div>, will that make <div> an inline element?

    html.css it's just a feature, an opportunity for the user to play with default style, it doesn't prove anything.

    The correct answer lies in OO. The string class may be superclass for a number of classes of html elements .

  6. #6
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Correct. The html says nothing at all about rendering the content; only about what the content is.

    cheers,

    gary
    Another one

    HTML says EVERYTHING about rendering the content (visual or non-visual)!

    Plus:
    Hmmm, I wonder. What the <pre> element says about what its content is? NOTHING!
    Hmmm, I wonder. What the <div>, <span> are saying about what their content is. ALSO NOTHING!

  7. #7
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,812
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by noonnope View Post
    Hmmm, I wonder. What the <div>, <span> are saying about what their content is. ALSO NOTHING!
    Wrong - they say a lot about the content - the div and span tags in particular will identify exactly what sort of content they contain based on the information contained in the id and/or class attributes on those tags.

    For example <div id="footer"> identifies the content as being the footer.

    You should never use a div or span tag without applying an id or class to identify what that content is (unless the tag is there specifically to get around shortcomings in CSS).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  8. #8
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    For example <div id="footer"> identifies the content as being the footer.
    I'm sorry, but that sounds quirky to me

    The content is an... element? The content is a... concept?


    Quote Originally Posted by felgall View Post
    You should never use a div or span tag without applying an id or class to identify what that content is [...]
    Any reliable sources?

  9. #9
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by team1504 View Post
    I am having some serious issues with firefox & opera not accepting styles on html5 elements.
    Have you tried setting display:block?
    Simon Pieters

  10. #10
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    You should never use a div or span tag without applying an id or class to identify what that content is (unless the tag is there specifically to get around shortcomings in CSS).
    I doubt the w3c validator will require a div or span to have an id or class.

    I would normally give a div or span an id and/or class because it is most likely needed for css and/or javascript.

    But if the div or span didn't need an id or class for any reason another option is to simply add comments in the html to describe the purpose of the div or span.

  11. #11
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Kalon View Post
    I doubt the w3c validator will require a div or span to have an id or class.
    No, in just the same way that it won't slap you down for using layout tables, <h1> tags for body text or any other unsemantic nonsense. Felgall's point, if I've understood it, is that you shouldn't just be slapping down <div>s and <span>s unless they need to be there. In most cases, they will have a class or ID applied, which is used as a hook for CSS or Javascript. Sometimes the <div> or <span> will be unnamed but implicitly referenced as a child selector or getElementByTagName.

    On the other hand, there are a huge number of pages out there stuffed full of <div>s and <span>s that do have classes and IDs but are totally unnecessary, as the same properties could be applied to parent, child or alternative elements to achieve the same effect but in a more efficient and more semantically appropriate way.

    So I would re-state the point as "You should never use a <div> or <span> unless you need to".

  12. #12
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by noonope
    A css declaration of display: block; on a <div> element from the html.css file doesn't really make the <div> element a block level element! It seems you are implying just that. If so...

    html.css is just another external css file. If I make another css file and in it I put display: inline; for <div>, will that make <div> an inline element?
    My understanding of Gary's comment was that if you remove your browser's default stylesheet (which he showed how to do in his post, just rename the browser's stylesheet so it can't find it anymore), then all elements will jumble together as if they were styled like inlines.

    Not saying that a div is an inline element, but that it won't *look* like a block element if you remove the browser's default stylesheet.

    This explains why browsers like FF and Opera who don't understand HTML5 elements are "not styling" them... by default any <foo> they don't understand gets shown as if it's inline (just as they do with all the others if you take away their default stylesheets). This is why Team has to set those new HTML5 elements to "display: block" as most of his styles likely require/expect them to be blocks.

    Browsers who "understand" HTML5 basically have those elements already pre-styled in their default stylesheets as blocks.

  13. #13
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No, no, no, no...

    I'm saying that gary tries a bogus explanation, that does more harm than good.

    1. You can remove the browser's default style because of the browser's modularization, not because html, rendering, semantics, Ursa Major or global warming And the removal only proves the modularization works, nothing more, nothing less.

    2. When html specs say that an element is block level, it has nothing to do with css style, right?

    3. The proper explanation would be:

    firefox & opera treat unknown elements like inline elements!

    It has little to do with html5 (only recently it does, since it introduced new tags) and all to do with xhtml (which presented the issue long before), where you can define your own tags and make your own elements.

    Right?

  14. #14
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Yeah. But that's what Gary said:
    Remember, all html elements make up an inline string without style rules.
    Inline string... what you see on the screen when the browser doesn't have a default stylesheet*. Explaining to Team what FF and Opera are doing here with the HTML5 elements.. yes, because they are unknown to those browsers, or more precisely, they are unstyled in their default stylesheets.

    1. You can remove the browser's default style because of of the browser's modularization.
    Isn't that what Gary said? He even showed how to do it (in one of those superior OSes : )

    *more accurately, their contents. Obviously if they're empty you won't see them at all.

  15. #15
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe you're making the same mistake. You should know that: ALL != UNKNOWN !

    1. Not all html elements are reduced to inline strings when the html.css is messed with. Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!. There are elements having nothing to do with strings: forms.css.

    2. We talk about a technical implementation, not the actual standing case. The fact that some html elements may have the same superclass: string (like Object Java superclass). But that doesn't reduce them to the superclass when I mess with the technical implementation (if I was to remove some jar files, that will imped proper display of some objects, this will not change the way Java defines them). Which you're suggesting. And gary did too. Wrongly so. Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!

    3. Tempering with the technical implementation doesn't redefine any at all. It just proves you can mess up with it. That's all Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!

    Right?

  16. #16
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!.
    Nah. The specs say what can go in what. But that doesn't actually stop anyone from
    <a href="foo"><div> lookee mee</div></a>

    The rules are based on what the w3c calls a "block" and what it calls an "inline" but how they display is still purely from the default browser stylesheets (and luckily they mostly make W3C blocks look like blocks and W3C inlines look like inlines).

    Comment #2, I don't do Java, but it ends with the same arg as #1 so I'll count my answer to #1 and #2 together : )

    Tempering with the technical implementation doesn't redefine any at all. It just proves you can mess up with it. That's all
    Yeah, and? Isn't that what we're all saying?

  17. #17
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    NO!

    Did I say that specs don't say what goes in which? NO! In fact I said that by using and tempering with technical implementation you're trying to contradict the specs to prove a bogus point.

    Let me remind you:

    You're saying that by tempering with technical implementation (removing html.css) you can prove all html elements are inline strings. WRONG! There are elements that have no string content or have nothing to do with string at all. You might as well make an external css with all inline and link it to your page and say: "Look, all html elements are inline text!" IT'S THE SAME THING WITH REMOVING HTML.CSS!!! It's only manipulating the implementation, it's not proving anything useful.

    You used that to prove how come you need display:block for an element that happens to appear in html5 specs and is unknown to firefox&opera. WRONG! HTML5 has little to do with it, XHTML does since before and display:block, in any external css file, including html.css, has nothing to do with redefining an element as being a block level or not, as you imply.

    You're saying because unknown elements are treated like inline all elements are treated like inline. WRONG! All elements is not the same with unknown elements.

    WRONG! WRONG! WRONG!


    Quote Originally Posted by Stomme poes View Post
    The rules are based on what the w3c calls a "block" and what it calls an "inline" but how they display is still purely from the default browser stylesheets (and luckily they mostly make W3C blocks look like blocks and W3C inlines look like inlines).
    This is the biggest of them all!
    The default browser stylesheets are based on HTML specs. If you remove the default stylesheet you ignore the specs. And block or inline have exact specific meaning for all of them not because of luck

    You should make a distinction between theory and implementation. Implementation may seem to coordinate the theory or contradict it, but the theory stands as the base for the implementation.

    You can do wrong things with the implementation but that will not change the theory.


    HTML === HyperTEXT Markup Language. TEXT! It must have a default visual presentation! First! because it must be written in the first place. And HTML specs are there to offer you a default visual presentation. Which is not about font, pixel or em sizes, colours or anything specific like that. It has to do with block or inline, with h1 being bigger that h6, etcetera.

    You cannot ignore that, not for aural reasons nor for any other current hypes

  18. #18
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    You're saying that by tempering with technical implementation (removing html.css) you can prove all html elements are inline strings.
    No, not that they ARE inline strings, but that that is what a browser is left with if it doesn't have a default stylesheet.

    in any external css file, including html.css, has nothing to do with redefining an element as being a block level or not, as you imply.
    Redefining and element?

    All elements is not the same with unknown elements.

    WRONG! WRONG! WRONG!
    Dr. Robotnik demands an explanation?

    Show me and I shall convert!

    The default browser stylesheets are based on HTML specs.
    I would hope so, though of course it's that vendor's view of the HTML specs.

    If you remove the default stylesheet you ignore the specs.
    I disagree, because I don't believe a browser stylesheet is necessary to acknowledge the HTML specs. All I need is HTML for that.

    HyperTEXT Markup Language.
    You meant HyperText MARKUP Language right? Markup.

    It has to do with block or inline,
    Yes, the specs state those things.

    with h1 being bigger that h6, etcetera.
    No.
    <!ENTITY % heading "H1|H2|H3|H4|H5|H6">
    <!--
    There are six levels of headings from H1 (the most important)
    to H6 (the least important).
    -->

    <!ELEMENT (%heading;) - - (%inline;)* -- heading -->
    <!ATTLIST (%heading;)
    %attrs; -- %coreattrs, %i18n, %events --
    >
    It says which is important, but not which is larger.

    Later it says is "Visual browsers usually render more important headings in larger fonts than less important ones." A descriptive statement of fact, but not proscriptive (it does not say they must, or even that they should).

  19. #19
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Show me and I shall convert!
    That sounds kinky! Can we do something like this in here?


    Code:
    1. <!ELEMENT DIV - - (%flow;)*            -- generic language/style container -->
    
    2. <!ENTITY % flow "%block; | %inline;">
    
    3. <!ENTITY % block
         "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
          BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
    If for you the word block has absolutely no meaning but a notional conceit, I believe I have now two english languages to learn, one I've never heard of

    You seem to get thrown off by the fact that CSS exists. But CSS role is to improve.

    You seem to get thrown off by specific font, pixel value, colours and consider them as default style for html elements. No, default style is this: block, inline, bigger importance etcetera. All these get materialized in a general visual style and are defined in html specs Basic visual style for TEXT. By MARKUP. It's nothing about "we all consent to this" specific visual style: 16px, blue colour for links etcetera.

    You seem to get thrown off by technical implementation over theoretical implementation.

  20. #20
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D View Post
    So I would re-state the point as "You should never use a <div> or <span> unless you need to".
    That I totally agree with

    but what felgall said was totally different in that every <div> and every <span> should have an id or class (unless the tag is there specifically to get around shortcomings in CSS).

    Originally Posted by felgall
    You should never use a div or span tag without applying an id or class to identify what that content is (unless the tag is there specifically to get around shortcomings in CSS).
    I don't agree with that at all and suggested you can use html comments instead if you choose to which imho enable you to provide a more meaningful description of the elements' contents than an id or class do.

  21. #21
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It appears some philosophy came along and blurred things up a bit.

    So, my point is, that for a thing like this:
    Quote Originally Posted by gary.turner View Post
    Remember, all html elements make up an inline string without style rules. Only browser configuration or its internal style sheet makes certain elements otherwise (cf. lynx.cfg to [path to Firefox]/res/html.css). To demonstrate, mv html.css html.css.orig, and view a page in Firefox. (mv is rename in the common inferior os )

    cheers,

    gary
    to be looked upon as stupid and wrong, you only need to take a look at what the specs are saying:

    Code:
    <!--================== HTML content models ===============================-->
    
    <!--
        HTML has two basic content models:
    
            %inline;     character level elements and text strings
            %block;      block-like elements e.g. paragraphs and lists
    -->


    This defines a general visual style, w/o being specific as to how font, colour, whitespace should look and measure up. But it does imply a certain visual style that, I think, it's pretty clear to everyone.

    This is where most people seem to mix-up: between default style apparent from specs and some commonly agreed upon specific default stylesheet: 16px, blue text for links, etcetera.

    Inline and block have nothing to do with Firefox's html.css. Furthermore, the way firefox&opera treat unknown elements is not to be regarded as a hint towards demonstrating a general rule, a wrong one nonetheless.

    Yes, you can temper with UAs modularization by hidding html.css. That only proves that you know how to cause a malfunction

    Yes, you can alter html.css. That only proves a feature, a technical one

    Yes, you can make an external css stylesheet and rule all html elements be displayed inline. That doesn't mean all html elements are basically inline, it only demonstrates you have freedom in coding

  22. #22
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,812
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Kalon View Post
    That I totally agree with

    but what felgall said was totally different in that every <div> and every <span> should have an id or class (unless the tag is there specifically to get around shortcomings in CSS).
    It is not totally different at all - just that I was stating what the end position looks like and Stevie D explained it in terms of how to get to that end point.

    When you only use divs and spans when you absolutely have to then they will either have an id or class applied to them or they will be there to provide an extra hook for the CSS to use. Any div or span that doesn't have an id or class and which isn't there to resolve CSS shortcomings is unnecessary and should be removed.

    The id or class basically defines what tag you would be using if you could define all the tags you need. Far more appropriate than using a comment since a comment doesn't allow someone to come along and style your 'custom tag' differently.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  23. #23
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    It is not totally different at all -
    A wise person once told me

    Say what you mean and mean what you say
    I can only reply to what you actually said and not what you meant to say.

  24. #24
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Wrong - they say a lot about the content - the div and span tags in particular will identify exactly what sort of content they contain based on the information contained in the id and/or class attributes on those tags.
    Wrong - the div and span tags have a clear and universally accepted definition and meaning, enforced by definitions in specs. The id and class attributes have a personal and subjective meaning, are usually undocumented, and therefore are only useful in a personal reference system.

    It's like with XHTML new tags, you may or may not be able to decipher their meaning. You can understand their meaning for sure only when an additional DTD info is present.

    So, when you say that div and span id the content based on id and/or class attributes values, you're saying you should provide more id and class DTD info to make your self universally understood. I believe you're not doing so, and instead you're basing your whole theory on an assumption: english id/class attributes values have the same weight as documented english tag names. Wrong.



    Quote Originally Posted by felgall View Post
    For example <div id="footer"> identifies the content as being the footer.
    For you. For an english language aware person. Let's see I am not, in any way or extent, an english language person. How will I make my self clear to the rest of the web? For example <div id="subsol"> The id value alone will suffice to make you understand what sort of content it has? No.

  25. #25
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Obviously there are few times where you don't need to add the class or id attributes as they can be both generic language and style containers. The DIV and SPAN does not impose any presentation semantics besides block-level and Inline. I think that has been completely demystified now.

    It probably got lost in translation that Gray probably meant association with a style sheet language and DTD to perform rendering. As obviously markup itself cannot render content; it is just "plain text" nothing more - there is no argument it is a plain fact.

    It is only when you apply both the DTD and the Style sheet Language (including user-agent style sheet) you will see any display/rendering differences (in a visual browser or other UA) AND applied semantics respectively.

    Some people were talking about; rendering, some about pure markup and others about rendered HTML via the browser and DTD. All completely different topics! That probably explains why there was a semi-pointless debate going on due to language misunderstandings.

    Hopefully that should clear things up?


Tags for this Thread

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
  •