Comment by matt4077 | Hacker News Reader

Comment by matt4077 | Hacker News Reader

This is excellent. And with the fast pace of browsers, and the improved habits of users (or automatic updates), it should be available for 95%+ of users within a year (It's in the current Safari Technology Preview, so Safari should get it with the next macOS point update).

This is also a good moment to remind people that you don't need Bootstrap and the like as much as you used to. Grids were 90% or the reason people started using these frameworks, and CSS (already with flexbox I'd argue, but definitely with grids) has caught up and is now easier to use and more flexible than any framework was.

It's also time to reconsider the atrocity that is class="col_xs_12". I've never undestood why people would lynch anyone using style="..." but happily littered their code with those grid classes. With the invention of sass at the latest, actual semantic class names should have once again become the only acceptable best practice. With html5, there's also a range of semantic tags[0], and using them improves both code readability, as well as allowing all sorts of new ideas in clients (not just browsers, but also text-to-speech and other accessabiity tools, or spiders, or brosers on new device classes)

o: <article> <aside> <details> <figcaption> <figure> <footer> <header> <main> <mark> <nav> <section> <summary> <time>

Since you included the <time> element in your list, something I wish browsers provided is a way to automatically format time elements based on user's preferences. I just want to provide the value in ISO8601, and let the browser take care of it.

Luckily, Intl.DateTimeFormat [0] seems to finally allow a reasonable degree of i18n in the browser. If you can live with the limited Safari availability, of course.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

>something I wish browsers provided is a way to automatically format time elements based on user's preferences

That'd quickly get awkward. I live in Norway where the default format is DD/MM as opposed to MM/DD used in the US. This works fine for us in general, we know to expect the first one when we read something in Norwegian and the second one when we read something in English. If a computer formatted a date based on a default preference and considering that most websites probably don't specify the lang attribute, I think it'd get messy quickly. Also, different date formats will lead to different sentence structures making sense. For example you might say "ever since 9/11 something something" but you wouldn't naturally write "ever since 11. September 2001 something something" (you'd write "ever since the 11th of September 2001 something something") and likewise you also wouldn't naturally write "ever since 2001-09-11T08:46:40-0400 something something".

You already have that problem, whether or not you were aware of it. Many (most?) English speaking countries use DD/MM.

I'm, for one, completely fine with the last example.

On more serious note, such functionality is meant for formatting freestanding dates/times (eg. contents of table cell labeled "last modified") not dates in flowing text.

Sometimes you need to show times and dates in a timezone different from the local browser tz (for example you have customers around the globe and want to see relevant timestamps in their local tz).

What you suggest would make that difficult if not impossible. Already it is unnecessarily hard, as JS Date object automatically uses local tz and cannot be coerced otherwise.

> it should be available for 95%+ of users within a year

only if you don't have enterprise customers. Those will continue to run IE11 for the foreseeable future as IE11 will remain supported in Windows 10 until 2025.

While Microsoft is pushing Edge as an IE replacement, Edge is still lacking features and looks too different from IE for companies to feel comfortable pushing it to their users without retraining them.

> only if you don't have enterprise customers. Those will continue to run IE11 for the foreseeable future as IE11 will remain supported in Windows 10 until 2025.

We're still supporting IE9... It was a glorious day when we could finally give up on IE8.

It's not a problem in this particular case, as CSS Grid was introduced by Microsoft, in IE10. So, more or less, four years ago.

I chuckle when Google announces that Chrome will support this feature as the next big thing, while it was clear years ago that this approach is much better than flexbox. But, I'm glad it finally lands in all browsers.

The version of CSS Grid that's supported by IE isn't the version that's in the standard and supported by all other browsers. Same with Flexbox.

Doesn't autoprefixer solve this?

It's not about vendor prefixes; MS IE implements a very old version of the CSS Grid Spec. But I guess MS will update the implementation now that CSS Grid is Candidate Recomendation. Actually, Rossen Atanassov (Microsoft) is one of the current authors of the spec.

IE11 ?!

You lucky guys, we still have to support older versions for some specific customers.

But even better was Safari for Windows, on a very specific case around three years ago.

There's a government tool for mandatory testing that everybody in a certificate course must use. A feedback thing.

It only runs under IE7.

How I hate it.

A lot of conservative enterprise customers are pushing Chrome, managed by group policy, since new productivity apps don't work well on IE.

Also for security reasons alone!

I once sent feedback citing security as a moral hazard that someone would get fired over, as the reason IE8 needed to be ditched.

Chrome showed up a few months later, I'm guessing once they'd tested group policies and install scripts (which I think google makes very easy these days). No idea if it was because of me but it was certainly welcome

Also note that every browser that supports grid also supports @supports: https://developer.mozilla.org/en-US/docs/Web/CSS/@supports

This means that you can start implementing it today for modern browsers, and then remove the old one once you are ready to ditch old browsers.

Every browser supports @supports. If the browser doesn't know what @supports is, it ignores the entire block.

Actually, if a browser did support grid but not @supports, wrapping your grid in @supports would result in the grid rules not being used.

Well, that is true.

My caveat is that currently @supports is far more heavily supported than grid layout which is not fully available in any current browser. As usual, only IE is the major holdout for @supports and most likely we'll be doing special things for IE until it totally dies out anyway.

If you are speaking of people manually inserting style attributes into their code then there's a point for the resistance to that. It's horrible in comparison to classes.

If you are speaking of JS framework dumping code into the style attribute on the fly then there's a smaller point for the resistance to that. There are features of CSS that are not available through the style attribute. Plus, it's just plain inefficient.

Reply on news.ycombinator.com