Has anyone improved /main_block.png to have transparent rounded edges?

Started by Biology Forums, August 30, 2019, 11:35:58 AM

Previous topic - Next topic

Antechinus

That doesn't mean anyone has to use it. ;)

Anyway, have implemented that conditional to deal with av vs no av. It works. :)

Arantor

You wish, I have clients (think gov and NGO) who have tons of internal systems and haven't even moved beyond the impending EOL of Windows 7 yet :(

Gwenwyfar

Thank god estimations of IE mobile usage are below the 0.0% line. And opera mini is apparently meant to not work with anything so that's their problem.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

I don't have to support it anymore than I want to. I spent hours debugging 2.0.x in IE6, simply because the team had made a commitment that it would work in IE6. By the time I was finished, 2.0.x had taken so long (due to a range of factors) that nobody cared about IE6 by the time it went Final. The result was all that time and energy was wasted.

I am not going through that again. Not for a project like this little "Curve clean up". ****** IE. In all its pestilential manifestations.

But I might, after everything else, including RTL for sane browsers, is sorted, make basic support for IE11 as the aforementioned "I'm with Stupid" variant. Every time someone wants it, they'll have to choose "I''m with Stupid". :D

Arantor

Fair enough, I was just lamenting that I'm stuck with Incessantly Evil for a while yet.

Antechinus

Oh sure, I understand that is going to be the pits. At least you're getting paid for it though. Life's too short to waste it debugging IE for free.

I used to call it Infernal Themerooter.

Antechinus

Anyway, on a lighter and more interesting note, I've been playing with menus. Using display: none; on them is usually bad for a11y, unless you implement some other enhancements. No good for pure CSS drops. Nobody can find them if they aren't using eyesight and a mouse.

I twigged to something though. It's actually a really good idea for the hamburgered menus. Usually with something like the admin menu you'd want a skipnav thrown in to get past the humungous sequence of links. But if you use display: none; for the hamburgered menus only that's effectively a built-in skipnav. Anyone on a screen reader will still be fine, because they'll be notified of the checkbox trigger and its state, and will have the label read out to them. All they have to do is check or uncheck it when they want the menu, and otherwise they just go straight past.

Similar situation for someone like Crip. They can see when it hits focus on the trigger and select or not as they please. If they don't want the menu they just tap to the next link. Based on this, there would be a good arguments for having the menus permanently hamburgered on any res as an a11y measure.

Doesn't work with the standard "see it all the time" menu though, not if it's pure CSS, because then there's no way of triggering the change from display none to display block if you're not using eyesight and a mouse. So those are still better using left positioning, which is still easy to set up and perfectly reliable as long as you set your positioning in px rather than em. And skipnavs for those, of course.

Gwenwyfar

Quote from: Antechinus on September 18, 2019, 08:13:24 AM
Oh sure, I understand that is going to be the pits. At least you're getting paid for it though. Life's too short to waste it debugging IE for free.

I used to call it Infernal Themerooter.
I like to call it the party pooper. Everyone is having a party with nice functions and IE comes smear it's ****** all over it just to ruin a nice thing.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

I hate IE. Utterly loathe it. Although IE8 and IE9 weren't that bad for their day in that at least they implemented CSS2 properly, which was a big advance over 6 and 7. In fact they were better at it in some ways than browsers like Safari (the current Safari on iPhone is still unable to handle absolute positioning of pseudo elements). But they were still always woefully behind on some other things. And shipping IE11 with borked flexbox handling is just inexcusable.

Gwenwyfar

At least flexbox *works*, despite the borked handling. Grid is way worse. The one thing you most want it to do doesn't work, which is automatic columns/rows... it tosses everything into #1 and if you want things to go elsewhere you need to specify it... one by one.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

Might be better off using old school stuff then, if you have to support it. TBH I only threw some flexbox in this one because I realised it'd be handy for a few details. Don't actually need it. Not really. Nicer with it though.

Haven't played with grid yet.

Gwenwyfar

