SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 70
  1. #26
    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 RamsayX
    Ok so basically if you're not using XML at all on a page, but just HTML content, you shouldn't use XHTML?
    Since IE/Win, which is by far the most common browser out there, doesn't support XHTML at all, I think XHTML is more or less useless except for niche sites or intranets where you know all visitors use a more capable browser.

    If you want to use elements from other XML namespaces, such as MathML or SVG, you must use XHTML. You can't include those in HTML, because it's not XML and it doesn't support namespaces.

    If you don't need to this, I think you should use HTML 4.01 Strict, which is the latest recommendation with widespread support.

    The thing to remember is that XHTML is XML.
    It's not 'HTML that looks like XML,' it's 'XML that looks like HTML.'

    Quote Originally Posted by RamsayX
    I'm like the above people who have been using XHTML because the code is much cleaner and structured nicely.
    How can the code be cleaner, when you have to add stuff to it?

    The structure is the same. XHTML is a 'reformulation of HTML as an application of XML.' In other words, it's XML that includes the exact same element types as HTML, so the document structure is the same. In HTML, you may omit certain tags (not that I recommend that you do so), but the corresponding elements are still created. See Gez Lemon's Required Elements, and Required Tags for an easy-to-grasp explanation of this concept.

    Quote Originally Posted by RamsayX
    Using HTML 4.01 Strict, does the code need to be structured the same? Lowercase tags, self-closing tags, etc ... ?
    You don't have to use lowercase tags in HTML, but any self-respecting author is at least consistent. I always use lowercase tags and attributes in HTML.

    You don't have self-closing tags in HTML, because they are not allowed. HTML defines SHORTTAG YES in the SGML FEATURES section, so <br/> means <br>&#38;gt;, i.e., a BR element followed by a greater-than character. Most browsers parse this incorrectly, which is why you get away with XHTML markup served as text/html.

    Quote Originally Posted by RamsayX
    But I thought XHTML was a good thing?
    It is – at least in theory. It's extensible, which HTML is not. But extensibility is not quite as useful as you'd think. Sure, I can define and use my own elements, but how is a browser supposed to understand what it is? You can't define semantics in a DTD or an XML Schema.

    For extended markup, you'll need some sort of plug-in until it's been incorporated in the browser itself. Like you do with MathML today, for instance.

    Quote Originally Posted by RamsayX
    It stopped all the sloppy coding that HTML was so forgiving to (the browsers that is, not HTML).
    Really?
    I've seen tons of very sloppy markup that purports to be XHTML. If it were to be served as real XHTML, all you'd get would be a big, fat error message.

    Quote Originally Posted by RamsayX
    Thats why I made the transition to XHTML. Now you're saying that was all a waste of time?
    Not necessarily. You've probably learned a better way to write markup, and perphaps you've also learned about semantics and about the separation of structure from presentation and from behaviour. That is a good thing. It is fully possible in HTML, too, but there hasn't been much of an incentive to use it there because of forgiving parsers and clever rendering engines.

    But you can write HTML 4.01 Strict that is essentially identical to XHTML 1.0 Strict (except for the self-closing tags). That's what I do. When (if?) XHTML 2.0 becomes a reality and there is enough user agent support for it, I have no more extra work than those who have written XHTML.

    Quote Originally Posted by RamsayX
    So to put it very bluntly, if theres no XML being used on a page (which I don't have because I haven't learned XML yet, its on my list of many things to study) ALWAYS use HTML 4.01 strict?
    That's what I would recommend, but write that HTML 4.01 Strict as if it were XHTML 1.0 Strict (again minus the self-closing tags).

    You can use XHTML if you like, even if you serve it as text/html, as long as you make sure that it also works when served as application/xhtml+xml. That last part is very important, because if it doesn't, then you're not 'future-proofing' your markup at all.

    The markup is the least of your problems, though. You need to know the differences in how CSS is applied in XHTML vs. HTML. You also need to understand how scripting is different (those differences are much more pronounced than those in CSS). You also need to understand why you cannot use named character entities (like &#38;ndash;) in XHTML, etc.

    Quote Originally Posted by RamsayX
    I don't see the point of html transitional ...
    Neither do I. And I definitely don't see the point of XHTML 1.0 Transitional.

    Quote Originally Posted by RamsayX
    As a side point, I would like to understand why I've never had a page get destroyed by IE
    Most likely it's because you serve your pages as text/html, so you're using HTML instead of XHTML. IE supports HTML (well, mostly).

    Quote Originally Posted by RamsayX
    I've seen these examples of pages that IE would just show the document tree, but thats never happened to me. Is that because I've made sure they validated?
    No, validation has nothing to do with it. It's because you're not using XHTML but HTML.

    If you serve application/xhtml+xml, IE/Win will prompt you to download the document, because it doesn't know what to do with that MIME type. If you serve application/xml or text/xml, IE will treat it as XML (but not XHTML, since it doesn't understand the XHTML namespace). Without a style sheet, IE will then display the DOM tree. If you supply a style sheet, it will be applied, but since IE is treating the document as generic XML, it doesn't have a default style sheet, so you'll have to set display:block and margins etc. for your paragraphs and other block-level element types. It's not worth it.

    Quote Originally Posted by RamsayX
    Two more questions, pages that are using an XML-driven CMS like Movable type, should I use XHTML strict or better yet XHTML 1.1?
    I think you should use HTML 4.01 Strict, unless you actually need XHTML.
    If you decide to use XHTML, go with XHTML 1.0 Strict.

    Quote Originally Posted by RamsayX
    One more, how do you actually serve the document as application/xhtml+xml;? I don't understand "using the headers to serve it" thing.
    When a user agent (e.g., a browser) requests a page from a web server, the server sends an HTTP response. This response consists of one or more headers, a blank line, and then the body (that's your markup).

    The first header contains the status code (like '200' for 'page found') and some information about the HTTP version number etc. There can be other headers as well, for controlling caching and so on. Cookies are set through HTTP headers, too.

    One important header is Content-Type. It tells the user agent what sort of content comes in the HTTP body, and, optionally, what character encoding is used. For an HTML document, it usually looks something like this:
    Code:
    Content-Type: text/html; charset=iso-8859-1
    If you want to use real XHTML, it should look like this:
    Code:
    Content-Type: application/xhtml+xml
    You must instruct the server to send this header, because web servers usually default to text/html. How you do that depends on what web server you're using and which server-side scripting language (if any) you're using.

    One way is telling the server to associate certain file extensions with a certain MIME type. With Apache, you can do that in the httpd.conf file or in local .htaccess files using the AddType directive:
    Code:
    AddType application/xhtml+xml .xhtml .xht
    This will make the server send the application/xhtml+xml MIME type for files ending with '.xhtml' or '.xht'.

    Another way is to send the header yourself, using a server-side scripting language. In PHP, you can use the header function:
    PHP Code:
    header('Content-Type: application/xhtml+xml'); 
    Note, however, that you cannot specify the content type using a meta element with an http-equiv in your document. The browser needs to know the content type before starting to read the document, in order to choose the proper parser.

    If the server sends text/html, the browser will choose its HTML parser and start parsing the document. When it reaches a line like this:
    HTML Code:
    <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"/>
    it's too late to change parsers. In theory, it could switch to the XML parser and start over, but AFAIK no browser does that.
    Birnam wood is come to Dunsinane

  2. #27
    SitePoint Wizard mPeror's Avatar
    Join Date
    Mar 2005
    Location
    Saudi Arabia
    Posts
    1,724
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Seems like we got another Paul O'B for the HTML/XHTML forum

    You've done a great job explaining things AutisticCuckoo. Perhaps you should correct the common misunderstanding of xHTML in a new thread so that the admins sticky it? just a suggestion

  3. #28
    SitePoint Addict RamsayX's Avatar
    Join Date
    Oct 2003
    Location
    Canada
    Posts
    324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    AC, thanks very much on taking that time to write back and help me understand this thing.

    I'm not trying to make you look silly but when I tried the php header serving, IE seems to be treating my page just fine ... www.ramsaystudios.ca. I used this code:
    Code:
    <?php
    // To test for serving this document as a real XHTML document, in order to "future-proof" the page.
    	header('Content-Type: application/xhtml+xml'); 
    ?>
    I'm only trying it just to see what happens and learn from it. I find it interesting that IE is working fine so far, but in Firefox theres a background problem, where the bg colour doesn't run all the way down the page. Now I know you mentioned that CSS is applied differently with HTML and XHTML, is there a reference page somewhere where I can learn these specific differences? Thanks.
    Personal Portfolio
    Paul O'B is the CSS god

  4. #29
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's odd. I looked at the page, and it is indeed served as application/xhtml+xml, so if that code is unconditional, IE should be in trouble.

    There is a registry hack that makes IE accept application/xhtml+xml (still treating it as HTML, though). Did you run that, by any chance? Did you clear IE's cache? Maybe you're seeing a cached HTML version?

    I can't try it in IE at the moment (can't seem to find a Linux version ).
    Birnam wood is come to Dunsinane

  5. #30
    Non-Member
    Join Date
    Jan 2005
    Location
    Netherlands
    Posts
    4,300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello

    at the moment I get a download page request in IE

    www.ramsaystudios.ca

  6. #31
    SitePoint Addict RamsayX's Avatar
    Join Date
    Oct 2003
    Location
    Canada
    Posts
    324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey guys, ok now its prompting me to download the page, interestingly enough even though I'm sure I cleared the cache yesterday when trying this thing out. I guess I couldn't have ...

    I changed it back to text/html ... now I understand why XHTML isn't a good idea, yet. One more reason to hate IE I've been reading the IEblog but I don't remember seeing any reference to them fixing the xhtml problem, do you know if they plan to fix that? For IE7 perhaps?

    Also do you know of any reference pages where I can learn the differences between CSS for HTML and XHTML? Thanks AC.
    Personal Portfolio
    Paul O'B is the CSS god

  7. #32
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IE7 will not support XHTML. It will take a fundamental rewrite of the IE engine for that, not only 'lipstick on a pig' which is basically what they're doing now (cosmetic changes to the flawed IE6).

    The differences for CSS aren't that big. They can be summarised as follows:
    1. Element type selectors are case-sensitive, so a selector like UL will not match an unordered list (you must use ul).
    2. In HTML, some elements are present in the DOM tree even if the corresponding tags are not. That is not the case with XHTML. Your selectors won't match a tbody unless you have explicit <tbody>...</tbody> tags in your markup.
    Birnam wood is come to Dunsinane

  8. #33
    Non-Member
    Join Date
    Jan 2005
    Location
    Netherlands
    Posts
    4,300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    IE7 will not support XHTML. It will take a fundamental rewrite of the IE engine for that, not only 'lipstick on a pig' which is basically what they're doing now (cosmetic changes to the flawed IE6).

    The differences for CSS aren't that big. They can be summarised as follows:
    1. Element type selectors are case-sensitive, so a selector like UL will not match an unordered list (you must use ul).
    2. In HTML, some elements are present in the DOM tree even if the corresponding tags are not. That is not the case with XHTML. Your selectors won't match a tbody unless you have explicit <tbody>...</tbody> tags in your markup.
    yeh browser IE is still wasting our time
    Last edited by all4nerds; Jan 1, 2006 at 11:54.

  9. #34
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    3. 'background-color', 'background-image' and 'overflow' on the BODY element in text/html will act as if it was applied on the root element, unless it is specified on the root element aswell.
    For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. For HTML documents whose root HTML element has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of those properties from that HTML element's first BODY element child when painting backgrounds for the canvas, and must not paint a background for that BODY element. This does not apply to XHTML documents.
    -- http://www.w3.org/TR/CSS21/colors.html#q2
    UAs must apply the 'overflow' property set on the root element to the viewport. HTML UAs must instead apply the 'overflow' property from the BODY element to the viewport, if the value on the HTML element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.
    -- http://www.w3.org/TR/CSS21/visufx.html#overflow
    Simon Pieters

  10. #35
    SitePoint Addict
    Join Date
    Dec 2005
    Posts
    276
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If true xhtml must be sent with a content-type header, does that mean that locally saved or written xhtml documents cannot be loaded properly in a browser?
    "Never imagine yourself not to be otherwise than what
    it might appear to others that what you were or might
    have been was not otherwise than what you had been
    would have appeared to them to be otherwise."

  11. #36
    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)
    Well, you can use the *.xht or *.xhtml extension in Firefox which should trigger the XML Parser. In either case vanilla XHTML (which only really needs the well-formedness) can be loaded it's just that it may not be processed as 'application/xhtml+xml' in some user-agents.

  12. #37
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Using a .xht or .xhtml file extension also works in Opera.
    Birnam wood is come to Dunsinane

  13. #38
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...or you could use *.xml.
    Simon Pieters

  14. #39
    SitePoint Addict
    Join Date
    Dec 2005
    Posts
    276
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But then isn't the Mime type a local setting? Why the big issue about servers sending the correct content-type if it is a local setting? If we open a .xhtml file on a server in our browser will it still have the correct content-type?
    "Never imagine yourself not to be otherwise than what
    it might appear to others that what you were or might
    have been was not otherwise than what you had been
    would have appeared to them to be otherwise."

  15. #40
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When you load a resource over HTTP, the file extension is totally irrelevant. The HTTP Content-Type header says what kind of document it is, if the server says that foo.doc is a text/html file then text/html it is!

    When you load a file from disk, there is no such thing as HTTP, thus your operating system will have to tell the browser what kind of file it is. Windows happens to rely on file extensions...
    Simon Pieters

  16. #41
    SitePoint Addict
    Join Date
    Dec 2005
    Posts
    276
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay thanks
    "Never imagine yourself not to be otherwise than what
    it might appear to others that what you were or might
    have been was not otherwise than what you had been
    would have appeared to them to be otherwise."

  17. #42
    Non-Member
    Join Date
    Jan 2006
    Location
    Chicago, Illinois
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    AutisticCuckoo, great information. I use XHTML 1.0 strict on all of my documents, and style them tableless (unless the data is tabular) with css. This might not be proper according to what I read, but it's not hurting anything and it gives me the possibility of sending in true XML later on when it's supported. I also like the syntax for XHTML closing tags /> and such...

    When will we possibly see browsers (Main stream browsers) that support true transfer via xml?

    Also, what exactly is an XML namespace? I tried reading and understanding definition on Wikipedia, but I couldn't. To my understanding, it just lets you use the same names on different attributes, correct?

    Another thing, the xmlns syntax looks like this xmlns:namespace-prefix="namespaceURI" correct? Then why is this at the top of xhtml documents? what does it do? Also, it is not used when transfering xhtml as text, correct?
    HTML Code:
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    Thanks.
    Last edited by Ferrarislave; Jun 12, 2006 at 20:43.

  18. #43
    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 Ferrarislave
    This might not be proper according to what I read, but it's not hurting anything and it gives me the possibility of sending in true XML later on when it's supported.
    Correct, provided that you actually understand the fundamental differences that exist between HTML and X(HT)ML. If you serve it as text/html, and aren't aware of the differences concerning CSS and JavaScript, it can be 'harmful'; you may keep on using HTML-only techniques without realising that they are, in fact, HTML-only.

    Quote Originally Posted by Ferrarislave
    I also like the syntax for XHTML closing tags /> and such...
    Not exactly the best argument for choosing XHTML over HTML.

    Quote Originally Posted by Ferrarislave
    Also, what exactly is an XML namespace? I tried reading and understanding definition on Wikipedia, but I couldn't. To my understanding, it just lets you use the same names on different attributes, correct?
    A namespace in XML is similar to the concept of namespaces in programming languages. It allows you to use the same element type names for different elements.

    For instance, XHTML contains a label element type. If I want to create a WidgetML markup language, I may want to use the same element type to denote the labels on my widgets. By using my own namespace for WidgetML, I can do that, and XML-compliant user agents will have no problem telling XHTML's label elements from WidgetML's label elements.

    An XML namespace is a URI. XHTML's namespace is http://www.w3.org/1999/xhtml. If you specify a namespace for an element, its descendants will be in the same namespace unless you say otherwise. Attributes, however, do not 'inherit' the namespace of their elements.

    Quote Originally Posted by Ferrarislave
    Another thing, the xmlns syntax looks like this xmlns:namespace-prefix="namespaceURI" correct?
    There are two forms of XML namespace declarations.
    Code:
    <foo xmlns="http://example.com/ns/foo" xmlns:baz="http://example.com/ns/baz">
      <baz:bar/>
    </foo>
    This says that the foo element is in a namespace identified by http://example.com/ns/foo.
    It also declares another namespace (http://example.com/ns/baz) and binds it to the 'baz' prefix.
    The baz:bar element is a bar element in the http://example.com/ns/baz namespace.
    Without the prefix, the bar element would be in the same namespace as its parent (foo).

    So, an xmlns attribute declares the namespace of its element and its descendants. An xmlns&#58;xxx attribute declares a namespace and binds it to a prefix, as a shorter way to refer to that namespace. Without the prefix, the previous example could have been written like this:
    Code:
    <foo xmlns="http://example.com/ns/foo">
      <bar xmlns="http://example.com/ns/baz"/>
    </foo>
    In this case there's no major difference, but if there were more elements in the baz namespace, the first syntax would be much shorter, since you'd use a baz: prefix instead of repeating xmlns="http://example.com/ns/baz" on every element.

    Quote Originally Posted by Ferrarislave
    Then why is this at the top of xhtml documents? what does it do? Also, it is not used when transfering xhtml as text, correct?
    HTML Code:
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    That namespace tells the user agent that the document is XHTML. It says that the html element and all its descendants are in the XHTML namespace.

    A MIME type of application/xhtml+xml, application/xml or text/xml only tells the user agent that the document is some sort of XML. The namespace declaration is necessary to specify that it is, in fact, XHTML. Without that namespace declaration, the document will be generic XML without any known semantics.

    The xml:lang attribute is in the XML namespace, which is bound to the predefined (and reserved) prefix 'xml'. It will take precedence, in XML user agents, over the lang attribute in the null namespace.

    If the document is served as text/html, the xmlns and xml:lang attributes are invalid and will be ignored.
    Birnam wood is come to Dunsinane

  19. #44
    Non-Member
    Join Date
    Jan 2006
    Location
    Chicago, Illinois
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I see, thanks for clearing that up. You seem extremly knowledgeible in this subject, hey they dont give the guru of the year award to anyone It's nice to see somone with your kind of knowledge sharing it with others.

    Thanks. I really had trouble understanding the namespace, but now I do, and im sure I will get a even better understanding of it when I starting using it in the future for things that require it's use.

    What is the actual purpose of sending xhtml via xml, and not text/html? What is the future benefit of this method? Is it just easier for programs to understand XML and it's simplified syntax compared with html, or what?

    Where can I also read more about the "dangers" of JS and CSS with XML transfers, and not html.

  20. #45
    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 Ferrarislave
    What is the actual purpose of sending xhtml via xml, and not text/html?
    XHTML is XML. To be precise, it's an application of XML, which means it's XML with a predefined (but extensible) set of element types and attributes.
    The purpose of serving XHTML as application/xhtml+xml is to tell user agents that the document is XML, so that they can choose to use their XML parser instead of the SGML parser required for HTML.

    Quote Originally Posted by Ferrarislave
    What is the future benefit of this method? Is it just easier for programs to understand XML and it's simplified syntax compared with html, or what?
    The MIME type (a.k.a. content type or media type) informs the user agent about the type of content that is about to follow. A user agent needs to know this before it receives the actual document, to know what to do with it.

    XML's well-formedness rules makes it much easier to parse than HTML. An XML parser can (must, actually) presume that the markup is well-formed, i.e., that there is a closing tag for each opening tag. It can also presume that all attributes have values and that those are quoted. That makes it easy to write the parser, and the parser can be quite small and fast. XML's well-formedness rules also stipulate that the parser must abort if it encounters a well-formedness error.

    HTML's rules are more complex, allowing you to omit certain end tags and even some start tags, plus disallowing some end tags. It also allows attribute values to be unquoted if they only contain certain characters, and it allows attribute minimisation. Those things require a much more complex parser. On top of that, an HTML parser must be able to deal with markup errors and try to do the best it can.

    Quote Originally Posted by Ferrarislave
    Where can I also read more about the "dangers" of JS and CSS with XML transfers, and not html.
    Some are mentioned earlier in this thread. A good introduction is Hixie's article Sending XHTML as text/html Considered Harmful. Lots of XHTML proponents dislike this article and dismiss it entirely, but it's actually spot on (albeit a bit dogmatic).

    The important thing to remember is that XHTML is XML that looks like HTML, not the other way round.

    By following all of the guidelines in Appendix C of the XHTML 1.0 specification, and by relying on bugs in the SGML parsers of most user agents, you can get by with serving XHTML markup as text/html. That's fine (but useless) as long as you make sure that it still works when served as application/xhtml+xml.

    If you use HTML-only practices such as document.write() or the non-standard .innerHTML property, you are abusing XHTML.

    If you use character entity references (like &#38;nbsp;), you're taking chances that you really shouldn't take. Entities are defined in the DTD, which is only read by validating XML parsers. No browser (AFAIK) uses a validating parser, since they're not required to and it doesn't make any real sense.

    Serving XHTML as text/html also lets you get by with certain errors in your CSS, like uppercase type selectors, implied elements, and applying certain rules on the body element that really should be specified for the root element (html).
    Birnam wood is come to Dunsinane

  21. #46
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tommy, thanks for writing up that post on namespaces. I didn't know that there were two ways to specify one.

    Could you explain what you mean by "implied elements"?
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.

  22. #47
    Non-Member
    Join Date
    Jan 2006
    Location
    Chicago, Illinois
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excellent Tommy, simply excellent. Approximetly how long have you been doing xhtml/css?

  23. #48
    SitePoint Wizard bronze trophy Tyssen's Avatar
    Join Date
    Oct 2005
    Location
    Brisbane, QLD
    Posts
    4,067
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    and applying certain rules on the body element that really should be specified for the root element (html).
    Which rules are those?

  24. #49
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tyssen
    Which rules are those?
    See post 34 in this thread.
    Quote Originally Posted by Kravvitz
    Could you explain what you mean by "implied elements"?
    Some start tags are optional in HTML: <html>, <body>, <head>, and <tbody>. The elements are inserted into the DOM even though the start tag isn't present in the source. Those elements are therefore "implied" in those cases.
    Simon Pieters

  25. #50
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Right, but what does that have to do with the CSS?
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.


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
  •