| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Comments:
<0> (or something)
<1> webben: You're searching for any possible excuse to keep using XHTML because that's what you're comfy with. I've given you many reasons which you're simply trying to trivialize, and you're exaggerating any issues with switching to HTML even though that's what most people use and what most browsers are geared toward
<1> I'm frankly getting tired of arguing about this.
<2> i have HTTP AUTH based authentication. not form based. and browsers cache authentication info and resends them. how do I disable it?
<1> I think I've made my case pretty clear and you haven't provided a single real reason to stick with XHTML
<3> Nanobot: want me to pick it up?
<3> ;p
<1> Sure
<0> Nanobot: well, look you don't have to have an argument about it. You don't have to see it as something where one of us has to convert the other.
<0> Nanobot: that's certainly not how i look at it
<3> so... why /are/ you using XHTML?
<0> gxti: why do you ask?
<3> curious.
<1> I want to say one more thing: You said you're worried about switching to HTML because some browsers *might* treat it differently. That's only true if they were using XHTML-style rules in the first place, which most browsers don't. So the very fact that you were worried about it suggests that you should be worried about using XHTML in the first place, since you feel some user agents might be treating it as real XHTML against yo
<1> ur expectations.
<1> That's additional support for my claim that you have to test twice as many cases
<3> sending XHTML as HTML, but worrying about your HTML being treated differently is just silly :P
<4> nice one gxti .. can I steal that for my sig? :D
<3> go for it
<0> Nanobot: yes it is additional support for that ... although i'm not sure having to test things is inherently bad.
<4> heehee
<3> webben: having to test things is a natural part of any development cycle
<3> webben: having to test MORE things is something you want to avoid
<0> gxti: well, it's something you have to factor in when you decide what to do
<4> particularly if it's easily avoidable
<3> if there's no justifiable reason to keep the features which cause you to test more, then why keep them?
<0> WebDragon|away, well, if it's not avoidable then it's not a choice so it's not a decision
<3> you're not offering more rich content, you're not offering more compatibility (less, actually)
<4> less time testing = quicker the job is finished, client satisfied, and you get paid sooner
<3> oh dear - does this involve a client?
<3> or was that more of a hypothetical situation? ;p
<4> the only way I can see it being unavoidable is if you're doing something like MathML that would require you to use XHTML
<1> webben: No, but the reason for having to test it is. You have one file that's trying to be two different and inherently incompatible things at once. If you don't care about the null end tag issue, then you don't seem to care much about the standards, rather favoring only what most popular browsers happen to do. It's the same mindset as those who use tables for layout or otherwise design sites that don't work in text-only brows
<1> ers or screen readers
<4> barring that, I see it being completely and easily avoidable
<1> Anyway, I'm off to work on Web Devout
<3> Nanobot: toodles
<0> WebDragon|away, well actually i might end up using a custom xhtml dtd
<3> :o
<0> WebDragon|away, but then that may be possible with html
<0> yeah, i know, crazy crazy talk
<3> webben: if you're doing /that/, you had better be using the right mimetype
<4> as soon as I found out about the problems with xhtml, I switched back to HTML 4.01 Strict and stuck with it
<3> WebDragon|away: ditto
<4> didn' t even hesitate to drop xhtml like a hot potato
<0> gxti: not necessarily, depends what the custom dtd does
<4> less issues = faster devel time = sooner paid
<3> WebDragon|away: what the dtd does has nothing to do with whether or not you're using it correctly
<0> gxti: for example, a dtd might just add in commonly support html attributes which are non-standard
<3> erm
<3> -> webben
<0> (e.g. the autocomplete attribute)
<5> is there a way to cover the page with a layer in javascript ?
<3> webben: i presume you are sending your XHTML as text/html
<6> `html layer
<7> Nothing found for HTML 4.01 - layer
<0> gxti: sorry, yes, currently i am
<3> you never did answer my question as to why
<3> if you're using html you could use the attributes legitimately rather than hacking them onto your own DTD
<0> gxti: i'm trying to answer several things at once, as well as trying to find out several things at once
<3> i wouldnt think explaining your intention would require research
<0> gxti: AFAIK autocomplete is not standard HTML ... just common HTML (see the Mozilla docs) ... so you'd still need a dtd
<3> `html input
<7> Found for HTML 4.01 - input - http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT
<3> correct you are
<3> what does autocomplete do?
<0> gxti: search on MDC ... better explanation than i can give you
<0> gxti: all i know is that it's useful if you have an ajaxy autocomplete because it prevents the browser autocompleting the field
<3> oh, it's to /prevent/ autocomplete?
<0> (this comes up with Ruby on Rails helpers, which just mindlessly add in autocomplete="off"
<0> gxti: yeah, i _think_ there were security uses too (but that's from memory)
<6> autocomplete suggests things you've typed before
<3> well if you've got frameworks spitting out crap left and right your issue is complicated
<0> gxti: no kidding :)
<3> some frameworks wont even let you output flat html, but half the time their xhtml is invalid anyway
<3> in which case you cant be helped
<0> gxti: and whenever i'm involved with a framework i try and help get them to a stage where they'll output valid whatever they claim to output
<3> one of the things i hated about wordpress was its markup
<3> ugly and needless xhtml
<0> gxti: so when i was trying to use Wicket, i helped push the devs into escaping their JavaScript and styles as Ian Hickson suggests
<3> if they want to showcase their xml-fu, apply it to the rss feeds :p
<0> gxti: agreed, Wordpress is pretty ghastly
<4> indeed
<4> notwithstanding I managed to write a decent plugin for it
<4> webdragon.net/wp/
<0> gxti: and the ability to enter your posts in xhtml is a bit of a mirage as you have to hack it to get it to stop mangling them
<4> but touching it again, will be problematic -- I've moved on from that client now
<4> mmm tinyMCE
<4> *cough*
<0> gxti: don't we all
<3> one in perl or python, that supports postgres
<3> because mysql fails it ;p
<3> (and so does php)
<4> Movable Type?
<0> i'd like to see something using xml as a backend, that supports syntax highlighting and footnotes/references out of the box
<4> which, IIRC, is perl-based
<0> then one could just do content negotiation and send IE its desired html and everything else could get xhtml
<4> nad if they built it sensibly with the DBI, you should have no problem working with postgres
<4> I'd rather not spin all those extra memory cycles in my brain holding all that together cohesively and just creat and serve HTML
<0> gxti: but to try and answer your question, there's the frameworks issue, there's the customization issue, there's my own familiarity with xhtml and doubts about html
<4> HTML's relatively speaking, compared with XHTML, solid as a rock
<4> doubts?
<4> O_o
<0> gxti, and there's the fact that while i understand Nanobot's contention that compatibility relies on a hack, i think that it's a very small hack which i can live with not a huge one that i can't
<3> content negotiation is silly
<0> i don't expect anyone else to agree with me though per se
<0> gxti: why?
<3> especially since you have to handle a ton of cases
<3> different browsers mean different things
<0> WebDragon|away, willis?
<3> some send */* but vomit when they get xhtml
<4> old TV show reference, webben
<4> don't worry if you don't get it
<3> :P
<0> gxti: content negotiation is good, if you like REST (as i tend to do)
<4> gxti: myspace. I need say no more.
<3> WebDragon|away: myspace is a browser now?
<4> no, but it's the largest amalgamated concatenation of incompatible markup and protoplasm I've ever seen
<0> But why i actually came was to point to an xhtml page which "looks the same" (i still don't understand what Nanobot meant by that) when served as xml or html
<3> i was talking about what browsers send for accepted-content or whatever it's called
<3> ie sends */* but tries to download xhtml
<3> i think firefox sends */*
<0> but more importantly to ask why the validator doesn't parse <br /> as <br>>
<3> and others actually send */* AND text/html,application/xhtml+xml
<0> which i believe Nanobot said it would
<4> they probably should
<3> 13:16:29 < webben> gxti: but to try and answer your question, there's the frameworks issue, there's the customization issue, there's my own familiarity with xhtml and doubts about html
<3> doubts?
<0> http://www.benjaminhawkeslewis.com/safexhtml_as_html.html is the html version
<4> that was my question
<4> doubts?
<3> (i missed that line somehow)
<0> as i was explaining to Nanobot, i'm worried by the JavaScript and CSS being treated differently
<3> that's a rediculous thought
<0> gxti: why?
<3> using XHTML instead of HTML will not fix that problem
<8> gxti: */* just means that they'll accept that content type
<0> gxti: depends what you mean by "fix"
<8> not that they can render it on screen
<3> GarethAdams: then why do some include the application/xhtml+xml explicitly to state they support it?
<3> it'd be more useful as an 'i support' than an 'i accept'
<0> gxti: if you're using XML dom methods, or a framework designed for XHTML 1.0, or whatever, then you might be looking at serious breakage
Return to
#web
or
Go to some related
logs:
Mudlide shot
Redhat fstab LABEL boot1 ext3
#php
mysql order by combination of rand() and other field
#perl
#css
scanelf: rpath_security_checks()
#fedora
#php
gentoo xen deep
|
|