In my country (Brazil) it's illegal for doctors to require an appointment just to give a prescription. I see them doing it all the time anyway. It's sad.
Imagine you had an application that could do cool stuff.
But nobody knew what cool stuff it could do unless they digged up a webpage from 2006.
That's the modern web browser.
The lack of discoverability in modern UI design is reaching utterly ridiculous levels. And I firmly believe the lack of main menus and statusbars is to blame.
Firefox used to have this in its main menu. You could stumble across it. Now nobody knows it even exists and they think light/dark themes are a real alternative to the full spectrum of colors and designs we could have before (if only webmasters implemented it, which they never did (but anyways I blame browsers for this because very few people even knew they could add alternative stylesheets to their own websites and users had no notification that they could switch rendering the incredible feature pretty much useless all the time)). Then browsers look at their metrics and how nobody is using the feature they told nobody about and decide to stop supporting it because why would they support a feature nobody uses, right?
Reddit had entire subdomains to do what Firefox could do with a single click in the main menu.
There could be a key that if I press it Chrome sends me to the search box at the bottom of this page, and I will never know about it because when I click the search box there isn't a status bar unintrusively hinting to me "hey, heads up, you can press Ctrl+Alt+Shift+S to quickly go to this box ;)" and I don't think we'll ever get that back.
Firefox for Mac still has a menu bar and View > Page Style is still there.
Alternative Style Sheets are cool but the idea needs to be taken further In Firefox, if you browse full one page to another on the same site with the same sheets available, it still switches to the new page's default sheet. Imagine if sites could have a persistent theme picker using a browser UI!
On that note, I think the best app I've seen for button hotkey observability is Eagle (https://eagle.cool) (ironically built in Electron), which uses a simple setup of unobtrusive tooltips that give a label for the button you hover over and whatever hotkey triggers it.
You know, there used to be a standard on how shortcuts were presented, that the developer didn't even have to think about because it was handled by the GUI widgets, and didn't require mouse interaction (but worked with the mouse too).
I wish these CSS selector details were better documented somewhere. For example, if right to left is always true, then
.cls[attr="value"] is always slower than [attr="value"].cls
But I never see anybody using the second one.
I think it's also interesting that there is no way to do figcaption.cls inverted like .clsfigcaption.
It's strange that default CSS that comes with tools like Wordpress abuses pseudo-selectors as much. I think everyone just writes it off as "it's the CSS 3 way."
On interesting example is that some javascript libraries to highlight code syntax will use ancestor selectors like .highlighted .keyword, which in my mind is crazy. You are making the classes through javascript, you could just use a single glass, which is what Highlight.js does: its classes look like .hlts-kw.
One time I had to deal with layout in CSS being too slow. It was not because of webpage, but an electron app for android that needed to get the bounding rectangle a lot to place divs for its custom GUI elements on screen. Since changing the DOM/CSS changes the bounding rects, placing a div and then checking the bounding rect again was a performance cost. The solution ended up being caching the client rect once before updating the DOM to avoid the thrashing.
Anyway, great talk :D I hope more people become aware CSS isn't magic, nor a black box, so they can think twice before writing their selectors. Sometimes I see CSS code with superfluous nested ancestors (e.g. .wrapper .content .post-body img), and I think that happens because it really just works, but unfortunately it seems that mentally carries on after a developer stops being a beginner, because the CSS just keeps working anyway.
Per your example I wonder if CSS engine devs optimize for most common use like many JS engines do. For example JS `for` loops, `for (let i=maxVal;i--;)` should hypothetically perform better than `for (let i=0;i<=maxVal;i++)` but they are pretty much equal in modern interpreters.
I don't think it is any more a black box than JavaScript and the DOM, it just happens that most people don't take the effort to learn it that they spend on the other stuff, and unless those people are super geniuses I'm sure there are still parts to the technologies they have bothered to learn that surprise them or they are unsure about and would have to check from time to time.
I think it would be better to compare it to SQL. The RDBMS does a lot of stuff in the background with the query planner, but it's very easy to get information about implementation detail. It's not hard for someone who just writes SQL to learn how indexes make rows faster, how btree indexes work, and why using asc/desc in a multi-column index matters. With CSS you never get any of that, so I think it's a much blacker box than normal.
I've worked on both an RDBMS optimizer and a CSS engine, and while the comparison is interesting, it's also not quite right. In particular, you can write pretty crappy CSS and it will work quite alright, including in all major browsers. Database engines are not like that; there are more ways of doing everything, the bad choices are _really_ bad, and the heuristics much more prone to suddenly do really slow things based on reasonable queries. Most optimization differences between versions and engines are about constant factors and not radically different algorithms (although for some select topics, like invalidation, you may get burned). Even if you write a truly horrible CSS rule, it is unlikely to freeze your page for a minute in any current browser. This is not because browser engineers are more talented than RDBMS engineers, it's just a much simpler problem.
You're right in that there's less information out there for CSS engines (from flipping through slides on this talk, it looks like a great way to improve on that situation!), but there's just a lot more to _say_ about SQL performance. And a lot of what's being said about the latter is honestly pretty sketchy :-)
I cannot speak for Firefox or WebKit, but at least in Chromium, these are going to be pretty much identical. Both are going to be bucketed based on the class (i.e., would only be considered for an element with class="cls", based on a hash table lookup), and then the [attr="value"] would be checked the obvious way.
The reason why the right-to-left rule makes sense _between compounds in a complex selector_ (i.e., “the parts that are separated by a space”, for an imprecise term) is that this is the part that applies to the element you are computing style for right now. I.e., say that you have a rule like
.a.b span { color: whatever; }
This rule will apply to a <span> (the span is the “subject” of the rule) that has an .a.b element somewhere up higher in the tree. If you have made the rule specific enough that it rejects on the subject (say, you're computing style right now for a <h1>, not a <span>), you can skip the entire rule right away. (Most rules do, after all, not match most elements, so rejection is what you want to optimize for.) But once that “span” selector matches on some element, you need to walk the ancestor chain from that element, potentially every single ancestor, to verify that there's no parent that has both classes .a and .b, before you can reject the rule. So rejecting on the subject (save for :has(), which is a story in its own) needs to look at one element, rejecting on something non-subject is much worse. (The Bloom filter would stop early if you don't have at least something with .a and something with .b in your tree, a so-called “fast reject”, but it can't distinguish <div class="a"><div class="b"><span> from <div class="a b"><span>.)
The best thing for selector performance _by far_ is to write the subject so that most elements don't even see it, by means of getting it into the right hash table bucket. A selector like “#xyz” is going to be _so_ much faster than “#xyz *”. But of course, most sites are not really style bound; CSS performance is something you should probably look at after you have your HTTP and JavaScript issues under control.
No, I haven't. But I'm assuming it is based on the "right to left" concept while you are assuming it isn't based on browsers' ability to optimize this. The spec says nothing about it and I have never seen any documentation saying "this case will be optimized." And this is the problem with it, imho. Why would this be optimized but not .cls :has(.foo) .bar? Is :nth-child optimized? Should I do [attr]:nth-child or :nth-child:is([attr])? There are several ways to write the same complex selector and a lack of first-party guidelines about the best way to do it.
Edit: to illustrate my point better, it used to be that if you wanted to make a table with alternating row colors you just used a class on each row. Then :nth-child(odd) and :nth-child(even) came out and everyone was like "just use that instead! No more classes in every row!" And now we have .foo-table :nth-child(odd) > td because obviously there's a tbody/thead/tfoot between tr and table and nobody knows if you should do this or .foo-table > :is(thead, tfoot, tbody) > :nth-child(odd) > td or which one is faster or if you should just use .odd > td because HTML TABLES ARE THE REAL EVIL TABLES IN WEB HISTORY. CSS TABLES WERE SAINTS COMPARED TO THIS. Anyway, every browser has different optimizations, and I have 5 different ways to make a row color alternate. This is the problem. When we have actual complex styling that makes use of the most powerful CSS selectors, all common optimization for simple stuff fall apart. So why even use powerful CSS selectors when they have potential to be permanently slow on HTML code that you may not ever be able to change in the future?
I'm honestly just professing ignorance! Along with generally wondering about the state of CSS query optimizers, I think the two have the same specificity, which (in my very-incomplete mental model) makes me think that they're about the same amount of work to resolve.
One thing I wonder about CC is whether you have to include attribution and license in the same page the work is embedded. It's common sense that this would be the case, but in Wikipedia, for example, CC works don't actually have attribution in the page they're shown, you have to click on them to see the attribution.
I wish this was clarified. Like, why is Wikipedia allowed to do this? Is it because they're thumbnails?
Civilization is an artifact of thermodynamics, not an exception to it. All life, including civilized life, is about acquiring energy and creating order out of it, primarily by replicating. Money is just one face of that. Ads are about money, which is about energy, which fuels life. AI is being created by these same forces, so is likely to go the same way.
We might question the structural facets of the economy or the networking technology that made spam I mean ads a better investment than federated/distributed micropayments and reader-centric products. I would have kept using Facebook if they let me see the things my friends took the trouble to type in, rather than flooding me with stuff to sell more ads, and seeing the memes my friends like, which I already have too many cool memes, don't need yours.
The article is very interesting but am I the only one that feels weirded out by how articles like these are published on the web?
There's no author information besides "Editor at SurferToday" in the HTML metadata. I understand that some people may wish to publish anonymously, but I think if you used a pseudonym like John Surfer it would at least feel like an actual person wrote it in our current era of AI-generated articles.
There's no date of publication. Of course the page itself may change with any CSS/template change and one of the great things of URLs is that you can modify the article with more recent information, still, having a date is kind of important.
There is no attribution. So is this an article of someone who interviewed her personally or is it a transcription of the video? The video is not by Surfer Today, it's from a channel called "Imagining the Digital Future Center" with 900 subscribers, but the actual brand on the video is called Internet Hall of Fame.
I've seen so many articles like this and it always feels so strange to me for some reason.
According to every article on social media every platform is dying simultaneously: Facebook is dying, Twitter is dying, TikTok is dying. Is Reddit dying? Probably in the next few days as it IPOs!
Tumblr has been dying for a whole decade and I bet most people don't even know LiveJournal still exists.
One thing I find interesting about TikTok (and potentially modern algorithm-driven social medias) is the region-locking. Growing up I was fascinated by the fact I could force people across the ocean to read my broken English, and that was basically how I learned English. Nowadays a lot of English vocabulary has invaded my language in gaming and tech circles, while apps like TikTok have their recommendation algorithms designed with strong regional bias and no way of opting out of that apparently. It's hard for me to tell if TikTok is really the way Americans say it is when, if I try to use TikTok, what I will end up seeing will be in literally a different language.
I hope this doesn't catch on. It makes the world wide web feel a lot less world wide.
Not OP, but when searching for files, spelling something wrong, or using the wrong synonym is a big problem. We're just used to computers being inflexible.
It sounds like you want... folders. Genuinely. Or a tag system. Or some other metadata.
Like, take this query for example: show me the folder(s), where my old University projects are stored. How would an AI, however powerful, know what are "university projects" if they aren't tagged as such? And if they were, why is the AI necessary?
One approach I've tried before is: if you have a folder /projects/ with so many project folders in it that you don't even know anymore what is what anymore, you just create a text file called /projects/index.txt and write the name of each folder in there and what it's for, so you don't forget later.
Well, but they ain't tagged or sorted. And an AI could know, because of the context. If it knew what year I studied and what courses etc then this information would be enough to separate content. But I am aware, that this tech ain't there yet.
Unrelated, but is there something like Bonzi Buddy for linux? Not the spyware part, just the friendly looking clippy-esque character that can tell you about your new e-mails, weather, or whatever? I kind of wish I had something like that.
