Whenever an argument among otherwise reasonable people turns intractable it is usually because both sides have overlooked something really fundamental, and I think this is the case here. The fundamental thing that both sides have overlooked in this case is that HTML is (or at least should be considered) object code. Let me explain what I mean by that.
Consider a hello-world program written in C:
main() { printf("Hello world"); }
Of course, this is not really a hello-world program. To get the "real" program you have to compile the above "source" code into "object" code, which looks more like this:
0000000 ce fa ed fe 07 00 00 00 03 00 00 00 02 00 00 00
0000010 0c 00 00 00 c0 03 00 00 85 00 00 00 01 00 00 00
0000020 38 00 00 00 5f 5f 50 41 47 45 5a 45 52 4f 00 00
[and so on for 12,588 bytes]
But now consider this:
0000000 6d 61 69 6e 28 29 20 7b 20 70 72 69 6e 74 66 28
0000010 22 48 65 6c 6c 6f 20 77 6f 72 6c 64 22 29 3b 20
0000020 7d 0a
Is that source code or object code? (Before you go on, take a moment to think seriously about what you think the answer is and, more importantly, why you think that's the answer.)
Here's a clue. Try this:
echo 'main() { printf("Hello world"); }' | hexdump
So if you said, "It's object code, because it looks like object code" you are wrong. But if you said "It's source code because it's just the hexadecimal representation of a C program" you are also wrong. The right answer is it's both. Yes, it's the hexadecimal representation of a C program. But just because it's C code doesn't necessarily mean it's source code. C is often used as an intermediate target language for compilers of other languages like Scheme. And Scheme can be used as an intermediate representation for other languages, like Qi. (Qi actually compiles to Common Lisp, but it's the same idea.)
Now consider this:
<html><div id="top">Hello world</div></html>
Is that source code or object code? In other words, is that code that a coder writes, or code that a compiler emits? Hopefully by now you realize that the answer is: it can be both.
I think a lot of the arguments against using tables for layout rely on the tacit assumption that HTML is source code. For example, one of the arguments against tables is that they fail to separate layout information from content. But this assumes that HTML is source code, and that the combination of content and layout information must be done in the browser. Neither of these assumptions is correct. I can create a layout as an html template:
<table>
<tr><td colspan=3> %header
<tr><td> %leftnav <td> %center <td> %rightnav
<tr> <td colspan=3> %footer
</table>
and combine this with separate content information on the server. Now my layout and content are completely separate, and yet I'm still using tables, and so I get the advantages of the simplicity and uniformity of cross-browser table rendering. Plus, my layout is only five lines of code. And it doesn't need Javascript. And it's going to look reasonable no matter what my content turns out to be.
IMHO, no one should ever write any HTML by hand. HTML should be considered exclusively as object code, except for the most simple of quick-and-dirty hacks. The idea that HTML can (or even should) be considered source code is the root of many evils on the Web. The right way to create web pages is by building higher-order abstractions in a programming language (preferably functional ones, but I'm not dogmatic about that).
Nowhere is this clearer than when it comes to forms. Even CSS advocates concede that it's OK to put form elements in tables. They say it's because "forms are a kind of tabular data, and that's what tables are for", but this just begs the question of how one can tell if a particular set of data is tabular or not. (Apparently, the criterion is: it's tabular data if it's completely hopeless to make it not look like crap when layed out with CSS.) But the trouble with forms goes far beyond layout. Consider the following:
<form method="GET" action="date-foo">
Enter the date:
<input type="text" class="dateinput" name="date">
<input type=submit>
</form>
Simplistic to be sure, but nothing offensive to the W3C standards. Now imagine a site that has this form and others like it throughout, and we want to augment our date input fields with a little javascript calendar widget. According to the philosophy of CSS we should be able to write:
.dateinput { ... }
but of course we can't, because the semantics of CSS are so hopelessly impoverished that the mere suggestion of doing something like this is probably enough to send CSS advocates into conniptions. (Any minute now, ChristianZ and Pherdnut will start to rant about how I Just Don't Get It (tm), and I need to study harder.)
But if we combine content and layout (and even style I might add) on the server, we can write:
<standard-form>
<date-input label="Enter the date">
</standard-form>
or something like that. Then we write a program that "compiles" this little private HTML-ish web page description language down to actual HTML for delivery to the client. Now changing all the date inputs to use a javascript widget is trivial, because we really have separated style from content, and we have done it in a way that is vastly more expressive and powerful than CSS.
There is only one argument for using CSS for layout that this approach does not completely demolish, and that is accessibility. CSS advocates argue that tables impede the rendering of web content for non-visual media. I think that's debatable, but even if it's true, it's irrelevant because there is no reason why the same content has to be rendered the same way on the server for all clients! This again assumes that HTML is source code, and you so you don't want to have different HTML for different clients because that would make extra work and violate the DRY (don't-repeat-yourself) principle. But HTML need not be source code. The source code can be a higher-level representation, and that higher-level representation can be rendered in different ways for different clients. For example, imagine a world where the client said to the server, "Give me web page FOO, and oh by the way, my user is blind" and what came back from the server was not HTML at all but an audio file. Now blind users wouldn't even need a special client! All they would have to do is configure a standard browser with a custom header to indicate blindness, and they're off to the races.
Separating styling and layout information from content is a great idea. But requiring that the rendering of those separate pieces be done on the client exclusively is overly restrictive because it requires that the kinds of combinations that can be done be standardized. It is that assumption that leads to the religious wars over CSS, not the merits or drawbacks of CSS per se. Whatever the standard is, it's either Turing-complete or it's not. If it's Turing-complete, you might as well just use Javascript (with all of its attendant problems) and if it's not, there will always be something that someone will want to do that's not possible. The answer is to cut the Gordian knot, treat HTML as object code, and do (at least part of) your rendering on the server. That way no one has to argue about anything. (Not that I expect that to stop anyone.)
In my Visual Basic 101 class in college I heard comments on various assignments like "wow, this is really hard - you'd have to be a real brain to figure this out."
ReplyDeleteMy reply was "this is basically just written out in English. Think about the people who wrote Visual Basic - that's the real brain."
Unlike some other people, I am smart enough to not wade in over my head...hasta la vista, baby ;-}
You certainly can do .dateinput { ... }; it just looks like this instead:
ReplyDelete$(.dateinput).append("whatever extra html you need to support the augmentation").click(function() {javascript to make it work});
Huh? That's doesn't look like any CSS I've ever seen, and when I tried it (extrapolating as best I could to a real example) it didn't work. Can you point me to some docs that describe this feature?
ReplyDeleteRon, what Shawn posted was jQuery-style JavaScript, not CSS.
ReplyDelete"Even CSS advocates concede that it's OK to put form elements in tables."
ReplyDeleteActually most CSS advocates don't concede that. The vast majority of them try all different ways to display forms with CSS and without tables because they have this stupid idea in their heads that using HTML tables under any circumstance is bad.
Ron, if you want to use tables to layout a page go ahead and do it. You bring up a good point that it's hard to always tell exactly what is tabular data and what is not and I have tried to explain to others that sometimes something is tabular data that may not seem at first glance like it is. But if you choose to enclose something in TD tags that is not tabular data you are entirely free by the rules of the universe to do so just as you can use a spoon to spread butter on your bread if you want to. Just don't tell others you are using a knife when you are using a spoon. And if others follow the W3C recommendation to use CSS to layout a page and to not use tables to do so then please don't have the audacity to tell them they are doing it wrong and that you question their judgment, as you have already said.
My problem is not so much that you and/or the people you hire use tables to lay out web pages. It's when you act like CSS is harder than it is, and when you tell people who know how to do it that they were stupid for picking up some arcane, useless knowledge. That is pure hubris. If you say, "Well, I didn't say they were stupid," you still know what I am getting at.
This comment has been removed by the author.
ReplyDelete> You bring up a good point that it's hard to always tell exactly what is tabular data and what is not
ReplyDeleteIf you concede that then you have to concede your entire point. Because if you can't define what tabular data is, then the guideline to "only use tables for tabular data" becomes vacuous.
> please don't have the audacity to tell them they are doing it wrong and that you question their judgment
Sorry, but I call 'em as I see 'em.
> what Shawn posted was jQuery-style JavaScript, not CSS
ReplyDeleteAh. Then Shawn, please re-read the last paragraph of the original post, and particularly the passage that begins, "Whatever the standard is, it's either Turing-complete or it's not."
"Because if you can't define what tabular data is, then the guideline to 'only use tables for tabular data' becomes vacuous."
ReplyDeleteDon't worry, I can define what is tabular data and what is not, even if some cases are harder than others I can still do it. That is funny that if I say some people have a hard time with it you assume I'm saying I have a hard time with it.
"Sorry, but I call 'em as I see 'em."
So, as in the beginning, this whole thing comes down to your own personal lack of knowledge. You have even explicitly declared such numerous times and then gone on to berate others for knowing more than you do ("I can't take the time to learn CSS and anybody who does learn it is stupid. Stupid, I tell you! Those goldern' CSS learners, thinkin' they know everything . . . ")
Additionally, you have sidestepped numerous valid points I have made against your diatribe.
When working on a team, or when writing code that is expected to be maintainable in your absence, it is often necessary to agree on a policy regarding CSS use. One could argue that this is nearly always the case.
ReplyDeleteIn such cases, this issue demands an objective resolution. It can't simply be dismissed as a matter of personal taste.
Of course. When working on a team, or when writing code that is expected to be maintainable in one's absence, it is necessary to agree on policy regarding *every* aspect of the project, not just CSS use. Has anything I've said contradicted that?
ReplyDeleteNot at all, I was loosely addressing ChristianZ's comment about spreading butter with spoons and preemptively, any argument along the lines of "do whatever you want, it doesn't matter", which tend to pop up in this debate.
ReplyDeleteAh.
ReplyDeleteBut both spans AND divs contain display styles by default (ie: they behave very different in terms of forcing things to the next line - unless you control the floats) just like table cells, so they are not a full separation of display and content by any means (until you do so explicitly - which you also totally can with table cells). for all intents and purposes, a table cell and a div are actually very similar then no?
ReplyDelete"Not at all, I was loosely addressing ChristianZ's comment about spreading butter with spoons and preemptively, any argument along the lines of 'do whatever you want, it doesn't matter,' which tend to pop up in this debate."
ReplyDeleteSeems like you may have missed the point of my "butter with spoons" comment. The point of it was: you can go against the W3C's recommendation to not use tables for page layout and you can put things in table cells that are not tabular data, but if you do don't get on your high horse and tell people you are using tables correctly. Just admit you're concocting your own use for them and move on. Spoons weren't made for spreading butter but if you want to use them that way then go ahead. Just don't tell people it's a knife you're using and just don't tell the people that are using knives to spread butter that they're stupid and that you question their judgment.
"But both spans AND divs contain display styles by default (ie: they behave very different in terms of forcing things to the next line - unless you control the floats) just like table cells."
Okay, so here's somebody who doesn't understand SPANs and DIVs. A SPAN is a generic inline element, a DIV is a generic block-level element. One forces a line-break, the other doesn't, but that is not a styling issue. SPANs and DIVs have no further meaning beyond that until a developer gives them meaning.
Okay, so here's somebody who doesn't understand SPANs and DIVs. A SPAN is a generic inline element, a DIV is a generic block-level element. One forces a line-break, the other doesn't, but that is not a styling issue. SPANs and DIVs have no further meaning beyond that until a developer gives them meaning.
ReplyDeleteWhat is different about how I described spans and divs and how you did? One forces content the next line = one forces a line break as far as I'm concerned. No need to be an asshat here...Now HERE's someone who doesn't understand tables..(not really but I think we can all be a little nicer about accusing people of knowing or not knowing things - I'm not an idiot and neither are you, k?).
Tables force a structure, just as, like you say, divs (which force a line break, AND a box around content). Spans are inline, but they absolutely force display properties, because like divs they force a box around the content. By themselves they do not change the way the information looks, but they are purely for display purposes - as I would argue are all tags. Where do you draw the line on what is or isn't a display property, because forcing a line break definitely sounds like visual structure to me.
What about lists etc. should we not use those as well because we can make elements appear identically in CSS or JS? Though it's against the spec, someone who truly favors full separation would want to have the output as generic as possible, and style as far from content as possible which would mean nothing BUT divs and classes or ids and forms (maybe more you get the point though). But no, you probably use list elements all the time.
Out of curiosity do you use h1 tags?
"What is different about how I described spans and divs and how you did?"
ReplyDeleteI'm just clarifying that it's not a styling issue, even if I covered some ground you already knew in the process.
"Spans are inline, but they absolutely force display properties, because like divs they force a box around the content."
That still doesn't add styling. It just preps them for styling to potentially be added.
"Though it's against the spec, someone who truly favors full separation would want to have the output as generic as possible, and style as far from content as possible which would mean nothing BUT divs and classes or ids and forms."
Actually not. Structure is separate from style and even though browsers have default style sheets that come into play automatically that doesn't mean that the HTML elements themselves are adding style to the content they wrap. I've already been talking about that in this thread.
"Out of curiosity do you use h1 tags?"
Yes.
"Seems like you may have missed the point of my "butter with spoons" comment. The point of it was: you can go against the W3C's recommendation to not use tables for page layout and you can put things in table cells that are not tabular data, but if you do don't get on your high horse and tell people you are using tables correctly. Just admit you're concocting your own use for them and move on. Spoons weren't made for spreading butter but if you want to use them that way then go ahead. Just don't tell people it's a knife you're using and just don't tell the people that are using knives to spread butter that they're stupid and that you question their judgment."
ReplyDeleteIf we all restricted ourselves to using the web as it was originally intended, it would be nothing but a wiki, minus the convenient editing and versioning features.
Innovation on the web has historically been a process of finding novel uses for existing capabilities, in many cases "violating" their ideological basis (though not necessarily violating the ultimate wishes of their creators).
We strive to adapt our standards to encompass innovation, but this doesn't always work out. In particular, CSS has evidently failed to establish the industry consensus required to lend a standard legitimacy. It is neither universally supported nor universally approved of, thus has no reasonable claim to authority.
The claim that someone else is doing something INcorrectly, despite achieving their practical goals, is the exceptional claim. It has to be justified with concrete, real-world consequences. Appealing to dated idealistic visions does not suffice.
Jedediah, you think you are contradicting me but you are not. I'm all for innovation and if someone feels they want to use tables for page layout I have said over and over that they can. But what is wrong is when those people tell those who know how to use CSS that they question their judgment. When I can do a page layout in CSS, do it quickly, have it work in all major browsers, and have it meet all my practical purposes (and it just so happens to jibe with the W3C recommendation to boot) then why do we have people telling me I am doing it wrong? That's the very thing you accuse me of doing to others.
ReplyDeleteInstead of adopting Ron's attitude a wiser course of action for a tabled-layout advocate would be to say, "I have a way that works for me and I haven't yet noticed any particular problem with it. But that doesn't mean I am going to demean people who do it a different way, especially when I outright admit that I don't know CSS very well."
For the reasons mentioned in my first comment, and for many other reasons, there is a dire need for consensus on this issue. That means we have to decide which approach is better, in the general case, not in your case or mine.
ReplyDeleteIf someone is literally arguing that you don't know what you like, then that is indeed silly, but I don't think anyone is actually arguing that.
Just read all Ron's statements where he, in effect, says, "Sure I don't know CSS very well and I really question the wisdom of anyone who bothers using it to layout a web page."
ReplyDeleteI know it's silly for me to be arguing against one guy who has an untenable position but I think some good information is being covered in the process, such as clarifying that structure and style are not the same thing.
I won't put words in Ron's mouth nor universally endorse his view, but I read "I question the wisdom of someone who does this" as a colorful way of saying "we shouldn't do this". The debate is about CSS, not about your level of wisdom.
ReplyDelete"I won't put words in Ron's mouth nor universally endorse his view, but I read 'I question the wisdom of someone who does this' as a colorful way of saying 'we shouldn't do this.'"
ReplyDeleteThat'd be awesome if he felt the same way. Maybe he just words everything too harshly and we are supposed to know he's just giving others a good-natured ribbin'. I'm cool with that.
No, I meant what I said. And what I said was that I question the *judgement* (not the wisdom) of someone who would uncritically use CSS for layout just because some standards body says they should, particularly when the design criterion in question is circular ("Tables should be used for tabular data") and hence vacuous. If there's an easy way and a hard way to accomplish the same thing, I question the judgement of someone who would choose to do it the hard way without a compelling reason. And "I know how to do it the hard way (and you don't)" is not a compelling reason. Neither is "The W3C says so."
ReplyDelete(I also question the judgement of someone who puts so much time and effort into sustaining what is ultimately a pointless argument. It's quite clear that neither of us is going to convince the other. And while I appreciate all the attention, sometimes you gotta know when to give it a rest.)
Who's judgment are you questioning now? Your own?
ReplyDeleteAmong others, yes.
ReplyDeletejust "do things right":
ReplyDeletelast time i had to built a website, the user wanted pictures of various sizes to be vertically and horizontally centered on the left side of a webpage that looks a little like a book ( on the right side there's text):
Of course i wanted to do the arrangement of my elements (as always) with CSS!
Every working CSS-Code needed the height of the picture.
For some reasons this was not acceptable.
After one working day, i decided to use a table and five minutes later, everything worked beatifully.
As Goethe said in Faust:
Grey, dear friend, is all theory, and green the golden tree if live!
"No, I meant what I said. And what I said was that I question the *judgement* (not the wisdom) of someone who would uncritically use CSS for layout just because some standards body says they should."
ReplyDeleteI never said that's the only reason. I said that's the way I and others happen to do it and it just so happens to coincide w/ what the W3C recommends. And why would you insist that people use it "uncritically?" You really, seriously think people who use CSS layouts have never, ever thought about how it works compared to tabled layouts? Honestly? You really think that?
"If there's an easy way and a hard way to accomplish the same thing, I question the judgement of someone who would choose to do it the hard way without a compelling reason."
So you've overlooked all the times when I and others have said it's not hard for them. Great. That's why this keeps going on: because you won't accept it's not hard for everyone.
As my dad used to say: you can't reason with a headless man.
> So you've overlooked all the times when I and others have said it's not hard for them.
ReplyDeleteNo, I haven't. YOU have overlooked the fact that just because it's easy for YOU doesn't mean it's easy in an absolute sense. Everything is easy once you know how to do it. Breaking 100 in golf is easy for Tiger Woods. Swimming 100 meters in under a minute is easy for Michael Phelps. That doesn't mean these things are easy.
Why are there so many books about how to do layout in CSS, but so few on how to do layout using tables? Why are there so many web sites on how to do a fluid three-column layout using CSS? It's because these resources are NEEDED because doing layout in CSS is HARD (or at least hardER than doing it with tables).
One of your original criticisms of my original piece on CSS was that the web site I used as my source for how to do three-column fluid layout got it wrong. That in and of itself proves my point. Why did this site, which was put together by a professional web designer, get it wrong? It's because getting it right is HARD!
> As my dad used to say: you can't reason with a headless man.
Teach a pig to sing. Lead a horse to water. Yadda yadda yadda. What was it I just said about questioning the judgement of someone who puts so much effort into fruitless endeavors?
"Why are there so many books about how to do layout in CSS, but so few on how to do layout using tables?"
ReplyDeleteThere's a really good answer for that and one of these days you'll figure it out.
"It's because getting it right is HARD!"
However YOU perceive it, why would you question the judgment of somebody for whom it is not hard? There's a number of arguments you keep repeating and whenever one doesn't work you just rotate back to one of the other ones.
> However YOU perceive it, why would you question the judgment of somebody for whom it is not hard?
ReplyDeleteBecause there's no BENEFIT. I'm not opposed to doing things the hard way if there's a payoff down the road. But in the case of layout with CSS there is no payoff. In fact, there's an anti-payoff: the site becomes harder to maintain. I now need to find and hire very specialized talent whenever I want to make a change to my layout. And what have I gained? Absolutely nothing. All your claims about CSS being better for accessibility or SEO or whatever have been debunked. All that remains is: "I know how to do it." Sorry, but that is not a compelling argument.
It's NOT hard for me to create and it is EASIER for me to maintain. I guess I'm the one person in the universe that that is true for. And you've seen me talk little about accessibility and SEO.
ReplyDeleteI'm trying to leave a tip on your site but that tipjoy thing isn't working for me.
ReplyDeleteNo it's not working for me either.
ReplyDeleteI started to use CSS because I wanted to have text over an image and if there is a way to do it with tables I couldn't find it. I can now have text wherever I like, and also have a small image for example over another image, which gives a 3D effect. I do this by altering the CSS positioning data and it has been a long uphill task requiring trial and error. But it's worth the effort.
For me the hardest task is to move inline styling to the CSS file. I think it's baffling and I have not found advice as to how to do that.
I think that Ron's observation that using CSS for layout can be very time consuming is correct, at least for me.
Is this because I have not learnt how to do it first? I have lots of books but little time to read them. One of the attractions of using tables is that everything stays in the table cell. And that cell can be moved by adjusting the size of the surrounding cells.
I like whitehawke's idea of using a single table for layout and then using CSS to style the content. At present I am using Eric Meyor's CSS sculptor and Expression Web 2and sticking with the CSS approach. I started a thread on Daniweb: "checklist for CSS problems" and people have contributed to that list.
This thread is very interesting even though some of it is above my head.
Geoff
"For me the hardest task is to move inline styling to the CSS file. I think it's baffling and I have not found advice as to how to do that."
ReplyDeleteIf you have placed an inline style such as:
<p style="line-height: 18px;">
then all you have to do to move that to the style sheet is change <p style="line-height: 18px;"> to <p> and in the style sheet add:
P { line-height: 18px; }
I understand that this post was to explain a single point in a wider discussion but it makes it seem like there's a conflict between HTML-as-object-code and CSS (for layout or otherwise). I don't see a conflict there. One could write code in any language, compile that code to HTML, and it could contain the appropriate CSS classes and be otherwise semantically correct. (I mean semantic in the sense of the intended semantics, not the natural semantics that have evolved no the web.)
ReplyDeleteI've reread it a few times now and I don't understand why "we can't" say ".dateinput { ... }". Could you clarify that point? It seems to me like if you have:
<input type="text" class="dateinput" name="date">
then that is a perfectly good way to augment the element using CSS. Now, you can't augment the behavior with only CSS, so you'd also need some JavaScript, but that's beside the point. For me, bringing a JavaScript example to a CSS/HTML discussion is a little confusing. In the end I'd expect that this:
<date-input label="Enter the date">
would compile to the above HTML anyway. Is the point that it would need to include a little icon next to it to show the user that it had a JavaScript-enabled calendar widget? If so, then that icon should probably be added by JavaScript when the event handlers and everything else are attached so that users with JavaScript disabled don't see an interface element that they've disabled.
I like the idea about serving an audio file to a user-agent that requests one, but I think it slightly mars one of the attractive qualities of the web which is that the data is served to the browser and then the browser can interpret it differently for different users. The user might want the text to be read faster, or more slowly, or in a different voice. Maybe they're on a platform that is able to parse text and read it much more accurately than the software on the server in question. Sending one big audio file would be a bit like just coding a whole site in flash. That's just the trade-off I see with an approach like that.
This may be a major source of the contention: I really like the fact that I can change the code of a webpage that comes to me. What is received by the user agent is both source code and object code and that's what is so great about it. You (correctly, I would say) accuse your opponents of assuming that HTML is source code. Of course, you have already said that it is source code. The way in which you're correct is that they think it's only source code. To me your argument comes off as a backlash and tries to claim that HTML is only object code.
I think this is the point that other people also try to make about semantic HTML as well: In a perfect world the server would send the user agent markup that was semantically meaningful to the user agent. It would be able to figure out not just which text were links or paragraphs but also what the heading of the page was or the footer or anything else. It could then use these pieces to display the page in a way that the user preferred. It could even just use this information to help customize the experience to different devices. Sure, this can be done with classes, but in an ideal world it wouldn't have to be.
So, even though HTML is object code, doesn't mean that separation of concerns should be ignored since it's also source code.
This is a good discussion and I'm glad that you continue to have it. And for what it's worth, I find it easier to lay out and maintain webpages with CSS than with HTML tables.
Thanks ChristianZ
ReplyDeleteThat's useful and clear information.
Geoff
> I've reread it a few times now and I don't understand why "we can't" say ".dateinput { ... }". Could you clarify that point?
ReplyDeleteIt's because CSS has limited expressiveness. There are some things you can say easily in CSS (like make this text bold, or make the background color green), some things that are much harder (like make this element centered relative to its container) and some things that are flat-out impossible, like "augment this element with the following bit of Javascript."
> I like the idea about serving an audio file to a user-agent that requests one, but I think it slightly mars one of the attractive qualities of the web which is that the data is served to the browser and then the browser can interpret it differently for different users.
What difference does it make if the interpretation of the data for different users is done in the browser or on the server? Why should the user care where the computations are done if the end result for them is the same?
> Sending one big audio file would be a bit like just coding a whole site in flash
Yes, exactly right. The reason Flash sucks is because it does too much rendering on the server side, which impacts functionality, at least for sighted people. HTML pages do more than just render as an image on the screen. They render as a structured image that the user can interact with by, for example, selecting and copying text, or clicking on buttons. But a blind person has no need to select and copy text or click on buttons, at least not in the usual way of moving a mouse around on a visual representation. (I'm actually just guessing here. I don't really know much about how blind people use the web.) So while there might be better ways to serve a blind user than just sending out an MP3, it's still almost certain that however a blind user is best served, it will involve some sort of server-side rendering. It's much like mobile content. The assumption that HTML is going to get rendered on a screen and viewed by a sighted person is woven deeply in to the fabric of the web, and there are limits to how far you can stretch that on the client side before things start to break. That may not be the ideal, but that is the way it is.
> I really like the fact that I can change the code of a webpage that comes to me.
Yes, that's a very cool feature of the Web. But just because HTML is the lingua franca of interactions between servers and browsers, that is no reason for site developers to constrain themselves to writing their source code in (raw) HTML. In fact, no one writes raw HTML. It is not even possible to build a modern web site in raw HTML because raw HTML is by design inherently static. When the web was invented, it was envisioned as a distributed collection of mostly static data that occasionally got edited by hand, essentially a big distributed wiki. But the modern web has evolved way beyond that. It's now chock-full of dynamic content. That changes the game in fundamental ways. In fact, any HTML you see was almost certainly the result of some sort of server-side rendering already, even if it's nothing more sophisticated than filling in a template or doing some kind of SSI.
> However YOU perceive it, why would you question the judgment of somebody for whom it is not hard?
ReplyDeleteBecause I have to keep my site maintained whether or not you are available to work for me.
BTW, if CSS is so easy, then please point me to what you would consider to be the Right Answer to the so-called "holy-grail" layout:
1. A fluid layout with a header, footer, and three columns, each with its own background color, and borders between all the sections. All five sections contain dynamic content, so no hard-coded sizes allowed, except for a minimum size beyond which an area may not shrink.
2. No spillover or hidden information under any circumstances. For large content you can either grow the container or provide scrollbars, but cropping is not acceptable.
3. Dynamically resize with the window, but don't let it shrink below some minimum width.
4. Margin. I've seen solutions that necessarily push the content right to the edge of the screen, which looks like crap.
5. Allow each content area to be selectively centered, left-aligned, right-aligned. For bonus points, allow justified text as well.
6. Nestable, so that I can use it to host a blog in which I can post an entry about how it is done that includes an actual example in-line.
You get all this for free if you use tables.
> I'm trying to leave a tip on your site but that tipjoy thing isn't working for me.
Heh, maybe that explains why I'm not getting any tips. :-) I'm not sure what I can do to fix it since this is third-party code. (Hm, it seems to work for me. What makes you think it isn't working for you?)
I appreciate the gesture regardless.
"Because I have to keep my site maintained whether or not you are available to work for me."
ReplyDeleteThat still doesn't explain why you would question the judgment of somebody for whom it is not hard. If their method works for them and their own projects why would you tell them it doesn't and/or that you question their judgment? That's the great unanswered question here.
Do you have a live example of holy grail site in tables so I can visualize it better?
"What makes you think it isn't working for you?"
Because I clicked on it and absolutely nothing happened. Tried it in a different browser and still nothing.
"Some things that are flat-out impossible, like 'augment this element with the following bit of Javascript.'"
Not entirely sure who ever claimed that CSS is supposed to be able to do that or that somehow it's easier to do that with a tabled layout. That's what jQuery is for.
"The assumption that HTML is going to get rendered on a screen and viewed by a sighted person is woven deeply in to the fabric of the web."
So you are concerned about blind users. In that case it sounds like you are making a lot of websites (I haven't seen examples of your sites though - but I would like to) that are telling a blind person you are presenting a table of information to them and they will listen to it and think, "The 'information' in that table doesn't seem like a table." Don't interpret this as me saying, "Don't use tables!"
> It's because CSS has limited expressiveness.
ReplyDeleteNot everything should be easy to express in every language. Making JavaScript a subset of CSS seems like a mistake to me. IE supported it for years but it did as much to hurt performance as it did to help layouts. Since CSS is only for defining how something looks and JavaScript is for defining interactions with it I actually prefer to attach the interaction in JavaScript and style the element in CSS. I think the readability and maintainability suffers when the two get merged together. I don't think what you're describing is a stated goal of CSS nor should it be, in my opinion.
> What difference does it make if the interpretation of the data for different users is done in the browser or on the server? Why should the user care where the computations are done if the end result for them is the same?
The end result is not the same. I gave some examples of how a user agent might be more capable and therefore rendering on the server would needlessly limit the quality of the final product. That's the point of progressive enhancement. When you say, "the same" do you mean the same for each browser? If your goal in coding a page is that it look identical on every platform then I would suggest you re-evaluate that. My goal is to make accessing that page as good as the particular platform can handle. It's true that each platform could send even more information to the server than it already does on each request describing its own abilities. But why do that when it's already possible today using natural properties of the C in CSS and feature detection in JavaScript?
> So while there might be better ways to serve a blind user than just sending out an MP3, it's still almost certain that however a blind user is best served, it will involve some sort of server-side rendering. It's much like mobile content.
I would suggest actually observing how blind users browse the web. From usability studies I have read and watched it's my understanding that they do not usually have different content rendered for them on the server.
> That may not be the ideal, but that is the way it is.
I realize that some things are the way they are and we have to work with what we have. My point here was that your approach hints at moving away from the good qualities that emerge by rendering on the client. I just wanted to suggest that we not throw out the baby with the bath water, but instead, take the qualities that we like in the baby and make them even more a part of the web when we, uh, throw out the bath water.
> But just because HTML is the lingua franca of interactions between servers and browsers, that is no reason for site developers to constrain themselves to writing their source code in (raw) HTML.
I'm not even remotely suggesting that. We completely agree on the point of HTML not ever being the highest level source code. I would venture to guess that we actually also agree that HTML is not the lowest form of object code. Do we agree on that? The HTML that is sent from the server to the client is both source and object code. I feel that some of what you've written counters the "HTML is only source code" argument so much that you end up too close to "HTML is only object code". Both extremes are wrong, in my opinion.
> That still doesn't explain why you would question the judgment of somebody for whom it is not hard. If their method works for them and their own projects why would you tell them it doesn't and/or that you question their judgment? That's the great unanswered question here.
ReplyDeleteI don't care what someone does in the privacy of their own website.
> Do you have a live example of holy grail site in tables so I can visualize it better?
http://www.flownet.com/ron/demosite.html
> Not everything should be easy to express in every language.
ReplyDeleteIndeed. But if a language is to be used for layout it should IMHO at least be possible to say, e.g. "Make this thing the same height as that thing."
> When you say, "the same" do you mean the same for each browser?
No, I mean "the same as if the rendering had been done on the browser instead of the server."
> they do not usually have different content rendered for them on the server.
For sure. But this could simply be because web designers aren't serving blind users properly.
> your approach hints at moving away from the good qualities that emerge by rendering on the client
There are tradeoffs for everything. There are advantages for server-side rendering, and there are advantages for client-side rendering. The art of engineering is in making reasonable tradeoffs. The Right Answer is rarely at either extreme of any debate.
"I don't care what someone does in the privacy of their own website."
ReplyDeleteOkay, so then you agree it would make sense for you to stop saying that you question their judgment. Agreed? Agreed. Problem solved. Thank you for your agreement.
"http://www.flownet.com/ron/demosite.html"
Wow, that don't look like anything I would ever use. I was kind of hoping for a real-world example, where somebody actually wants to use that layout, but at least I see what you're getting at. Love the Buzz Lightyear. Hoping to catch Toy Story 1 and 2 in 3D right before Toy Story 3 comes out next year.
That wasn't even a challenge. 15 mins. A few tweaks could be made, and I only tested on FF for now, but here it is.
ReplyDeletehttp://jsbin.com/otoge
> I only tested on FF for now
ReplyDeleteWhich is how many people fool themselves into thinking that one hack or another actually works. In this case, the hack is display:table-cell, which doesn't work in many popular browsers (I believe IE is one of them, but I don't remember). If display:table-cell worked in all browsers that would, of course, solve the problem. But it doesn't, so it doesn't.
> Indeed. But if a language is to be used for layout it should IMHO at least be possible to say, e.g. "Make this thing the same height as that thing."
ReplyDeleteI agree about layout. Making two things the same height should be easy for a language that is meant for layout and that's why CSS as supported by the current crop of browsers leaves much to be desired when it comes to layout. I was just pointing out that your example of a JavaScript date selector widget is not very good because it's not clear how it relates to CSS/layout.
>> When you say, "the same" do you mean the same for each browser?
> No, I mean "the same as if the rendering had been done on the browser instead of the server."
Then there is a problem since depending on how much rendering is done by the server the result will be different. Rendering text on the server is a good example. The analogous example, which I gave, for a blind user (switching which voice or text-to-speech algorithms are used) is also applicable.
To be clear, I don't think you're wrong about this, in general. I agree that we need better tools for layout on the web. I am just trying to offer constructive comments to point out some things that come off as too extreme, to me.
"Making two things the same height should be easy for a language that is meant for layout and that's why CSS as supported by the current crop of browsers leaves much to be desired when it comes to layout."
ReplyDeleteCSS may not be perfect in this regard, but you can do something like this:
#sidebar, #content
{
height: 800px;
}
> I was just pointing out that your example of a JavaScript date selector widget is not very good because it's not clear how it relates to CSS/layout.
ReplyDeleteI was trying to make the point that you *can* create an abstract "dateinput" widget which can be "styled" with a javascript calendar. But you can *only* do this on the server side. But once you accept that this is a valid thing to do in *this* case it becomes much harder to raise any principled objection to doing server-side layout using tables.
> Then there is a problem since depending on how much rendering is done by the server the result will be different. Rendering text on the server is a good example.
You still have to use some engineering judgement. But there are cases where even server-side text rendering can serve a valid purpose. For example, the email address on my home page is an image in order to make it harder for spambots to harvest.
> height: 800px;
And what if my content is only 10 pixels high? Or 2000 pixels? Of course there is no problem in CSS if you know ahead of time exactly what size things are going to be. That is why I stipulated dynamic content.
Let me just say that as of ten minutes ago I got turned down for another job by somebody saying:
ReplyDelete"Your output unfortunately uses tables (a complete no-no!)."
In case anyone's wondering I had used tables in a PSD > XHTML conversion test run for a potential employer in two different spots to present tabular data.
What has this crazy world come to?
My sympathies. There are times in anyone's life when they are faced with the choice of caving in to the demands of an ignorant and unreasonable customer or boss, or doing the Right Thing (c.f. Michael Jackson's physician). This is never an easy choice to make. But just because there are ignorant and unreasonable customers in the world does not change the fact that the Right Thing is still the Right Thing.
ReplyDeleteBTW, these fads come and go in predictable cycles. Remember CORBA? About ten years ago that was the hot item. One of the things that made Google great was that they had an explicit item in their interviewing guidelines that if an interviewee said they would use CORBA that was to be considered a huge red flag. So they got people who were willing to go against the fashion of the day and do the Right Thing. It seems to have worked out OK for them. And, not coincidentally, Google uses tables all over the place. They even have one on their home page.