Live data from Hacker News

How to Center in CSS

howtocenterincss.com

211–220 of 297 posts

Re: How to Center in CSS

#211
post #23

Earlier quoted context omitted.

I've heard that android's XML layout is terrible (from an android developer) and that iOS auto layout is borderline magic (from an iOS developer). Personally, I don't find css to be that bad at all, but I work in it at least a little everyday so it might just be stockholm syndrome.

iOS developer here. AutoLayout is definitely not borderline magic, and some people hate it. It is inefficient. It is awkward to set up in code, so many people write their own syntactic sugar around it. It crashes hard when it isn't 100% sure what to do with its constraints. Working with multi-line text is still a pain, so you often run into clipped text on iOS if you dare to increase the font size. etc.

Hey thanks for the reply. I don't work on mobile apps at all, so I really wasn't aware. It's definitely interesting to see your point of view,

Re: How to Center in CSS

#212
I know the web is not print, pages are not static, user screens vary and one shouldn't try to control everything bla bla bla, but it seems all my layout woes ultimately boil down to difficulty in lining things up.

That's what 'layout' means after all, isn't it? Aligning one thing with another, to show they're related. I'm not a classically trained graphic designer, but doesn't any explication of visual fundamentals include 'alignment' somewhere up near its top?

Yet CSS really, really sucks at lining things up.

Anyone designing a better system might do well to start with the notion of alignment as a basic primitive/operator. To be able to say, item A here ought to line up with item B there (and if not possible, predictable behaviour C results).

My gut feeling is that one could then derive all other types of layouts from there. I admit that might be naive. Also, I realise that I've probably just described constraint-based layout, but as yet I haven't tested one of its implementations such as GSS in a real project.

Re: How to Center in CSS

#213
My personal trick is to position the content absolutely at 50% (both left and top), and then transform the content using a -50% translate in both directions.

Works for dynamically sized content (and statically sized content as well, obviously).

Re: How to Center in CSS

#214
post #158
post #150

Earlier quoted context omitted.

The element has no semantic meaning, screen-readers don't read them and they have no intrinsic behaviour unless associated with an aria tag.

Why couldn't we just have made non-semantic tables? In addition to the semantic tables, I mean.

adding role="presentation" to a element will tell screenreaders to treat the element and its required children as non-semantic. I still say using a table for layout (of non-tabular data) is should be a last resort but it's easy for me to say since making a layout is rarely my job.

Re: How to Center in CSS

#215

I know the web is not print, pages are not static, user screens vary and one shouldn't try to control everything bla bla bla, but it seems all my layout woes ultimately boil down to difficulty in lining things up . That's what 'layout' means after all, isn't it? Aligning one thing with another, to show they're related. I'm not a classically trained graphic designer, but doesn't any explication of visual fundamentals…

[deleted]

Re: How to Center in CSS

#216
post #127

Earlier quoted context omitted.

is content, table-cell: is presentation. Semantic tag use matters because some people are blind and their screen reader will start randomly start talking about some structure that makes zero sense in context

I understand and agree with the general argument, but is it actually true that screen readers for the web are that naive? I would expect them to render a page (like with WebKit) and try to figure out the layout of the page, which things are actually visible, etc., or at least use heuristics to figure out what is and isn't content (in the same way that Readability-esque algorithms presumably do).

The browser, not the screenreader, does the rendering, figuring out what's visible, etc. The results, an "accessibility tree" which is sort of a subset of the DOM, are then presented through an accessibility API to screenreader software. Screenreader software is pretty naive, there might be some that initially assume a table is being used for presentation, not data, if it lacks good semantic structure (e.g. no header elements). Case by case, it's hard to tell in which way the author is bad at their job, using a table for presentation or poorly marking up a table for data.

The stakes are much lower for Readability-esque algorithms, when they fuck up the user can just go back to the site's native presentation; screenreader users don't have that choice.

Re: How to Center in CSS

#217
For everyone who thinks CSS is just a collection of hacks (rightly so) etc., you should try playing with GTK+3. It borrows a subset of CSS, has it's own Flexy Grid model system etc. It will still be fair to call it a Work in Progress but I think it's layout system is quite nice.

Re: How to Center in CSS

#218
post #140
post #121

Earlier quoted context omitted.

Only partially. You usually have to use browser prefixes to get it to function. http://caniuse.com/#feat=multicolumn

Add Autoprefoxer in your build process and never type them again.

That is not CSS anymore, it's "CSS + autoprefixer". Which, I agree, is great, but it's worth mentioning. Vanilla CSS requires the prefixes, "CSS + autoprefixer" doesn't, but it requires other things like an extra build step (and a build process, at all). Worse, it could be mutually exclusive with other tools.

When you advocate an add-on to an existing solution, you're changing the solution. It's like people who recommend typescript in reply to JS's lack of types, or Coffeescript to its ugly syntax: you can't have both, they change the original thing. Or vimperator with firefox, or vim-mode emacs, or... it's all not the same thing anymore. You push the carpet down in one place, it comes up in another.

CSS still requires the vendor prefixes. If autoprefixer is the perfect solution to that, let's stop people everywhere from using vanilla CSS and switch them over to "CSS + autoprefixer". Turns out it's not that easy, which gives the original "but it requires prefixes" argument more meat.

Re: How to Center in CSS

#219

Earlier quoted context omitted.

What's broken is not Safari but people who buy Macs. ... I can't go any deeper. Still I'd like my site to look good to a meaningful market share.

True, but I wouldn't say 4% is a meaningful market share, so fuck Safari. It's the new Internet Explorer. Leaving the sites broken in Safari (and maybe adding a notice that explains why it's broken) also helps keeping it at 4%.

Safari is also the native browser for iOS. I don't know where you got 4% from but Safari (both for OS X and iOS) is more than 4% market share.

Re: How to Center in CSS

#220
post #38

The mere fact that a site like this can exist and not be a joke is proof that CSS is still badly broken. I should be able to center things by writing: foo { align: center; valign: center; }

You're in luck. foo { display: flex; /* opt into the new box model */ justify-content: center; /* "align" */ align-items: center; /* "valign" */ } Vendor prefixes may or may not ruin your day (for now), but the spec is there and is exactly what you want. CSS is no longer "badly broken" if that's your metric.

Flexbox is nice and makes some things easier, but its still (IMHO) a half assed solution compared to something like QML's anchors.

In QML I can center like this:

    anchors.centerIn: parent
(replace parent with id of item you want to center in if not the parent item). You can also do just vertical or horizontal centering, or you can fill another item or you can anchor eg the left of your item the the right of another item and the right of your item someplace else and it resizes/repositions your item as required.

Flexbox still often requires lots of nesting to achieve what should be (and is in QML) relatively simple layouts. I've also hit a few things that I couldn't do at all with Flexbox (although that could just be lack of CSS/flexbox skill on my part - but to that I say that CSS gets very hard quite fast, while complex layouts in QML are pretty easy).

Post reply on HN