begin quoting James G. Sack (jim) as of Fri, Feb 23, 2007 at 02:43:04PM -0800: > Stewart Stremler wrote: > > begin quoting Paul G. Allen as of Fri, Feb 23, 2007 at 09:39:38AM -0800: > >> On Thu, 2007-02-22 at 20:18 -0800, Rick Funderburg wrote: > > [snip] > >>> Indeed. But if you do want a reason to not like XHTML, you could claim > >>> that it is poorly supported by browsers, since some browsers (like IE) > >>> do not support the appropriate mime types[1]. > > > > Why should _any_ mime types be supported, rather than being completely > > optional? > > I don't grasp what you are saying? The web depends on mime-types. Of > course, the web _is_ optional, I suppose. :-)
Well, I should have said "_any_ /particular/ MIME types". My error. If I choose to only use text/plain, who are you to go about forcing application/activex down my throat? [snip] > > You might as wish that the W3C would provide better standards; every > > time I go look at "W3C standards" I start wondering what sort of drugs > > they're smoking (and why they're on such a power-trip). They're not as > > bad as ECMA, but still... > > Perhaps not all agree, but I think the W3C standards have been > enormously successful at resolving the horrors of html incompatibily > that haunted the good-old v3.0 browser days. Not really. They just legitimized various bad habits. > I think that CSS is really really really good idea, and works fairly > well. It still needs work, but it sure makes webpage maintenance > possible rather than black art. If you're not worried about maintenance, > then it sorta doesn't matter, I guess. I have spent more time futzing with CSS than I have in creating content. This is not a beneficial tradeoff. The least maintenance-approach to web-pages seems to be CGI or other "programs that emit html". Stuff like Blosxom and wikis let the content creators concentrate on content, and pushes the appearance off to some code somewhere. CSS... is just ugly. Plus, the promise that the user can "adjust" things to suit themselves is not borne out by the implementations in the browsers. > I am convinced that xhtml is the right successor to html, and gets us > closer to various benefits (including the "semantic web"). Although I > agree there are some transition pains, it seems to me that the trend > setters are coping fine, and developing good examples and practices. I see an ever-increasing reliance on javascript to accomplish simple tasks, meaning that everyone is caught up in the red queen's race. It is a mistake to think that all movement counts as progress. > The W3C is bound to suffer the same problems as all standards bodies. > But I wouldn't give up on standards, and I wouldn't rate W3C as any > worse than other groups (although I am just speculating on this last > point, without any firsthand expertise). It all depends on whether the standards body is trying to produce a good standard, or trying to justify their existence. I think the W3C is of the latter sort. > >> This goes further to other web developers as well (I admit to my own > >> laziness at times when just trying to get a page or several pages done > >> quickly and I skip the standards verification step. > > > > So is it a problem with the browser developers or the web developers? > > Standards adherence is a problem with browser developers. Maybe always > will be, since standards will likely always be evolving. The best they > can do is attempt to meet standards at given milestones and selectively > support ongoing improvements. Or we should take an axe to many standards and reduce 'em to the simplest useful subset. > Writing valid html (or xhtml or css) is not too hard if you do it for a > living, or do a lot of it, or just do it for satisfaction. There are > validators readily available, and while they themselves are imperfect, > they are _pretty good_. > http://validator.w3.org/detailed.html > http://jigsaw.w3.org/css-validator/ CSS is just freakin' *tedious* and error-prone. Hard, no. Boring, mind-numbing, tedious, counter-intuitive, backwards, baroque... all of these, yes. So, we have tools create it. We collect recipes so that we can crib, as figuring out the right thing to do is a black art. We divorce the data -- the content AND the CSS -- from the realm of human- comprehensible. It gets so complicated we require *tools* to tell us if it's correct and/or strictly legal. Where's the upside again? Oh, yeah, it's shiny. Can't fight shiny. > Checking your code with a validator can be a useful debugging step. ...or simply avoid doing anything complicated enough to require a validator. There are aspects of CSS that are useful and clever. The rest? Bleah. > The biggest challenge these days is (still) coping with the remaining > browser differences, but I am impressed with the suggestion to first > write valid code, then adapt as required to either achieve acceptable > appearance on the common browsers, and/or at least fail gracefully (ie, > to an unstyled appearance). That's the wonderful theory, yes. It's generally good advice. > Did I mention that I like CSS? Did I mention that I'm generally unimpressed with CSS? :) -- CSS doesn't live up to expectations, and is sometimes The Wrong Answer. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
