Phrogz

Doing a search by laptop spec [1], there is exactly one laptop model, the Lenovo Legion Y740S-15IMH [2] that has an i7-10875H CPU, a 4K display, and no dGPU. Sadly, it seems to have pretty limited region availability so far (see the PSREF listing to check).

If you're willing to forgo the 4K display (a 15.6" 1080P screen at 24" is >60ppd, so it should be close to a "retina" display [3]) then you might have another option (the one I've been looking at). The latest AMD 4800H processors perform neck and neck with the i7-10875H (with much better power/perf) [4] and there's one ODM, Tongfang, that has a Renoir refresh (model PF5NU1G) that looks like it might be the best option available this generation (I'm looking for much the same thing as you - the highest CPU power possible, no dGPU for better battery life and less Linux hassle). It's using the same (1.5kg 15") chassis as their older Picasso model (see the Schenker VIA 15 NBC review for a good overview [5]) but with some notable improvements:

* Improved dual fan, dual heat pipe cooling means it can boost to 65W and sustain 54W CPU performance

* Dual channel, dual DDR4-3200 SODIMM slots (but the tradeoff is now only 1 M.2 slot)

* slight display upgrade from N156HCE-EN1 [6] to a NV156FHM-N67 [7] - matte, 300nit, 100% sRGB, dE<2, 1000:1 contrast ratio FHD screen w/ DC (not PWM) dimming

* USB-C PD (Power Delivery) support added, but no DP (DisplayPort alt mode); but has HDMI 2.0 support for a single 4K@60 external…

This site sums it up pretty concisely:

http://phrogz.net/CSS/WhyTablesAreBadForLayout.html

Not that I agree with him entirely. In particular:

> 6. Once you know CSS, table-based layouts usually take more time to implement.

For a sizable site with layouts reused over multiple pages, yes. For a single page, or a site with differing layouts for each page, in my experience, no. Actually, I'd extend that first sentence of mine into a new reason: with CSS you can specify your layout once, and not have to redo it for every page. Doesn't work with tables.

> 7. Tables are semantically incorrect markup for layout.

My response: So what? (Yes, I know about the problems with screen readers, but that's a different reason, one I happen to agree with.)

And then, on the other hand, there are the things no one wants to say: the advantages tables have over CSS. In particular, it's obvious to me that CSS was not designed with modern layouts in mind. The fact that it works at all is really just an accident: it turned out that you can make columns using floats (how 'bout that?). Yes, using tables for layout is a kind of jury-rig, but to be honest, so is using CSS. And at least tables have a mechanism for producing columns, that was designed with columns in mind.

And then there are the browser rendering inconsistencies. With modern browsers, these problems are fading, but for older ones, the inconsistencies with CSS seem to be much more troublesome than those with tables.

I love CSS2 just the way it is. Developers seem to have a knack of forcing object-oriented thinking on CSS. They want to dictate what CSS should do different, when browser vendors still have trouble deciding what specification-valid CSS should do.

Dynamic CSS to me is an abomination. CSS is not a programming language and I doubt treating it like one will enhance portability and suddenly inspire the OP to invent the "holy grail" of CSS layouts: A simple variable height multi-column design with a header and a footer.

Come on, give the web and the front-end community a little respect. Don't use javascript for essential design/layout work, you don't need it, never needed it for years. You don't need hacks or CSS3 to build a fantastic website. You can float and use absolute positioning to your hearts content. You can keep your stylesheet organized and even support mobile and print media with it.

@cletus Vertical-align:middle does work differently on block-display elements. Use it in conjunction with display: table-cell or look at http://phrogz.net/css/vertical-align/index.html

I consider the OP post a little flame-batish and uninformed. I could say this about Lisp in an exaggerated manner: I hate it, because it does support labda, though it has its drawbacks and all those brackets look silly and confusing. I haven't really studied Lisp, but it could benefit from listening to my problems (which are real).

In case anyone is interested - NVIDIA on PPD: http://phrogz.net/tmp/ScreenDens2In.html#find:density,pxW:1920,pxH:720,size:12.3,sizeUnit:in,axis:diag,distance:31,distUnit:in

They claify that while acuity limits for a person with 20/20 vision is 60PPD, the average acuity is more like 20/15, equating to 80PPD. It looks like NVIDIA put the PPD benchmark for an ideal display at ~92PPD, which would push the acuity limits for just about every human user. That seems reasonable to me.

As a point of reference, accounting for binocular overlap values (which I had to hunt for), I calculated PPD's for two of the highest pixel-count HMD's out there:

StarVR: 18.6 PPD
Sensics dSight: 20.2 PPD

I don't have the details needed to calculate Avagent or Hololens PPD's, but I'd venture to say their at this point or lower. So, as you can see, we still have a long way to go.

One more note - Displays don't need a constant PPD accros the entire rendered image, thanks to steep visual acuity drop-off relative to FOV angle (1). So, to the OP's credit, perhaps there is still some work that is needed on the PPD metric to account for HMD's that use foveated imaging (2), such that all displays (foveated & non-foveated) can still be compared side-by-side.

1. https://upload.wikimedia.org/wikipedia/commons/thumb/2/27/AcuityHumanEye.svg/500px-AcuityHumanEye.svg.png
2. https://en.wikipedia.org/wiki/Foveated_imaging

> A 28" 4K UHD has 157 dpi, so I wouldn't want to try it at 100% scaling - ouch. It ought to be running in the 150-175% scaling range.

That’s not how it works. Lower dpi does not somehow give you more real estate!

You should still be running with ~200% scaling because you are viewing it at a greater distance.

Optimal viewing distance, assuming 16:9 ratio, is 120 cm vs 140 cm for 24" vs 28", respectively[1]. Accounting for the difference gets you ~155 ppd with both monitors[2][3], maintaining 25.0° horizontal viewing angle.

The closer your viewing distance the more ppi you need for the same density. That 28" is not inferior to the 24", when you account for distance, despite the lower ppi, because the greater viewing distance makes the pixels look smaller, thus creating more dense image.

[1] https://en.wikipedia.org/wiki/Display_size

[2] http://phrogz.net/tmp/ScreenDens2In.html#find:density,pxW:3840,pxH:2160,size:23.8,sizeUnit:in,axis:diag,distance:120,distUnit:cm

[3] http://phrogz.net/tmp/ScreenDens2In.html#find:density,pxW:3840,pxH:2160,size:28,sizeUnit:in,axis:diag,distance:140,distUnit:cm

caniuse [0] has some stats.

Flexbox is supported in:

* Internet Explorer 11, but only partially

* Edge 14+

* Firefox 52+ (Everything but buttons in Firefox 50)

* Chrome 51+ (50 had it, but had a bug that still plagues Safari)

* Safari 9.1 (but Safari has a couple huge bugs [1][2])

* Opera 41+

* Safari iOS 9.3+ (but see [1] & [2])

* Every version of Opera mini

* Android Browser 4.4+

* Android Chrome 53+

A great bullet-point list of why not to use tables for layout can be found here [3].

Flexbox is designed to enhance and make easier some of the CSS that we already use today, so they go hand in hand.

As to Bootstrap, as of v4, it will include Flexbox as an opt-in option (in case you support old browsers where it wouldn't work). [4]

[0] http://caniuse.com/#search=flexbox

[1] https://bugs.webkit.org/show_bug.cgi?id=136041

[2] https://bugs.webkit.org/show_bug.cgi?id=137730

[3] http://phrogz.net/css/WhyTablesAreBadForLayout.html

[4] http://v4-alpha.getbootstrap.com/getting-started/flexbox/