Ask HN: Why does Gmail still have a loading progress bar? - <AUTHOR>

Why does does Gmail still have a loading progress bar ("Loading email@example.com") circa 2005?  What with the improvements in javascript speed in recent years, I would have thought this could be dispensed with.  Is Gmail no longer actively developed? <comment><USER2> This is a good question that is likely related to how it was made. Last time I heard Gmail was created with GWT that compiles Java into JavaScript.

The libraries will be cached but it means that most of the logic is processed and rendered from JavaScript code and not loaded from the server.

If Google wanted to start over they could pre-render these pages on their massive servers and you could then download these pages without any JavaScript at all. But rewriting is often not the way and really this is a trade off. Do you want to see the content fast or do you want the interactions to be fast when it is ready? If you pre-render everything you either have to rely on new request to get new views or you still have to download all of that JavaScript to do view changes.

They are speeding up JavaScript with Chrome, they are making faster protocols with SPDY and they are doing work in the back ground to make their servers faster. If they didn't do anything to the Gmail code base it would still become faster over time because of these other improvements.

Really the approach that they took is the same one that most Flash projects took because they found that interaction was more important than download time. I would assume they have tested this approach and likely most real users where not bothered by the second or two of progress bar.

</comment><comment><USER3> It is, but the datasets involved are huge, and the various AJAX requests do need their time.

20 emails in the inbox view (API endpoint 1), directory information (API endpoint 2), Google Chat (API endpoint 3), your most-frequented labels (API endpoint 3) - and especially the email-endpoints are quite traffic-intensive!

So the GMail team decided they'll load with a progress bar instead of creating four or five widgets with "loading..." placeholders (unlike I do at readme.fm). When you got a lot of various and/or traffic-intensive assets, then you have to choose one of those two models.

(Of course, you can take advantage of IDB/WebSQL/LocalStorage/AppCache, but that is only helping a little bit)

</comment><comment><USER4> Not everyone has a broadband internet connection you know</comment>


End to end encryption though Kafka: our proof of concept - <AUTHOR> http://www.symantec.com/connect/blogs/end-end-encryption-though-kafka-our-proof-concept <comment><USER2> a blank page?

<comment><USER3> Blocking their tracking (New Relic) means the page won't load.

<comment><USER4> I'm blocking New Relic and it loaded fine. I am allowing ajax.googleapis.com though.</comment></comment></comment>


I was a lead developer and got banned for multiple Code of Conduct violations - <AUTHOR> https://medium.com/@chx/a-note-from-an-open-source-lead-developer-who-got-banned-from-his-community-due-to-code-of-conduct-22d8f066ab9e <comment><USER2> I applaud this man's courage to accept the importance of conducive conduct to future entrants, despite the fact that he was affected by such a move.

> "Every moment that is spent on modulating language...is a moment not spent > on thinking about technical things, and therefore...a moment wasted."...But > this common view is a limited, short term view.</comment>


Pull request to remove sexist remark from CodeIgniter generates controversy. - <AUTHOR> https://github.com/EllisLab/CodeIgniter/pull/1615

<comment><USER2> just seems like general dickery all around in that comment chain. i don't blame the dev for aquiescing just to close it</comment>


Google 'Wasting' $16 Billion On Projects Headed Nowhere - <AUTHOR> http://www.internetevolution.com/document.asp?doc_id=240386&print=yes

<comment><USER2> Its not waste. Research and innovations help society. They use the massive cash pile to innovate in newer areas rather improving the same product for years. Failure does not mean loss always !!</comment>


Introducing Rickshaw: Interactive time series graphs in JavaScript - <AUTHOR> http://bits.shutterstock.com/?p=103

<comment><USER2> The controls don't work on mobile safari (iPad) :-(

<comment><AUTHOR> Thanks for giving it a whirl! When you say the controls don't work, are you talking about the controls in the extensions example ([http://shutterstock.github.com/rickshaw/examples/extensions....](http://shutterstock.github.com/rickshaw/examples/extensions.html)), or something else?</comment></comment>


India successfully shoots down satellite in space: PM Modi - <AUTHOR> https://timesofindia.indiatimes.com/india/india-successfully-shoots-down-satellite-in-space-pm-modi/articleshow/68593732.cms <comment><USER2> Question: What happens to the debris generated? Is there debris generated or the satellite is just "disabled" and falls down?

Space debris is a serious future problem, that should not be ignored.

<comment><USER3> From Indian Express:

The test was done in the lower atmosphere to ensure that there is no space debris. Whatever debris that is generated will decay and fall back onto the earth within weeks

Of course we can never know, but the fact that they discussed about it hopefully says something

</comment></comment><comment><AUTHOR> 4th Country to do such capabilities.

1\. Russia

2\. US

3\. China

4\. India</comment>


Why CSS should not be used for layout - <AUTHOR> http://www.flownet.com/ron/css-rant.html <comment><USER3> The article's argument would carry more weight if the author gave an example using tables where he changes the order without affecting the layout.

The whole point of the argument is to show that if you change the order with the CSS version, things move around. Then he goes on to show a static table. What the article really proves is that tables are not better than CSS. And CSS can do millions of things that tables can't (I'm not trying to start a troll on that topic). So I'll stick with CSS, thanks.

There is one valid point in the argument: improving CSS so that you can position elements in relation to each other _by name_ would help. So I could say that the DIV element called "left" should be on the left of the "center" element. Right now, relative order is based on the order in the HTML source.

<comment><USER4> "What the article really proves is that tables are not better than CSS."

Well, no. What the article shows is that, for layout, CSS has one of the same chief defects that people complained about for tables (content and presentation codependence), and that CSS doesn't even have the saving grace of allowing the content to be in the same order people read in (in Western languages, yes, yes), as tables do.

<comment><USER5> This is only true if you use CSS floats in a particular way which was not foreseen when the specs were written, which is only necessary if you want a certain kind of layout and don't want to use positioning or scripting. That strikes me as a step forward from _always_ having that codependence.

<comment><USER6> If this is true, then the CSS spec is bad. You should not have to require scripting to position elements. Period. If you do, then it shouldn't be called CSS, it should be called CSS/JS or some other merged acronym.

I've spent many hours tweaking a design with CSS and javascript to replicate what would have been a simple table layout. There are just somethings that CSS isn't good at, for example, it's bad a fluid column layouts. Particularly where you want to have a vertical alignment of a block line up with the bottom of the longest column. (I probably didn't explain that well...) I'm not aware of any CSS that can handle this well w/o javascript.

<comment><USER5> Who said you have to require scripting to position elements? I most certainly didn't mean to suggest that. That said, CSS is not a programming language, so by nature there are things possible in combination with JavaScript that would not otherwise be possible. I think it's worth considering when attempting to go against the grain of the language, just as it's worth considering changing direction to do something the language is better equipped to deal with.

</comment></comment></comment></comment></comment><comment><USER7> I have the sneaking suspicion that there are a lot of coders contributing to this recent rash of CSS vs. table discussions who flat-out don't know how to write CSS very well, and can't be bothered to learn.

That was my obligatory quasi-offensive hook to get you reading. Now, before you actually get angry... there's nothing wrong with that! You're a coder! Do what you do best - write awesome useful stuff! ...and don't be afraid to acknowledge that there's a language out there that looks like code, but that you don't have a handle on.

