I think this makes 99% of pages look really really bad and unreadable, and 1% look better.

This is especially limiting when making tables that contains images like UI screenshots, which you would really want to use as much space as possible.

Can you expand on what you're doing here? It sounds like this is the root problem we'd be more likely to address.

Wikipedia, the ultimate wiki, is full page width (https://en.wikipedia.org/wiki/Phabricator).

GitHub is not however: https://github.com/git-up/GitUp/wiki.

It's just one of those design/usability tenants, whitespace improves visual comprehension. Plenty of usability research out there supports this. We moved to fixed width... maybe 3 years ago or so? Longer? I can't even really tell.

If it's just about images/tables, would be happy to find something cool there to build (lightbox remarkup?)

Stuff like this:

I can't have 4 columns because then everything is too small and unreadable.

It's also a pain to assemble these things because Phrication doesn't auto-size images in a table in an intuitive way so you have to manually specify image sizes in the markup, trying to make it as big so it fits the wiki width, but not too much because then it breaks. You can't specify % units either.

| OSX | iOS | Android
|-- |-- |--
| {F774 width=240} | {F776 width=240} | {F778 width=240}

If all you want is a table of images (the recommended way since otherwise it's very hard to layout series of images predictively - there was a task about this), it's actually surprisingly hard to do. I would expect this to work with N images:

| {F774 size=full} | {F776 size=full} | {F778 size=full} | ...

It might also be worth exploring this stuff in Pholio v2... but maybe we can find some workarounds in Remarkup in the meantime. Maybe @epriestley has thoughts too.

It's just one of those design/usability tenants, whitespace improves visual comprehension. Plenty of usability research out there supports this.

What's the reasoning behind not having Maniphest behave this way then? I'm genuinely asking: if full-width works for Maniphest, why not for Phriction? In both cases, you have remarkup content. I would also postulate that the type of content overlaps significantly i.e. it's not like Phrictions is only for English literature while Maniphest is for tech content. Why would this common content be full-width in 1 case and fixed width in the other?

FYI here's what Maniphest would look like with the same fixed width as Phriction:

Or maybe Phriction could do like medium.com: fixed width text but images can be ~120% fixed-width or even full-width:
https://medium.com/the-story/making-medium-more-powerful-for-publishers-39663413a904

Honestly I'd love to add some cool Medium like stuff, it's what I had in mind with the Phame update, we just haven't been able to prioritize building anything like that out. If it's something you're interested in, we can look at more. I think going larger with images (or tables) separately should be doable,

The 'mild redesign' we've been rolling out will have a fixed-width option likely per user under Accessibility, I've planned it to 'just work' once I've been able to hit all the pages and update to the new layout engine. I was originally intending to go full fixed-width, but @epriestley thought doing both two-column and fixed-width might have users up in arms, so we stayed fluid.

The 'mild redesign' we've been rolling out will have a fixed-width option likely per user under Accessibility

Does this affect all apps? What is the default setting?

What's the task BTW, I'd like to follow it.

I was originally intending to go full fixed-width

I'm not sure what "full fixed-width" means... 😄

By full fixed-width I mean convert all of Phabricator. It was only explored in Photoshop and some light banter between Evan and I.

There is no formal task for adding a user setting for fixed or fluid content. When I do add it, it'll only support "new layout" pages, so not every page, nor workboards or conpherence, would get it, but you would get most pages. There are some random pings and IRC messages that users do want this option. We just don't want to formally support it until more pages are updated.

I think there are probably three takeaways here potentially:

• We are planning Phriction v3 at some point, and wanted it to be more "CMS" like, with custom navigation, other options. Might be a good place to discuss other layouts
• I would like Pholio v2 to add more features around presenting Mocks / Workflows as well as allowing designers more easily manage their workload (via a workboard)
• More Remarkup tools are always on the table, since they benefit many different apps.

T9379 is the Phriction v3 task, we don't have anything on radar for Pholio v2 summarized yet.

Thanks much for the info. What should happen with this very task then? Close it?

No matter what, it would be nice to have a new size option for images so that you can have them "fill" full-width while inside a table cell, which I'm pretty sure is easy in regular HTML / CSS.

Let's keep it open, can use it to decide what Remarkup options to add. I'm partial to adding full, fuller, fullest options to image sizes. :)

At least today, I don't think we can reasonably guess when a table is really a collection of side-by-side comparison images to do anything special with it. I think allowing block-level elements to change behavior based on content would require a total restructuring of how Remarkup parses, and make adding new rules far more complex (see also T10354).

We can add size=cinematic to images easily, but that won't solve the table-of-comparison-shots use case (and I think full is already reasonable if you have a single image, it could just be a little fancier).

Some ideas:

• Build a dedicated element for this (but it seems really niche?)
• With the <table> variant syntax, we could do <table kind-of-table="cinematic-tiles"> or something. This is basically a dedicated element by another name. Slightly easier to implement but seems even more niche and clunkier for the user.
• Make mock embeds more cinematic; accomplish this by creating a mock (but that would be quite cumbersome?)
• Build Phdropbox on top of Files, add syntax to "embed a directory", have it render a cinematic preview if the directory contains images (maybe good, but lots of work?)