The thing is, when you are doing CSS properly, you will "anchor" your selectors appropriately. What I mean is the following: Ltes say you got some "component" or whatever you want to call it, and have a button in it, that is special in some way. Of course you are not gonna write "button a {someproperty: specialvalue}". You should be writing the selector as specific for that component in this case, for example "my-special-component button a {...}". If the design is implemented thoughtfully, then most of the problems people claim to have with CSS are simply non-existent.
Like "side-effect" you mention. That can only happen, if the design is implemented reusing parts of other design definitions, where they are not meant to be reused. Any other side effect would be intentional. For example button text color and paragraph text color. If one wants them both to change, when one of them is changed, then one reuses the style definition, but probably in most cases one does not, and therefore has separate definitions and therefore has no silly side effects, even after a few months not looking at the project.
yeah i'm just tired of making the same argument over and over. for what it's worth i've been doing CSS "properly" since the time when that site was a thing.
back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component.
the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.
so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components.
tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.
Or you can just just ".special-component .button" selector adapting the selector to be more specific as needed. Most code reuse in CSS is bad, because they break when the design changes. You don't DRY just because the code are the same.
yeah and when you do that for 100s of components i'd rather just see a utility class on the button itself vs hunting down its meaning in the related section of the component.
this is exactly the shit i was annoyed by when scaling, having to scope a .my-component-X section for literally every component and then grokking it later. you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.
now maybe you say name it better or more semantically? congrats you recreated BEM lol. literally all the arguments used against it are purists for purity sake or thinking people haven't gone through this same thought exercise.
just use whatever is best for the task. i still use css the "traditional" way.
Why the hyperbolic about 100s of components? Because if that exists somewhere, then it's just plain bad design to me.
Let's say you writing templates for a website and you have a partial named "main-navbar", it has a search input field that looks like the other input, but needs some alteration. Are you going to name all these alteration like "margin-x-2px", "font-small". Or just add a new style block with ".main-navbar .search-input" as the selector.
> you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.
Why are you hunting it down? If I need to find the styles that are applied to an element, I just open the web inspector. More often than not, from bottom to top, it's the reset style, the component style, the variant style, and the styles derived from its relation with its parent and siblings.
I would add, that usually also I would not hunt things down, because I put styling for a navigation into a stylesheet file called "navigation.css". Not much hunting to do there. Sounds crazy, but actually works.
every page in our app is a "component" which could have many sub components, some reused. i think it's actually very common in large scale apps so maybe we're not even starting on the same foot.
would you not consider opening the web inspector "hunting down" when i can just understand the full thing just by looking at the element itself? to your example, let's say now you want to put your search bar next to another item, but that item requires that there be 4rem right margin. Then you put your search bar next to another item in another component that requires 8rem top margin. this starts breaking down at scale. in the past we would just inline the margin value. eventually this moved to basic utility classes which evolved into tailwind.
and with your code, you've just proved my point. i find tailwind overly verbose (necessary evil), but honestly i don't even need to open the "inspector" to understand how this will look. you can give me that 12 months from now and i can understand exactly what it is in 10 seconds. with "alert" i have to referencing something else. and this is just a handful of lines, imagine if your component is larger than that. it's also a bad example because i will just eventually roll the styles for "alert" into its own class if it makes sense. get the best of both worlds.
again, i challenge you to just consider that a lot of other people as smart as you have thought through these issues and made the according trade-offs. the example you're giving is just way too simplistic and pretty much like every example someone gives in these threads.
> the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.
At that point the design department of your business has failed its job. Case closed. If everything is slightly varied, then there is no coherent design. Not even my backend-dev developed "designs" are that bad.
> tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
I also care about what soup I deliver to any visiting browser. So I care about not having a thousand repeated inline styles, that make it harder to write user CSS for example. Visitors of my site can very easily adapt the styling, by simply changing the styling of 1 class or even 1 CSS variable that I defined in a theme.css.
But you are also making a general mistake. You are letting perfect be the enemy of good. Even if one only succeeds 90% at what I described, this is still great and simple to maintain in 90% of the cases. I doubt tailwind is a big win over that.
you know, maybe understand actual frontend dev issues more deeply before arguing against toolsets you are unfamiliar with. none of your suggestions/generalizations actually address my actual real world issues and rather they are non-issues in modern dev.
the type of apps i'm talking about aren't just a "theme.css", so whatever mythical large app you're talking about that adheres to this rigid css standard while being easy to maintain i'm ready to be proven wrong lol.
On the other hand CSS is very capable these days and many designs, that actually are not flying air castles and take the medium into account, can be implemented flawlessly using only CSS and HTML.
Agreed. A lot of modern web design problems come from trying to force a medium to do something it was never meant for. If you work with the grain of HTML and CSS instead of against it, you can still build really flexible and beautiful layouts without needing to hack the DOM or pile on JS. zen garden was a reminder of that and it still holds up.
I rather think FB was always part of the problem for most. Having 200 FB friends, but not a single one to go out with and meet them, that's not a healthy social life.
Some people might have used FB in a different way, but they would have been fine without FB existing in the first place.
I think you are on to something there. Already doing more than most people, I guess. Most people wouldn't even make the effort of going to the neighbors and saying hello.
I often ask myself, why some people, who are closest to what I would call friends, do not initiate any shared activity at all and how they can always be "busy". Do they not realize, that they are squandering the time they could have with friends?
Is there a way to switch to numerical multiplicities/cardinalities? I always find the circle and feet notation not very readable and also less precise in some cases.
My personal go-to tool for this kind of diagram may remain yEd graph editor for now.
Doesn't seem to work on mobile at all. Tables that I add are not shown in the diagram. The diagram area is not visible unless I scroll sideways.I cannot scroll sideways, unless I request desktop site and scroll there. But I still don't see any entities in the diagram. When I use the buttons to add tables in the diagram, they also do not show up in the grid, but only on the left in the textual list of tables. Seems like a complete non-functional tool on mobile.
Usually I wouldn't care too much about a tool like this running on mobile, but not at a PC right now, so that's all I can give feedback about.
Years ago I tried adding a weblink directing to a community, to an article about a game, where there were already weblinks to other communities, which were in no way any more official or proper than the community I linked to, but this edit never made it into the page, because someone played gatekeeper there, probably a person of the already linked communities. Since then I don't even bother editing wiki any longer. It is gatekeeping by people with their own agenda. What else I read about edit wars did not inspire confidence either.
If they want to do their job well, how about adding some thinking into the mix, for good measure? Good would also be,if they actually knew what they are talking about, before trying to tell the engineers what to do.
> If they want to do their job well, how about adding some thinking into the mix, for good measure?
That’s what the conversation I shared is demonstrating ;)
> Good would also be,if they actually knew what they are talking about, before trying to tell the engineers what to do.
Often the people enduring the rules aren’t supposed to be security specialists. Because you’ll have your SMEs (subject matter experts) and your stockholders. The stakeholders will typically be project managers or senior management (for example) who have different skill sets and priorities to the SMEs.
The problem is that when it comes to security, it’s a complicated field where caution is better than lack of caution. So if a particular project does call on following enhanced secret practices, it becomes a ripe field for snake oil salesman.
Or to put it another way: no company would get sued for following security theatre but they are held accountable if there is a breach due to not following security best practices.
So often it doesn’t matter how logical and sensible the counter argument is, it’s automatically a losing argument
They don't want to do their job well. They want to look like they're doing their job well, to people who don't know how to do the job and whose metrics are completely divorced from actual merit.
reply