I hadn't paid much attention to their $5 deal, so I looked it up out of curiosity.
It's the same food but in smaller portions, which sounds more appealing to me. I wish more places had appropriately sized & priced portions of food instead of "here's 2500 calories and a drink with enough sugar to give you diabetes for $10".
Sometimes I get random cravings for certain fast foods, but I always feel like a sucker when I opt to get less food but pay almost the exact same. The idea of getting the bigger sizes of fast food and reheating leftovers makes my stomach churn a little, though, haha.
The largest difference is everyone who joins would be editing the code like it's a Google Doc instead of having a read-only view of the host's screen; you still end up having to join some kind of voice chat (unless maybe there's an IDE VOIP integration I don't know about in some of these tools!). I haven't used this specifically, so I can't say how well it pulls it off.
However, from the few times I've used VS Live Share, it has been helpful being able to join into someone's coding session and pair with their code directly. Both of us being able to highlight and tweak lines as we're talking did wonders to remove the "add x, no, sorry, not there, the next line/parameter/<item I referenced too vaguely>" or "show me y, now z, wait, go back to y" song and dance routines.
It's not necessarily a game changer for the way every person or team works, but as someone who has an easier time forming a mental model of everything happening when I'm "in" the code, there have been times I think it's saved a lot of back-and-forth compared to a traditional screen share.
Oh! It was not clear to me at first that this was non-read-only, though in hindsight I should have concluded as much from the phrase "see what the others are looking at and and [sic, whoops!] what changes they propose in real-time". Makes sense, thank you!
Over the years, I've never seen a longer version. I thought CSPAN might have one, but searching for just "fred rogers" wasn't giving me any results pre-1980s. The PBS versions I've found are just the OP clip as well.
In my searches, I have seen one YouTube video that has a few seconds extra at the front[0], but I couldn't tell you if it's actually Senator Pastore screaming "shut up" or if the author sampled some random gavels and screaming, ha.
I'd love to see the full hearing just to get the context of how big of a shift Pastore really went through, but if CSPAN and PBS both don't have it, I feel it doesn't exist at this point.
Maybe I'm misunderstanding your comment, but I'm reading it as saying if I can show I bought it at one point in time, then nothing else should matter, and they should unlock it for me. But I believe I must be missing something, because that proof of purchase doesn't necessarily prove it's my laptop after it's been locked by someone else's iCloud account.
For instance, I've given family my old laptops, and they setup their accounts after they take ownership of the device. The way I interpret your comment with regards to my scenario is that Apple should disregard the fact it is locked to their iCloud account and unlock it for me, because I can prove I was the original purchaser - even if they accidentally left it at my home or I steal it from their home.
Is that what you meant, that if I can give Apple a receipt then I am the de facto owner no matter what? Or am I just way off base?
Because of this one extreme case that will almost certainly never affect you, that you can easily work around, you should abandon all the other benefits of 'buying Apple'?
I suppose if I was a big influencer like John Dvorak -- you'd have a point. But I have 38 points on Hacker News. You might be the only person listening to me :p
But doesn't Apple explicitly disavow secondary sales?
No way would they unlock a device like this for your relative. It's odd that they won't unlock it even for the original owner. In what cases do they even plan to unlock these devices?
They can't prevent it, but they can certainly disavow it. By explicitly saying they don't support it or by making it harder to sell to the next person like region-locked or console-locked media.
I guess I'm surprised they don't! As the other commenter points out they have a page dedicated to this. I conflated their stance on secondary sales with their hardware and software self-service hostility.
> Is that what you meant, that if I can give Apple a receipt then I am the de facto owner no matter what? Or am I just way off base?
That's currently how it works. Except for OP of course.
I personally think that a better tactic would be to create a separate device that is paired to the machine, comes in the box, and can bypass activation lock. This would layer nicely on top of the existing system without forcing rigorous document management and an appeal to an opaque system of power to exercise true ownership over your own computer.
In short, yes, that's probably the right approach, unless another person comes to Apple to prove they legally are the new owners (I'd imagine Apple contacting the registered adress, and requiring proof if there is a response)
For more background on this, the fact that you actually have the laptop in your possession is the key point:
In my unqualified opinion, I would think having an iCloud account tied to the device that the person in possession of said device doesn't own shows "clear and compelling testimony or documentation to the contrary [of them being the rightful/current owner]". Although, I can see how others might argue it proves nothing; in the end, neither side is probably 100% correct in all of the scenarios, and it's all up to interpretation.
All I know for sure is I can say I'm glad I'm not a lawyer!
I'm also fully unqualified, but short of the person that authentified the device coming up and detailing how they're the current owner, I still think a person with physical and proof of purchase should be prioritized.
If for instance the device had been sold to a different owner, that owner should have the receipt and be contactable (they have the email address and probably other info). And if the owner declared theft, we're out of Apple's field and it should be an official claim.
I see the passing down to a family member situation in the same light: if it was an informal transaction, the official owner is a still the same, and getting back the device unbricked and wiped out shouldn't be an ethical connundrum.
The thing that gives me the most pause is that Apple keeping a hard line on refusing to unbrick the device means they get an additional purchase from someone who's already heavily invested in the ecosystem. From their POV, bricking more devices has no counter incentives.
I appreciate how the author has laid out how the calculation works and the pitfalls of CSS calc. It makes it very approachable for folks.
Has anyone seen a responsive type solution like this that doesn't break the "resize text" accessibility section of WCAG? [0] I would love to be able to use this style of responsiveness, but every time I've ever seen it there's always accessibility concerns or a piece of a blog post dedicated to how you'll still need to tweak and fine tune to meet the needs of less sighted users so it isn't the silver bullet it seems.
For instance on this blog post when zooming in on the example section, my naked eye feels like I never see it actually grow to 200% bigger. I'm on my gaming PC which isn't set up well for much code inspection, but it feels like it's either not growing at all or clamped at a certain size based on the zoom's width. Looking at dev tools, it shows it going from 28px to 18px, so it technically is getting a little smaller, whereas if you have 2rem you see the text grow as you zoom in.
I also could be completely misinterpreting this WCAG section or maybe misunderstanding the font size calculation. It is college football Saturday here in the US, so my brain may not be firing on all cylinders!
I started with Vue then moved into React, and I do enjoy how much closer it feels to JS/TS. There's a few of areas where I think React is definitely simpler than it was with Vue 2.x and shudder at how I probably used to have to do things to truly do it "the Vue way" (and there are parts I miss like the built-in, easy slots).
However, I think Vue's dev tooling is way more developer friendly than React's. They probably end up mostly equivalent in how they let you find performance issues or debug states, but I've never been able to understand why React's devtooling just feels half-finished in comparison.
I guess Vue spoiled me a bunch in how approachable its UI was. It may be me misremembering, but I also remember it not hanging or erroring nearly as much as React's devtooling.
Not only was he a mathematician, but Alice is considered partially a commentary on the state of mathematics at the time! [0] It's one of my (irrational) pet peeves that modern audiences often try to explain his books as some kind of Victorian era equivalent to a Cheech and Chong movie about drugs when there's so much more hidden away in the pages. These two books are my favorite books ever, and I'd give an arm and a leg if I could ever get my hands on an original copy, haha.
I highly recommend The Annotated Alice for anyone interested in Alice's Adventures in Wonderland and Through the Looking Glass, because it makes a couple of fun, curious reads even curiouser! ;)
Dodgson/Carroll was a witty writer. This is so good a passage that it has influenced modern English:
- - -
"I'VE been to a day-school, too," said Alice, "you needn't be so proud as all that."
"With extras?" asked the Mock Turtle a little anxiously.
"Yes,' said Alice, "we learned French and music."
"And washing?' said the Mock Turtle.
"Certainly not!" said Alice indignantly.
"Ah! then yours wasn't a really good school," said the Mock Turtle in a tone of great relief. "Now at OURS they had at the end of the bill, 'French, music, AND WASHING--extra.'"
"You couldn't have wanted it much," said Alice, "living at the bottom of the sea."
"I couldn't afford to learn it." said the Mock Turtle with a sigh. "I only took the regular course."
"What was that?" inquired Alice.
"Reeling and Writhing, of course, to begin with," the Mock Turtle replied, "and then the different branches of Arithmetic-- Ambition, Distraction, Uglification, and Derision."
"I never heard of 'Uglification'," Alice ventured to say. "What is it?"
The Gryphon lifted up both its paws in surprise. "What! Never heard of uglifying!" it exclaimed. "You know what to beautify is, I suppose?"
"Yes," said Alice doubtfully, "it means--to--make--anything--prettier."
"Well, then," the Gryphon went on, "if you don"t know what to uglify is, you ARE a simpleton."
That makes a lot of sense actually. Thanks for sharing this anecdote. Sometimes brilliant people get buried because of their eccentricities and it deters from the meaning of their life's work.
All of the CSS grid syntax craziness is one of the biggest reasons I was completely OK when our dev team adopted Tailwind. I am one of those devs who couldn't implement all of the CSS spec like @OJFord mentioned... but probably because I always forget what in the world all the options mean/are, haha!
> but probably because I always forget what in the world all the options mean/are, haha!
CSS is so big, and only getting bigger all the time (just read the Chrome release highlights over the last few years, your head is going to spin just from the CSS additions alone), yet at the same time it's not a language (where you can typically get by with just learning the basics and start to write useful stuff real fast by relying on general algorithmization skill and programmer intuition), just a massive set of directives you can combine together, I really feel like at the point where it is all in your head and ready to go (i.e. you know what you're about to do, you do it and it does what you intended... without you having to go through a 10 minute Chrome dev tools & Stack Overflow intermezzo), you have to have such a good memory, that you would do much better as a lawyer or a doctor than "mastering css".
Is there some better universal styling solution than CSS? Probably not. Is CSS way, way too big nowadays? Hell yes.
I disagree. While you can absolutely just pick and choose when using css as "salt & pepper" for an internal app ("admin" kind of part of a system), once you get into coding for a reasonably big frontend (of, say, an ecommerce site), suddenly you need all the bells and whistles for all the different media query versions of the site, mobile first is now a real requirement (most ecommerce visits are from mobile platforms and google uses mobile view to index and rate your site with Web Vitals) and so you have to know about flex, grid, typography, sizing, animations, scrolling, interactions, layout shifts, performance, browser support etc. etc. as otherwise you have an ugly, buggy, jumpy, unmaintainable mess on your hands.
There's a reason there are dedicated jobs for just front end development. It's a big task, and often for a different (not worse, just different) kind of person than your typical programmer who enjoys algorithmization. It's more about a person's crisp memory and good visual design ability.
For some of us who work as "full stack" devs sometimes, it's a lot of additional crap that you need to know... and so I can see why things like Tailwind (and its paid and free components) are popular.
As someone who started when CSS was so underpowered that layout was still done with <table>… I remember the introduction of every new CSS feature, and I will cherish them all forever.
The introduction of flexbox was like Christmas to me, and CSS grid was all my birthdays and Christmases at once.
It’s definitely much easier when you learn all of these features as a drip drip drip over decades.
I can’t imagine picking up CSS from scratch as a new dev in 2023. It must be extremely intimidating.
Although on balance, I’d say that despite the extra features, CSS is a lot simpler now than it was in the 00s and early 10s. The rendering engines are much better and agree almost all the time, in the past you’d spend a most of your time debugging your layout in different browsers, or fighting CSS to get it to get it to make the layout that you want (and eventually giving up and using a table)
I don’t disagree with you. But you also don’t disagree with me either.
You said it yourself “once you get into the coding for a reasonably big frontend”. That’s a specific task and the web is not made of only big projects.
CSS is vast but also allows you to ease into it. You don’t have to master it from day one in order to use it.
And that’s the beauty of it imo. I personally enjoy working with CSS and one of the reasons why I like it it’s because after 10 years and hundreds of sites coded I still learn new things about it.
I feel like the frontend gets an unfair treatment by many here on HN. I doubt people complain that the standard library of python is too vast, and you cannot master it. I feel like there is a lack of respect for professionalism on the front end stack and a lack of understanding that we front end developers actually spend a lot of time mastering this craft so we can use it skillfully at our jobs.
The only way I can make sense of this sentiment is that people feel like CSS is something to hack with, it is a toy, for hackers to play with, not a tool for professionals who spend years mastering the skill. I wonder why this is.
My sense of this (and I might be entirely wrong) is that CSS is a tool that is geared towards the presentation/design layer and that is somewhat removed from what most developers do or want to do or are happy doing.
It lives in this weird in between land where it's not really a programming language but it's complex enough to be hard to use by designers who are not really into programming.
I agree with you that mastering frontend requires a lot of time and practice, especially because it's a constantly moving target with new features, new tools and browsers that are constantly evolving.
I personally like it, I love the flexibility and I love that it's constantly changing and I have new tools I can use. It's also funny how there seems to be always something missing.
This may be the case. While it is a standard practice in print design and graphic design that designers learn and use some tools to materialize these design into somewhat of a final product (tools like indesign, illustrator, etc.) it is not a common practice among web designers. A web designer is more likely to create a mock-up in a tool like figma, which a web developer than materialized into HTML, CSS and JavaScript. Of course there is an overlap, where a designer actually writes their own frontend or a web developer does their own design, but most of the industry has a separation there which is not present many other creative industries.
Perhaps there is a lack of understanding of the interaction between a web-developer and a web-designer which creates this unique negative perception of CSS as a tool. A back end developer might simply not understand it.
Isn't the critique that CSS is not at the right level? It's a collection of very specific pragmatic APIs? At least during the big Houdini effort it seemed like browser vendors want to offer something lower level, that allows more and better control of the whole layout and rendering pipeline. Please correct and extend my comment if possible, because I'm admittedly now up to date with even the status of that aforementioned project.
But once you get into a pre-existing project, you have to be aware how every part of the language interact with each other. Grid vs Flex vs Tables vs Queries vs Components You have to know the language pretty well to avoid visual glitches.
Corner and general cases are usually documented on the MDN, but they're not very intuitive, and often very, very subtle. Did you know that just by using an apple magic mouse vs a magic trackpad you could change the behavior of the "overflow" property?
This is a fair point and one I’d agree with when it comes to working on pre-existing projects.
I was commenting on CSS in general. That said, CSS is easy to understand in general IMO so even if you’re not familiar with a specific property or tool within CSS it shouldn’t take a ton of time to understand how to use it.
But that’s my experience with it and I understand that I worked with CSS daily for the past 10+ years so I might have a skewed perspective.
How would you have done differently in the grid spec?
You don't have to use named grid areas if you don't like. But honestly, why wouldn't you. grid-template-areas makes working with grid a walk in the park imo.
Also very few of us web devs know all of CSS by heart. We use tools and reference manuals all the time as we are working. I suspect no python developer knows all of python either and are constantly looking at documentation or hints from their language server/IDE. The real skill is knowing where to look, not what to write.
Just want to preface this with this is all my opinion, and I know I'm not necessarily correct at all.
If I were given free reign, I would have tried to do some different naming for properties like grid-auto-rows/grid-auto-columns/grid-auto-flow. My internal way of thinking about how the first two control the height & width, respectively, don't line up with how I view the word "auto" in other places in CSS.
I also feel like there should have been a true shorthand for just creating an mxn grid. That's one of the biggest reasons I enjoy Tailwind because I can just say "grid grid-cols-3" and get a 3 column grid without me having to explicitly say I want them all even. I would have probably been naïve and made it work closer to the old column-count where giving it a unitless number and it makes it equal in the space; on top of that, I'd then layer the actual spec so you could do variable sized rows/columns.
The other thing I would have done would have been to focus time and effort on finding a way to easily reverse a grid. I know you can use the rtl/ltr hack to do it, and that grid being a 2-axis display method brings a lot of hard questions about "what does reversing a grid mean?". I know names could help here, but it just doesn't make sense in a CMS environment where editors can place as many or as few items in a grid as they want, so I can't just do "a b" -> "b a" based on media query, because there could be columns C through F, too, and I want them all reversed. Thankfully, this is mostly a mobile problem when they're stacked, so I can just switch to flexbox and column reverse, but still would've been nice to have an easier way to do this as the amount of SO posts I remember seeing for this indicated to me that folks did want this feature.
To answer why I don't use grid-template-areas often, I just don't find myself in a lot of situations where naming has made it easier. I guess I could do this kind of thing, but then everyone else is going to ask "where does a/b/c come from?", haha.
Seems like you are looking for grid-template-columns: repeat(3, 1fr). I honestly don’t see a problem with the 1fr part here. I don’t know what you mean with variable sized rows/columns, because you can already do something like:
grid-template-rows: auto var(--some-length) fit-content(30ch) minmax(12ch, auto) 1fr;
While I admit reversing the flow of grid items is a bit more verbose than flex items, it is still a pretty trivial thing to do, if you have named areas, you simply change the order of the area names, if you have explicit columns/rows you can just use negative indices for your grid-column/grid-row. If you have implicit columns/rows, you should probably be using flex (as—unlike grid—flex-direction: row-reverse also adjusts the scroll position) and a subgrid (though I will admit, grid-auto-flow: row-reverse should probably be an option; perhaps you can raise that with the CSSWG if you have a clear use case).
I can see the appeal of Tailwind for developers that don’t feel like becoming experts in CSS layout. However a lot of us frontend devs have spent quite some time studying CSS layout and do know how to work with it to get a desired layout. In my opinion, CSS grid is a resounding success story. I use it all the time in my job without any major issues. Did it take time to learn? Yes it did, I even ordered a whole book on the subject as I was studying it (https://abookapart.com/products/the-new-css-layout). Me personally, I would get insulted if my team decided to go with tailwind, as I would feel left out from my area of expertise. And that now instead of using what I know about CSS, I’m forced to learn a whole new system, and consult new documentation that I’m not familiar with.
It isn't necessarily a "problem", but I personally am a fan of keeping simple use cases as simple as possible. In my eyes, bringing the syntax to barebones makes it easier to read and more maintainable for these ultra simple use cases (for instance this 3x3 equally sized grid).
grid-rows: 3;
grid-columns: 3;
Is it an excruciating pain to need to currently type repeat(3, 1fr)? Nope, not at all, and I'd gladly do it if my team wanted to plain CSS or SASS, but to me that statement doesn't feel nearly as succinct or (dare I say) elegant as other areas of CSS, such as:
margin: 2rem;
padding: 1rem 0.5rem;
What I meant by variable sized rows & columns was to keep the rest of the spec as close as possible to what it is now, but layered on top of my suggested simpler syntax from above. That way if I wanted to do something that isn't just n equal-sized columns, I could just write out
grid-template-columns: 1fr 2fr 1fr;
and it would work as CSS grid currently does. It's the best of both worlds!
I'm also a frontend developer who has spent a pretty significant chunk of time studying CSS. Maybe I gave off the impression that I'm too incompetent to learn the latest features of the language and write them in plain CSS, but that wasn't what I meant. It is way more that I find little pleasure in writing CSS compared to other frontend responsibilities.
Am I happy and grateful that grid, container queries, and the rest of the new features exist? Yes, I am, and grid is one of the tools I reach for the most. In the end, I only had tiny things I wish could have been different about it after using it and realizing "rats, that syntax could have been made a tiny bit simpler for how I use it a lot of the time," or wishes for features that would just make life easier even if the current way of doing things is trivial.
Haha, you know what they say, different strokes for different folks! I didn't feel insulted in the slightest when our lead frontend developer suggested we give Tailwind a trial run. As a group, we were searching for a way to have consistency and a friendlier developer experience[0] throughout our many different projects & internal tools, but without having to bike shed with 10 different frontend developers or saddle someone with the responsibility of adding new CSS helpers as features rolled out (and the inevitable bike shedding that would happen every time). Some of my coworkers were upset about it because they prefer CSS and styling over JS and other frontend bits, but I think even the most fervent "vanilla CSS/SASS or nothing" holdout came around when she had to cover a project while someone was on vacation, and she found a level of consistency and naming that hadn't existed in our codebases.
--
[0] A couple of very old projects in a siloed team had a CSS guru building his own framework in SASS, but it's utility left a lot to be desired. In my opinion, you can't even place all of the blame on him, because his project was extremely standalone (and therefore had lulls when waiting for approvals and this was a way to pass the time and learn) and the company had very little guard rails to prevent this sort of thing. The combination of a small development team splintered between many different projects (no guidelines stating "this is how we are going to do this as a group" existed), everyone being overworked and burned out, and larger projects "winning" eyes of senior developers who held them to higher standards left him in a spot where I think he believed wholeheartedly that he was making a maintainable masterpiece that would end up being used in the rest of the projects when he finally finished it. Sadly, the framework never reached anything resembling a production-ready v1.0, but it did showcase some of his impressive knowledge of CSS.
I'm still rocking my Series 0 Milanese (but on a Series 5 watch), and I feel really lucky to only have lost a few arm hairs to the loop after your comment, haha. I wonder if they've changed something about their design or manufacturing over the years? It'd be interesting to get to see what this band looks like with each new generation to compare.
[1] https://x.com/wesbos/status/1727730566143803522