The W3C is broken: it has spent the last 10 years standardizing ideas instead of existing practice. This is totally backwards and leads to standards that are too complicated, unrealistic, and in many cases not needed at all.
The W3C was originally created to standardize HTML, which was already being used by many vendors and users but in incompatible ways. That is exactly the right situation for creating a standard. It leads to standards that are realistic and motivated by a demonstrated need.
Unfortunately, almost everything else the W3C has ever done has happened in the opposite direction: in response to an idea or a perceived need, some people theorize about the best way to solve the problem and then write a document that a bunch of vendors are supposed to then implement from scratch.
This is how we ended up with the XML stack, which was designed to solve the data interchange problem but ended up being a disaster of complexity, inefficiency, and ad hoc implementations.
Even the case of CSS (which has been quite successful) is sub-optimal IMO, because it didn't choose to standardize the existing practice of how people were using tables for layout. The CSS box model makes it stupidly difficult to do things that are trivial with table-based layouts, like a a three column layout (which is considered a "holy grail" by even CSS advocates: http://www.alistapart.com/articles/holygrail/).
CSS could have used a table-like layout model that makes it easy to arrange <div>s into rows and columns, allowing a smooth upgrade from people who were using the <table> tag. Instead they invented something new that was much more difficult to design for, creating an unnecessary tension between web standards advocates and people who just wanted to get things done.
Standards should codify and refine existing practice, not attempt to invent new things.
The W3C is broken: it has spent the last 10 years standardizing ideas instead of existing practice. This is totally backwards and leads to standards that are too complicated, unrealistic, and in many cases not needed at all.
The general view of the W3C as a standards body is broken.
The W3C gets companies and individuals together to hash out ideas for the Web. After some time and trial and error they assemble a recommendation. Hopefully people (i.e. the members of the W3C) put this into practice to see how well it flies in real-life. At some point, if the recommendation proves its worth, a standards body such as ISO or ANSI may want to formalize it. Or so it was.
Once upon a time yo could find on the W3C site a statement to the effect that they were not a standards body. However, some people who wanted to see the ideas from the W3C gain more traction (i.e. XHTML) started referring to W3C docs as standards, and the W3C as a standards body. Jeffrey Zeldman, in Designing with Web Standards [sic], says the use of the word "standards" when referring to these specs was, in fact, "a guerilla marketing maneuver."
This is not mere semantics. There is great value in making a distinction between well-considered ideas that still need to be battle-proven, and proper formal specs that have been sufficiently vetted.
Eventually the W3C began to believe the hype and now presents itself as a standards body, to the detriment of the greater Web community because, as you point out, they are "standardizing" things that people aren't actually doing.
I agree with you in general, but not in the case of CSS.
The CSS layout model were indeed based on exactly the layout properties of "presentational HTML" which people were using for style and layout at that time. It was just made more fine grained, and separated from the markup.
For example, the much hated "float/clear" layout model were based on the align="left|right" and clear="left|right" attributes which Netscape (I believe) introduce on img- and table-elements, and which people did use a lot. The layout model of tables were also widely used, and that was codified with the display:table-* properties, which again provides exactly the same layout model in CSS as tables provided via markup.
The problem was basically that IE development were frozen for many years. IE implemented the float-related CSS before the freeze, but not the table-model. I believe IE 8 were the first version of IE to support the table model, more than a decade after CSS2 became a recommendation.
This resulted in period of many years where the float model were supported via CSS in most browsers, but the table-model were not. This in turn resulted in an amazing amount of confusion, and people believing that floats are somehow the CSS's substitute for tables.
display:table- always felt more like a hack than as something part of the design.
As in "Oh, we forgot to model certain properties of tables that numerous websites actually use. Here's a workaround that imitates a table cell until we get around to figuring it out. PS: tables are still bad."
CSS purists state that using table markup purely for layout purposes (e.g. for positioning a page footer) is bad, because it violates the separation between content and presentation. In that case display:table-* will give you the same layout (neither worse nor better!) but without requiring any specific markup in the html.
But this poses a dilemma for web developers, because display:table-* is not supported by all browsers, so some specifc kinds of layout can only be achieved with table markup.
Developers had to choose between (1) compromising the layout (2) compromising the semantic/style separation or (3) use complex workaround like the CSS frameworks, which tried to emulate the table-layout model without requiring display:table support in the browser. Neither is optimal.
I think you're misremembering history. It's not bad because 'it violates the separation between content and presentation', it's bad because you end up with tag soup. The table's demise was purely that it was too hard to maintain in anything more than a trivial layout. When you started getting down to your third nested table it was a friggin' nightmare. Also cells and rows had weird quirks as well as missing properties where you'd then have to nest a span in every cell just to get it behaving properly. Oh and also the occasional sacrifice to the dark god of 'table-layout:fixed'.
But I think we agree. Layouts with nested tables are hard to maintain because presentational concerns (like the attributes which defines cell sizes) is spread all over the document and intermingled with the content. It's a mess.
FYI, the reason why is that IE4 was released before CSS2 became a recommendation, and in fact implemented CSS1 (with bugs, but that is partly because it needs to be compatible with IE3) plus CSS-P:
http://www.w3.org/TR/WD-positioning-19970819
"CSS could have used a table-like layout model that makes it easy to arrange <div>s into rows and columns, allowing a smooth upgrade from people who were using the <table> tag."
A lot like that, yes, but that was not introduced until CSS2 which is so big and complex that they've spent almost 15 years correcting it (CSS 2.1 keeps bouncing back and forth between "Working Draft" and "Candidate Recommendation").
Despite being first defined in CSS2 (1998) CSS tables were not supported in IE for 10 years (IE8, 2009), and while some of the blame for this is surely Microsoft's, with a standard as big and complex as CSS it's hard to expect implementations to get it right for a long time.
To avoid this disaster CSS3 is "modular" and currently has over 40 modules defined! This is madness. The more complicated things get, the more difficult it is to bring the web to new devices or to innovate in the browser space.
CSS1 was deliberately designed to be 'simple' which is why they avoided the problem of layout entirely. Appendix E of the specification even says so (http://www.w3.org/TR/CSS1/#appendix-e).
Good to know -- though in that case, it seems inappropriate that web standards advocates were demanding everyone abandon table-based layouts when CSS did not actually support layout yet.
Recently the W3C has recognized and fixed the problem with a requirement that two implementations has to interoperably implement a feature for it to survive the Proposed Recommendation. That is how CSS 2.1 got created after CSS 2.0 that became a recommendation in 1998 ended up with no browsers fully complying with it.
Have you ever heard of HTML5? It is fundamentally a codification & standardization of existing practice (<canvas>, parsing, short encoding meta tags) — and when it isn’t doing that, it addresses actual needs (like how to handle video and audio).
HTML5 was created by WHATWG (not W3C) in 2004. WHATWG was formed specifically because W3C had abandoned HTML in favor of XHTML. Only when it was clear that XHTML was a failure did W3C abandon it and join forces with WHATWG in 2007.
In other words, W3C missed the boat on this. I don't think it's to their great credit that they joined a three-year-old effort after it was already clear that the whole industry was headed towards HTML5 and not XHTML.
Rhetorical, and if I could still edit to take the tone a step towards neutral, I would. But parent is an out-of-place and out-of-date criticism of w3c in my opinion. At minimum, they should explain why HTML5 is not a counter-example of their claim
You should learn the history of HTML5, it's a perfect example of how the W3C is terribly broken, and certainly not an adequate or passable standards body. HTML5 was developed outside of W3C, in spite of the W3C, and at the objection of the W3C. Remember XHTML2? Hopefully not, but that's what the W3C wanted to do. The WHATWG formed to create HTML5 because browser makers wanted to improve the web and it was obvious that XHTML2 wasn't going to do that.
After it was clear how useful HTML5 was, the W3C was dragged into participation, but unlike W3C standards, HTML5 continued on with it's open development model where discussion takes place in the open.
The W3C has not contributed the idea, the execution, the prolitical process, or the people to HTML5, and HTML5 is a W3C standard by label only. If you look at the other standards the W3C creates, you'll see a pattern where standards are developed in isolation behind closed doors and without implementations, in direct contrast to any useable and useful standard such as HTML5. RDF, OWL, SVG, all abominations that seem to exist to hold back others from making reasonable and useful replacements.
Disclaimer: I didn't test anything, just wrote the code from memory, peeking at random on-subject Google results. It is possible that I forgot, misspelled or misunderstood something.
That is because you picked an example where an old school HTML table shines and CSS looks complicated. But likewise there are many other things you can do with CSS that are pretty hard or impossible to do without it.
If webpages were always only made of box-like structures, CSS would have never made it. But you will admit that it offers a web designer much more flexibility.
That flexibility comes at a cost though, because some examples (like yours) that were very easy to realize with the very limited layout options pure HTML offered have now become more difficult. But that's because it provides a more general approach that takes care of many problems, not just three-column layout, and must thus be flexible. And flexible is what old timer HTML was not.
I'm not saying that CSS is the best or even a very good solution to the problem. I'm sure there are a lot of different approaches how to address the general problem of dividing content and layout. But it's there now, and it's bearable, I think.
Besides... all of what I wrote has nothing to do with the w3c :-)
This is definitely a huge improvement over the CSS box model. If this had been available in practice 10 years ago, I probably wouldn't be complaining about it now. But I still think it is because CSS2 is so big, complicated, and had so many errors that it wasn't implemented for so long.
Regarding verbosity: In any real wold page, you would have some additional css properties, so the overhead with defining classes and referencing them in css would be there anyway. So the verbosity advantage of html tables is down to "tr" being shorter that "display: table-row". That is not really a serious objection.
Btw., if you don't want a seperate stylesheet, you can embed the css style information directly in the html:
<div style="display: table; width: 100%"><div style="display: table-row;">
<div style="display: table-cell; width: 200px;">Fixed left column.</div>
<div style="display: table-cell;">Liquid center column.</div>
<div class="display: table-cell; width: 200px;">Fixed right column.</div>
</div></div>
This quickly becomes an unmaintainable mess but if you really want, you can do it.
It gives you separation of concerns between content structure and presentation. This allows you to adapt the presentation for different audiences. For example, on a phone with a small screen, you might not want a three-column layout, but just have everything in one column. You can do that with an alternative style-sheet.
Additionally, you don't have to confuse screen readers with a table which don't really contain tabular data. So it also more accessible.
Without actually trying that code, my guess is that unlike a formal "table", those 3 div tags will have different page-wrap behavior (e.g. not intra-div, but the wrapping of the div elements with respect to the screen width).
That may not appear to be a big deal, but try loading that page on a mobile device and it will become a bigger deal.
>The whole point of CSS is to take things like width="200px" out of the markup.
I don't see how that's really an improvement in this particular case. In fact, I would say that using 'width="200px"' inline may actually be more readily understandable and maintainable than having the style defined somewhere else and then used only once. (I'm assuming that the 'width="200px"' is not duplicated multiple times in the PHP/Python/Arc/etc code that generates the HTML page. If the same style needs to be identified multiple times in the source code, then of course it may be a better idea to define it once and thereafter refer to it by name.) Are there any practical benefits that I may be missing?
How do you know when you use a style the first time that you'll never use it elsewhere? If you've got many one-off style declarations, you probably don't have a very consistent graphical style.
Besides that, it's nice to know where all your styles live instead of having to grep your whole project. And inline styles take precedence over everything else, so mixing them with stylesheets can create havoc.
The example is contrived because there is no content in the table cells. In the real world there will be some content, and suddenly your "width"-attributes are many lines apart and not nicely aligned. This makes is a mess to maintain, because there is no single place where your layout is defined; the information is spread all over the document, mixed with other kinds of information.
Furthermore, separating style info into a style sheet allows you to adapt the style for different devices.
You have to show what your CSS would be also. My point is that the CSS you have to write to get your example to look like mine is extremely complicated when all you have is the box model.
People tend to avoid this relatively simple solution because of the double-left-margin bug in IE 5 & 6, but that's getting to be an excessively old set of browsers. And even then, it's usually fixed with a "display:inline;" on the ones with left margins.
edit: it's not an ideal solution, as it has those negative values which have to match the related positive ones. Which is solved with something like Sass or Less, because CSS lacks any "programming" abilities, which I see as its main failure. Even variables and simple math would be acceptable, but instead, nothing.
You can wrap the above in another div with a width of 660px or greater and it'll have the same effect as a table if the window width is less than the width of the columns (plus margins/padding).
I've been thinking about this sort of thing a lot lately. Sugar (http://www.sugarlabs.org/) get a lot of things right in terms of p2p user interaction. If you want to, say, edit a document with a friend you just click invite and Sugar will handle everything else. It will even send them a copy of the editor app if they don't have it installed.
I think developing small-scale p2p apps (eg IM, 1-1 audio/video, multiplayer-editors ala etherpad) can be made a lot easier than it is today. My rough plan of attack is to use erl-telehash (https://github.com/jamii/erl-telehash) for addressing and NAT traversal with something similar to bloom (http://www.bloom-lang.net/) for coordination / logging / debugging. Add libraries for at-least-once messaging, leader election and operational transform. Maybe piggyback on chromeos or android to get secure p2p app installation.
I also had some thoughts about the CALM hypothesis (http://www.bloom-lang.net/calm/) which I haven't seen mentioned in the literature. A monotonic bloom program is one in which every delivery order for a given set of messages results in the same state. For many protocols what I actually care about is that every possible end state is equivalent, for some protocol-specific notion of equivalence. For example, for leader election all I care about is that every end state should have exactly one leader. Monotonic programs are easy to model check and I think explicitly stating the desired equivalence relations will reduce the state space explosion at points of order. It might be possible to get good results from a very simple/naive model checker by exploiting this.
Not hugely related to the article, but its been on my mind a lot lately.
As the comments point out, this is not a generic decentralised web standard to get around ICE and the like, but just a specification for p2p audio/video/etc communications for online video conferencing and so on. Not as big as I hoped.
But if you enable p2p communication between javascript clients, there should be nothing stopping you from implementing that kind of stuff within the browser.
That's a shame. I was just thinking yesterday how great it would be to be able to host web pages in a P2P fashion (after all, people are building an economy of the bittorrent infrastructure). Sites like WikiLeaks would get a great advantage of this sort of protocol.
freenet and other services already do this. You can already use your browser to browse freenet, if you get the freenet program. They recommend using Chrome in Incognito mode for maximum privacy.
And it is impervious to DNS takedowns and you can even set up a darknet. It's used in China a lot. Also Perfect Dark is used. They operate on distributed hash tables. The problem is that without a central server, the only way you can connect to the hive is by hoping one of the last known hosts is still up. It also needs to use heuristics for routing.
The problem I have with freenet is that I don't want to blindly store or transfer other people's encrypted data.
I think, if we take some of the powers away from the government, it is all the more important that we are able to make a judgement on the kind of content and communications that we want to support.
No single entity should be able to control all access to information, not even a democratic government. But turning the tables completely and make everyone help anyone spread any kind of information can't be the solution.
I'm totally aware of the dilemma we're in. Knowing what other people transfer over our machines puts us in a position of "must make judgement and be liable". Not knowing puts us in the position of "cannot make a judgement even if we want to".
I don't know. I guess the answer to your last question is that I don't want a system that thwarts all kinds of social filtering or control and at the same time makes it impossible to trace people who commit horrific crimes. I think we want to decentralize social control, not abolish it completely.
"horrific crimes": Exactly. That was my 2nd thought on reading the headline. (1st was Awesome). We need some form of control, to prevent the worse of it. Perhaps some sort of community voting/blacklisting?
Yes, there are a ton of other overlays that do p2p. The advantage of a browser is that no one needs to download/install any software to avail p2p features.
Less corporate/company crap, more independent ideas please. Things like Freenet, GNUNet, etc. have the right idea for decentralization, same with more specific projects like Appleseed, StatusNet, etc.
Oh, it's simple! All we need is for each node to sign their content with a private key. Then everyone can check the validity of the content with the originating node's public key, even if it comes from some untrusted intermediary.
Hm, now all we need is a centralized server to distribute the public keys securely. But that's a lot of keys (one for every node), so let's use a distributed system... oh wait :)
"A number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, lest they be discovered. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.
They don't particularly care when the attack will be, just that they agree. It has been decided that anyone who feels like it will announce an attack time, which we'll call the "plan", and whatever plan is heard first will be the official plan. The problem is that the network is not instantaneous, and if two generals announce different plans at close to the same time, some may hear one first and others hear the other first.
They use a proof-of-work chain to solve the problem. Once each general receives whatever plan he hears first, he sets his computer to solve a difficult hash-based proof-of-work problem that includes the plan in its hash. The proof-of-work is difficult enough that with all of them working at once, it's expected to take 10 minutes before one of them finds a solution and broadcasts it to the network. Once received, everyone adjusts the hash in their proof-of-work computation to include the first solution, so that when they find the next proof-of-work, it chains after the first one. If anyone was working on a different plan, they switch to this one, because its proof-of-work chain is now longer.
After about two hours, the plan should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce in the allotted time. At the least, most of them had to have seen the plan, since the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work is sufficient to crack the password, they can safely attack at the agreed time."
All p2p tamper-proofing schemes reduce to the Byzantine Generals Problem. There exist working algorithms, and the math was figured out a long time ago.
There are two wrinkles, though: BGP solutions are kind of slow. Worse, it is impossible for any BGP system to function securely if more than 1/3 of the nodes act in bad faith.
Tonido (http://www.tonido.com) is a pioneer in this space. They have invented the model much before opera unit. The cool thing is that Tonido also provides a decentralized openid to end users.
Firefox should buy Tonido. It will change the industry if it happens and the way people share information. I probably may be little ahead. If you think deeply it will make sense.
Even if you were wrong, I don't think you need to apologize. Almost all of his comments were trying to promote something rather than provide meaningful discussion.
Yes I work for Tonido. There is nothing wrong in saying we do the same stuff. If u think Tonido is irrelevant to the discussion that is your prerogative.
The W3C was originally created to standardize HTML, which was already being used by many vendors and users but in incompatible ways. That is exactly the right situation for creating a standard. It leads to standards that are realistic and motivated by a demonstrated need.
Unfortunately, almost everything else the W3C has ever done has happened in the opposite direction: in response to an idea or a perceived need, some people theorize about the best way to solve the problem and then write a document that a bunch of vendors are supposed to then implement from scratch.
This is how we ended up with the XML stack, which was designed to solve the data interchange problem but ended up being a disaster of complexity, inefficiency, and ad hoc implementations.
Even the case of CSS (which has been quite successful) is sub-optimal IMO, because it didn't choose to standardize the existing practice of how people were using tables for layout. The CSS box model makes it stupidly difficult to do things that are trivial with table-based layouts, like a a three column layout (which is considered a "holy grail" by even CSS advocates: http://www.alistapart.com/articles/holygrail/).
CSS could have used a table-like layout model that makes it easy to arrange <div>s into rows and columns, allowing a smooth upgrade from people who were using the <table> tag. Instead they invented something new that was much more difficult to design for, creating an unnecessary tension between web standards advocates and people who just wanted to get things done.
Standards should codify and refine existing practice, not attempt to invent new things.