For example, see first post in Excellent sentences. However, if the quote includes a trailing blank line, it doesn't seem to happen, as in a later post in the same thread.
BTW, I like the new quote boxes, much easier to read.
For example, see first post in Excellent sentences. However, if the quote includes a trailing blank line, it doesn't seem to happen, as in a later post in the same thread.
BTW, I like the new quote boxes, much easier to read.
BTW, I like the new quote boxes, much easier to read.
I was still tweaking the code and CSS while you posted. Reload the page with shift-reload to see the final version. You might not like as much.
But now it's consistent.
It still has the font size changes, going from a serif font above the quote to a sans font, smaller, below - looks like it's the same font as used in the quote box.
Reload the page with shift-reload to see the final version.
I'll have to wait for something I haven't seen before to get the full effect, because of the 'viewed-shading'.
ETA - The post-quote font changes now seem to be fixed - are you still fiddling?
The post-quote font changes now seem to be fixed - are you still fiddling?
Nope, this is the final version.
I was fiddling because of the unintended font change after a quote box. That's now fixed.
On my way, I fiddled with dimensions and padding of a quote box.
Did I ever say that I hate working with CSS?
If not: I hate working with CSS.
Did I ever say that I hate working CSS?
don't know anyone who likes working with them.
Did I ever say that I hate working with CSS?
don't know anyone who likes working with them.
CSS is great when it works as intended, but it's maddening when trying to troubleshoot why something unintended is happening.
Especially when you track it down to a duplicate definition three sheets up a four sheet cascade.
Especially when you track it down to a duplicate definition three sheets up a four sheet cascade.
that's why I avoid cascading sheets and have the code in just one sheet that's called or in the base file if it's a simple file set.
that's why I avoid cascading sheets and have the code in just one sheet that's called or in the base file if it's a simple file set.
I prefer using a single file for each project but I split it in two because I separate the colors for theming. Not ideal but it works. The var definitions for the colors only need to be in the color-css so it keeps the other one cleaner. Might merge them again when I'm done fiddling with it.
I prefer using a single file for each project but I split it in two because I separate the colors for theming.
For projects other than SOL's engine (which has many separate stylesheets), splitting off the colours helps in the auto-dark-mode thing.
For projects other than SOL's engine (which has many separate stylesheets), splitting off the colours helps in the auto-dark-mode thing.
I didn't know it was convenient for the auto-dark-mode thing. I do it mostly for my own convenience because I prefer a permanent dark mode myself, when available, so it's obvious I want a dark mode in the projects I create.
I didn't know it was convenient for the auto-dark-mode thing.
When you have the color statements split off, you can use something like:
various CSS statements excluding color ones on top, then:
@media (prefers-color-scheme: light) {
color statements for normal mode;
}
@media (prefers-color-scheme: dark) {
color statements for dark mode;
}
When you have the color statements split off, you can use something like:
Thanks, I'll do some research on the prefers-color-scheme, looks interesting. I'm originally not a HTML/CSS/JS programmer so everything is self-tought by looking up what I need and implementing it using my professional programming knowledge. Not easy since I'm used to object oriented programming. I'm currently doing the same with PHP which has fortunately made a few steps towards object oriented programming.
Not easy since I'm used to object oriented programming.
I really think schools screwed up going so entirely into OOP. Yes, there are instances (especially simulations) where object orientation can drastically simplify program structure. However, it isn't universal. Sometimes logic programming, or procedural programming, or functional programming are more useful. Focusing on one approach and teaching students to shoehorn everything into one approach is simply flawed.
I really think schools screwed up going so entirely into OOP. Yes, there are instances (especially simulations) where object orientation can drastically simplify program structure. However, it isn't universal. Sometimes logic programming, or procedural programming, or functional programming are more useful. Focusing on one approach and teaching students to shoehorn everything into one approach is simply flawed.
I don't think you understand the concept of object oriented programming. Nothing in that concept withholds you from logic or procedural programming. It's about how you can logically organize the parts of your program, not about the way you let the logic flow.
Not really.
OOP is just (in most applications) functional programming (such as used in C) with the exception that complex data types are all treated as references, and there are references to functions which deal with the data contained in the type attached. And yes, in some cases this tends to be very useful. Performing mental gymnastics to consider interaction with the user as something requiring 'objects' rather than simple I/O, for example, leads to programmers not being able to think outside a quite artificial paradigm for a number of things.
Performing mental gymnastics to consider interaction with the user as something requiring 'objects' rather than simple I/O, for example, ...
That's (UI) design, not actual programming. A whole different field.
... leads to programmers not being able to think outside a quite artificial paradigm for a number of things.
I wonder where you get the idea that programming using OOP leads to not being able to think outside the box. The two have nothing to do with each other. And if they touch in some convoluted way of thinking I would guess that OOP supports programming an outside of the box idea, not bothering it.
not being able to think outside the box
I believe all SOL readers can think. Almost none of them are inside a box. So all of them can think outside a box. Even if they don't program computers.
Almost none of them are inside a box.
Actually, probably almost all of us ARE in a box. I'm right now sitting inside a box made of plaster, lath, and wood.
Actually, probably almost all of us ARE in a box.
And many would like to be in a different box, of course...
And many would like to be in a different box, of course...
When we're all vaccinated and covid is under control, they'll be able to see their girlfriends again instead of having to make do with the wife ;-)
AJ
I'm right now sitting inside a box made of plaster, lath, and wood.
You drive a Trabant? Actually they're quite trendy in a sort of retro-chic way. But those emissions... :-(
AJ
I wonder where you get the idea that programming using OOP leads to not being able to think outside the box.
If you can't code without being constrained to using 'objects', that's a problem.
If you can't code without being constrained to using 'objects', that's a problem.
OOP is good for some applications but rubbish for others. Its rise to ascendancy is mystifying.
AJ
OOP is good for some applications but rubbish for others. Its rise to ascendancy is mystifying.
In simple terms an object is a data block with optional logical functionality for that block. Such constructs are used in almost every program. The extreme control you have and the ease of use makes it's ascendancy anything but mystifying.
OOP is good for some applications but rubbish for others. Its rise to ascendancy is mystifying.
AJ
Not really. Programming fads pop up regularly. The oddity is that the OOP thing has stuck around so long.
The oddity is that the OOP thing has stuck around so long.
OOP has the biggest cachet on a CV so developers demand it, even when an alternative would be better for the application. I think that's one of the reasons so many big projects fail, trying to use an inappropriate development methodology.
AJ
If you can't code without being constrained to using 'objects', that's a problem.
It's a 'toolbox' you can use or not, nothing constraining about that. The beauty is you can use it for parts in a program where convenient and other techniques for the rest. That is usually the case.