As someone who has spent the last several years doing nothing but writing HTML and CSS in a professional capacity, I am here to tell you that if all you beautiful, intelligent hackers out there (I'm only being facetious about the beautiful part, 'cause I've seen some of you ;) really understood front-end layout the way you understand all your programmy stuff (which I do NOT), we wouldn't be having this discussion.

If you're just working on a personal project, or trying to hammer out the beta version of your web app... sure, use tables, so you're not wasting time trying to do something that's not your core competency. However, if you're taking it beyond that, or trying to get into front-end stuff in a professional capacity, you need know CSS like the back of your hand. Someone who's competent at layout should be able to write something from scratch that does whatever they want it to without having to debug it for hours.

If you're at the point where your biggest problems would be solved by using table layout instead of CSS, you're probably not at a point on the CSS learning curve where it's appropriate to make assertions about which layout technique is superior.

All that said, if you're a coder, why do you want to get into layout anyway? Your skills are WAY more valuable... designers like me are just here to make your work look good ;)

<comment><USER8> Well, is there anything you have to say on the substance of this debate? The good thing about Ron Garret's article is that he said specifically why he thinks that CSS is unsuitable for doing layouts. You're free to come up with a counter argument.

Instead what you do is talk in general terms about the competence of people whose CSS competence you know nothing about. That's just not very convincing.

And by the way, you're "argument" reminds me of what C++ advocates keep going on about. Templates are turing complete, etc, you just need know how to use them. But even if competent CSS experts can make most things work, that doesn't mean they wouldn't be much more productive using something better suited to layout.

<comment><USER9> * that doesn't mean they wouldn't be much more productive using something better suited to layout*

What would you suggest is better suited to layouts than CSS?

<comment><USER8> I agree with Ron Garret that tables are a better fit in most cases, even though they do have their own drawbacks that I'm not denying.

I don't buy the argument that tables somehow imply semantics that contradict their use in layouting. Tables have no semantics without a formal system that lends them semantics (like the relational model).

I'm not aware that the W3C or anyone else defined the formal meaning of tables, and since HTML is a UI technology I don't see why "table" should not be interpreted as a form of laying out content in rows and columns.

<comment><USER7> "Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables."

<http://www.w3.org/TR/html401/struct/tables.html#h-11.2.1>

<comment><USER8> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] <http://www.ietf.org/rfc/rfc2119.txt>

From that RFC:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

</comment></comment></comment></comment></comment></comment><comment><USER10> A well written and compelling argument. Way above the average CSS/Table rant for sure.

<comment><USER11> Above average, sure, but still misinformed and one-sided.

It is correct that some layouts are easier created using tables rather than CSS. However, there is also many types of layouts which cannot be created with tables, but require CSS.

A serious article (rather than a rant) would explain the limitations of both approaches, given the limitations of current browsers.

<comment><USER12> I for one would be interested in an HN submission that fleshes out the suggestions you're making here.

<comment><USER11> I have an article which explains when to use tables: <http://olav.dk/articles/tables.html>

But now that the pendumlum seem to have swung from _never use tables for layout_ to _always use tables for layout_ , I suppose it should be extended with an explanation of when _not_ to use tables :-)

</comment></comment></comment></comment><comment><USER13> The author's point might have been better if there weren't a bunch of CSS libraries which have already solved this (<http://developer.yahoo.com/yui/grids/> and <http://code.google.com/p/blueprintcss/> to pick two).

You wouldn't rewrite cstdlib why would you rewrite your CSS framework for every project?

More over I think a lot of people neglect the real issue which is the high touch point of the Web, it's the multiple clients. You try to write cross-OS GUIs in Java and Swing and find out how easy that is (it isn't, obviously).

The reason people advocate CSS is that it presents some real tangible benefits. CSS was specifically designed to present the semantics of layout rather than HTML tables. The author doesn't even talk about CSS tables ([http://thinkvitamin.com/design/css/tables-the-next- evolution...](http://thinkvitamin.com/design/css/tables-the-next-evolution-in- css-layout/)).

Again I wish people would talk about technologies they were familiar with and had even made spent time with. You don't see me critiquing the algorithmic design of search engines because I didn't choose to follow CS down that route of expertise.

<comment><USER14> Grids need more coverage, as they are by far the best way to bypass css misery and create a flexible, controllable layout for your website. They require a whole lot less markup than tables, are more intuitive, are much more controllable, and in general should never be not used. With Grids, you start thinking about ratios rather than pixels, which is a real help in making your site aesthetically pleasing and flexible.

</comment></comment><comment><USER15> When you first start learning CSS you learn how to get rid of tables. When you get _really_ good at CSS you learn when to bring them back.

</comment><comment><USER16> First, <http://shouldiusetablesforlayout.com/> for the idealist in me.

Second, <http://giveupandusetables.com/> for practicality.

<comment><USER6> I particularly like that the first one uses a single table for layout.

If you're reading the page's source, you'll also find this eternal wisdom: "Fact: Chuck Norris hates layout tables!"

<comment><USER16> Actually, if you check the first one again, it uses CSS, but it has a table layout commented out.

</comment></comment></comment><comment><USER17> His html example for the 3 column layout is subpar anyway. The wonderful advantage of CSS is that I can create a multi-column layout where the html might put the content div first and the nav last, if I have a reason to do so. My underlying html structure doesn't need to be in any particular order in order to achieve the layout that I want. He completely misses the fact that CSS2.1 has had display: options to do table-like alignment for years. These are well supported in modern browsers, except for IE6 and 7.

I completely recognize this is an argument of "what should be" versus "what is". As it stands though, I have been doing this for years and have never, never EVER needed to use tables for layout purposes. I get that some people are more interested in writing applications and just don't have to time to learn all of the idiosyncrasies that go into dealing with cross-browser display problems. However most of these are easily overcome, most without even needing CSS hacks.

<comment><USER18> "except for IE6 and 7"

So it doesn't work for the majority of browsers, yea, that's a technique I really want to count on.

<comment><USER19> That's the fault of IE6 and 7 though, NOT CSS. Blaming CSS for the inadequacies of MS browsers is flawed logic.

<comment><USER20> It doesn't really matter who's to blame, it doesn't change the sorry state of things...

</comment></comment></comment></comment><comment><USER21> The arguments presented seem like a half truth to me.

1 HTML multiple CSS not 1 CSS multiple HTML

The whole concept should be that HTML should be written to have 100% accessibility across all readers (browsers and mobile devices), meaning someone with the most ancient browser can read the page and understand the content of everything without any form of presentation.

What the author has done essentially is the following: Try reversing some words in a sentence and then later complain that English is flawed because the sentence no longer makes sense reading it left to right.

The HTML won't make any sense if you start reversing it... I mean what is the point of putting
 tags below your
 when it's obvious that the
 tag is acting as the heading for the
 below. I wouldn't be able to read that, so why is CSS @ fault?

The logical flow of the content should be based upon the reading the raw HTML in a procedural order. This will keep it simple for coders to update the content, and css artists can pump many different layouts and show many different layouts to clients in a matter of seconds.

Good CSS also requires good HTML. Why the author of the article is using a div container to wrap them all when a body tag exists is beyond me.

I think as much as we point our fingers at css as a flawed language, we need to point our fingers at how write our HTML as well.

www.csszengarden.com

<comment><USER22> > I mean what is the point of putting
 tags below your
 when it's > obvious that the
 tag is acting as the heading for the
 below. I > wouldn't be able to read that, so why is CSS @ fault?

Nobody is talking about putting headers after the content they're introducing. The author is talking about a situation where it makes sense to order the markup one way, but CSS demands it to be done a different, not easily readable way. Which does happen sometimes.

> Why the author of the article is using a div container to wrap them all when > a body tag exists is beyond me.

This looks like a ridiculous statement to me. But please, explain further what you want him to do.

I find it comical that you go on about "good HTML" and then point to CSS Zen Garden, where the HTML is inextricably bound up with the presentation (ie, adding wrapper elements to allow for flexibility in styling). CSS Zen Garden is an example of HTML as it should not have to be.

<comment><USER21> CSS doesn't demand it to be done differently though. If the HTML is written with a different flow the CSS will need to be written to accompany that.

I won't say it's perfect, but if you wrote div col 1 div col 2

and then you wanted col 2 to be on the left of col 1, you'd write the css differently then you would the forward method.

>This looks like a ridiculous statement to me. But please, explain further what you want him to do.

Well look at it this way
<stuff>

What is it that div container is doing so well that body isn't already doing as a binding tag?

> I find it comical that you go on about "good HTML" and then point to CSS Zen > Garden.

I will have to disagree. CSS Zen Garden reads perfectly and logically without css. It's something that 90% of sites are missing out there. And although the HTML is inextricably bound up with the presentation as you write, it is 100% readable by Netscape 1.0.

