| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Comments:
<0> webben: For most major browsers, XHTML sent as text/html is treated exactly the same as HTML sent as text/html, because the text/html determines how the browser parses the page
<0> The doctype is just some additional information on what elements and attributes may be expected
<1> Nanobot: yes, but it's not really comparable, as the GIF specification does not (AFAIK) attempt to allow GIF to be compatible with PNG, nor does the PNG media type RFC (I ***ume) actually say that GIF data can be sent as PNG
<0> But the rules for parsing and treatment of the page is determined by the content type
<0> webben: The XHTML 1.0 does not have a normative section detailing how an XHTML document may be compatible with true HTML user agents
<1> Nanobot: i _think_ that's right... but because of the complexity of the text/html media type, that doesn't actually simplify the issue much
<1> Nanobot: indeed, it has a section detailing how to make documents compatible with "existing" UAs
<0> Perhaps you missed that part. Appendix C is not normative
<0> Meaning it is not actually a part of the "standard"
<0> It's just informative notes on the side of the standard
<1> Nanobot: i don't think the fact that it is not "normative" means it is not part of the "standard" (though for all i know the W3C may have a specific definition of "normative" which defines it as such)
<0> That's precisely what normative means
<1> Nanobot: sorry but "normative" does not mean "standard". They're vaguely related concepts.
<0> Informative sections are purely that: informative. They note trends and browser tendencies rather than specifications
<1> Nanobot: sorry, i'm just trying to work out if w3c do actually define what they mean by "normative"
<0> Google is being unusually unresponsive for me right now
<1> Nanobot: seems alright where i am
<1> Nanobot: there may be another definition somewhere but from http://lists.w3.org/Archives/Public/public-wai-eo-lexicon/2005AprJun/att-0026/Lex-Corrrections-Draft.htm
<1> we get: "The status of criterion that must be satisfied for conformance with a given specification."
<2> gxti: skwashd: cheater: http://auralmoon.com/playingdetached.php
<2> though it won't be there for long :)
<2> my dedication finally came up
<2> hehe
<1> hmmm... that's not even quite english
<2> (now playing on live.str3am.com:2010 )
<0> An informative section is purely that: informative. It is not a part of the standard, but is rather additional information that may be useful or interesting to someone reading the standard.
<1> They didn't mark it non-normative however, or did they? I wonder if there's a difference between a section not marked normative and a section marked non-normative
<1> For example here: http://www.w3.org/TR/2003/WD-ws-gloss-20030514/
<1> "Acknowledgements" are marked "non-normative".
<0> webben: It was marked as "informative"
<0> Which means it has nothing to do with conformance to the specification
<0> It's just extra info
<1> Hmmm ... judging by my earlier link, that's not quite the same as "non-normative"
<0> In this case, it's just noting that an XHTML document could theoretically be made to render sort of as expected in most major web browsers under certain conditions
<0> Huh?
<1> Non-normative is defined (there) as "That status of information in a specification that is not required for conformance but contributes to the correct use and implementation of the specification."
<1> Whereas Informative is defined as "That status of information in a specification that is not required for conformance but contributes to the correct use and implementation of the specification."
<1> sorry
<1> "non-normative is defined as "The status of descriptions or prescriptions that lie outside the normative criteria of a specification."
<1> so informative may not be normative, but it is not just baguely interesting information
<1> but rather information important for actually using the standard
<1> (unlike acknowledgements? perhaps?)
<0> What page did you get those definitions from?
<1> Nanobot: http://lists.w3.org/Archives/Public/public-wai-eo-lexicon/2005AprJun/att-0026/Lex-Corrrections-Draft.htm
<1> (like i say there may well be better definitions somewhere)
<1> (i tend to find the w3c site very difficult to find the information i want)
<0> That's just a draft of something. I'd like to see a definition from a finished spec
<1> Nanobot: so would i
<0> Regardless, the specifications contradict each other. XHTML 1.0 does not define "a profile of use of XHTML which is compatible with HTML 4.01"
<0> Because of the NET issue, XHTML is inherently incompatible with HTML 4.01
<0> And the XHTML spec clearly says in Appendix C "Note that this recommendation does not define how HTML conforming user agents should process HTML documents."
<0> Therefore, it maintains that HTML conforming user agents should support null end tags and are therefore incompatible with self-closing XHTML tags
<0> Ian Hickson, from the CSS Working Group, at least claims that Appendix C is "non-normative". http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0138.html
<1> Nanobot: yes, i _suspect_ informative does not imply normative but OTOH it's still important information
<1> that said, given Hickson's aggressive stance (however well justified) against serving XHTML as text/html, he's perhaps not the most neutral observer you might have chosen on the matter
<1> As I said, I'm not sure why the null tags issue should be seen as a problem with the XHTML spec rather than the HTML spec however.
<1> (and indeed, sometimes other people do see it as a problem with the html spec, hence the requests for an addition to the errata)
<0> It isn't a "problem" with the HTML spec. It's a feature of SGML.
<0> <title/This is the title of the page/
<0> It's a shorthand method that most major browsers just don't support
<0> It isn't a problem, just a difference between the two languages.
<1> Nanobot: well, it depends what you mean by a "problem"
<0> But the fact that it's a practically unavoidable different shows that XHTML in most cases simply cannot be made compatible with HTML
<0> *difference
<1> Nanobot: a problem in the abstract world of language definition, no; a problem in the real-world of serving xhtml, yes
<0> They are two different languages with different rules
<0> The problem in the real world is that IE and many other user agents just don't support XHTML.
<0> So don't try to use something that things don't support
<0> You don't use MNG because most browsers don't support it.
<1> Nanobot: well yes that's part of the problem to
<1> Nanobot: i don't use MNG because i don't know what it is
<0> The XHTML spec has an informative section saying how an XHTML document could theoretically be made to look right in most modern browsers, but that's it
<1> Nanobot: but i don't tend to not use things because browsers don't support it, as long as there's a workable fallback for browers which don't
<1> (which was what that whole compatibility section was for)
<0> There isn't
<1> Nanobot: isn't what?
<0> Unless you don't mind certain user agents seeing problems all over your page
<0> There isn't a truly workable fallback
<0> You're deliberately causing problems and gaining nothing in the process
<0> Why?
<0> just so you can be "cutting-edge"?
<1> Nanobot: by certain user agents, though, you don't mean browsers ... you mean certain validators
<0> I'm sure some browsers
<0> There are a heck of a lot of browsers out there with varying levels of standards support
<1> Nanobot: the only browser i've heard of which might _possibly_ be confused by null tags was emacs/w3 or whatever it's called .... and i think somebody was gonna patch that (and the last i know about that was from 2003 or something)
<0> You're relying on the fact that major browsers are lacking support for something. It's basically a hack.
<1> Nanobot: yes it's basically a hack
<0> "patch" that? It isn't an error.
<0> webben: You still haven't provided me with one legitimate reason to use XHTML over HTML
<1> Nanobot: Like i said, browser makers are interested in rendering pages, not fulfilling obscure specs
<0> I've given you lots of problems with using XHTML and you haven't given me any benefits
<0> webben: Wrong. It's a balance.
<1> Nanobot: yes it's a balance
<0> webben: Even Microsoft is now willing to break compatibility in the interest of standards compliance
<0> Anyway, give me some reasons for using XHTML sent as text/html
<1> I can easily give you a personal explanation (which may not be satisfactory at all). When I began to seriously get into writing html/css/web stuff that was simply what the web designers I read recommended.
<1> So it was what I learnt
<1> I had learnt html a long time ago at school
<0> And now many of the big names in web design are going back on that
<1> but XHTML is what I know
<3> Well, since XHTML1 sent as text/html and HTML4 have little differences, why not using HTML 4.01 Strict anyways?
<0> So get with the times. Once upon a time, tables were what I knew, but I changed that once I learned the problems with tables
<1> Nanobot: yes, some of them, and they may well be right to do so (although, again, I don't think the null tags issue is a strong enough reason for me to do so)
<1> Nanobot: partly because I just don't see the two issues as in the same ballpark at all
<0> webben: Well you also have to go through nearly twice the amount of testing to be sure it works in the same amount of cases
<1> Nanobot: twice? why twice?
<4> hi
<0> Even if you send a page as text/html, browsers will in some cases turn around and treat it as XML. For instance, if the webpage is saved locally and reopened without the original content type information.
<0> You have to test both cases: HTML treatment and XHTML treatment
<0> If you just use HTML, you don't have that issue
<1> Nanobot: well, yes, ***uming you want your webpages to be saved locally
<0> ...
<0> Some users will want to
<0> All you're doing by using XHTML is creating problems for some users
<1> Nanobot: yes, not all organizations will want that to happen however
<4> I want to do a "fade screen" effect, as I've seen on some website once (can't remember the url though). Actually, I want to create a kind of semi transparent layer (with a one pixel png I think) which would cover the entire page
<1> Nanobot: but i take your point
<0> webben: WTF? If it's a public webpage, some people will do it
<1> Nanobot: that some people will do it, does not imply that the organization will want to make it easy for them (or that they are obligated to do so)
<0> A relatively small percentage of people require certain accessibility features, but you still provide them. Same deal here.
<0> You're making excuses for hurting certain users' experience for no reason
<1> Nanobot: i haven't actually made an excuse for hurting someone else's experience
<0> You still haven't provided me with one benefit for using XHTML instead of HTML
<1> Nanobot: i'm trying to answer points as they come up ... we're hopping and skipping a little here
<0> Well show me a benefit
<1> (which is fine ... just try not to be too impatient with me)
<4> Nanobot: XHTML is parsable, that means screenscraping is much easier to code
<0> Obviously, HTML is parsable too. WHat's your point?
<4> I mean, by a XML parser :)
<0> Well-written HTML is equally as eay to parse as XHTML
<4> of course
<0> A very simple automated transformation will give you XHTML
<0> Parsing valid HTML is trivial
<0> And it's much better from the user's point of view, considering all of the hidden issues with XHTML sent as text/html
<0> My website is completely written in HTML and I run automated scripts on it all the time. It's no more difficult to parse than XHTML
<1> Well, _one_ reason I'd be hesitant about switching to HTML is that I'd be worried is that I'd worry (these may be entirely false fears) that the JavaScript would be different.
<1> for example, with a html doctype ... what happens with dom methods
<0> webben: It is different from true XHTML. But it's exactly the same as XHTML sent as text/html
<0> Like I've said, XHTML sent as text/html is treated *exactly* like HTML
<0> Meanwhile, if you don't test how it behaves when sent as application/xhtml+xml, then you're missing some hidden problems
<1> Nanobot: are you sure? I mean do you actually know exactly whether all the browsers parse them exactly the same.
<0> All of the major ones do
<0> Safari and Konqueror I believe have some slight differences in CSS rules, but they're actually more consistent with other browsers when you use regular HTML
<1> Nanobot: now you see "all the major ones" vs. the one _possible_ one (to my knowledge) which might not like null end tags
<1> Nanobot: see that's very confidence-dampening
<0> WTF?
<0> One possible one that supports null end tags?
<0> Any HTML user agent should support null end tags
<0> Just like any HTML user agent should treat documents sent as text/html as HTML
<1> Nanobot: should, but they don't otherwise <br /> would be parsed as <br>>
<1> (or something)
Return to
#web
or
Go to some related
logs:
#perl
strtol_internal ()
#css
#ubuntu
ubuntu how-to rename folder
fatal error file too large gpart
play supaplex know
PHP+Startup:+Unable+to+load+dynamic+library+%27./mssql.so%27
perl use base unknown error
etch /dev/xconsole
|
|