Possibly email addresses that won't accept more than 200 plain text chars, so real people get to the point quickly and spam becomes easier to determine.
You're absolutely right about this and I can attest. Whenever I tell someone I run my own software business the first question I'm asked is how many employees do I have?
Nobody cares about the revenue of the sites, it's just that if I have more than 10 employees then you're successful. So in India a person making 1 mil / month is less successful than someone who has a company of 10+ employees that is drowning in debt.
Makes you wonder why HN won't budge with those <table> tags in the source code. One day I hope to see "Table layouts are back with <table> tags" and the HN programmers would have saved themselves so much work.
Flexibility is what allowed webpages to be "responsive" before media-queries even existed, and semantics is what allows accessibility, search engines, and other html parsing tools ("readability" in Firefox and Safari, ...) to function better.
The only advantage it has is that it's old and predictable. That's why it's still used to format emails for instance, it's reliable and works on most supports.
I mean, it is semantic, if you want a table. One of the most baffling things to me is people trying to use not-tables when they're literally trying to display tabular data.
I laughed when I had to make a minor change to an old web application, and found our tabular, scientific data was being displayed in a series of DIV and SPAN elements, with the CSS table styles applied to them.
I changed it to a real TABLE, since that's far more accessible -- most users can cut and paste into their spreadsheet, and a screen reader might give options to avoid reading out all the data.
Another time, a web developer changed all my <i>Homo sapiens</i> to <em>Homo sapiens</em>.
To be perfectly semantically correct (which he was no doubt attempting, as I is a purely visual/appearance tag, and EM connotes some meaning), he should have used
<i> is the correct element, so <i lang="la"> if you wish. A taxonomic designation is the first example given in the specification:
"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts."
Well, I should specify I meant that in most cases using <em> is preferred over <i> in terms of the traditional sense of what <i> was used for in the past. These days both have their specific uses, but in most cases one would more likely to use <em>.
For example, further down the page:
"Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term."
As an element it used to be the way to italicize text, to emphasize that text, before CSS. These days it has had a semantic reason for its existence applied which is a slight variation of its original purpose under the HTML4 spec.
Sometimes it's worth it. A real pain with tables is that you can't have it be positioned relatively. So if you want to display an absolutely positioned tooltip next to a row it becomes a gigantic pain and i'd argue impossible — or extremely hacky — without using JS.
Those are not semantic because divs have no inherent semantic meaning, while using tables for layouts is not semantic because tables have an inherent semantic meaning that's incorrectly applied to a layout.
Exactly this. How are DIVs more semantic than TABLE? And who is reading the source? Your developers and a web spider. The web spider doesn't care (I wrote one and getting it to parse DIV content and TABLE content wasn't much effort)
As far as I am aware no spider is looking at the DIV and gathering semantic information from it. Sure, it may look at the TABLE and initially assume it has tabular data in it, but a tiny bit of logic fixes that.
> And who is reading the source? Your developers and a web spider.
Or blind people using a screenreader?
DIVs aren't entirely semantic, but table is semantically wrong for how it's being used. It'd be like if I asked you to "get me the pencil off that thingie" and pointed at a chair with a pencil on it. As opposed to "get me the pencil off that table" while pointing at the same chair with a pencil on it.
Screen readers and spiders do look at tables as semantic content though. Tables are simply the wrong idea.
That said, CSS layout should have been based on tables/grids from the get go, ie. specify a set of blocks as rows and cells, with colspan and rowspan. It took way too long to get to this point.
This argument was over a decade ago and it's because it's a nightmare to work in tag soup.
I still have to deal with tables for layout on mail templates, bloody Outlook, and that extra 2 layers of tag nesting you have to do on every level quickly turns the code into an incomprehensible mess, even with careful indentation.
And if you're not very careful with indentation it turns into an utter nightmare.
It's not. There were a few arguments against "table layout", some of which apply to hn as well IMNHO. Added tags without semantic value (just as your div-soup above also illustrates). Layout speed (in reality not much of an issue now - and also an issue with deeply nested tags with complex layout).
Both are fixed in modern html5 which moves (back) towards simple, semantic, document layout (html-body-article-heading-etc).
With flex-box layout it's also quite easy to have the article/main content come first (possibly preceded by a header) - followed by sidebars and footer -- all as their own "top-level" boxes/containers.
In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.
And finally table layout is generally verbose and messy for other types of content than tabular data.
I look forward to trying modern flexbox and grid layouts. I have not had the privilege (?) to work with either yet; our customers are not necessarily on the bleeding edge of browser releases so I have to stay a little behind the curve. Hence, a lot of div soup and ridiculous indentation levels.
Honestly, for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere) a Bootstrap-style div layout gets at least as verbose and messy as a table layout would. I especially hate having to always do HTML comments with class/id names after every </div> so I know what closes what when I'm near the bottom of the file. At least with tables you get </td></tr></table> instead of </div></div></div>.
But of course a div layout is at least partially semantic and mobile/small screen friendly.
In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.
In practice, any bog-standard div layout today has a <div class="container"> at top level which contains nothing but other divs and sets size and positioning for the whole page. This is roughly equal to a <table>, no?
> for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere)
Right. There's different contexts between an application an a (hyper)text document.
What's good semantic markup for one, will generally be bad for the other.
It's admirable (and desirable) to strive for adaptive layout and accessibility in applications - but they need a different type of framework than documents made for browsers. The browsers straddle this divide rather uncomfortably - being in part hypertext document browsers, and in part virtual machines for running general applications.
Approaches like web components[1] might help us move toward a standardised reality for "applications that happen to run in the browser", while css and html are still (more and more anachronistically) (hypertext) document markup and layout tools.
If you want to make a Web page/site (like alistapart.com) that's great. Swim with the current and draw inspiration from stuff like css zen garden[2]. With flex box, you can burn[4] most of the old complicated grid layout stuff, and comparatively easily make great sites.
That doesn't really help if you're a "front-end developer" making "apps" though. Even the few that make an effort to color within the lines are still fighting the browsers and the standard, trying to fit a code-on-demand app into a REST shoe[3].
[3] https://news.ycombinator.com/item?id=13500635
(I've said it before - the true tragedy isn't that too few read Fielding's thesis and never understood REST - It's that so many ignore that he covered a lot of other architectures that are more suitable for many applications than REST is)
The "container" is common, but typically not needed.
Sometimes it's a redundant stand-in for "body > .content" or similar (eg: divs dropped directly in body) - and is prevalent because developers don't understand and care about css selectors (or there's that one person on the team that doesn't -- don't get me wrong -- I realize the real world is full of real co-workers, and making a change isn't always easy).
And partially it can be an artifact of abusing floats for "grid layout". Most typically though, the "container div" just ends up being a completely redundant extra "body" element.
It's not, clearly. Modern "grid-based layout" frameworks are just the next generation of table-driven web layouts, and they're frequently shoehorned into webpages in ways that hearken back to the olden days before CSS was invented.
<div class="container"> is one of my least favorite things to see in HTML, in particular. No shit it's a container; all HTML tags are containers. HTML5 introduced all these wonderful semantic elements precisely so that we don't have to pollute HyperText documents with thousands of divs.
Also, that "text-center" class drives me to drink :)
That's a problem for sure but last week I looked into creating a family tree with the basics of HTML and CSS and the following nested lists seems to be the best solution according to forums. Now, try to add into these nested lists some siblings(the people kind) and some new branches as you discover people in census reports from 100 years ago. Now add in a newborn. Is this the best we can do? (apologies, but I haven't the time to tab this correctly, link to Codepen at the end):
Lifted from there, but with broken indentation :) In fact with correct indentation, you see that this goes down 4 levels (instead of the seeming 14 the current rendering seems to indicate). That's significantly better, and once you get used to the structures of lists it's actually relatively straightforward to understand a list like that. Moreover, it's trivial for a computer to understand a list like that as nested lists of lists.
Side note: the top-level div isn't really necessary; you can just apply the `tree` class directly to the `ul` with a small tweak or two to the CSS.
Absolutely, but try researching a family tree and then implementing it using that model and see how quickly you get lost in the nested list structure. The, as I said in another comment, try adding a child born after you started the lists, ie, before the first UL. Then add a divorce and a new spouse and see how easy that is to logically display the relationship.
To illustrate how HTML so ill suited to this structure, I had another look at the problem and found Treant, because yes, the easiest to do this on the Web and maintain it is to write an entire API.
It is, but it also illustrates the problem of drawing a simple diagram for the web. It was in response to user mattmanser's illustration of diabolical nested tables and user einar's nested divs. HTML is problematic for anything complex. I suppose the best way to represent the data is to not use HTML at all, but instead use an image (SVG? for scalabilty) or a big PDF that opens a new tab?
I googled for a solution that I could add to and maintain myself and this was what The Internet threw up as the best solution, but it is far from good.
I would say that best for drawing diagrams in html pages would be to use a DSL like plantuml or dot and some javascript library to transform it into a SVG image.
You can mitigate this about 50% by switching from pure Bootstrap to something like Bootstrap-Sass and inheriting selected rules on something semantic like <article>.
(But then you'll hit a wall as you try to deal with the containers and subcontainers.)
No there is, try using a screen reader, it reads out the header in front of every cell, its really hard to understand vs a semantic document with css styling for people not living with disability.
Accessibility is dead, alas.
It is extremely sad to watch what is happening with the web right now. All the good initiatives are being forgotten in the chase for the latest fad. "You were so excited that you could that you've forgotten to think if you should" can describe a lot of movement in this space.
Even without the accessibility in mind, go to http://csszengarden.com/ and try to replicate that with tables. Barely ten years have passed and the idea that not everything on the web is an app and sometimes it is nice to have ability to change the presentation without even touching the markup.
Nothing. But tables are for tabular data. Laying out a page using a table to divide it up and make it look pretty (or in lots of cases, lay it out so it performs some kind of sales based task) doesn't make much sense. Hence the preferred CSS route, even if the markup is just as verbose (as mentioned in this thread).
Web apps aside [sigh], if one was to disable CSS (and thus all the blocks making it look pretty), the page should still make sense. An H1 as the main header, copy in paragraphs, headers dividing up the content, blockquotes, navigation in lists - and tabular data in tables (etc, etc).
It doesn't always work like that in practice, but that's the aim.
And webpages are a document presentation format. If jamming applications into documents made the web an application platform, than jamming grid layouts into tables made them a grid widget.
Calling a SPA a "page" is a larger and more ridiculous lie than calling the table tag a grid layout widget. Anyone still committed to the table tag lie should move all their apps out of the browser today.
Web developers can work around the table tag, but not the fact they're jamming apps into documents. So one of these lies is taken more seriously than the other.
I'm on a crap connection, and it's not unusual for the styling content to not make it (whether it's CSS or javascript). The ones that follow these principles remain usable, the ones that don't, don't.
It is broken. Every single comment is announced (in Voiceover at least) with “Row x of y. Column 1 of 1”. With proper markup you could either avoid that entirely, or announce a correct relationship with ARIA attributes.
Potentially, although it’s not VoiceOver but what the browser exposes as an accessible table. Chrome and Firefox have horrible hand-coded algorithms to determine what should be a data table or not:
Congrat on shipping. The game idea is very original and interesting. I will definitely give this a try (forgot to bring my phone today but thanks to the really nice feature of Play store that lets you install apps from browser, it should be installed on my phone already).
This is super interesting for someone who has no knowledge of the field. Has my interest piqued as to how they do it, what is number of bases, why do mice have more bases than us, etc. Very nice presentation wise, even if it is incomplete (as other comments state).
Sequencing today is done mostly using computational methods. Think of DNA as a couple long strings (Number of bases is effectively the character count of those strings, each string is a "chromosome" in higher organisms), so the problem is how do we read these long, physical strings. It turns out that parallel processing is way more effective, so we break the really long strings into much, much smaller strings that overlap (Millions of characters long to hundreds often). Because the strings overlap, we can construct a good portion of the actual sequence computationaly by exploiting this overlapping feature of our small strings.
The physical way they do this is by using machines (Think GPU vs CPU) that are effectively a bunch of parallel microscopes specialized to read those short strings and by "attaching" colors to each of the characters (DNA bases). Initial DNA sequencing methods lacked both the computational and physical devices to do this, so they were done by hand. The move from doing sequencing by hand to doing it computationally is why we see the significant increase in characters read (Number of bases).
Your last comment I think is the most interesting, as it effectively asks "Why do mice have a larger string size than us, which means they contain more information on an absolute level?". The answer is just because. The number of bases, or even the number of blocks of information that produce proteins (These blocks are called genes, and a protein is another chemical construct that mainly focuses on doing actions in the cell), is not strongly correlated with the complexity of the organism. The key is how those bases interact, not necessarily in how many there are.
If you have any more questions or need some clarification I'd love to address them, it is a wonderful time to be alive.
1. What is the (maximum) range of read lengths that modern gene sequencers can produce? Any timeline on when those read lengths will increase substantially?
2. How do bioinformatics people contend with repetitive genomic regions?
3. Are there any differences in how gene sequencing technology works on DNA from different species? For example, does an approach that works on humans (e.g. gene sequence alignment or de novo assembly) work on something like wheat?
1. Depends on the technology. On Illumina (cheapest tech and highest throughput), you get the first and last 125 bases of smallish DNA molecules with an acceptable error rate. Pacific Biosciences (lower throughput and more expensive) gives you up to 40.000 bases with a rather horrible error rate.
2. They fail epically. There is nothing you can do computationally. With paired end reads (two reads at an approximately known distance), you still can't assemble repetitive regions, but you can get the contigs around the repeat in the right order.
3. Definitely, but I don't know the details. Plants are often more difficult than animals; they have bigger genomes and often have multiple chromosome sets. Assembly of a wheat genome is more difficult than assembly of the human genome---and I'd argue even the latter isn't actually a solved problem.
This is really interesting. For someone who knows nothing about the subject, how were DNA strands physically read at a low level before computational methods? I was under the impression DNA is too small to see without an electron microscope. You mention reading dna by hand, and I'm really interested in how that is done.
Given a string, I can easily discern one characteristic, which is length. That's because the length of the string is tied to how "massive" it is and thus when I push on things that are more massive they move more slowly. That's the general idea behind gel separation.
Now, I just need a way to make all the combinations of substrings starting from the first position (0 => 1, 0 => 2, etc.). This is a bit more difficult to explain and chemically intensive, but let's assume for each character (C) we have another character (C') that is pretty much the same thing. The key difference, however, is that C' is marked (Radioactivity or with something that lights up) AND that it doesn't allow any more characters to be added on. If each distinct C' is a different color, we can now distinguish between our different substrings, based entirely on the last character. We know that our strings are ordered by size, so we can construct our original sequence based on the terminal member of the substrings.
You can imagine this process being done by hand, it works for that. However, it doesn't scale well to the millions and billions of base pairs we need in the modern day.
As a fun aside, protein sequences were originally determined in a way pretty much the inverse of this. For a given protein string, remove the first element with chemistry. Then, try to figure out what you removed. Now take your string of size N - 1 and repeat, until you have determined each character. This method ended up not being tractable for DNA because of chemical differences. Also, a lot of protein sequencing is done in a similar way to DNA sequencing, in that we break up, shatter may be a better word, the protein. We then try to construct the original protein based on how is shatters (Like reconstructing a window based on knowing where the pieces fall and where the baseball came from).
That depends on the technology. The technology I most often work with will have lots of fake DNA basepairs in a soup, which has the real subject's DNA broken apart into fragments and attached to a substrate to keep it from moving. The fake DNA basepairs bind to the complementary real basepairs and emit fluorescent light when doing so. En masse, the fluorescent light gets captured on camera and each of the possible basepairs' colors are scored, to provide a call for that basepair. Repeat the cycle a few times, map the lights to the same spots, and you generate a sequence of basepair 'reads' which are then sent further down a software pipeline for later analysis.
...the later steps in the pipeline involve using lots of complex math to reassemble the sequenced fragments back together, either using a reference assembly (such as the Human Genome Project) or else de-novo assembly (which basically _builds_ a reference assembly through lots and lots and lots of effort).
There are other technologies as well which I'm not so familiar with.
If you think about what is required for a mammal to survive multiple environments it seems intuitive the more environments a mammal can survive the more genes is needed to create different phenotypes (observable characteristics of an organisms due to the interaction of its genes with the environment). Just looking at the organisms themselves a mouse is capable of surviving harsher and diverse environments than humans. Due to this resiliency the mouse must have more phenotypes and thus have more genes than humans.
This would also perhaps explain the reason as to why some plant species have far more genes than mammals as without the ability to move they need to be able to code for multiple environment changes throughout their life.
The whole thing hurts because things got twisted for no reasons. Both tiny business. Birth of networks. Katz did not only rename and sell, based on the reddit comment it had value. It's just that social perception and hubris turned into a sour sauce. If Katz and Henderson's companies managed to collaborate instead of going into battle .. I can easily see immensely better ending for both parties.
I often store my password using PHP's password_hash('password', PASSWORD_DEFAULT) function. This function has been baked into the language since version 5.0 I think. I'm sure most other languages must have a similar function too, yet so many sites save the password in plain text. Doesn't make any sense.
Major props to Anthony https://github.com/ircmaxell for adding this as a language supported feature to PHP as well for his work on techniques for preventing injection.
I work with C#, Java, Python Go and JS on backends a lot and no other language I worked with had such a simple but secure API.
Not a std lib in Python, but Django has nice API as well for saving the password [0].
from django.contrib.auth.models import User
u = User.objects.get(username='john')
u.set_password('new password')
u.save()
And here is the code which does all the magic - [1]. You can also generate nice passwords [2], use many available different hashers [3] Or write your own [4]
One really nice feature that Django has that is rare and well done is the password upgrading workflow. Not only do they let your app support multiple algorithms at the same time (with one preferred), they also let you chain algorithms during upgrade [0], so if you have a legacy database with all SHA1 passwords, you can upgrade all of them to PBKDF2. At first these will all be PBKDF2(SHA1(pw)), and they will get migrated to just PBKDF2(pw) as users log in, if you set PBKDF2 to your preferred algo.
Note that of course the password algorithms are typed, so this doesn't cause a problem in the corner case that a user's password is a sha1 hash of something else.
I can't speak for all of those languages, but this functionality is often provided at the web framework level in Python and it fits quite nicely there. Since your web framework typically also knows where you are storing your passwords, you can do nice things like increase the number of bcrypt rounds in a settings file and have users transparently migrated as they login which I'd assume doesn't really work at the language level.
Still, a pragmatic answer and, given PHP started life as a web framework, fitting :).
This is a great move. Though I only hope that depositing whatever money you have is easy because all I can imagine now is kilometer long lines at every bank