He uses HTML to describe the data that is being wrapped in the tags, and the information that is grouped by divs are grouped by the fact that the content is related, not by the fact that the data should be visually sitting beside each other.

While there is excessive usage of  tags written throughout, it was a design decision to enable css artists to replace text with images, or allow them to get around browser quirks that are challenges that CSS still face today.

<comment><USER22> > and then you wanted col 2 to be on the left of col 1, you'd write the css > differently then you would the forward method.

At the cost of a lot of flexibility. Most people, when faced with a change in design like this, simply reorder their HTML. So perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.

> Well look at it this way
<stuff>
 container>

The container is providing a hook for layout information that the body tag cannot. For instance, if I wanted the body background color to be blue and the container's background to be white. Also, if you want your content to be restricted in width, it's a lot easier to wrap it with a div than deal with the lack of the > operator in IE 6.

> CSS Zen Garden reads perfectly and logically without css.

I didn't say that it's hard to read. I said that by the standards community's definition it is not good HTML, because it mixes content and presentation.

Just to be clear, I think that "bad HTML" is pretty much the only practical way to go right now. So, I don't have a problem with the way CSS Zen Garden uses wrappers, nor do I have a problem with the wrappers in this blog post. But you are criticizing one and making excuses for the other.

<comment><USER21> >At the cost of a lot of flexibility. Most people, when faced with a change in design like this, simply reorder their HTML. So perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.

I don't doubt that cost/time is a factor. As programmers, we would all love to do without the additional overhead of coding practices, and for an unlimited number of reasons.

I realize that css isn't the best language in the world. But if it was intuitive to write css forwards and backwards regardless of document flow -- this wouldn't be a discussion topic. The question is the amount of time invested to learn it.

>The container is providing a hook for layout information that the body tag cannot. For instance, if I wanted the body background color to be blue and the container's background to be white. Also, if you want your content to be restricted in width, it's a lot easier to wrap it with a div than deal with the lack of the > operator in IE 6.

This is true. I was looking purely from layout perspective, but yea, body bleeds background-color and image everywhere regardless of limiting the width.

>Just to be clear, I think that "bad HTML" is pretty much the only practical way to go right now. So, I don't have a problem with the way CSS Zen Garden uses wrappers, nor do I have a problem with the wrappers in this blog post. But you are criticizing one and making excuses for the other.

Practical -- yes I don't disagree. With the way browsers interpret things differently, it's just about the only way you can get compatibility across the board.

Though you are right that I criticizing one and making excuses for the other: at least one follows a clear stated goal -- html describes the content, css draws the presentation. Provided items are added to make do with incompatibility issues, but at least at the core we can see that HTML is purely being used to describe the content. Allowing _enough_ separation required for programmers to be nearly clueless of a designer's job.

The other has no such goal; creating a massive grey area between the programmers and the designers.

<comment><USER22> > I realize that css isn't the best language in the world. But if it was > intuitive to write css forwards and backwards regardless of document flow -- > this wouldn't be a discussion topic. The question is the amount of time > invested to learn it.

Quite right. The argument, as I see it, is that it's much more practical to use the best cross-platform tool for the job, which in many cases is tables and not CSS. He's arguing that it's not worth the time.

> at least one follows a clear stated goal -- html describes the content, css > draws the presentation.

This isn't even close to CSS Zen Garden's stated goal. Its goal is to show what is possible to do using CSS. It's goal is to be "A demonstration of what can be accomplished visually through CSS-based design." There's nothing about content/presentation separation anywhere on the site.

> but at least at the core we can see that HTML is purely being used to > describe the content

That's certainly not what I see at all, especially at CSS Zen Garden, if that's what you're still referring to here.

> Allowing _enough_ separation required for programmers to be nearly clueless > of a designer's job.

If you mean programmer == HTML, and designer == CSS, then this is simply wrong.

<comment><USER21> Programmer == backend html // designer = AI/PS/CSS cutter, and css writer

 __When I view source csszengarden this is what I see:

<acronym>

<acronym>

 etc etc. And it goes on.

All I see are information grouped by content. The ids, and class tags describe the information. The paragraphs are ordered p1,p2,p3, because for them to make sense they have to be in that order.

Page header, quick summary and preamble are all items that belong to an introduction.

I think it's great.

<comment><USER22> In the source of csszengarden, do you also see this

> There are more classes and extraneous tags than needed, and in a real world > situation, it's more likely that it would be much leaner.

and this

>

and this

>
 id="extraDiv1">

 id="extraDiv2">

 >

 id="extraDiv5">

The HTML guy could not be "nearly clueless" about the designer's needs if CSS Zen Garden's flexibility is what you're looking for.

<comment><USER21> Sure I see it.

But your whole argument is on the basis points of 2 commented divs?

Add extra imagery -- it's posted at the bottom and away from the content. It's not like it's messing with what the programmer needs to develop. You could have easily have removed those tags and only the designs that decided to take use of them would get hurt -- but it is optional, not a requirement.

 I thought we discussed that browsers incompatibilities are the reason for this.

The core of the content is listed at the top of the HTML page which is organized properly.

TBH: I would hardly call this level of adding extra markup anywhere close to other HTML where the presentation is completely ingrained.

<comment><USER22> > it's posted at the bottom and away from the content

But it's HTML, and should therefore should BE content. But it's not; it's presentation.

> I thought we discussed that browsers incompatibilities are the reason for > this.

You seem to be missing my point. If CSS, as implemented NOW, worked as advertised and offered a way to separate content from presentation while retaining flexibility, then we'd have no argument. I'd happily be using it for what is intended. You just can't do that now, and I'm tired of people telling me that I can.

> I would hardly call this level of adding extra markup anywhere close to > other HTML where the presentation is completely ingrained.

Of course it's not completely ingrained. But I want it to be able to be completely separated before I'm going to join your camp.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Do we really want this kind of bickering around here? There's a time and a place for every technology. Everything has pros and cons. There's no _perfect_ solution. There are lots of _good_ solutions. Sometimes CSS is one and sometimes Tables are one.

Usually tables are used for tabular data. It is helpful for understanding what is on the page. It helps the robots.

CSS knows nothing about the data. It doesn't care what's in whatever it is making pretty and the robots are fine with that.

There's so much work to do. Why do we argue over these silly things. If you can do it with tables, do it with tables. If you can do it with CSS, I'll pay you 5 or maybe 10 dollars more per hour.

Look, for every weakness you can find in the CSS route, I can find a weakness in the tables route. Try doing a fluid design with tables. Show me a search results page that will automatically fill in tiles to fit the users' resolutions. That's hard to do with tables, you have to use JavaScript and it's nuts.

With CSS, just make them float left.

That's why CSS is cool, little things like that. Yes, Tables are easier, they are. No one denies it. Easier does not make it better. Just because CSS has _some_ flaws doesn't mean you shouldn't use it.

CSS is good, it's separation of data and presentation. It's division of labor. It's not bad. It's good.

If you have an application for example and you want to let your users put information anywhere using only one text file and without programming, let them do it with CSS. That makes sense. Tables are hard to make dynamic...

Maybe that's the divide: static vs. dynamic

Static layout with tables, fine. Dynamic layout with tables, not fine.

Look, anyway, why all the animosity toward the CSS'ers? CSS is totally fine. No need to be hatin. It's not a popularity contest, it's a technology that can be used to do things.

<comment><USER23> Who are you arguing with? Mr. Garrett states very clearly that both tables and CSS have a proper use.

</comment></comment><comment><USER24> He makes a great point. Besides, your tables will work on more browsers than the CSS layouts.

</comment><comment><USER25> It doesn't matter if the logic behind using xhtml+css is flawed: the xhtml+css evangelists have so saturated the development world with their propaganda that I'm worried if I make an educated decision to use html 4.01 or occasional layout tables it will hurt me when potential employers, clients, or even the general webdev community review my code and think I don't know what I'm doing.

Does anyone else feel that way?

<comment><USER26> Yes and No.

