Should be entitled "The tragic history of CSS episode n" where n is any number between 0 and infinity.
CSS is a complete utter crap that failed to solve the problems for which it exists. Today CSS is a broken tool that still can't easily be used to design even the most basic layout without requiring a ton of hacks.
Among a fews:
- A broken box model that the W3C picked over the one from MS. For finally adding the MS's model years later leaving us with 2 boxe models and a broken compatibility.
- Centering things? You have to use hacks even for this simple purpose.
- Building grids? Let's have fun and pick the one you prefer : html tables, display table, floats, flexbox, css grids...
- About Tables: 15 years ago everybody switche to tabless layouts for the purpose of separating markup from presentation. A few years later we got access to the table display mode in CSS because, well, not a single one from the other solution worked well to build layout. Qo we got offered the option to emulate html tables in CSS.
- They added CSS animations. What animations have to do with styling and layout? Oh it's to compensate the bad performances we got when animating things with JS.
> CSS is a complete utter crap that failed to solve the problems for which it exists.
Huh? Do you not remember/know what it was like to style webpages with FONT elements before CSS? CSS was a godsend. That was the separating content from presentation breakthrough.
The problem for which it existed wasn't layout. CSS1 (1996) didn't even have anything in it for layout.
>- About Tables: 15 years ago everybody switche to tabless layouts for the purpose of separating markup from presentation.
Using tables for layout was the original hack. Likewise using floats to avoid it was also a hack. Neither of those features were designed for those purposes. You can possibly blame the CSS standard for being incomplete, but you can't blame it for designers creating elaborate hacks out of it.
> A few years later we got access to the table display mode in CSS because, well, not a single one from the other solution worked well to build layout. Qo we got offered the option to emulate html tables in CSS.
You make it sound like table display was added after the failure of other layout methods. Not so - table display was there right from the beginning when CSS first added layout (CSS2 in 1998). It was IEs failure to implement it for nearly a decade that meant nobody was aware of or could use it for many years.
The display:table css properties are exactly equivalent to the display model of html tables. They were specified in CSS2 which became a recommendation in 1998, which is 17 years ago (!).
But due to the IE6 dominance and abandonment it took many years before this part of css was broadly supported by browsers, so developers had to either use html tables (even when not semantically appropriate) or use hacks like floats (which was not designed for this) to achieve a table-like layout. So the age of hack was due to browsers not supporting css, not to to deficiencies in css as such.
That said, html tables never displayed identically across browsers before css. There were lots of corner cases e.g. with the interaction of fixed and flexible columns. Which is not really surprising since the display model for tables were never specified in the first place before css.
The delicious irony is that CSS had to emulate the old table model to overcome its default layout deficiencies. And IIRC it still can't natively handle mixing relative and fixed widths, and consistent vertical centering.
> html tables never displayed identically
My bread and butter used to be slicing photoshop comps into websites. My table layouts were pixel perfect on every browser without hacks. I do agree there were a few things that had to be accomodated using and spacer gifs - but it was painless compared to elaborate and fragile CSS hacks.
I shouldn't still care about this stuff - I moved to IOS dev thank goodness - but I still nuture a burning hatred of CSS years later :)
There is no irony. CSS replicate the table layout model in order allow you to separate markup from presentation but still be able to show tables. Otherwise, how should the default style sheet for table-elements look? CSS obviously needed to to have at least the same presentational power as presentational HTML to be backwards compatible.
I think CSS is wonderful, but the real tragicomedy is Bootstrap and Foundation grids which have CSS classes and Divs that are just as much management and just as much code as tables yet are very arguably less functional. Reliable vertical centering anyone? Now can you do it without wierd hacks?
> Huh? Do you not remember/know what it was like to style webpages with FONT elements before CSS? CSS was a godsend. That was the separating content from presentation breakthrough.
Have you tried using FONT recently? (Or indeed, any time this decade?) When you're generating your pages programmatically it's really easy to separate content and presentation concerns in code but then combine them when finally rendering the page. You can use a normal programming language which is much clearer than CSS selectors. CSS was necessary in the days of hand-written HTML, but once you have a CMS you might as well use FONT and inline styles (possibly using CSS just with single classes, as a kind of "cache" to avoid repeating the same inline styling block everywhere).
I already build up my HTML programmatically from reusable components, following DRY (Don't you?). That means the markup for what it means to be e.g. a paragraph heading is already in one place. It's no trouble to style it there, with a font tag, and if I want to change it then I can change it there. And if I want to abstract out a particular piece of styling and reuse it across several components, it's just code, I factor it out the same way I would anything else.
So yes, seriously, it's simpler than using a CSS selector.
>You make it sound like table display was added after the failure of other layout methods. Not so - table display was there right from the beginning when CSS first added layout (CSS2 in 1998).
Yes I mis-formuled it.
>It was IEs failure to implement it for nearly a decade that meant nobody was aware of or could use it for many years.
No it wasn't only IE, display table was also broken in Firefox and Opera. There were plenty of layout that you couldn't obtain in CSS but worked well with HTML tables.
CSS is a complete utter crap that failed to solve the problems for which it exists
really? to me it seems to work very well. When I compare it to doing layouts in desktop apps such as winforms or WPF, CSS is amazing. I am no expert in it, but 99% of the time it more than meets my needs and I love how I can easily override other websites styles with something like stylebot. Seems like your experience is 100% opposite. What would be a good solution in place of CSS ?
CSS is a complete utter crap that failed to solve the problems for which it exists. Today CSS is a broken tool that still can't easily be used to design even the most basic layout without requiring a ton of hacks.
I don't agree with this. CSS is a warty tool with a mixed background, but modern CSS is pretty effective and pleasant to use, especially when combined with a preprocessor.
A broken box model
The W3C box is counter-intuitive, but bear in mind that nobody really expected CSS to be used for layout at the point it was initially selected, so I doubt it was considered that important. And in any case, it's fixed now, with box-sizing supported by like 98% of browsers globally.
Centering things? You have to use hacks even for this simple purpose.
No you don't. There are well-documented, consistent ways to centre in CSS. Vertical entering used to be difficult (for obvious reasons), but now we've got flexbox which solves that problem entirely.
Building grids? Let's have fun and pick the one you prefer
These all do different things and have different characteristics – so you can pick the one that most suited.
Qo we got offered the option to emulate html tables in CSS.
Not quite – we got the ability to build visually-table-like things that use table layout rules, but separated them from the semantic implication of tables. That's a good thing.
They added CSS animations. What animations have to do with styling and layout?
Animations are just the time axis of layout. It makes much more sense to define them and the transitions between them declaratively using CSS.
Etc, etc, etc. CSS is just a complete mess.
In contrast, I find that CSS is mostly a bit of a scapegoat. Sure, it's taken a while to become a comprehensive layout and styling tool – but combined with something like SASS, I absolutely love writing CSS.
> No you don't. There are well-documented, consistent ways to centre in CSS. Vertical entering used to be difficult (for obvious reasons), but now we've got flexbox which solves that problem entirely.
So, what's the way to put something in the center?
Just to add to your post, the reason that there are multiple ways to "center something" is because tables and flexboxes have different behaviors, especially for multiple children, and the third case of arbitrary translation, but all can be made to give the same visual effect here -- the specific case of aligning and valigning a single child to the center of the parent.
In my experience though, the flexbox model is the only example of DWIM in the majority of cases (the only surprise I've had was some situation with an overflowed child inside of a flexbox and requiring an explicit min-height: 0 [1]... something that seemed unintuitive, but modern browsers are beginning to support uniformly).
You shouldn't need 3rd party server side code to manage and compile your front end style sheets though. I do like SASS as well, but the very fact that it needs to exist is testament to just how poorly designed CSS is for the modern web.
I'm sorry, you're just completely incorrect. I'm a <insert HTML/CSS/JS worker title here> and literally do this every day. The Box model issue is being fixed with flexbox; centering is getting there too, gridding is improving; CSS animations are ENTIRELY about style and not to do with JS, it's to state hey, anything style related should be CSSable, not required another language. CSS is evolving just like any other language. I'd suggest if you really think this about CSS, you're doing it wrong. CSS was painful for a long time, but still light years ahead of HTML styling. This is how tools evolve.
>I'm sorry, you're just completely incorrect. I'm a <insert HTML/CSS/JS worker title here> and literally do this every day.
That's cool. I'm too HTML/JS/CSS dev (among other) and I'm not "just completly wrong".
>The Box model issue is being fixed with flexbox;
It could have been fixed 15 years ago. And when it appeared it broke a ton of librairies developped during those years, like CSS grids and stuffs like jQueryUI which still has some incompatibilites.
It's no fun at all if you have to maintains some older projets are if you are building services for regions were IE 8/9/10 are still used. Even in Europs for some markets you still get about 8% of those 3 versions of IE.
> centering is getting there too, gridding is improving;
Getting there? After 15+ years? We are talking about "centering" and "grids"! And still not there yet. This is just crazy.
>CSS animations are ENTIRELY about style and not to do with JS, it's to state hey, anything style related should be CSSable, not required another language.
Just try something basic : animate an element along a sinusoidal path in CSS. Look at the code you get .
Then try the same in JS.
> CSS is evolving just like any other language. I'd suggest if you really think this about CSS, you're doing it wrong. CSS was painful for a long time, but still light years ahead of HTML styling. This is how tools evolve.
CSS was less painful a few years ago when they were less devices and web applications were simpler. Now with all the differents devices screen size, the need of advanced applications CSS just doesn't make it. Responsive layout using media-queries just adding broken hack on top of the Web stack.
> It could have been fixed 15 years ago. And when it appeared it broke a ton of librairies developped during those years, like CSS grids and stuffs like jQueryUI which still has some incompatibilites.
And a hundred different problems with C could have been fixed any number of times, and that doesn't make it a bad tool.
> Getting there? After 15+ years?
I'm sorry, would you prefer it took 30? Is it not better that progress happens than not? The CSSWG is a glacial apparatus that create some of the worst bureaucratic bullshit I've ever seen, but CSS itself isn't a bad tool. Thanks to browser makers adding proprietary extensions they all agree on then shoving it down the throat of the WG helps a lot.
The pace of progress still doesn't mean it's a bad tool, or worse than what we had.
> Just try something basic : animate an element along a sinusoidal path in CSS. Look at the code you get .
> Then try the same in JS.
Still doesn't prove CSS is somehow the worst thing ever and kill puppies.
Yes, programming for the web is hard. Programming is pretty much always hard, no matter how easy we make it because humans suck at long term planning. CSS is still leaps and bounds better than what we had, and makes a lot of things incredibly easy.
> And a hundred different problems with C could have been fixed any number of times, and that doesn't make it a bad tool.
CSS is just a presentation language, you can't compare it with C which is much much more. The problem with CSS is it's the only thing we have appart from HTML tables for building layouts but it didn't have the right functions to do so.
I reckon that it's getting better at some point but come one, it's been 19 years since the release of CSS 1 and we are just getting some tools really dedicated to building layouts.
> I'm sorry, would you prefer it took 30? Is it not better that progress happens than not?
What about 5 years? It should have been enough to have some bricks to build columns, centering, grids, etc.
> The CSSWG is a glacial apparatus that create some of the worst bureaucratic bullshit I've ever seen...
I couldn't agreee more.
> but CSS itself isn't a bad tool.
If you thing a bloated presentation layer that have to be hacked to death to build presentation isn't a bad tool... well...
> Yes, programming for the web is hard. Programming is pretty much always hard, no matter how easy we make it because humans suck at long term planning. CSS is still leaps and bounds better than what we had, and makes a lot of things incredibly easy.
I don't know what CSS have to do with the eventual difficulty of programming. Actually it's easier to build a layout framework programmatically with JS, using a restricted features set from CSS and fixing the bad parts in code than to use CSS alone.
> Getting there? After 15+ years? We are talking about "centering" and "grids"! And still not there yet. This is just crazy.
No, this is what happens when multiple competitors have to agree on a complex evolving standard. Result: they all drag their feet one way or the other, each release breaks all sorts of stuff, and so on.
That's because interoperability with competitors is NOBODY'S PRIORITY when all actors are well-established (the youngest browser engine is khtml/webkit, started in 1998; seen any new engine recently? Didn't think so.). In fact, the largest the market-share, the greater the incentive to add more incompatibilities in order to keep your lock-in as strong as possible.
So yeah, CSS can be maddening, and in many ways it's not entirely succeeded (you mention mobile, that was quite a failure), but it wasn't because of problems with the standard itself, or at least not entirely.
> What animations have to do with styling and layout?
What don't they have to do with it? CSS is all about defining the way the site looks. Animations, and especially transitions between states, is the exact same thing. Animations are just layout plus time.
> Centering things? You have to use hacks even for this simple purpose.
To be fair, that was solved a while ago with flexbox, which now has next to universal adoption. If youre targeting a browser that doesn't support flexbox, you're going to have a lot of other hacks in place as well.
Jut to put you rant in context, the CSS color names were not decided by CSS, they were adopted from presentational HTML.
The initial stage of CSS was to provide an alternative to presentational HTML (font tags, bgcolor attribute etc.) by supporting at least the equal presentational power in a style sheet language. Since HTML already had color names, CSS also needed them in order to allow easy porting of style information from HTML to CSS.
>Perhaps the most vehement denunciation comes from a 2002 e-mail written by programmer Steven Pemberton: “The X11 colour names are an abomination that should have been stifled at birth, and adding them to CSS is a blemish on the otherwise excellent design of CSS.
Now I don't have much experience with CSS. Only have been using it for ~5 years, and never any of the real complex magic. But if I were to make a list of design problems I have with CSS, color names wouldn't even make it on the list.
Yeah, it's not like various programmers don't write "denunciation" emails/posts all the time for every kind of thing. Not sure why this particular denunciation gives the issue much weight.
Besides this guy is associated with even more failed projects than CSS color names, such as XHTML2, XForms, and RDFa.
Funny - I had a conversation with a friend about this exact topic the other day.
Painting a few (old) walls in my apartment. I asked the original designer what color they were, and she confidently replied "Swiss Coffee". Great! So I got to Lowes only to find out....there are about 35 different variations on Swiss Coffee.
We seem to have solved the color issue when it comes to programming - hex codes are (relatively) easy. Why are we still choosing our home paints based on horribly arbitrary names like "Shadow Mist" and "Lily Pond" ... ?
(And yes, I know the actual answer - branding! Why would you buy Brand A over Brand B if all the colors get commoditized into hex codes....the answer is...you wouldn't. So? Fancy names for everyone!)
It has been more or less solved - it's called the Pantone Color system. That said, it doesn't really work the way you'd expect. It'll get you close (say, if you need a consistent color for your brand), but a pantone color on it's own isn't enough to define a material.
The issue with defining physical colour codes is that it gets really complicated when you consider finish. With screen color, you have only one finish, and that's whatever the user's monitor happens to have. With paints and plastics the finish (how glossy the surface is, how metallic it is, coated or uncoated, inclusions like metal flake, etc) really messes things up. This tends to "break" systems like Pantone, and means that it's really hard to choose a few variables to absolutely define a color.
> With screen color, you have only one finish, and that's whatever the user's monitor happens to have
Screens have a huge number of "finishes" because calibration varies wildly between devices. It's gotten better over the years but still few users have screens that accurately reproduce 100% of sRGB.
> few users have screens that accurately reproduce 100% of sRGB.
All currently selling Apple computers (at least phones, tablets, laptops, and desktops, I’m not sure about the watches) are extremely close to sRGB. So that’s a considerable proportion of computer/mobile device users.
Other vendors’ devices have a much spottier record, but matching sRGB is by no means an impossible goal.
More generally, screens can be precisely characterized (either at the factory or by end users) and color management software can pipe pixel colors through a lookup table on their way to the display, so that at least in-gamut colors appear correctly.
Sadly Windows and Linux didn’t support proper color management at an OS level for many years, so lots of software on those platforms still doesn’t do it correctly. And web browsers on all platforms punt on correctly doing color management for CSS colors, with the excuse of matching non-color-managed Flash.
Even more unfortunately, neither iOS nor Android has any color management whatsoever. iOS gets around this by making sure all the displays have nearly identical color (at least on recent machines), but on Android getting accurate color is a crapshoot.
Then there are televisions, for most of which color is a complete joke.
I don't think it's a conspiracy to create paint brand loyalty, it's just too hard to codify real life color except as mix ratios of the formulations for pigments and paint that differ from brand to brand.
You could define a standard measuring device and a standard light source and white and black balance but then you'll have two paints that measure #F00 but aren't guaranteed to at all look the same color to the human eye in varying natural light conditions. If you got really sophisticated and defined color as a graph of wavelength to albedo then you'd probably
just end up where we already are of "Cherry (brand A)" and "Cherry (brand B)" because it's post-facto and not prescriptive (and still wouldn't account for specular vs diffuse reflection).
You couldn't even name a paint by a short number (like a hex code) if you wanted to. That only works because we get to think of colors in terms of three channels, a mix of red/green/blue. Cherry (brand a) and Cherry (brand b) paint could look identical under daylight but totally different under incandescent.
To define an actual reflective color of an object, you need a spectral reflectance distribution. This measures what percent of light is reflected at any given wavelength.
Then the actual color you see depends on the spectral power distribution of the light source. For every wavelength, you multiply the amount of light of that wavelength by the percent of light reflected at that wavelength, and you end up with a new spectral power distribution for light coming off the object.
That goes into your eye, hits the retina, activates three types of cones in some proportion, and your brain turns it into a perceived color.
Incidentally, the image linked above includes a tomato. “#FF6347” doesn't cut it.
Pantone works because it's a lookup table that maps short names to a set of predefined reflectance distributions. In the real world, that's as close to hex colors as we can get.
For a bit more detail in that step at the retina, here are the relative responses of the different cones to various wavelengths (normalized to max = 1):
Once you account for how much light comes off the object at each wavelength, these curves determine how strongly they impact your color perception. S/M/L stand for short, medium, and long, and are the names we give to the different cone types based on the relative length of waves that stimulate them.
As you can see, we don't have a very balanced view of the "visible spectrum." Butter, for example, is about 1.5x as reflective at 400nm as 450nm. But your eyes are something like 20x as sensitive to the light at 450nm (near peak sensitivity of short wavelength cones), so that light has a bigger impact on activating the short cones. 450nm is also picked up by medium and long cones, while 400 is pretty much below their range.
Pantone uses coded colors (e.g. things like "#106U Bright Yellow"), with each having RGB and CMYK values, physical ink-mixing proportions for custom printing, paint standards, etc.
From what I understand it's pretty popular with corporate marketing because it takes the hassle out of getting extremely consistent colors across different physical and digital media.
> (And yes, I know the actual answer - branding! Why would you buy Brand A over Brand B if all the colors get commoditized into hex codes....the answer is...you wouldn't. So? Fancy names for everyone!)
There's no denying physical paint brings additional complexities. The paint's exact recipe will change the interactions with the surface, the thickness of the layers and how the paint ages, all of which (and the painted surface itself) influence the final color and how it evolves. And then each color can come in a variety of finishes.
Our team at work had a very long-running argument last year with the general manager in charge of our main income-generating operation who wanted to base the search on the our main product site on product codes. Those product codes are fairly logical in the way they are structured, and are clearly very specific, and he just did not get why people looking for items might not find them far more useful than, say, names of things
I've never shopped paint brands based on color. I always just assume the brand will have the color I want in their collection of swatches.
I have bought different brands based on perceived/researched quality. I've found personal/anecdotal differences in how well paint coats, how runny it is, how well it holds up, using different brands.
> I always just assume the brand will have the color I want in their collection of swatches.
The problem comes when you need to do a patch job on the drywall for whatever reason (lost cat in the walls, wiring problem, whatever), and when it comes time to repaint not being able to match the exact color gets you a square that's a slightly different color than the rest of the wall.
The big problem is that the color on the wall changes over the years. If you have to fix a scratch in a colored wall after 3 years you might as well just paint it new.
Personally, the nice thing about a color name (maybe not these color names) is that it tells you what it's supposed to look like. So if you want a tomato color, you can use "tomato", and not worry that your monitor is or isn't calibrated correctly.
If you're at all color blind, trying to design using color codes is probably an exercise in frustration.
Maybe what you need is a separate tool that tells you what that specific color code most looks like, sort of like xkcd's color survey:
Says the author: "I have no opinion about whether it should be used to build a new X11 rgb.txt except that seems like the transition would be a huge headache."
The CSS color names are incredibly stupid. The colors they call “red”, “green”, “blue”, etc. are nowhere near the colors humans would consider closest to matching those labels, and combinations of basic CSS colors result in unusably ugly design.
More generally, color collections without any order or structure are terrible – that goes for Pantone, Crayola crayon colors, paint names at the hardware store, etc. These are great for vendor lock in, but useless for human understanding.
And in the context of computers, the specification of color as RGB coordinates is fine for CPU-to-display communication, but ordinary people should never be forced to interact with it, as the dimensions of gamma-corrected RGB have very little relation to the structure of human color perception. Trivial shims over RGB such as HSL or HSV are not an acceptable alternative.
Well, #ff0000 is the definition of "red" within the RGB colorspace, corresponding to the full brightness of the "red" (only) pixel components, constrained by your monitor's limited reproduction gamut.
So yeah, it's "red". But it's not the color of anything that has ever been viewed by humans in real life (except itself). There are few pure colors in nature anyway, but you can talk about "red" being wavelength of the center of the "reddish" range of the visible light spectrum.
Of course, names for colors are always subjective. Crayola might be the best universal reference. Crayola red bears little resemblance to #ff0000, even discounting the pigment vs. light mixing and perception differences.
But you have to call it something, right? So #ff0000 is "pure red, RGB, luminous". :)
The hue 5B in the Munsell system is not supposed to be some idealized “blue”. The “B” is just a mnemonic device: breaking the 100 hues which make up the full Munsell hue scale into 10 sections R, YR, Y, GY, G, BG, B, PB, P, and RP is a way of making the numbers a bit easier to remember than just a number from 0–100, but the precise boundaries of those categories are not in themselves meaningful. The whole point of the Munsell system is that you learn what color the hue number represents, and then it’s predictable, you don’t need to rely on someone’s arbitrary choice for each color term, or the specifics of some printer inks. The 100 hues are uniformly spaced with respect to human perception, and since human color categories are not organized in an orderly way relative to hue perception, it’s inevitable that any rigorously organized system won’t match up precisely with those categories.
As for RGB #FF0000, the “R” primary on a computer display is very orange-ish compared to what a human would call the unique hue “red”.
>The colors they call “red”, “green”, “blue”, etc. are nowhere near the colors humans would consider closest to matching those labels, and combinations of basic CSS colors result in unusably ugly design.
Is there even a standard for what people would say represents a given color? Color perception may very well have a cultural component to it. I know the perception of sound does have a cultural component because there are certain distinct sounds that, if not exposed to while really young, are effectively simplified into a single sound by the brain. The common example is the r and l sound among Japanese, but there is far more.
A lot of research has actually been done on how humans and individuals perceive colors and tons of statistics exist. The results was the creation of many perceptual color spaces such as XYZ and CIE Lab that more closely match human perception axes of lightness, blueness and green-red-ness.
While it is true that our perception differs, we mostly share the same attributes close enough that we can fix standards (except for different cases of color blindness). For instance, we physically perceive blue, yellow, green and red as distinct colors and the rest is a mix of those (magenta being kind of a special case).
What we see as pure blue is actually a precise color point defined by how the eye physically perceive light. Reds, yellow and green are a little bit more fuzzy because they depend a lot on the ratio of red and green cones in our eyes so the brain is taking a little more liberty there.
The major difference between individuals is how precisely they can differentiate two similar colors.
I think the problem with CSS is they tried to qualify way too many colors with subjective terms instead of sticking to a clear and predictable system (either mathematic or designed), even if imperfect.
It's interesting that the article kind of skipped straight from X11 colors to CSS. Presumably what happened was that JWZ, who was hacking together the Motif frontend for Mozilla (shortly before they renamed it to Netscape), added <font color="foo"> and <body background="bar"> to it, and just handed that string directly to XLookupColor, so that <font color="red"> would work? And then whoever was hacking together the Microsoft Windows and MacOS frontends had to copy rgb.txt and "#c0ffee" parsing into the Mozilla code in order to get cross-platform combatibility? I don't know, I wasn't there, but to me that's the actually interesting juncture. Up to that point, WWW colors could have been specified in any way whatsoever. After that, browsers had to be compatible with Mozilla (then Netscape, and then later IE) or people wouldn't use them.
If you were writing an application where you wanted to allow your user to choose colours - say for tagging items or customising an interface - it might make sense to present them with a list of named colours rather than make them choose from a colour wheel (or, heaven forfend, directly enter a 24 bit RGB number).
It would likely be best to define your own list of named colours, for localisation reasons if nothing else, but for the initial version of a feature I could see using the CSS colour names directly.
I use the hex-values/rgba because what does 'papaya whip' even mean? Plus not everyone on the internet are literate in English so RGBA or hex-RGB is far more internationalized.
> “I'm not a native English speaker. Imagine my reaction the first time I saw the ‘gainsboro’ color or ‘papaya whip,’” Daniel Glazman, co-chairman of the CSS Working Group, told Ars.
Speaking as a native English speaker, I don't see how this could possibly be worse for non-native speakers. They have no idea, and neither do we.
Oops - sorry I did NOT expect that at all. It didn't go to my junk mail it was sitting pretty in my inbox waiting for me and I've just been slack in reading. Thanks for letting me know!
Edit: Also - I recognise that the downvotes are for an empty comment with profanity.
We've been running a series of experiments to find a solution to good stories failing to achieve liftoff from /newest.
The latest experiment involves emailing submitters when we notice a
good story that got overlooked and inviting them to repost it. (On HN,
a small number of reposts is ok when a story hasn't had significant
attention yet; see the FAQ.)
Such reposts get an initial upvote from us. They also go into a pool
from which the software periodically selects a story to place randomly
near the bottom of the front page. Not all such stories get this treatment—it depends on factors like how old they are, how stale the front page
is, and some randomness.
Placing a story near the bottom of the front page ensures that it gets
a bit more attention from the community—surprisingly less than
expected, but still a lot more than languishing on the 5th newest page. If
there's interest, the story rises; if not, it falls off after a
few minutes.
We use a combination of software filters and human review to find
good-but-overlooked stories. "Good" here means by HN's definition of
"gratifying intellectual curiosity".
The currently open questions are: (1) what to do when the submitter
has no email address or doesn't check their email; (2) whether to add
a profile setting people can turn on to have this happen
automatically, and how exactly that would work; and most importantly
(3) how to distribute the human review aspect to the community in a way
that doesn't just reduce to the upvoting mechanism,
which obviously does not suffice to surface the best stories.
Here are some links to look at if you want more about this:
Please email hn@ycombinator.com if you would like
us to send you a repost invite. This is an experiment
we've been working on that gives good stories a
second chance at attention on HN.
CSS is a complete utter crap that failed to solve the problems for which it exists. Today CSS is a broken tool that still can't easily be used to design even the most basic layout without requiring a ton of hacks.
Among a fews:
- A broken box model that the W3C picked over the one from MS. For finally adding the MS's model years later leaving us with 2 boxe models and a broken compatibility.
- Centering things? You have to use hacks even for this simple purpose.
- Building grids? Let's have fun and pick the one you prefer : html tables, display table, floats, flexbox, css grids...
- About Tables: 15 years ago everybody switche to tabless layouts for the purpose of separating markup from presentation. A few years later we got access to the table display mode in CSS because, well, not a single one from the other solution worked well to build layout. Qo we got offered the option to emulate html tables in CSS.
- They added CSS animations. What animations have to do with styling and layout? Oh it's to compensate the bad performances we got when animating things with JS.
Etc, etc, etc. CSS is just a complete mess.