Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Grid Lanes

webkit.org

Post reply on HN
Print view View original

181–190 of 237 posts

Re: CSS Grid Lanes

#181

Post by docmars »

sabellito wrote: post #168
rahkiin wrote: post #149

Earlier quoted context omitted.

Have you considered using tables? It is funny how we keep asking more and more and more even though we already have it so much better than before. Can we never be happy with what we have?

How would tables solve the issue they're talking about?

Borders can be applied to table cells independent of the content inside cells.

Gap decorations allow you to add borders between flex/grid items, but without the woes of dealing with table quirks and behavior.

Common use cases would include mimicking design patterns found in print layouts, particularly newspapers and menus, to help divide groups of items or info.

Examples: https://developer.chrome.com/blog/gap-decorations

Re: CSS Grid Lanes

#183

Post by anonymous908213 »

crazygringo wrote: post #179
anonymous908213 wrote: post #67

Earlier quoted context omitted.

Going back 2 versions, only ~50% of Chrome users are on v140 or newer. If you go back another 2 versions, that number increases to around ~66%. Going back another 2 versions only increases that to 68%, with no huge gains from each further 2 step jump. That you think your target gives you 98% coverage is concerning for the state of web developers, to say the least. After checking further, almost 20% of Chrome users ar…

Can you link to the source for your stats? I'm not finding anything to corroborate that -- I'm seeing stats suggesting things like 90% of Chrome users are on the newest version after two weeks: https://timotijhof.net/posts/2023/browser-adoption/ And Stat Counter shows that the current version of Chrome utterly dominates in any given month: https://gs.statcounter.com/browser-version-market-share/desk... The glacial ad…

My go-to reference is this, which itself cites statcounter: https://caniuse.com/usage-table

I was specifically referencing desktop Chrome, not including Chrome for Android, but other than that, if there are discrepancies, I'm not sure what the cause is.

Re: CSS Grid Lanes

#184

Post by temporallobe »

It’s always nice to see native implementations of functionality pioneered by third-party libraries. Bootstrap, for example, has made this kind layout (somewhat) possible but there is also a Masonry plugin that simplifies it.

Re: CSS Grid Lanes

#185

Post by 8n4vidtmkvmk »

hu3 wrote: post #166
nehalem wrote: post #161

There is an element of tragic comedy to those announcement. While remarkable on their own, everybody knows that one cannot use any new browser feature reliably any time soon due to Apple not shipping continuous updates to the browsers they force upon their users.

iOS from 2 versions prior don't get latest Safari? I can't check because my wife's iPhone is, regrettably according to her, "updated to the latest glAss version".

I know one of my clients complained something didnt work on their few year old iPad. So.. I don't know what the cutoff is but clearly not everything updates regularly. He did try updating it manually too but couldn't.

Re: CSS Grid Lanes

#186

Post by runarberg »

anonymous908213 wrote: post #67
runarberg wrote: post #60

Earlier quoted context omitted.

I think a very common browserlist target is "last 2 version, not dead, > 0.2%". So if you have a 2-year old browser you are probably dozens of versions behind and are very likely in that 2% of users which developers simply ignore.

Going back 2 versions, only ~50% of Chrome users are on v140 or newer. If you go back another 2 versions, that number increases to around ~66%. Going back another 2 versions only increases that to 68%, with no huge gains from each further 2 step jump. That you think your target gives you 98% coverage is concerning for the state of web developers, to say the least. After checking further, almost 20% of Chrome users ar…

Note that the comma in browserlist queries are OR. So if any given browser version still has > 0.2% usage, it is included. This would include Chrome 109 which is three year old. Meaning developers with this browswerlist target would fail their static analysis / peer review (actually even a more reasonable > 0.5% still fails on Chrome 109) if they used a feature which Chrome 109 doesn’t support without graceful degradation or polyfill.

Furthermore the "baseline widely available" target (which IMO is a much better target and will probably become the recommendation pretty soon) includes versions of the popular browsers going back 30 months, meaning a competent team of web devs with a qualified QA process should not deliver software which won‘t work on your 2 year old browser.

I can‘t speak for the developers of the websites which break on your 2 year old browser... Maybe they don‘t have a good QA process. Or maybe you were visiting somebodies hobby project (personally I only target "baseline newly available" in my own hobby projects; as I am coding mostly for my own amusement). But I think it is a reasonable assumption that user tend to update their browsers every 30 months, and you won‘t loose too many customers if you occasionally brake things for the users which don’t.