Exactly, unless you know the amount of items (and it isn't more than a couple), it pretty much makes it useless :(

Well for one simple use case, it makes anything with two (or more) side-by-side things with floats work nicely as they should, without all the pain floats usually are. Flex doesn't do this too well because you can't tell it to wrap at specific points.

display: grid; item-1: column 1; item-2: column 2, aand you're good to go.

I haven't played a lot with it yet either, but even those simple cases are already well worth it... if you get to ignore the party pooper :D
"It is impossible to communicate with one that does not wish to communicate"

Bloc

Why even bother making IE11 or IE9-8-7 work? The less they are supported the sooner they will die. :D I am not supporting in any kind of way, modern browsers do things the correct way.

I have used grids extensively for a while, and they are great. Doesn't solve all problems, but combine with flex here and there and you never need to float anything. Not for layout purposes at least.

Antechinus

Sure, but there's nothing wrong with floats where they will do the job. If something is as simple as declaring overflow on a parent or sibling and float on a child, then that's minimal coding and there's no real reason not to use it. Grid is probably great for more complex things, but unnecessarily verbose for simple things.

Table-cell is another good one that has some of the benefits of flex. For normal purposes the only thing it won't do is the equivalent of flex-wrap, but then inline-block will often be just as good for that. The more tricks we have up our sleeves, the better.

I have no intention of offering any support for IE 8 or 9, but I checked and user stats for IE11 are actually quite significant. The previous beta of this thing (b5) would have been fine with IE11 as that didn't use flex at all. I only threw flex on #upper_section because it was useful for a touch of detailing, not because it was necessary to make things work. Floats were working just fine there, and I could have achieved the same small improvement as flex by using display: table-cell; instead. Both are flexy and won't break layout, both have automatic RTL support, and both are easily made responsive by declaring display: block instead;.

The main reason I went with flex is because of this: need help moving stuff around...

Sticky post footers on short posts are something that has been requested by people for years, and I thought I could make it work with flex (not having tried flex at all before). The sticky footer tutorials I read didn't work for this application, which annoyed me, so I got in one of my determined moods and figured out how to make it work. :D Having used flex there I figured I might as well use it in the header too. But I could easily do the posts with table-cell or the original float, at the minor cost of not having sticky post footers on short posts, and IE11 would be fine with that.

The hamburger needs to be changed anyway because it's not just wonky in IE11. It's wonky in Safari/iShiz too. Which is getting a bit much to ignore (even though I'm pissed at Apple for not fixing longstanding bugs in Safari/iShiz).

Bloc

Haven't checked what the hamburger consist of..pure CSS? Testing such a thing right now, as opposed to image or icontype, which I used in Tsunami.

Flex is still a bit of a mystery to me..but thats prob. becasue I don't use it much. For the case you linked I would simply use a main grid on poster and post areas: grid-template-columns: 20rem 1fr; and then a height: 100% and grid-template-rows: 2rem 1fr auto; on the post area. Meaning the post "header"(title++) would have a set height of 2rem(could be auto too) and the footer takes what it needs(signature etc) since its auto. The remaining height will be available to the post, as in "1fr". Mind you, haven't tested this :D but just to show what it would mean using grid instead.

Read in several articles that if you stick with flex for horisontal/one direction layouts and grids for 2-dimensional, you should have the best of both worlds.

Antechinus

Yup, I've read the same comment about flex vs grid. But, y'know, I'm kinda old and lazy, so don't really want to learn grid this week :D

And yes, the hamburgers were pure CSS. Code was like this:

.sidebar_toggle {
position: relative;
display: block;
width: 30px;
height: 11px;
margin: 4px 0 6px;
overflow: hidden;
text-indent: 100%;
border-top: 5px solid #77899d;
border-bottom: 5px solid #77899d;
}
.sidebar_toggle::before {
position: absolute;
top: 3px;
left: 0;
width: 100%;
content: "";
border-top: 5px solid #77899d;
}


Which was fine in most browsers, AFAICT, but both Safari on iShiz and IE11 on W7 couldn't handle that presentation of the pseudo.

They both insisted on applying the top positioning as if the toggle had been declared as border-box (which it wasn't). They placed the top of the pseudo 3px down from the top of the top border, instead of 3px down from the the top of the parent, where it should be.

They also insisted on applying extra width to the pseudo, as if the parent had left and right borders (which it doesn't). So a bit stupid, them there browsers. :D

I'd go with an image if you're worried about either of them, and are determined to have a hamburger.

Gwenwyfar

Quote from: Antechinus on September 18, 2019, 04:36:01 PM
Sure, but there's nothing wrong with floats where they will do the job. If something is as simple as declaring overflow on a parent or sibling and float on a child, then that's minimal coding and there's no real reason not to use it. Grid is probably great for more complex things, but unnecessarily verbose for simple things.
Can you make a float identify the width of the content and only use that (while resizing every other row accordingly) and automatically resize everything else to fit? ;)

And if you're doing a pair in floats that's actually more verbose for the same end.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

I never said you could. I said floats were still fine for simple things.

Gwenwyfar

It's really not verbose for simple things though. And even if it were a bit, the annoyance of floats not ever matching the content (a random percent that is way above what you need, just to be sure it fits, while you leave a huge empty space in-between 99% of the time) is not nice at all.

Floats are still fine if you don't want to line anything up with them.

Also: I have a new theory: Antechinus is a bot. Or maybe that's an old theory.
* Gwenwyfar runs
"It is impossible to communicate with one that does not wish to communicate"

Bloc

Quote from: Antechinus on September 18, 2019, 06:11:43 PM
Yup, I've read the same comment about flex vs grid. But, y'know, I'm kinda old and lazy, so don't really want to learn grid this week :D

And yes, the hamburgers were pure CSS. Code was like this:

.sidebar_toggle {
position: relative;
display: block;
width: 30px;
height: 11px;
margin: 4px 0 6px;
overflow: hidden;
text-indent: 100%;
border-top: 5px solid #77899d;
border-bottom: 5px solid #77899d;
}
.sidebar_toggle::before {
position: absolute;
top: 3px;
left: 0;
width: 100%;
content: "";
border-top: 5px solid #77899d;
}


Which was fine in most browsers, AFAICT, but both Safari on iShiz and IE11 on W7 couldn't handle that presentation of the pseudo.

They both insisted on applying the top positioning as if the toggle had been declared as border-box (which it wasn't). They placed the top of the pseudo 3px down from the top of the top border, instead of 3px down from the the top of the parent, where it should be.

They also insisted on applying extra width to the pseudo, as if the parent had left and right borders (which it doesn't). So a bit stupid, them there browsers. :D

I'd go with an image if you're worried about either of them, and are determined to have a hamburger.

Would using a couple of nested spans instead of :after work better? Of course it means adding some markup code..but it will avoid the whole issue. I have had some diffculties getting :after and :before code to behave as expected, that is, act like a proper block element. Probably because its, you know, a part of whatever its :after or :before to.

Advertisement: