> "In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability."
Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel.
FWIW, I think it is possible to make exception-like error handling work. A lot of systems code has infrastructure that looks like an exception handling framework if you squint.
There are two main limitations. Currently, the compiler has no idea what can be safely unwound. You could likely annotate objects to provide this information. Second, there is currently no way to tell the compiler what to do with an object in the call stack may not be unwound safely.
A lot of error handling code in C++ systems code essentially provides this but C++ exceptions can't use any of this information so it is applied manually.
Wonderful. Allow an "unmonitored" extension from a random stranger on the Internet have access to "all data for all websites" just to support an image format for which Mozilla should have long built in native support...
That's not the reason, but the excuse. The reason Firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die.
Also the parent comment was about that you really shouldn't just let a random Russian guy run any javascript on any website you visit, that's stupid.
Also also, am I missing something, or Firefox extensions are broken, there is no way to limit an extension to websites (allow or disallow), or even just to check the source code of an extension?
The link I posted shows that Jpeg-XL will come to Firefox, and that that same Google is the one making that possible by writing a secure implementation.
> That's not the reason, but the excuse. The reason firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die.
So what, you think they were just lying when they said that they'll ship JXL when it has a Rust implementation? You think Mozilla devs were just bluffing when they were working directly with the JXL devs over the last year to make sure everything would work right?
Firefox Nightly v149 has added experimental support via Settings > Firefox Labs:
Webpage Display
Media: JPEG XL
With this feature enabled, Nightly supports the JPEG XL (JXL) format. This is an enhanced image file format that supports lossless transition from traditional JPEG files. See bug 1539075 for more details.
I'm not a fan of these custom elements. Unless you do something really interactive, dynamic and reusable (an element with complex behavior), I don't think it's worth to use them. The SEO / accessibility becomes more challenging. Also, worth to noting, web components require JS, so they are not pure "CSS" web components. Web components are useful for isolation, when used with shadow DOM.
Using custom elements as the article suggests doesn't require JavaScript, so they are "pure" HTML and CSS (though whether they count as "web components" is up to you). More to the point, all of the technologies that the term "web components" includes — custom elements, <template> tags, shadow DOM — can be used without JavaScript.
<div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
My point is that defining a complex behavior for a custom tag is not possible without js.
For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>. I mean you can use something like <host-element> (html5 allows that), but it will just be an inline element, almost like <span>, but without semantics. It's not a full web component.
> "shadow DOM — can be used without JavaScript"
Yes, shadow DOM can be used without JS, but I was talking about web components.
> "I'm not sure what SEO and accessibility challenges custom elements would introduce?"
If you replace standard elements (such as 'p', 'a', 'button', etc) with custom ones it can hurt SEO and accessibility. There are very few reasons to use custom element names and attributes if they are not full web components.
What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
Right, but the article isn't talking about defining complex behavior; it's talking about using custom element and attribute names as hooks for CSS. I don't think it's suggesting they be used in place of semantically meaningful elements like <p> or <button>, either; it's saying that you can use them instead of class names or data attributes.
> My point is that defining a complex behavior for a custom tag is not possible without js.
Not necessarily. CSS alone can allow for a lot of useful complex behaviour. You can customise how something renders (or not) or is interactable based on parent elements, sibling elements, css variables, or other state.
> For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>.
Actually you can, using <template> and <slot> elements. No JS required.
> What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
This is really two questions:
1. What's the point of using <link-button> instead of a link-button class?
2. What's the point of using a size="large" attribute instead of a "large" class?
To answer 1:
Classes end up being misused compared to custom elements. When you make a custom element (in this example "<link-button>"), you're explicitly saying this is a <link-button>. It is not a <blockquote class="link-button">, it is not a <form class="link-button> and it is most certainly not a <picture class="link-button>. It is a <link-button>.
Also with what was stated above, you can use <link-button> to declare default internal elements (using <template> and <slot>) without using js to say what should be inside a link-button.
To answer 2:
Because you should make impossible states impossible (or at the very least present impossible states as impossible). Size is a state, it could be small, large or any other list of predefined values. If you use classes then you can end up with something like <link-element class="small large">. If you use attributes, you end up with something like <link-button size="small"> or <link-button size="large"> but not <link-button size="small" size="large"> (since that's illegal in html and duplicated attributes are ignored).
Plus you're already using attributes for interactive aria roles (or you should be).
You use css to style the menu being open or not with: `#navbar-toggle[aria-expanded=true] ~ #navbar-menu` and not something inaccessible like: `.navbar-menu.navbar-menu-open`.
jQuery was very useful when many features were missing or not consistent/standardized between browsers. Nowadays, JS / DOM API is very rich, mature and standardized. So, jQuery is not as necessary as it was before.
Yes, sometimes the vanilla JS analogs are not the most elegant, but the vast majority are not terribly complicated either.
IMHO, another advantage of vanilla JS (aside from saving ~30KB) is potentially easier debugging. For example, I could find / debug the event listeners using the dev tools more easily when they were implemented via vanilla JS, since for complicated event listeners I had to step through a lot of jQuery code.
Please never do version checks. Test for the existence of the exact features/methods you need instead - this is trivial in JS: if(Temporal)
Checking against version numbers helps cement existing browser monopolies, makes it difficult for new browsers to view websites (even if the browser correctly implements every feature), and encourages everyone to spoof version numbers / browser names which leads to them becoming a less and less useful signal. See any browser’s User-Agent string for an example of this
Maybe you are not required to close, browsers are ridiculously tolerant to html mistakes. But do you think it would be easy to maintain that HTML file and not accidentally include something in that unclosed tag? I often format with indentation in order to work with the file comfortably.
Also it annoys me when people are still closing tags with '/>'.
Did you read the article? An unclosed <p> is not a mistake that the browser is tolerating, it's 100% well-defined html5 according to spec.
If your tooling can't handle the language as defined, maybe the problem is with the tooling.
C is fast and maybe has predictable performance, but, for example, strcmp(), strlen(), strncmp() are not as fast (and also secure) as C++ std::string analogs, unless you don't help a bit by storing the string lengths.
Some AI videos are harder and harder to distinguish from real ones. This terrifies me, since it's not that obvious AI fake that some average grandmother would fall for. In short videos, it is more difficult to distinguish AI fakes from real ones, because there is less time for some error or inconsistency to appear.
Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel.
reply