5 ms·
Ah yes. The old "x is hard. Writing x sometimes gets messy. I don't want to deal with all the intricacies and details of x. I know, I'll create an abstraction l
by skoob 17y ago
Ah yes. The old "x is hard. Writing x sometimes gets messy. I don't want to deal with all the intricacies and details of x. I know, I'll create an abstraction layer!"
Of course, in the best of all possible worlds, you'll end up with a perfect abstraction layer which is powerful enough to allow you to do everything you need, while hiding all of the the gory details. In the worst case, you end up with a leaky abstraction. Suddenly you need to know not only the underlying language, but also how the compiler works.
That's not to say that all abstraction layers are evil. C vs. machine code is an example of an abstraction that works well. You rarely need to dive down into the machine code and you can, to a large extent, be ignorant of how the compiler works and still be able to be a decent C programmer.
There's no doubt that developing for the web can be quite hairy and sometimes you wish you didn't have to deal with all of the compatibility issues etc. It's possible that the solution is something like Vaadin, which lets you develop web applications as if they were Java desktop applications. But I'm not convinced just yet.
I guess the real question is, what exactly is the problem with HTML? If the problem is that HTML isn't abstract enough, then yes, an abstraction layer would be the answer. But if the problem is something else then slapping an extra layer of complexity on top of HTML won't magically solve those problems.
- wvenable 17y agoI guess the real question is, what exactly is the problem with HTML? HTML is ok, it's CSS that's got the problem. It's the difference between Microsoft Word and Publisher; CSS doesn't provide enough layout primitives to do common web layouts easily. Instead, you have to specifically structure your HTML for it and layer on the <div> tags and copious amounts of CSS code.
- derefr 17y agoThe problem is that, unlike Word vs. Publisher, we don't have a set medium that we're working toward (e.g. paper.) When CSS was created, it controlled and formatted all the things that browsers could present, which wasn't very darn much. Then we thought of more things for browsers to do, and had to make our CSS much more complicated to get the same effects. To give an even older parallel, when HTML was created, it had formatting primitives that were just fine for the browsers that existed at the time. Then, as people wanted more from browsers, spacer gifs and other such aberrations were invented to allow us to achieve our complex ideals, until we invented CSS and things were simple again, for a time. The point is, the web is an ever-changing medium. We create a language for easily expressing existing web designs, and then set our sights higher and bludgeon that design language into expressing new (and previously unachievable) designs—such as, say, multi-column text layout—until we create a new web design language and the process starts over. This isn't a problem with CSS; no matter what we create, it will never be enough. There's only so much you can do with ink on the boundaries of a page of paper; there'll never be a limit to new ways to lay out shapes and vectors in an infinitely scrollable, resizable, dynamic, animated and reactive space that can be variously interpreted by different clients. That's not to say CSS isn't showing its age. It's just that this isn't shouldn't be considered a failing in the original design of CSS; rather, it should be seen as a sign of experience for web designers, that they now have newer, larger ideas that their smaller, brittler tools aren't up to expressing. Perhaps this is the best argument of all for separating content from presentation—if they're separate, we can replace CSS with something more robust (and then replace that with something even robust-er-er) without touching the content itself.
- wvenable 17y agoI agree! But the main failing of the original design of CSS (which could resolve most of these arguments) is that they didn't include a way to do page layout in the way that tables work. Many years later, with CSS3, they've finally adding it. But it seems like an obvious layout deficiency given the previous use of tables for layout.
- olavk 17y agoPage layout equivalent to tables was already included in CSS2 which was finalized more than a decade ago. It is just that browsers - specifically IE - were slow to support it. CSS3 has some proposals for grid based layouts that is much more powerful that CSS2/tables.
- aboodman 17y agoIt's a lovely story, but it isn't true. Designers have been trying to create grid-based layouts since the beginning of the graphical web. CSS was created after that, and its creators did not see fit to bestow on us the basic tools (flexible boxes) that could be used to create these layouts elegantly. As a result HTML and CSS have always been coupled. Only by using both together, can engineers create the layouts designers want. This most certainly is a failing of CSS. Sadly, it is also a failing of the web development community, who looked for progress from the one group of people who were completely incapable of delivering it.
- olavk 17y agoCSS does support flexible grids (with power equivalent to HTML tables), it is just that IE has not supported it until IE8, which means it hasn't been used widely. I fint it strange that people keep blaming the shortcomings of IE6+7 on the CSS standard.
- aboodman 17y agoReference? Are you referring to http://www.w3.org/TR/css3-grid/ http://www.w3.org/TR/css3-grid/? Which is at the working draft status?