When is eval justified? In pragmatic terms, when you say it is. If it's your program and you're the programmer, you set the parameters.

Moral Mazes

We assume that the people who are in the bestposition to accurately assess the degree of bullshit in their organizations arethe people who work there; therefore, we set out to develop a reliable andvalid scale to measure employees’ perceptions of the extent to which bullshitexists in their organizations. Next, we turn to how we developed theOrganizational Bullshit Perception Scale (OBPS).

Applying the logic of Petrocelli (2018), leaders will be driven to bull-shit when the social and professional expectations to have an opinion are high,and when they expect to get away with it. These two conditions are subject tohow (un)knowledgeable their audience is. Similarly, if leaders exhibit high levelsof overconfidence, and believe they are popular amongst their peers, this willmake them likely to engage in more bullshit-related behavior (Jerrim et al.,2019).

ll respondents assessed their overallperceived bullshit in their organization on a simple 4-point scale ranging from 1indicating ‘there is no bullshit in our organization’, through 2 indicating ‘there isa little bullshit in our organization’, through 3 indicating ‘there is some bullshitin our organization’ to 4 indicating ‘there is a lot of bullshit in our organization’.The overall perceived bullshit in the organization was regressed on the threeperceived bullshit scale factors. The R2value of 0.36 indicates convergencebetween the OBPS and the overall bullshit perception measure, withregardfor truthandthe bossbeing significant predictors of the overall bullshitperception.

The second dimension,the boss, confirms that employees believe that theirsuperiors are key players in the dissemination of bullshit. Bullshit aims only toserve an immediate end – whether to puff up one’s reputation or to advancetheir point of view or argument (Gibson, 2011). Further, employees are likely tohave to take action based on any bullshit communicated by their bosses. As aresult, employees are likely to be acutely aware when their superiors use bullshitto advance their own self-interests.

The final dimension,bullshit language,considers some of the commonly usedtypes of language employed by bullshitters, namely the excessive use of acro-nyms and jargon. The finding that employees perceive that the excessive use ofsuch language is a form of bullshit confirms that they are not oblivious to its usein the workplace. They may share the opinion of McCarthy et al. (2020, p. 258),who argued that “if a statement is riddled with meaningless language, acronyms,buzzwords, and jargon, then it is likely to be bullshit.” It is possible that theexcessive use of acronyms and jargon may occur to employees as an exclusion-ary mechanism in the workplace, whereby those unfamiliar with the terminologymay not be able to meaningfully contribute to the conversation or voice theirconcerns.

There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.

The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.

The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.

the notion that any given component should be in charge of its own thing, and not do something outside of itself. I.e., loosely coupled components in a sandbox, not tightly coupled to something outside of its own scope.

Personally, I think class is too blunt an instrument — it breaks encapsulation, allowing component consumers to change styles that they probably shouldn't, while also denying them a predictable interface for targeting individual styles, or setting theme properties globally

...but ultimately the component itself has control over what is exposed, and can specify its own fallback values using normal CSS custom property syntax:

A component should be in complete control of itself. Not only should a component's styles not leak out but other component's style should never leak in. Consider this 'Encapsulation part 2' if you will. When writing a component, you have certain guarantees that not only will the styles you write be contained within the component, but nothing from the outside should affect you either. You have a certain confidence that if it works in isolation, then it will continue to work when embedded within a complex application.