It isn't just propaganda anymore. Pure CSS is what you're going to see in almost every code base you might work on. The last several gigs I've had wouldn't even allow tables for tabular data, which I think is ridiculous.

If I were reviewing your code, I'd give you points for using tables to deal with tabular data. I might not even hold it against you if you used it in a layout, depending on context. Unfortunately the person reviewing your markup will probably expect pure CSS, even if it is data displayed in a table format. Adjust your expectations accordingly.

<comment><USER27> Wow - not allowing tables for tabular data - this just shows how much kool-aid some people have drunk

</comment></comment></comment><comment><USER28> A related argument against table-based layouts, which I don't see any discussion about yet, is that "it's important to maintain a high ratio of content to markup for SEO purposes."

In my view, a complicated div-based layout is just about as markup-heavy as a table layout, given separate CSS files in both cases. So I would think the point is moot. And my suspicion is it's just SEO firms blowing smoke in an effort to figure out things to sell.

So, is this at all a substantiative claim?

</comment><comment><USER29> I agree with this guy -- CSS is horrible :)

One of my Great Plans For The Future is to write a language that abstracts away HTML, CSS, and (some) JavaScipt. You describe your layout in a format that makes sense, and the compiler will decide whether to use tables, CSS hacks, or whatever.

Ideally, this wouldn't be necessary, but I've never written CSS without the knowledge of the HTML it's going to be applied to, nor have I written HTML without considering how to style it.

I am not being dumb, either. HTML needs all sorts of hooks for styles (classes), since HTML doesn't have any meaningful elements. (Oh boy, I get
, , and lists.) When I have done three-column layouts, my HTML has always needed tweaking -- the content has to be in a certain order (usually left/right/center, which is stupid), and it has needed hacks like
.

So clearly we don't live in an ideal world; we are stuck with HTML and CSS the way they are. It is time to abstract away the stupidity like programmers abstract away the computer with high-level languages.

</comment><comment><USER30> I'll stick with CSS. I've never once had to place CSS items out of order that is a ridiculous statement. There is a place for tables from time to time but once you actually "understand" CSS, life becomes much easier. I think the problem with most people is, they are told to use CSS, but without guidance they might not understand the core and basics.

<comment><USER31> Please paste an update to the example, that just 'behaves' like the table then? eg the background goes to the bottom, bad things don't happen depending on size of the content etc.

I've never seen a css example that behaves like a table.

<comment><USER32> Just out of curiosity... why do you want something that is not a table but behaves exactly like a table? Isn't that what tables are for?

I think starting from the premise that CSS (as it is currently implemented by major vendors) is a super set of tables, and as such, must do everything tables do is misguided. From my experience, the absolute need to use tables doesn't appear in every layout (for me, at least, it's rather rare), and pragmatic CSS developers tend to use tables only as a fallback when CSS / IE / whatever doesn't quite work.

I've seen css examples that can't be done with tables, so I don't know exactly where we are trying to get with this line of reasoning.

</comment></comment></comment><comment><USER33> I would be more inclined to be sympathetic to the cause of the author, and the ridiculous amount of people who upvoted this (wow, demographics change on HN, pg wasn't kidding) were he/she to show more than a three hour understanding of CSS.

Obviously, when you can produce something like this: <http://www.csszengarden.com/>, showing how a single html page can be manipulated in an infinite number of ways, it isn't CSS that's lacking, but your knowledge of it.

I'm sorry if this isn't the popular opinion on this board, but as someone that coded tables and then made the transition, I can assure you that css is a much more powerful medium for web page layout, despite its quirks.

<comment><USER34>
      > wow, demographics change on HN, pg wasn't kidding

Right Click -> View Source

<comment><USER35> I thought grandparent was referring more to the quality of the content than the claims of the argument.

<comment><USER33> I was thanks.

</comment></comment></comment></comment><comment><USER36> One of the most compelling arguments _for_ css is to use it rearrange the content of your webpage so the most relevant content appears earlier in the data. Apparently this can have a significant effect on your search engine optimization.

<comment><USER37> If it's your choice, making the most relevant content appear earlier in the layout too (thus removing the need to reorder) sounds like a good idea.

</comment></comment><comment><USER38> One thing that CSS does especially badly that tables do well is correlated sizing. It's easy with tables to make all the elements in a layout row all have the same height. Doing the same in CSS is possible but requires so many hacks that the net result makes you feel dirty.

I've watched this war for years now, and just wish both sides would give some ground. As long as you do your layout with the fewest amount of tables needed (trending toward zero), the you shouldn't need to guilt yourself out about it.

</comment><comment><USER39> Conceptually, styles and positioning are two different animals. We need a tripartite model of 1) content, 2) styles, and 3) layout/positioning. Unfortunately neither tables nor CSS handle positioning well in all cases, hence the perpetual argument.

Maybe I'm just ignorant, but I've found it necessary to use CSS, tables, & JavaScript (yes, all three) to produce acceptable dynamic layouts for web- based apps. This is unfortunate.

</comment><comment><USER40> The paradox is that CSS was not meant for precise layout. It was meant to only vaguely suggest a layout. That's why it deliberately excludes the ability to force elements next to each other the way tables can and spread them out evenly. It's not for generating pixel-perfect PDFs. It's for saying, "Hey, put some content here, make it kinda look like this, and if it doesn't fit, let it flow to the next line. No big deal."

Yet the people who are so gung-ho about how it's superior to tables are...get ready: the people who think CSS is for controlling every pixel of a layout. Those people should really be using tables not because they're easier for what they want to do, but instead on principle!

Instead we end up with some horrible, disgusting hybrid. Pixel counters for whom tables work perfectly instead abusing CSS to force a precise layout all the while gloating about how they're doing something noble and difficult and looking down their nose at those who do it the "easy way."

<comment><USER11> I thing you got that backwards. _CSS_ supports pixel-precise sizing and positioning. However, CSS _also_ supports sizing and positioning based on the properties of the viewport, which adapt better to different screen sizes. Both approaches have advantages and drawbacks.

HTML-tables OTOH does _not_ support pixel-precize positioning, although you can get some of the way if you combine it with transparent gifs, as people used to do before CSS support became widespread.

</comment></comment><comment><USER11> This whole CSS vs. HTML-Tables discussion is ridiculous. It is not either/or. There are some specific cases where Tables are superior over CSS, but many things can be done with CSS which is impossible to achieve with tables.

This article explanin the _concrete cases_ where you should use tables: <http://olav.dk/articles/tables.html>

The submission shows some examples where tables are needed. However, one could easily show other layouts where HTML-tables would be useless and CSS is necessary. Any serious web developer need to know the limitations of _both_ tools.

BTW. the submission also contains some major misunderstandings:

> when it comes to layout, the design of CSS is fundamentally flawed. Use > tables instead

This is blaming the shortcomings of Internet Explorer on the design of CSS. The CSS spec supports exactly the same layout model as HTML-tables, it's just that IE doesnt support this CSS feature.

</comment><comment><USER41> I'll tip my hat to the author for writing the first well-formed, non-ranting, description of why one should use Tables over CSS (that I've come across), though I'm sure with the amount of these people that are coming out of the woodwork I'm sure I'll end up seeing more...

I still feel the need to disagree with him though. This kind of mentality is counter-productive to the web moving forward - CSS can be a bit more difficult at points, yes, but 90% of the issues that are generally encountered with it stem from IE's horrific rendering engine. We've finally gotten to a point where IE's market share is declining, and with that CSS based development will only get easier.

On one last note, CSS is being adopted in more places than just the web - <USER2> instance, there's various projects attempting to integrate CSS into the GTK setup. If CSS was really that bad and unusable, do you think it'd be getting any further adoption at all?

<comment><USER42> Just my two cents but I would say that this argument is not counter- productive, but rather essential to the web moving forward.

Until CSS is improved, tables will never go away.

<comment><USER41> I guess the way I'm looking at it is that this argument has already happened. CSS doesn't necessarily need to be improved, rather the browser situation does, which is certainly not helping CSS to look better in comparison to Tables.

