4 ms·
1. Yeah, I guess I worded that incorrectly, though you can see the tie-in between semantics and how that html is executed (rendered). Using proper semantics = n
by tdavis 18y ago
1. Yeah, I guess I worded that incorrectly, though you can see the tie-in between semantics and how that html is executed (rendered). Using proper semantics = not using tables for page layout = better rendering (under circumstances mentioned)
2. ... so you're saying we should write HTML, then write XML to describe that HTML? Why not just write HTML which describes itself in the first place? It seems awfully redundant to do it any other way, considering HTML comes with all these handy tags which, when used correctly, describe the content already. Hell, XHML was created as an HTML which conforms to the XML spec for precisely this purpose.
If you write something like:
<body><div id="content"><h1>My Cool Site</h1></div></body>
You've already "encoded" it. If you write:
<body><table><tr><td colspan=2><font color="red"><big>My Cool Site</big></font></td></tr></table></body>
Then, yeah, you've got your work cut out for you to give that any sort of meaning...
3. "And in that case munging the results afterwards is as inelegant as patching machine code." -- Right, so your choices are write it yourself or get a bunch of garbage generated by an IDE or Framework or whatever. If you're happy with the garbage then you probably don't need to edit it afterwards or just "edit" it using the same IDE or language or whatever. What happens when your IDE or framework or language can't generate HTML/CSS to do something you need? Then you have to start editing that crap by hand... this should eventually lead to suicide.
- netcan 18y agoPersonally I think the most important of the anti zealot side of this debate is the insistence on everything being centred on code being written by hand. Dingy little WYSIWYG editors, machine generated web pages, & (in this context, I suppose) software that allows users to generate anything from blogs to shops to social news sites without any technical knowledge, and all their friends have probably done more for for the web (& it's accessibility) then standards have. We aren't there yet. From online shops to Slinkset, you still need a little css & html to get you past a certain level of control. But I think it would be an achievement, if these weren't needed any more & 'view source' got taken out of browsers from lack of use.
- tdavis 18y agoI don't really know what "View Source" has to do with not writing your own HTML, but I completely agree with your argument. I'm not saying I want to always write HTML by hand, I'm saying it should be done until such a time that WSIWYG editors, online web site creators and so forth get to the level that they generate proper HTML. I don't get any more pleasure out of writing boiler-plate HTML than I do from writing boiler-plate code for the backend. If someone has created a framework or library that already does what I need (or gets me on the road to what I need without getting in my way), I'm certainly going to use it. Needing a little CSS and HTML to get you past a certain level is no big deal, assuming the initial code generated is semantic, (mostly) valid, extensible, blah blah blah. Having tables nested 5-deep is none of these things.
- netcan 18y agoNo sorry, I think I as unclear. I meant the opposite. 'View Source' will be removed because no one should want to view source. What I was saying is that the ability of non technical users to make sites, no matter how bad that code, is much more important then anything else in this debate. Standards should (i think) almost be written specifically for machines. Sure, you can think of creating the best possible environment that makes sense & so that the pages can be used on future browsers & browser like things, but that is dwarfed by the prospect of letting grandma have a website. Standards should not be built for hand coders.
- tdavis 18y agoSure, you can think of creating the best possible environment that makes sense & so that the pages can be used on future browsers & browser like things, but that is dwarfed by the prospect of letting grandma have a website. I would argue that the continued evolution and improvement of the Web are far, far more important than letting Grandma have a website. Besides, Grandma can already have a website -- there are dozens of services out there like Typepad, Wordpress, Blogspot, etc. which allow Joe Public to have a website -- and he should be able to have a website, so long as whoever (or whatever) makes that site uses proper HTML, CSS, and Standards to create it. Would it be great to get to a point where Standards are written for machines, I can write some super high-level markup that describes how I want a page laid out (or just draw it!) and nobody has to write another line of HTML or CSS, ever? Sure. But it's not going to happen any time soon and pretending like it has just hurts everybody. If your framework generates a 30-character ID for damn near every element on the page (hi, Microsoft), it's Not Good Enough. If your language generates tables for damn near everything, it's Not Good Enough.
- pg 18y agoIt seems awfully redundant to do it any other way So you're against rss feeds? You think it would be a more elegant solution if instead of having an rss feed for a site like hacker news, other apps scraped the front page?
- tdavis 18y agoOf course not, but you seemed to be saying that if any semantic meaning is desired, it should be encoded as such and made available separate from the HTML... I don't agree. Take Microformats, for instance. Say you're already displaying Events somewhere on a site; to add Microformat support all you do is add a few attributes to your existing mark-up and any Microformat-aware browser can properly recognize it. Sure, you could create another file entirely that contains XHTML specifically created as a Microformat, but that would be redundant and not nearly as helpful to visitors. Or, say, a sitemap. Many times it makes sense to have a completely separate XML-based Sitemap for, say, Google. Then again, what if you just added the requisite semantic mark-up to an existing sitemap, one your visitors can use, but so can Google? You basically get two for the price of one. RSS is a different animal and in most cases couldn't logically be encoded into the XHTML itself because you wouldn't have every RSS item on one page, etc. That's why the <link> tag is used to include it in the source, just like you include Javascript and CSS and so forth.