I used the W3C Schools method of making a hamburger menu. It’s a series of 3 divs that are contained within an outer <a> tag. Then I can style it like so
div.hamburgerMenu {
width: 100%;
height: 5px;
background-color: var(--navBtn-text-color);
margin: 6px 0;
}
And the <a> tag acts as both the hamburger menu’s container and its link.
Hmm, could you get away with just the <a> and using the ::before and ::after pseudo-elements?
Eww, block elements inside inline blocks… It’s like seeing GOTOs, or nested else statements. It may work but is bad practice for the most part.
A better suggestion would be to do something like this: https://codepen.io/erikterwan/pen/EVzeRP
Of course, there are exceptions to every rule, but…
back in my day… joe burns at htmlgoodies was my guru, his articles were always titled something like “so, you want a/an X, huh?”.
it’s a completely different site now than what it used to be, broken links here and there in the old articles, but that’s where i started learning… like in the late 90s. I never hated CSS nor found it all that difficult, but i’m not a programmer. I hate javascript (kinda) and have really struggled with learning and retaining anything when it comes to js and php.
I’ve seen too many ppl that might be competent programmers that don’t really get bootstrap (let alone css) and manage to make some interesting messes. I have a feeling that might not be a common thing but just unique to the “lowest bidder wins” process that i think my betters rely on for just about everything. I think bootstrap’s real strong point has always been how well documented it is - in theory that should make it easier for multiple ppl working on the same project to not do things that conflict with each other. I wasn’t crazy about using any css framework when i was kinda forced into bootstrap by a noob php/angular/whatever dev but since i already knew a lot about CSS it wasn’t hard for me to figure things out.
I use flexbox every chance i get, still don’t think i understand all of it, grid’s better in some cases but not for any of my projects yet.
flexbox center:
.container{
display: flex;
align-items: center;
justify-content: center;
}
grid center:
.container{
display: grid;
place-items: center;
}
oh. I have an easy fix for this:
a.className {
display: block;
}
I don’t care. CSS is complicated enough already for me, and wrapping a link element around the 3 hamburgerMenu divs works.
Yeah, flex is awesome.
I just started learning flex a few days ago when I started re-working my site CSS.
I’ve implemented a simple navbar with it, and am surprised how well it works:
Regular layout on desktop(examples):
On desktop, when the navbar items get too long, the 3 regions(left,center,right) will be separated usefully:
On mobile, the menu just collapses to a list:
Also I’ve implemented the shittiest CSS minifier in just 7 lines of bash:
#!/bin/bash
rm -f style.min.css style.css
wc -c *.css
cat *.css > style.css
sed "/\/\*.*\*\//d;/\/\*/,/\*\// d" style.css | tr -d "\t" | tr -d "\n" > style.min.css
wc -c style.css
wc -c style.min.css
For best results, indent using tabs only, and use only space as argument separator. All tabs can be safely removed this way.
Works fine for me™
7827 style.css
6368 style.min.css
Edit: I’m definitely one of those programmers 
The problem with your approach is that you will most probably get nested hyperlinks, which… Should crash and burn in any standard compliant HTML5 browser. At least use a span element instead.
Side note: I wish the XHTML 2.0 idea of adding the href to every element had caught on, that way we could’ve done cool stuff like:
<nav>
<ul>
<li href="one.html">My</li>
<li href="two.html">incredibly</li>
<li href="three.html">cool</li>
<li href="four.html">hamburger</li>
<li href="five.html">menu</li>
</ul>
</nav>
Alas, XHTML 2.0 was too ambitious and too strict about it’s ideals, so… Here we are
I think css is quite ok. Not perfect.
But it can do a lot.
So much in fact that most html elements seem completely redundant when you go down the path of creating custom components. You’ll mainly be using a lot of divs…
I miss XHTML 2.
Instead we got WHATWG running around like a bad high-school comedy character claiming that “standards are so-oo last decade” and that what really matters is keeping up with what the cool kids (Mozilla, Opera, Apple) are doing. I guess that did not work out so well for Opera.
At least you can still use the XML serialisation (XHTML5).
// rant/mourning over
plz no
To be fair, XHTML2 had a bunch of idiotic ideas too, which is the reason why it never left the drawing board.
The main reason XHTML2 failed, was because it wasn’t backwards compatible with HTML 4.01 or even XHTML 1. That was a really stupid decision that was pretty much universally hated by everyone except the W3C.
Maybe things would be different if XHTML2 instead was named XDL (XML Document Language) or something similar. No idea where XML stands today, a few remnants like SVG is still alive I suppose, but for documents and config files the concept seems to be pretty much either dead or dying.
Of course, today HTML and CSS is nothing more than glorified template technologies for web apps. Static web documents just aren’t that hot anymore, and if they are, they are automatically generated.
Well… If I look at some of the component libraries I’m not entierly off in how I’m doing things. For instance the kendo text inputs we use at work consist of like 8 divs and 2 input texts (one hidden). So yes mostly divs. (Ok, no actually, just counted them, it seems to be 8 spans 2 input tags 1 div, I thought all the spans where divs). For all intents and purposes it might as well be a div since span is just an inline-block div.
But I mean there are things like buttons which well yeah it does make sense to use it if you wanna make a button. But if you want to make a very custom button for the most part the button tag just achieves you having to remove more styles. And a not very custom button I don´t need to make since we already got those on mass.
Then there is the whole form package. With form and submit buttons. Maybe add hyper links to the pack. Which are all not very useful when you are developing a SPA. Every single form you make you will do e.preventDefault and apart from the submit action it does not do anything special.
SEO, accessibility and searchability aren´t important for every app… If it where that way SPAs would have never gotten traction, because they are pretty bad for SEO.
yeah context is everything, every now and then i look at the source of something and the element i’m interested in is buried 20 divs deep. i don’t care enough to figure out why those 20 divs are necessary unless it’s something i need to work on for some reason and i’ll try to reduce that kind of mess if i have to work on it. i know nothing at all about all the js framework wizardry or whatever else ppl are using to spit out all those divs but as long as they aren’t doing things that i consider to be “breaking the web” it’s probably fine. PWAs are beyond my experience but at some point someone might care if a screenreader or other assistive tech can’t interpret the content in an intelligible way for the user. no idea what state of the art assistive tech is like on phones and tablets but i’m sure there are people working on ways to make those apps more accessible for people that can’t see or have other issues.
breaking the web? i’m sure there’s a better, more proper term for it that i can’t recall right now but silly things like using divs instead of paragraphs - that’s a semantic thing that helps machines understand the content whether for search results or for people that might be using a screen reader. using divs and setting them to display:inline is another one that sets off my OCD - because they put it inside of a paragraph element but don’t want it to break up the text - just use a span since those default to display:inline.
i’m fairly certain that a decent html validator warns when you’ve done something like putting a div or other block level element inside of a p tag. I haven’t really run a validator on anything important in years so my memory’s a little fuzzy. i think i’ve forgotten more than i currently know.
also, if you’re doing the “framework spits out components” type thing, couldn’t you make the element anything you wanted? something like <yt-button-holder>boo</yt-button-holder> instead of <div class="ty-button-holder>boo</div> for example. i’ve seen elements like that in youtube’s source code and it’s a bit easier for me to understand/read/navigate when it’s not just a ton of nested divs.
I ment SPAs. Sorry mixed up the buzzwords. Fixed it afterwards.
Yes, you do exactly that. But it does not change that inside the file containing the source for yt-button-holder it´s still divs (or whatever it might be) all the same and divs will land on the page it spits out at the end of the day. Things like that are for re-using whatever it is you did in a more nice way.
Not sure what it is youtube is doing. But yeah… you are right there are a lot of yt-something elements, even when you inspect it from the browser. Bit odd never seen that either. Normally when you use something like vue for instance the page it spits will not end up containing your custom defined element like that but straight up contains what you put into the files with some rewriting going on.
SPA … omg wtf yet another tla lol … still an app and to me an app (PWA, SPA, w/e) is basically web code that won’t be seen in a web browser. for better or worse i pretty much only deal with web pages - even if it’s just a mockup for a ‘webapp’ that the lowest bidder devs will gleefully ignore 
I can see it working if rendering engines implemented it as a third mode;
quirks mode, xhtml 1, xhtml 2
and kept any new/changed features active only there. Old documents would just render as normal in the old mode, as quirks mode once did.
As long as there was consistency, you would see a shift into XHTML 2 to use the new features, but if browsers start non-uniformly saying, “let us backport just this one thing,” then the clean break begins to fall apart.
The main issue would be with old browsers, but there seems to be some appetite in the modern web for websites failing on older browsers anyway, so I do not see a transition period into XHTML 2 as impassable. There was a stretch of time where I remember this happening with CSS; maybe when flexbox started to gain traction?
Or more dramatically, several years ago, I had issues visiting sites that were already fully dependent on ~4 month old features, which meant that even fully up-to-date Firefox ESR could not properly view them. Luckily I have not seen that happen since, but browser forward-compatibility is always a casualty, XHTML 2 or not.
I do admit, XHTML 2 was not the path of least resistance, I just wish we could have made it happen.
Personally, I feel like we should reinvent the browser to a proper remote-app-renderer tool. Heck, we already kinda do it with REST APIs and phone apps; why not break it off completely?
And yes, I do hate the concept of apps, because 90% of the time they do pretty much what a well-designed webpage would do in the first place.
Alas, I fear that ship has sailed. If only… 
Sorry for hijacking thread about the state of web development, carry on!
WebX11? 
The thread itself is a rant about web technologies, so I figure we were close enough to on-topic. To really tie it back, we could compare the HTML4→HTML5 transition to CSS2→CSS3, which I was slightly hinting toward above.
The new display modes (flexbox, grid) do seem to fit into CSS rather well; though the re-ordering is a bit strange. I suppose the true benchmark would be, does a newcomer to CSS see the new additions as more or less out of place than display:table.
I am getting better at CSS, and I’ve found that I actually hate it less, lol. You were right. I still have plenty of rants about it though as it seems inconsistent tbh. The MDN web docs have been an amazing resource. https://codedragon.dev
That’s just a temporary portfolio since my programming accomplishments are rather anemic at this time. I’d been working on the permanent solution when I realized that I don’t have anything to put on it.