CSS3 (and CSS 2.1, which is still not fully supported in some cases) have various properties for forcing display models, but the caveat always ends up to be IE6/7.

Though to be fair, I guess you're right, this argument is rather essential to the web moving forward, I just have to wonder if this is really the argument worth having.

</comment></comment></comment><comment><USER5> I find his choice of "typical" CSS layout to be misleading, when neither his site (which uses CSS, naturally), his blog (CSS), any of the pages he links to (CSS), or this site (tables) use such a layout.

Yes, he chose it to illustrate his point, but that point doesn't connect to the trollish overstatement of the title. It is evident that person can use CSS for other layouts (even using floats) without ever encountering the problems he describes. The real conclusion here is that CSS is hard or even impossible for some desired layouts--something just as true with tables. I doubt that that's news to anybody.

<comment><USER22> The auto-expanding equal height three column layout is such a standard layout on the web, and ways to do it are so often requested that it is referred to as the "holy grail" by the CSS community. So I find your critique and accusation of trolling to be rather misplaced.

<comment><USER5> I did not say it was uncommon, I said his choice was misleading. It's a trick: it allows him to demonstrate a problem with one kind of layout using floats (which by definition do not behave like tables) but then claim it is generally applicable to all layouts and CSS in general. It is not.

I stand by my statement that his title is a "trollish overstatement". It was chosen for the sake of continuing argument, not reflecting the content, educating, or informing.

<comment><USER22> You said it was misleading that he implied it was "typical", which is a synonym for "common". You can take issue with his conclusions, but illustrating your thesis with a common case can in no way be construed as a trick.

<comment><USER5> You're missing the point. Yes, it's a _common_ case in that it occurs frequently, but it is not a _typical_ case in that it is characteristic of the whole set.

That is my problem with it, as stated for the third time. His conclusion reaches far beyond what his carefully selected evidence supports.

<comment><USER22> And for the second time, "common" and "typical" are synonyms. Furthermore, there is no one case that is "characteristic of the whole set". Apparently, in order to satisfy you, a blog post (!) must cover every type of layout. Awfully demanding, aren't you?

<comment><USER5> > And for the second time, "common" and "typical" are synonyms.

That two words can be synonyms does not mean they have only one shared meaning. In context, a thing can sometimes be one but not the other, e.g. A dictionary is a common type of book, but it is not typical of books to consist of lists of definitions set in very small type on very thin pages.

I don't understand why you're insisting on interpreting the word as "common" as I have already stated that that was not my meaning and in the context of the article (in which the author uses a single example to reflect badly on the whole) it's likely not that of the author's.

> Furthermore, there is no one case that is "characteristic of the whole set".

My point. I disagree with the author's attempt to depict _this_ case as characteristic of the whole set of CSS layouts.

> Apparently, in order to satisfy you, a blog post (!) must cover every type > of layout.

Hardly. I only wish for the author to restrict his conclusion to one that is supported by his example.

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> i hope this comment speaks for most.

In a perfect world, CSS is awesome.

tables are good, except when it comes to a point when you have to start nesting tables within each other to format your your layout.

explanation is below: \</comment><comment></comment><comment></comment><comment></comment><comment>---

