“Googles 'vertical center div css' for the 100th time. reads for 7 minutes”
bleonard.com
bleonard.com
<div style="display:table;">
<div style="display:table-cell;vertical-align:middle;">
<div style="margin-left:auto;margin-right:auto;"></div>
</div>
</div>
Also, naming issues aside, we are forced to pollute our markup with pointless, unsemantic container divs simply to achieve a basic style on the contained div.
Also, if divs have no semantic meaning in the context of the document's structure, it means they serve some other purpose: and that purpose is visual styling (not directly but through a css applied to them). How is this not a violation of the separation between document structure and presentation?
That said, separation between structure and presentation is desirable, and the necessity to use multiple divs to achieve a layout effect means CSS 2 is not as powerful as we could want. The grid model in CSS 3 is much more powerful, and allows things like separating the presentation order from the structural order.
Yes, it's better to have fewer divs that serve no purpose but to create the desired visual effect. As someone else suggested, in your example you probably don't need <div style="display:table;"> so it only requires adding one container div.
Why wouldn't the principle be applied everywhere? Expressing your intent -- writing semantically -- is a general principle of clean code, and of clear communication in general.
It's fine if you want to argue it's more important in html than in css, but that doesn't grant a pass to the creators and proponents of pure CSS who peddle the ideal of semantics with religious zeal and then fail to apply the principle to their own language, or even to realize that they've failed to do so because, I suspect, many of them don't actually grasp the true goal of the principle -- clarity and usability.
If they did, CSS wouldn't be the unusable mess of quirks that it is.
What I more often see is people advocating for using semantic HTML, because it exists, and separating concerns (content & presentation). If there was a choice to use CSS properties and values that better conveyed the presentation intent (what you might call its semantic value), they would advocate for that as well.
That's exactly what I said. I think the difference is in our interpretation of that causality: you see it as an intentional concession in the name of backwards compatibility; I see it as a failure of imagination.
You seem to be misinterpreting my arguments -- I'll assume not deliberately. They could have easily provided the same facilities for backwards compatibility of table behavior while also providing clearly-named and usable methods for doing things as basic as centering.
Is your position that CSS is a thoughtfully, well-designed system for presentation, and that the complaints of 95% of professionals web developers are the result of their own misunderstanding of it? Can you imagine taking such a position on user complaints as the CTO of a private software company?
I do believe most complaints about CSS is really complaints about missing and buggy implementations in browsers. For example for years I have seen people complain that CSS is not as powerful and simple as html tables, when the issue really was that Internet Explorer didn't support the display:table properties from CSS2, which meant you either had to use hacks with floats (which was never designed for this) or use html tables. This gave CSS a bad rep, when it really was IE that was to blame.
In any case, there is no irony here. The display:table-* properties is defined precisely to mimic the layout model of HTML tables (hence the name), in order to allow you to achieve the same layout with pure CSS, so you don't have to misuse <table>-elements.
It seems some people have misunderstood the recommendation against using <table>-element for layout, and thinks there is something wrong with table-based layouts. But table-based layouts are fine, and sometimes the only was to achieve a desired effect. The problem is only misuse of <table>-elements for something which is not semantically a table.
<style>
.table-example { display: table; }
.table-example div { display:table-cell;
vertical-align:middle; }
.table-example div div { margin-left:auto;
margin-right:auto; }
</style>
<div class="table-example">
<div>
<div></div>
</div>
</div>Of course such a project won't work with most non-React web projects. Idiomatic React projects tend to have a large number of small components with extensive re-use. (~5 lines of HTML not counting closing tags per component is my metric)
In a perfect world, we don't need wrap layers of div of divs for styling, why don't we invent a more semantic tag called "table". Oh wait...
I always failed to understand what is hard about the _being_ something vs _being displayed_ as something. I have met so many smart people just failing to grasp this simple dichotomy.
For the sake of public education, here is an example from the article. H1 is for (document) titles, and is so used by auto outliners and Google and Pocket. Document titles are document titles regardless of the way your page is displayed (user agent or current style fashion). If you want to display bigger just use "font-size".
Just because CSS hasn't proven to be all it was supposed to be, does t mean the criticism of the old way was incorrect.
?
Certainly, flex-box addresses a problem that's been making CSS writers frustrated for a long time.
Same deal with mobile OS support, really. You have to have a pretty unusual or long-standing audience to support anything pre-4.2, let alone pre-4.0. iOS7 is also probably not worth the time to target for most products.
Yes i.e. DRY
You don't need web programmers for web design. You can export from a WISYWIG to HTML, or design a big ol' GIF and post it on Wordpress. Lots of restaurants do that sort of thing.
But you probably want something that interacts with the user, changes layouts based on screen size, provides information to disabled users, validates and submits information, allows commenting and moderation of comments, etc. Eg, a program. And you do need programmers for that.
Why can't the designer specify that? Because the current tools suck for designers (i.e. they were made for programmers).
> provides information to disabled users
Ditto.
> allows commenting and moderation of comments
There should be ready made solutions for that, usable by non-programmers. If you wanna buy a toaster, you don't go "oh, it's an Electrical Device and we need an Electrical Engineer". A toaster is complicated inside, but it was made with good engineering so users don't have to care.
The web is not like that. The needs of most websites are well understood by now, but somehow we still need programmers to make layouts and comment systems. My only explanation is that the whole system of HTTP/HTML/CSS/JS is poorly designed, in a way that's very hard to fix. Name me one other medium where positioning elements on the screen/page/whatever isn't a completely solved problem. Show me a single game developer who just can't seem to get the crosshair centered vertically on the screen.
Print designers also have to think about the platform their design is presented on e.g. what kind of color bleeding will happen in the press when an image is used on newsprint.
[0] https://www.netmarketshare.com/browser-market-share.aspx?qpr...
I pretty sure my kid would care if that happened.
I run multiple sites, and most of them have IE (any version) as under 10% of users. One of them doesn't; IE represents ~13.5% of users on that one.
My untested theory about this is that IE users are generally less adventurous web users, sticking to sites like Gmail, YouTube, local news sites, etc.
TLDR: unless you're working on Gmail or a site where you expect to soon see the world turn up at the doorstep, it might be safe for you to mostly ignore IE.
This, of course, is going to be different for every project and website. Each team would need to look at _their_ browser usage stats and make a judgement on what resources you want to spend on supporting the stats that you're going to see.
You have to either be enhancing an existing product where you know that the segment in question isn't worthwhile supporting, or be prepared to estimate whether that segment is going to be meaningful for you.
Another thing to keep in mind is that sometimes the result isn't a deal-breaker. Suppose I try to get vertical centering working on one of my sites using flexbox. Perhaps the 5% IE users simply see the content of each div at the top rather than being vertically centered. Not ideal, but not the worst possible outcome, either.
Out of interest, does anyone know how flexboxes break on IE if you try to use them for vertical centering? Does the content actually just sit at the top?
That's why any commercial entity will be very wary of closing the door on paying users no matter how old their setup is.
Not a problem.
But if you're only looking for that, then it seems very churlish not to use table layout, since that is the same amount of CSS and works in IE8+. There's no excuse for breaking layout in a browser if the alternative is just as simple and has no downsides.
Once you need to use flexboxes for more than vertical centering, it can cause more problems. Using it in place of inline-blocks, for example (one of its useful applications), can leave your content very weirdly laid out on older IEs.
Supporting IE < 11 shouldn't be a technical decision, I'd say. It is simply not technically difficult to do (outside of a couple of very niche web technologies). It is a business decision. So, you need to ask the CXOs if they're happy to leave those customers to your competitors to save you however many hours of dev and testing. There's a point where the answer will be 'yes'. Mostly we've passed that for IE6 now, but not always. I'm aware of one company targeting government clients, particularly in the developing world, for whom IE6 support is essential.
That the computer industry still can't get stuff right and forces users into an upgrade (which may or may not work, could quite possibly lead to a borked browser or even a totally borked system leading them to have to 'upgrade' to a more modern operating system, which in turn may require them to shell out money for new hardware) is no reason to push the responsibility for the laziness of web developers onto the end users.
We went through this years ago with IE6, there were always plenty of devs with variations of "screw 'em", but blaming or penalising users for their set up is a bit of a dick move, and shutting out or inconveniencing a big chunk of potential market is not a good business strategy.
There does come a point where the cost of supporting a browser exceeds the value of the people using it, but I'd be surprised if most sites have hit that for IE8 (the third most used browser, more than twice the market share of the most used firefox).
I wasn't trying to be a smartarse, I wish flexbox was usable. But IE < 11 is still a very large player.
If you start a new project today, there is almost no reason to care about IE < 11. By the time you get enough users that IE itself becomes a sizeable number, I am willing to bet that IE < 11 will be around 5% of users on the high end.
.centered {
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}
Wordpress with her custom theme seems to fail C. Github pages / Jekyll is failing B
I now am basically 100% Jekyll and Middleman...but having tried teaching Github Pages to college students...I'm skeptical that it's easy enough for a child to hack around with and get the same amount of enjoyment and productivity that she would out of Tumblr or WordPress.
(Apparently Ghost is pretty good too but I've never tried it)
For a little more functionality, I like ASmallOrange. My partner hosts her site/blog with them for $35/year and it's great, too.
Livejournal is still the best for writing posts and having discussions on. Takes no effort to keep going, and has threaded comments, supports images and videos, and basically just works:
http://andrewducker.livejournal.com/ (for an example)
body { position: relative; height: 100vh; }
#content { height: <defined>; top: 0; right: 0; left: 0; bottom: 0; position: absolute } .vertically-centered {
position: absolute
top: 50%;
height: 200px;
margin-top: -100px; /* minus half of `height` */
}
The typical problem with WYSIWYG webpage builders is that the web is not a printed document. If you don't know the underlying concepts of layout you expect things to behave much differently than they actually do. Or at least, that was how it was for me.
One of my earliest memories of 'coding' (It seems silly to call it that now, but hey, I was 13!) was opening the generated html files to remove the "Created with Frontpage" html comments that were automatically injected.
I'm thinking something like whatever minimal core would be considered the PCF of the web world.
<div class="center-this"><div>Stuff</div></div>
.center-this {display:table;} .center-this > div {display:table-cell;height:100%;vertical-align:middle;}
I even code pen'd it for you: http://codepen.io/anon/pen/RPEypL