lionelw

Joined 8 years ago

Karma

Submissions

Member since

Oct 4

Recent submissions

Is this the first time mainstream media is saying something? Prominent voices have done so for years e.g. Anil Dash[0], but no one seems to have gotten the memo; people who I thought would care have continued to either be on it or cite content from it, oblivious.

Edit: Scrolling down to related stories shows articles criticising Nazi Substacks since 2024

[0] https://www.anildash.com/2024/11/19/dont-call-it-a-substack/

Comment · 1 year ago

So how do you deliver design on the web, if not without code?

Remember that designing for the web is not like designing for print, where the dimensions of your canvas, and the amount and nature of your content, are known quantities. A web page is expected to accommodate every possible device, agent and viewport -- watches, phones, tablets, laptops, desktops, TVs, screen readers, ebook readers, etc. * portrait and landscape orientations * browser window sizes -- and content that can change by the minute and whose size is unknown until all of it has arrived on the device.

Think about all these conditionals and variables, and how much instruction you need to provide, efficiently, for making it all look as good as possible, to the browser/agent. Doesn't all this seem like the necessary purview of a domain-specific programming language?

Comment · 1 year ago

How many of those languages are declarative, or domain specific?

There's no use comparing CSS and assembly. It betrays a shallow understanding of CSS. Points to ponder:

- Assembly is superlatively imperative while CSS is the opposite. The difference can be jarring for some. It's commonly felt in day-to-day frontend work that switching to CSS (declarative) from almost anything else (imperative) -- JavaScript, PHP, etc. -- requires a significant mental shift, though it does get easier with experience.

- Lot of the vocabulary and concepts used in CSS come from outside the computing world, namely design and publishing. It's somehow a rarely shared factoid, but it's a hint at how too far away from Kansas we are to be making fair comparisons.

- A pervasive mistake that coders make (and unfortunately a lot of CSS teaching material out there too) is to approach CSS as a set of explicit, atomic instructions -- a fair coder-y assumption, but a bad mental model that leads to frustration. Understand that these instructions can affect one another; some switch entire layout algorithms[0] in a given scope, changing how other instructions behave (predictably).

[0] https://www.joshwcomeau.com/css/understanding-layout-algorit...

Comment · 1 year ago

Alright, if you say so. But what stupidity do you mean? What do you mean offload it to figma etc? Why is it dumb to write code for... the job CSS is built for?

Comment · 1 year ago

Ask your boss to hire someone better at CSS than you.

Comment · 1 year ago

When is it ever necessary to change event handlers?

Comment · 1 year ago

>Why is this so weirdly prescriptive about inline event handlers?

>> Even in a single file, inline event handlers are not a good idea. One button is OK, but what if you had 100 buttons? You'd have to add 100 attributes to the file; it would quickly turn into a maintenance nightmare.

What's so weird about this? This practice, known as event delegation, has been a known Good Practice for decades. One event listener attached to a common ancestor element of 100 buttons is more memory efficient than 100 event listeners. Even jQuery, which makes it temptingly ergonomic to give 100 buttons an event listener each, prescribes the event delegation pattern in their documentation.

Edit: Sorry I just read the section; now I'm dismayed the MDN article is not prescribing/recommending event delegation. However I did find other MDN articles explaining it: