Class names are "global mutable state". You can declare a class in one file, and other file can 'mutate' it.

There are solutions/workarounds to this. First following a convention like BEM, then enforcing that at build time (CSS Modules), and now (potentially, i haven't checked in with it) the language supports @scope.

> Class names are "global mutable state". You can declare a class in one file, and other file can 'mutate' it.

You can do this in TypeScript and Ruby too.

Class names and other selectors are more like a query language, because they don't do anything if you don't have an html element with that class or matching the selector.

on edit: a downvote on that, really. because I don't think class names are anything like a variable!

One of the main issues with global variables is their unlimited scope, which means any part of the program can modify them. That's what he's saying.

Give your element a class. Now show me the CSS that styles it. Good luck because it can be literally anywhere.

This doesn't make CSS classes mutable global state. CSS rules are applied according to specificity of selectors. You could maybe say that the overall style of a page is mutable state, but not the CSS classes themselves. A CSS class is assigned and that's it. Unless JS is involved, it also doesn't disappear or toggle.

I'm aware of browser defaults and how they work, yes. Just because someone does not agree with you does not make them uneducated.

Frankly I tend to find analogies not very useful, I don't think my analogy of CSS as a db is very good, but as bad as it is I feel it makes some sense as opposed to talk about classes as if they were global mutable variables.

I will take my analogy slightly farther.

I will say the browser ships with a DB system called CSS, and a toy DB called BrowserDefaults implemented in CSS, the same way MS Access used to ship with Northwind. The especially sucky thing about this system is that when you want to create your own DB you have to extend BrowserDefaults. This is why a lot of specific DBs have what are called resets that basically delete all of the BrowserDefaults setup so it is not messing with your DB.

The browser also ships with two languages with the ability to query CSS, one is JavaScript and that is a pretty straightforward language it can read and write to CSS using an API called the CSSOM. The other query language is a tree based query language called HTML (actually there is also another tree based language called XML in there but nobody talks about that anymore, let's just say it works almost the same as HTML only when you use it, it automatically clears all the data out of the base BrowserDefaults DB)

(We can see what I mean about analogies suck right about here)

This tree based query language is crazy as shit! Because it is not just a query language but also has some weird transformational capabilities.

And also the thing that is weird is that the HTML query language can be changed by the JavaScript language!

Let's look at an example

Let's suppose we have a tree structure like this

<div class="one"></div>

<div class="two"></div>

and the JavaScript holds a tree fragment <span class="myspan">text</span>

and the CSS says

.myspan { color: green; } .one span { color: red }

.two span { color: black }

the JavaScript reading that fragment css properties will see that "color" = "green"

but placing it inside of the parts of the HTML tree gives different values for the color property. Some people will mistakenly claim at this point that the is mutation of the global state but that is obviously incorrect. The CSS state has not been mutated at all, what the HTML query has done essentially is run a transformation and output an object, the CSS state remains unchanged because JavaScript can use the CSSOM to query what the data in the myspan class is.

JavaScript can mutate the value of the CSS classes, but HTML cannot. HTML essentially copies all the classes, runs a transformation, and outputs the result.

This is actually a pretty interesting situation, I don't feel that there is any similar architecture anywhere. I don't feel it really fits with DSSL or Latex (because of how JavaScript works with HTML)

Now although I don't feel that I have ever really had the problems that other people of undoubtedly superior programming ability seem to have with this, I can see how this unique and somewhat accidentally arrived at architecture can be irritating to people.

Note - when I say I don't have any problems I mean sure, I can create bugs with this, I can find bugs impacting me with this, but I've never really had long running hard to resolve bugs due to CSS/HTML. Bugs that are generally hard to resolve I find are in the JS stack.

Going back to the browser defaults thing - again not really a good example of either of our analogies, more an example of how every programming language has its idiosyncratic and stupid things you just have to learn about it and keep in mind or they will bite you on the ass.

on edit: obviously I am not making any claims as to internal implementations in browsers and how they do it, I am just discussing the external experience of these languages working together and how to think about them.

I'll just note here that there are some obvious points about CSS custom properties here that might seem more like mutating state, although there it is not global state being mutated, but I can't really address all that here, as it is midnight and I need to get up early.

also let us suppose I have the following

.one span {color: red}

.one span {color: purple}

inside of a CSS file.

Again I don't think I could consider that as mutating state.

This is mutating state

let color = "red";

if (x} { color = "purple"; }

because it mutates the variable value at run time based on something else.

The variable at different parts of the program have different values.

If you read .one span with the CSSOM in the above example it will always return color: purple.

That is not a mutated value, that is poorly written code that has been compiled down.

again here, in case someone wants to argue that the css itself has mutated the state, no it hasn't.

JS with CSSOM can read what the value .myspan, .one span and .two span all are.

because this is the point where CSS breaks down as a db holding properties, it is here that it is instructions for the HTML language on how it is to run transformations.

To be fair, most of us developers are out there building what amounts to over-engineered Drupal themes.

Theoretically the xss could become a non-self xss if the conversation is stored and replayed back and that application has the xss vulnerability e.g. if the conversation is forwarded to a live agent.

A lot of unproven Ifs there though.

(Should have been [2012] but ran out of characters)

FYI - no need to prefix your custom header with X- !

> Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.

https://datatracker.ietf.org/doc/html/rfc6648

What supposed problems does it cause in practice?

If a nonstandard X header becomes widely used and then adopted as the standard, there is a surprisingly lengthy and difficult transition period to the new name.

Both clients and servers have to support both the X name and the regular name for decades, and servers have to deal with questions like "What if both are present but different?"

If both are present but different the unprefixed version should be favoured. That seems uncontroversial & not complex to implement.

Sending two headers seems fine in most cases.

These are certainly downsides but hardly dealbreakers. On the other side, not prefixing has its own pros & cons, which seem more difficult to work around:

1. The obvious clash issue. If two pieces of software implement entirely different X-Value: headers, the standardisation effort clarifies the signal in the form of an unprefixed version. If both competing software applications start out unprefixed, the signal will always be ambiguous.

2. Implementation changes. If any lessons are learnt during initial use of a prefixed header, these can be applied by standardising on a slightly improved unprefixed version.

> If both are present but different the unprefixed version should be favoured. That seems uncontroversial & not complex to implement.

oops, you just enabled smuggling where there's a mismatch between what a proxy/firewall/etc supports and what an internal service supports.

    X-Do-Evil: true
    Do-Evil: false

Smuggling is a general concern whenever two headers have functionality that interact - it's not specific to prefix masking & given how implementation-based it is, it's not even likely to occur to any arbitrary prefix mask.

That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)

But isn't the problem with X- headers that if they ever get standardised, they necessarily create this smuggling issue? Whereas if you start with an unprefixed header and standardise it under the same name, you avoid this issue.

You could also solve the problem by standardising the header with the X- prefix, but this is more confusing to users and violates the idea that X- always means "not standardised", at which point the prefix is useless anyway.

> That's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)

But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!

It might not have but it's a lot more likely that it would.

iPhone getting USB-C was inevitable. I mean, their iPads were USB-C for years before any EU law.

The best the EU can say is that the law moved up the inevitable a year or two.

eligibilityd

https://theapplewiki.com/wiki/Eligibility

The Firefox/Chromium extension APIs are just javascript. Orion reimplements them with the features that Webkit/JavascriptCore provides.

Oh alright, thanks for telling.

Is there no way that something can be done for PWA abilities? What's stopping PWA on ios, I don't really follow? I would love it if you can clear up my confusion regarding it.

What actually does “PWA” mean? What APIs or functionality is iOS lacking?

what do you mean? 1Blocker blocks network requests.

It might not block everything to the degree of uBlock Origin, but it does block network requests.

The stuff that makes it through is what I mean.

Is Chrome's PWA support on Android a massive glow to Android Play Store's bottom line?

I don't buy this line, that Safari is intentionally hobbled to prop up the App Store. What's iOS missing for PWA's to be a viable money-maker for companies? Surely there so much money on the line that we would see companies using them. What does Match.com's portfolio of dating apps need to be viable as websites instead?

In reality, when you actually pay attention to Apple's software engineering practices you realise how incredibly cheap and stingy they are. All the apps are so under funded and under developed. Bugs are introduced all over their native platforms all the time and never fixed.

> Is Chrome's PWA support on Android a massive glow to Android Play Store's bottom line?

Probably, but Android allows side-loading. iOS does not.

> What's iOS missing for PWA's to be a viable money-maker for companies?

Brace yourself.

1. Notifications are hobbled. This is HUGE. Silent pushes, rich notifications, NSE, reliable badge counts, and reliable delivery. This is made worse by:

2. Hobbled background priority. PWAs are aggressively suspended and killed. No long running processes. No guarantee of process execution. IndexedDB and in-memory state may be wiped at any time.

3. PWAs can’t access most system frameworks. Bluetooth (CoreBluetooth). NFC (Core NFC). Background location tracking. HealthKit. HomeKit. CallKit / VoIP. Siri Shortcuts / App Intents. AirDrop. Apple Pay (full API). CarPlay. System share extensions.

4. No access to native rendering pipelines. Performance is severely limited.

5. PWAs have unstable, purgeable memory. No persistent file storage.

6. Limited UX and lifecycle control. No termination callbacks. No suspend notifications. Reloaded arbitrarily. Back/forward gestures conflict with browser.

7. No access to native UI components like FaceID, native text fields, drag and drop across apps, context menus, and haptic feedback.

Apple has done everything they possibly can to ensure PWAs are broken on iOS.