Re: CSS Grid Lanes

#187

Post by extra88 »

rendaw wrote: post #107
ChadNauseam wrote: post #46

Earlier quoted context omitted.

I didn't realize it was tracked like this, but I have noticed that as of iOS 26, Safari has gotten a huge number of great web features. It has WebGPU of course, but many small things like fixing up missing parts of the OPFS API that make it actually usable now. Now they even have the field-sizing CSS property [0], fixing imo the most glaring ommission from CSS: the inability to make text input boxes grow to fit the i…

I thought that was supposed to be fixed by contenteditable plaintext-only. Why was field sizing still necessary?

`contenteditable` is an HTML attribute but it depends on JavaScript to do anything useful. This problem is one of layout, CSS's domain, so `field-sizing` solves it while leaving HTML form elements to do the actual job of taking input.

Re: CSS Grid Lanes

#188

Post by anonymous908213 »

runarberg wrote: post #186
anonymous908213 wrote: post #67

Earlier quoted context omitted.

Going back 2 versions, only ~50% of Chrome users are on v140 or newer. If you go back another 2 versions, that number increases to around ~66%. Going back another 2 versions only increases that to 68%, with no huge gains from each further 2 step jump. That you think your target gives you 98% coverage is concerning for the state of web developers, to say the least. After checking further, almost 20% of Chrome users ar…

Note that the comma in browserlist queries are OR. So if any given browser version still has > 0.2% usage, it is included. This would include Chrome 109 which is three year old. Meaning developers with this browswerlist target would fail their static analysis / peer review (actually even a more reasonable > 0.5% still fails on Chrome 109) if they used a feature which Chrome 109 doesn’t support without graceful degrad…

A couple of examples of the kinds of hobby projects that break on my 2-year-old Chrome installation: ChatGPT.com, Claude.ai, Substack.com

Your position sounds reasonable upon elaboration, I only wish more web developers had the same consideration.

Re: CSS Grid Lanes

#189

Post by alwillis »

concinds wrote: post #170
alwillis wrote: post #136

Earlier quoted context omitted.

> I can't think of a single good reason why they don't adopt an "evergreen" 4/6-week update model except Not Invented Here syndrome or "it's not Apple-like, we prefer the OS team (and therefore Marketing) dictating our release schedule, users be damned". There's a new version of Safari Technology Preview [1] for macOS every two weeks. There's a new version of Safari released every September for macOS, iOS, iPadOS, an…

The Safari/WebKit people are doing good work, yes. I use Safari as my default, and like every Firefox/Safari user I still get some bugs that don't occur in Chrome (not talking about WebMIDI obviously), so watching that 30 point gap between stable Safari and bleeding-edge WebKit (longer than 7½ weeks) on wpt.fyi was quite frustrating. The average Safari user would have a better browsing experience with a shorter fix d…

> Having to wait for macOS updates holds back the browser, unnecessarily.

Safari is an operating system component, which lots of people don't seem to understand; hundreds of thousands of 3rd party apps rely on Safari's WebKit engine.

I've never heard a normie Safari user complain that Safari updates aren't being released quickly enough; that's something web and app developers care about… which is why Safari Technical Preview is released every two weeks.

Even the release versions of Safari on iOS, iPadOS and macOS allow you to enable web features that are still in development.

Re: CSS Grid Lanes

#190

Post by extra88 »

nextaccountic wrote: post #178
culi wrote: post #144

Earlier quoted context omitted.

Here's a comparison including the big 3, ladybird, servo, and flow https://wpt.fyi/results/?label=master&product=chrome&product... To answer your question, yes. Apple requires 80% test passage of all the tests on web-platforms-test in order to be considered as a valid browser for iOS so they specifically targeted this suite to reach that milestone It's a pretty silly requirement because wpt is not really meant to be…

I thought that no other browser engine could be provided on iOS. so no ladybird's engine, no servo, no gecko, no blink, only webkit

Some geographic regions have declared that not allowing other OS engines on iOS is anticompetitive so they're requiring Apple to allow them.

Apple is fighting it tooth and nail and coming up with requirements for other engines is a small way of doing that.

Post reply on HN