people who love tables would switch over to CSS if it did what everyone(and standards) makes it out to be and actually worked and/or rendered the same in ALL browsers (css hacks don't count as css)

but no matter what you say about CSS....(and i'm all for CSS) ...CSS can't solve all design issues...and if it can...it takes way to long to figure out... and if only a 10 year veteran/css master can implement flawless layouts then CSS isn't a practical language.

in theory is CSS is awesome!

i use tables for tables (tabular data) and i use CSS to layouts and comesic design.

think about it...if CSS rendered the same way in every browser abiding by CSS standards ...even developers who are pro tables...would switch over.

the reason why there is such conflict between tables and CSS is because many of people have tried CSS countless number of times and hours trying to make their template/layout work...however they've came across so many road blocks ...they give up.

i'm not saying tables are the ultimate design language...and i think people agree....they just use it because it works. in ALL browers!

but me say ONE LAST THING!

its not CSS the language that is problem....is the number of browsers that choose not to render CSS properly.

</comment><comment><USER44> I still don't get this debate. Before, it definitely used to be easier to just use tables, but now there are so many examples and frameworks out there that I never spend more than 20 minutes or so with CSS, even on very complex layouts. What am I missing?

</comment><comment><USER7> This is going to sound totally flippant, but I think it's always worth considering sources... let's take a look at the author's site, and reflect on how we feel about taking front-end design advice from this person.

<comment><USER36> I agree, so I read a bit further after looking at the page (which is, conceded, not exactly a high point in design), here is an interesting bit of information about the author:

<http://sitereservation.com/xooglers/index.cfm?entryid=16>

</comment></comment><comment><USER45> Okay, so why isn't "Center" centered?

With the CSS, Top Center Bottom are all centered, but with the tables, they're not.

Edit: am I wrong? Why am I being downvoted? I'm on Mac OS X 10.5 Safari 3.2.1

<comment><USER46> Even if they weren't, it's trivially easy to center it with CSS, or attributes. In the td tag, align="center", or in CSS text-align: center;

Another pet peeve of mine with any CSS layout is that vertical alignment is a huge pain. With tables, you can use valign="top" in the td, or via CSS, vertical-align: top.

</comment></comment><comment><USER47> If CSS at this level of browser support isn't working for you then you are doing it wrong.

</comment><comment><USER27> I think it's pretty obvious that often tables are better and more intuitive to use for layout than CSS. The problem is that we've been told for so long that tables for layout are bad that it makes one feel kind of dirty using them.

Web page layout should be simple it shouldn't require months/years of experience to work around CSS limitations and browser quirks to get some text and pretty pictures to display right.

Sometimes I spend (waste) hours working on a CSS layout because it makes me feel clever, but lately I've been shrugging my shoulders, going the easier route, sending an invoice and moving on :)

</comment><comment><USER48> Fail.

</comment><comment><USER49> Have fun seeing your SEO go down the drain.

Also there are tons of CSS frameworks which do enforce layout semantics, possibly even better than tables ever could.

<comment><USER50> > Have fun seeing your SEO go down the drain.

What rubbish are you reading? Tables vs css make zero difference. never has, likely never will, for all the obvious reasons (why bother? What difference does it make to users etc).

<comment><USER51> I'm not a SEO expert, but I think the commenter referred to the fact that you can position _content_ before _navigation_ with CSS.</comment></comment></comment>


Five things I'd tell my 21 year old self - <AUTHOR> http://shout.setfive.com/2013/04/17/tips-five-things-id-tell-my-21-year-old-self/

<comment><USER2> >Anyway, these are my notes to send back to 2009.

A 25 year-old lamenting the mistakes of his youth...

Seriously now, these are some good points that too many _never_ learn, particularly being afraid to say "I don't know" and understanding that "everyone is not like you"</comment>


Firefox getting smarter about third-party cookies - <AUTHOR> https://blog.mozilla.org/privacy/2013/02/25/firefox-getting-smarter-about-third-party-cookies/ <comment><USER2> Well, trackers will just switch to using localstorage instead since the preference doesn't affect it [1] and it pops up no permission dialog.

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=536509>

<comment><USER3> It really seems like all the things browsers do to allow sites to persist data on your computer (cookies, client certificates, localStorage, WebSQL/IndexedDB, the FileSystem storage API, HTML5 Application Caching...) should all be controlled by a single set of preferences/request dialogs. They wouldn't even need to break down the requests by type; it's pretty irrelevant to a user which kind of storage is going on.

Combining this with a "forgiveness is better than permission" principle (which seems to be sorely lacking in web browsers, other than a few just-plain- _strange_ places like alert() dialogs), the best UX might just be a warning bar stating "Example.com _has reserved_ 1KB/5MB of your disk so it can remember its place. [Disallow]"

Disallowing would make the site think it still has a permanent store, but internally replace it with an ephemeral one (FS::TEMPORARY, session cookie, etc.) This also might make browser makers get off their lazy butts and _make_ ephemeral versions of the rest of these mechanisms, to make this work ;)

<comment> mike-cardwell You could still use the plain old browser web cache to track users. Send a unique image to each user with a long expiry time with an id embedded in it somewhere, then on the page, simply read the image using javascript/canvas to get the id.

<comment><USER3> > send a unique image ... with a long expiry time

For any given mechanism, if it has different behavior between an ephemeral session and a regular, persistent one, it should trigger the warning bar. Browser caching with distant Expires is definitely one of those. In this case, disallowing the persistence would make all the retrieved resources instead have session-length cache expiry.

Think of the full effect of the warning bar + "Disallow" button as going back and pretending you had opened the page in an Incognito/Private Browsing mode tab from the start--and then making that also happen automatically for any further pages from that domain. It session-isolates caching, cookies, and basically any other form of persistence except explicit bookmarking.

</comment></comment></comment></comment><comment><USER4> Excellent. I know you, Mozilla guys, are on HN, so a question.

Any ETA for allowing to block Referer header from being included in cross- origin requests? If I'm on the page that pulls down something from Google Fonts, I see no reason why I should be sharing with Google the URL of the page I'm visiting.

<comment><USER5> First, there are already multiple Firefox extensions that will let you totally control the Referer header. (In general, if there's something that you want to change about Firefox, you should search <https://addons.mozilla.org> to find a solution, because somebody's probably already created an extension that does what you want.) I think one such extension is called "RefControl."

I also brought up the issue on Mozilla's dev.privacy mailing list [1] recently. See:

[https://groups.google.com/d/msg/mozilla.dev.privacy/wmPzPCdz...](https://groups.google.com/d/msg/mozilla.dev.privacy/wmPzPCdzIU8/Vrugn8XquL4J)

In general, we cannot block the Referer header by default on cross-origin requests because we know that would break too many websites. My proposal is to strip the Referer header down to just the origin + '/', e.g. <http://example.org/> instead of <http://example.org/foo?search=whatever+you+searched+for>.

I think it will be difficult for us to go further than that in the default configuration any time soon (and, as you can see in that thread, there's even some pushback to my extremely reasonable proposal).

Also, I know there is active work happening to bring extra control over the Referer header to Firefox's built-in prefs. This seems to be a little bit in conflict with our "Checkboxes that kill" project so I'm not sure how it will turn out.

[1] <https://lists.mozilla.org/listinfo/dev-privacy>

<comment><USER6> FWIW, I just followed your advice, searching Firefox Addons for "Referer". The results were not helpful at all for the goal abcd_f mentioned of blocking cross-site referrers. [Edit: Sorry, it looks like I mistyped "Referer". There is at least one promising addon on the first page.]

Also FWIW, I agree that this is indeed becoming a significant privacy issue. I too don't see why Google or Typekit or some widely used CDN should be gifted a convenient history of my web browsing just because they host popular JavaScript libraries or web fonts.

I'm intrigued by this comment:

 _In general, we cannot block the Referer header by default on cross-origin requests because we know that would break too many websites._

Is this because some of the third party resources are only authorised for use by certain sites and rely on Referer to establish whether a given request qualifies? Given that there is no security or verification for Referer headers, that seems like a rather broken model to start with.

I can't help thinking that if one of the big browsers forced the issue then those services would have to reconsider and do things a smarter way. That seems likely to inherently reduce the amount of unnecessary information being passed across to those third party services in the first place.

<comment><USER7> > Is this because some of the third party resources are only authorised for > use by certain sites and rely on Referer to establish whether a given > request qualifies? Given that there is no security or verification for > Referer headers, that seems like a rather broken model to start with.

It's just a first-order approximation to defend against hotlinking. Disabling referes wholesale has mostly worked out for me (via about:config, not an extension), but very rarely I have to turn them back on or switch to a backup browser profile or whatever.

<comment><USER6> But if you're linking to an image on your own site from your own site, the proposal not to send Referer headers across domains to third parties wouldn't do any harm.

In other words, if your interest is in blocking unauthorised hotlinking, can't you just assume anyone who doesn't include a Referer is equivalent to someone sending a Referer from a malicious site and decline the request?

<comment><USER7> Sure, that works in many cases. It's also fairly typical to host static-ish content on another domain though, in that case you would have to inspect the referer header, or otherwise conspire with your "main" domain.

</comment></comment></comment></comment></comment></comment><comment><USER8> There are lots of cases where third party cookies are used as auth tokens, not tracking tokens. Seems to me that the browser vendors should get together and come up with a better solution for browsers to store and manage auth tokens.

Right now it is done piecemeal by websites, but is confusing to end users. Having a direct, first-class API and UI in the browser that can show the user exactly what third party sites they are "logged into" and have a "Logout/Deauthorize" button next to them would be worthwhile, and have less of a chance of "breaking the web", or imposing workarounds that might hurt user experience.

BTW, how does Firefox treat a CORS XHR response? Does it allow a cookie to be set? Seems to be ad trackers could then just run a server that permits CORS, have a bit of JS that makes the request to opt it back in.

<comment><USER9> Isn't improved browser-level authentication handling (including not letting information leak via authentication) one of the things BrowserID is about?

</comment></comment><comment><USER10> Finally. Third party cookies provide almost zero value _for users_. Only use case is for log in on iframe-embedded apps such as Discus comment boards, but the ones you use yourself can be counted on one hand so adding exceptions isn't such a big issue. Adding some UI that shows that you are logged in to Discus on a particular web page would just good imo. I think the "From visited" option is an excellent trade off as a transition period until a better option for embedded authentication is available.

<comment><USER11> > Third party cookies provide almost zero value for users.

I don't like third party cookies either, but this is false. Your information is worth something to the right people. The websites you visit, mostly free, can make money off that information. The value to the user are free websites that provide you entertainment/content/etc... and are able to stay free because they are utilizing this as a revenue stream. We all know there are other ways, perhaps more moral ways, but to say it provides nothing to the user is false. It funds the websites you're visiting.

<comment><USER12> While that's often true, many (most?) users have no idea that they're making this deal (i.e. "I let you store your cookies on my computer and in return I get free stuff.").

The European "cookie law" has caused many websites to give better notice that they're planting cookies, but it's rarely clear how those cookies are being used.

There is a better way. What if I purposefully signaled my intent to potential sellers, rather than having them guess what I want (based on their data about me)? Amazon wish lists are an example (although they'd be better if I stored the list in a place of my choice, where I control who sees what, and I'm told who looks). For more on this idea, see:

<http://en.wikipedia.org/wiki/Vendor_relationship_management>

</comment></comment></comment><comment><USER13> I have been thinking about cookie sandboxing for a while:

The idea is to have a separate cookie store for each 2nd level domain I am visiting.

So the Facebook cookie on some site I am visiting that has a Facebook "Like" button on it is different from the actual Facebook cookie I would get from visiting Facebook.

This would make cookie tracking across sites unusable, since each site would have it's own version of a cookie.

</comment><comment><USER14> I'm really enjoying the self-destructing cookies addon: [https://addons.mozilla.org/en-us/firefox/addon/self- destruct...](https://addons.mozilla.org/en-us/firefox/addon/self-destructing- cookies/) . It's really great to go to Facebook and see it have absolutely no idea who I am every time I go there. Plugin works very well.

<comment><USER15> Never heard of this one, and it looks really good. I'll try it right now. But will it still be useful with the new Firefox updates?

<comment><USER16> Hi, I'm the author of this add-on. You might want to read the FAQ entry "Q: How is this different from disabling 3rd party cookies and installing Adblock?". Firefox's new 3rd party cookie policy is actually weaker than disabling them outright, so this will not change anything.

<comment><USER17> Back in the day, Firefox experimented with making third-party cookies session- only, but I believe this option was disabled because some websites using third-party login cookies required users to login every session.

Have you run into any problem websites with self-destructing cookies?

<comment><USER16> Disabling 3rd party cookies has never broken a single site for me. I've heard that some banks require them, though. As for Self-Destructing Cookies: it's a pretty drastic measure. Considering this, it's surprisingly compatible. Among the sites that I frequent, not a single one stopped working. Inter-domain transaction - e.g. a shop forwarding you to Paypal and back - used to be a problem, but the latest version has a heuristic for that. Still, I'm pretty sure that some people will experience fallout. You can work around that; SDC has numerous functions that can help in such cases (pause, undelete, whitelist for session).

</comment></comment></comment></comment></comment><comment><USER18> Google is in the ad business making it tougher for them to go in this direction. Go Firefox

<comment><USER19> > Users of this build of Firefox must directly interact with a site or company > for a cookie to be installed on their machine.

There are not many users that don't interact with google. While I don't expect the chrome team to add this to their feature list (even as optional), if they did, it would not really hurt google. It would actually hurt all the other "smaller" players.

<comment><USER20> >It would actually hurt all the other "smaller" players

Exactly. But it's not neccesary a bad thing though.

What all the "smaller players" in emerging retracking field - where 3rd party cookies are used in the first place - are doing now is nothing conceptually different from "ah, you've added iPhone to shopping cart at shopX! Now we'll show you iPhone ads for a week on every site you visit!". And user is beating her head against the wall because she bought the iPhone offile a week ago.

If 3rd party cookies will be disabled by default in significant part of browsers, all that players will need to find a ways to add some value visible to users and show it to them and _convince_ them to enable 3rd party cookies manually because that will be just the only way to track them.

We don't know yet what that added value(s) could be, but I'm sure they will be invented. And that would be good thing.

<comment><USER21> You're right that these retargeting shops have a stupid thesis and can only exist because marketers' metrics haven't evolved enough yet (and that's changing). Highest purchase % doesn't mean you changed intent or created business, you just won the bidding war to show an ad to someone who was already going to buy, or maybe already bought.

But users will never manually enable 3rd party cookies, even if they agreed with you that the ads were adding value (which odds are they never will either).

Content has to be monetized in some way -- if not ads, then how?

All that blocking 3rd party cookies will accomplish is put most of the less technically-mature shops out of business while the smart ones figure out a way to route around using the exact same data science for targeting.

<comment><USER22> Is your criticism of retargeting based in experience? I'd love to hear more about it.

I work at a "retargeting shop" and our customers test the crap out of our tools to make sure we're actually driving results. Others may use more smoke and mirrors, but when done right, retargeting does in fact change user behavior and generate ROI.

<comment><USER21> Well, there are situations where retargeting makes a bit of sense, like selling business services on a low-traffic website.

But most e-commerce retargeting, IMHO, is trading on the fact that a naive marketing manager will put too much stock in a high conversion percentage. All of those people were, by definition, aware of the product and actively shopping. Did you create a customer? Probably not, maybe by virtue of them clicking the ad instead of going somewhere else, but that's still pretty zero- sum.

Prospecting for people who haven't previously clicked the item on your site, but would be interested, is a lot harder and potentially more valuable.

All IMHO of course.

<comment><USER23> sophisticated marketers have done hold-out tests with retargeting shown that it can drive incremental sales at a profitable roi. this includes big ecommerce brands.

granted not every viewthrough and clickhtrough conversion is driven by the advertising, but some definitely are and it is often profitable if a campaign is optimized and run well.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Does this affect Google Analytics (or any analytics software for that matter)? if so: How would a webmaster deal with that?

<comment><USER25> Google Analytics javascript runs on your domain and the cookies it uses are on your domain. So it should count as "first party" here.

<comment><USER24> Interesting. Isn't the website just telling to load the script from a Google server (which could count as 3rd party) and execute it?

<comment><USER26> It's loading from a 3rd party (with a 3rd-party HTTP request), but the script itself is _run_ by the first party: scripts are owned by whichever page executes them, regardless of how that page conjured them up. That's why you can load jquery from a CDN without breaking lots of things, because jquery still "runs from" your domain, same as if it were hosted locally. Also a reason that you really need to trust the third-party host, because if you load malicious third-party JS, it runs from your domain.

<comment><USER27> Thanks, that's a neat little explanation and cleared a couple of things up for me :)

</comment></comment></comment></comment></comment><comment><USER28> So this will be the end of remarketing? IMO remarketing is the best thing that has happened to advertisement online. It's a win-win-win situation for visitors, advertisers and publishers.

<comment><USER27> A win for me is not seeing advertising, at all, ever.

Targeted ads are not a win-win, they're creepy.

</comment></comment><comment><USER29> When it first came out, Chrome's killer app (to me) was performance and the lack of bloat that had infected Firefox at the time. However, FF can more than redeem itself by making privacy and allowing users to easily "go off the grid" its killer app.

</comment><comment><USER30> This is good news for sites like Facebook that track users across multiple, unrelated sites.

Individual sites can still track you with third-party analytics tools by creating a CNAME (DNS alias) to a third-party tracking domain.

</comment><comment><USER31> Curious for people that actively write way more JavaScript and deal with cookies more than I do:

Outside of Local Storage, is there still a loop-hole (though it defies user expectation) for ad retargeters (they must rely on third party cookies)? I feel, if not, that this will totally kill those businesses. I am neutral and just wondering if I am missing something.

Google was sued for using iframes to get around this so defying user expectation no matter the loop hole is quite dangerous.

<comment><USER32> HTTP ETags are probably the most widely used workaround for 3rd-party cookie blocking.

<http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags>

Not sure whether the Firefox folks have figured out a way to patch this workaround up or not.

I do think that retargeting businesses are in for a bit of pain given the headwinds re: third-party tracking across the US and world.

</comment></comment><comment><USER33> I have been blocking 3rd party cookies for years.

The only site that has ever had a problem was my local power company (aps.com). However, it was easy to get around because even though their site warned that 3rd party cookies were required, you could just click around it to pay your electrical bill.

I've never had a problem on any other sites that I use in at least five years, though I suspect it's been more than that.

</comment><comment><USER34> Sounds like a superb idea. One thing though: surely this will leak my browsing history, albeit very slowly?

On balance it seems a net gain all the same.

</comment><comment><USER35> Does anyone know what Chrome does for 1st party vs. 3rd party cookies? Are they doing this too yet?

<comment><USER22> We're following the issue closely and so far there's no indication Chrome will follow suit.

</comment></comment><comment><USER36> So this would essentially break all conversion tracking and the like done by advertisers, right?

</comment><comment><USER37> We have an app that runs in an iFrame on another site (in a Google+ Hangout). Are the cookies in the iFrame going to be considered 3rd party cookies by this if they match the domain of the iFrame source?

<comment><USER27> I would expect so. From the sounds of it you may have to direct users to visit your site directly before this works.

<comment><USER38> The same issue will likely apply for Facebook apps that run inside of iframes... and I think these days that's all of them.

</comment></comment></comment><comment><USER39> Firefox is getting better and better now. Great!

</comment><comment><USER40> What's great is the mobile version of firefox also can turn off third-party cookies while the Chrome mobile has no such option.

</comment><comment><USER41> How is this going to interact with plugins that cover similar ground (e.g. DoNotTrackMe, Ghostery)?</comment>


NASA Hubble Finds a True Blue Planet  - <AUTHOR> http://www.nasa.gov/content/nasa-hubble-finds-a-true-blue-planet/

<comment><USER2> And science marches on.

Maybe I'm showing my age, but it astonishes me how quickly the study of exo- planets has progressed. I wonder if I'll live long enough to see images beamed back from an interstellar probe?

<comment><USER3> "I wonder if I'll live long enough to see images beamed back from an interstellar probe?"

I would say you have a small, but definitely non-zero, chance of that - but it probably depends more on the development of effective life prolonging therapies that anything else. We're quite a long way from being motivated enough to build a dedicated interstellar probe and then you would probably have to wait a few decades for the probe to actually get somewhere and a, much smaller, time for the signals to get back.

Personally, I'd settle for seeing manned exploration of Mars and I think that may just happen...

<comment><USER4> Mankind is into space since what, 75 years?

Its too early to think of traveling to far points in space using the technology we have.

Imagine some thousands of years back, planning to explore the world using an ox cart. Yet today, airplanes have made that perfectly possible.

<comment><USER3> Well, if we _really_ wanted to we could probably hack something together along the lines of the Project Orion designs right now, but it would be hugely expensive and pretty messy so I can't see anyone doing that.

[http://en.wikipedia.org/wiki/Project_Orion_%28nuclear_propul...](http://en.wikipedia.org/wiki/Project_Orion_%28nuclear_propulsion%29)

I suspect if we do send out interstellar probes they will be tiny rather than flying battleships:

[http://en.wikipedia.org/wiki/Starwisp](http://en.wikipedia.org/wiki/Starwisp)

</comment></comment></comment></comment><comment><USER5> Dose NASA have a full time staff of artists? Or do they outsource these "artistic interpretations" we some frequently see?

<comment><USER6> I think they have actual photos. Only, the government hides them from us... maybe the alien overlords don't want to reveal themselves yet?

<comment><USER2> That would be cheaper, yes.

</comment></comment></comment><comment><USER4> When I looked at the word 'blue' in the title, my first thought was there could be life but. But reading further...

>> It is only 2.9 million miles from its parent star, so close that it is gravitationally locked. One side always faces the star and the other side is always dark.

and

>>day side and night side temperatures on HD 189733b differ by about 500 degrees Fahrenheit.

Means life similar to us doesn't exist there.

Seems like our exploration of the cosmos and some drastic results with regards to that will only happen after some drastic changes in technology. It took a ship, and a few determined men to explore places on earth.

It will take some radical invention in transport systems. And few determined men this time too.

I don't think we will ever discover anything substantial as long as the physics of that is limited by things like speed of light. Its like thinking of heavier than air flying machines before the discovery of bernoulli's theorem.

<comment><USER7> I think this part made it sound nastier:

> On this turbulent alien world, the daytime temperature is nearly 2,000 > degrees Fahrenheit, and it possibly rains glass -- sideways -- in howling, > 4,500-mph winds.

<comment><USER8> That description makes Venus look like a habitable planet.

<comment><USER9> Actually, if you could somehow use balloons filled with human-breathable air as floating devices, you could float about 50 km above Venus surface, in a nice earth-like 1 atm pressure and 0–50 C temperature range.

[http://en.wikipedia.org/wiki/Colonization_of_Venus#Aerostat_...](http://en.wikipedia.org/wiki/Colonization_of_Venus#Aerostat_habitats_and_floating_cities)

</comment></comment></comment></comment><comment><USER10> And here I was thinking they had found an Australian Planet...

[http://www.urbandictionary.com/define.php?term=true%20blue](http://www.urbandictionary.com/define.php?term=true%20blue)</comment>


Google Refine: A power tool for working with raw data - <AUTHOR> https://code.google.com/p/google-refine/

<comment><USER2> Hopefully this can evolve into being the canonical tool for data startups, data cleaning should not be a differentiating factor. Value extraction should be the differentiator.</comment>


Protecting Our Users in Kazakhstan - <AUTHOR> https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/ <comment><USER2> [https://news.ycombinator.com/item?id=20755897](https://news.ycombinator.com/item?id=20755897)</comment>


Ask HN: Biomimicry in software? - <AUTHOR>

The title is pretty much self-explanatory: do you know of any algorithms/solutions that emulate nature to solve problems? I know of neural networks, and chaos theory (think plant leaves and algo-trading), but I'd like to find out about specific implementations of this. <comment><USER2> Ant colony optimization algorithms [http://en.wikipedia.org/wiki/Ant_colony_optimization_algorit...](http://en.wikipedia.org/wiki/Ant_colony_optimization_algorithms)</comment>


The Facebook experiment has failed. Let's go back. - <AUTHOR> https://medium.com/a-programmers-tale/f7b8c66109ea

<comment><USER2> Every few years is another one. Remember GeoCities? TheGlobe before that? Then Bo Peabody's one?

Pretty easy to code, from there can collapse fast as it grew. FB no exception prob</comment>


AeroFS Raises $10M Series B - <AUTHOR> https://www.aerofs.com/blog/aerofs-raises-10m-series-b/ <comment><USER2> I have to say that AeroFS is a company I've always admired from a distance. They don't raise that much money, they don't make a fuss, and they just keep growing.

<comment><USER3> Makes them not come off as a fad or BS scheme to get a VC exit on a non- product, yeah? Interesting traits. I hadn't noticed it until you pointed it out and then... what you said might be why I hadn't noticed them lol. I'll add that a tech company operating in stealth or low-buzz mode has the extra advantage of building up quite an income stream before competitors' marketing or legal teams notice. That money helps when either responds to the new threat to their market share.

Some of the best companies I ran into in robust, software engineering are still unknowns. You don't see them or their methods on HN, Reddit, and so on. Yet, they continue to slowly grow and be profitable by word-of-mouth as they deliver results day in and day out. Nothing wrong with advertising but I admire those companies the most.

</comment></comment><comment><USER3> This is a product that seems to have the right features, is very flexible, and is extremely usable. That's a great combination in INFOSEC. As usual, I assume low assurance methods and plenty 0-days waiting until proven otherwise with rigorous review. Yet, doing a great job on the first part can generate enough revenue to gradually improve on the second part.

I wish them luck.

</comment><comment><USER4> Congrats, AeroFS! I'm glad to see more proper enterprise software making progress in the startup world.

</comment><comment><USER5> Nicest founder ever. People should give them even more money.

</comment><comment><USER6> I really like the philosophy behind AeroFS and how I get to keep my data on my computers only, but recently the app is taking up more and more RAM. I've seen it creep up to over 1GB until I restart it, and that's only with a 10GB shared folder between 3 machines.

Aside from that, I've never really looked back since deleting Dropbox and my account there.

Hopefully this round of funding brings about some performance improvements :)

</comment><comment><USER7> Congratulations! I see that it was over two years ago since the A round[1] so I guess that the business is going well :)

[1] [https://www.crunchbase.com/funding- round/a052c0385588a052cbe...](https://www.crunchbase.com/funding- round/a052c0385588a052cbefdd17ea2319f2)

</comment><comment><USER8> AeroFS is one of my favorite products, people need to be using this.

</comment><comment><USER9> Congrats guys!!! I love AeroFS!

</comment><comment><USER10> Congrats Yuri and the AeroFS team!

</comment><comment><USER11> I like the concept; you wonder why Dropbox didn't enter this space.

</comment><comment><USER12> Congrats Yuri!

</comment><comment><USER13> Why would they choose no-name investors? Maybe these investors are the new A16Z

<comment><USER14> Avalon and NHN are actually far from no name :)

Avalon has been our partner from our Series A and has funded some amazing startups like Indix, SkyCatch, Nanigans, CloudKick (YC S09), Chartio (YC S10), and Cloudant (YC S08). As an aside, Rich Levandov, who is on our board, was also one of the founders of Phoenix Technologies, creators of Phoenix BIOS

NHN is not well known in the valley, but it's Naver Corporation ([https://en.wikipedia.org/wiki/Naver_Corporation](https://en.wikipedia.org/wiki/Naver_Corporation)) which is one of South Korea's largest telecoms, and is also the parent company behind the Line messaging app.

We haven't talked much about it in our release, but one of the reasons we partnered with NHN is that there's a lot of need for data sovereignty in EMEA, and NHN is in a position to help us enter the asian markets.

<comment><USER15> What's your take on TiSA prohibitions against data sovereignty, [http://www.innovationaus.com/tisa-threatens-data- sovereignty](http://www.innovationaus.com/tisa-threatens-data-sovereignty)?</comment></comment></comment>


The Hottest Thing in Startups? Babies (A founder-father's homebirth story) - <AUTHOR> http://hellobubs.com/post/23494489962/homebirth-midwives-becoming-the-ultimate-dudela

<comment><USER2> LOVE this. Homebirth is so scary until you learn more about it. Then the opposite becomes true.</comment>