Oh that's weird, in the hacker news search index, this link was posted 4 days ago.
Readit Newswebstrand commented on Microservices should form a polytree bytesauna.com/post/micros... · Posted by u/mapehe
webstrand commented on Incomplete list of mistakes in the design of CSS wiki.csswg.org/ideas/mist... · Posted by u/OuterVale
moreover h* is just broken whenever dealing with more dynamic content — it simply can’t reasonably be made to work according to accessibility recommendations — and the accessibility guidelines around never skipping a level themselves are ridiculous given the practical reality that dynamic content exists and we have only h1, h2, etc. to work with — the readers and specs are what need to adapt here, not the entire internet
there should really be one header tag and its level should be based on some nesting depth
and don’t get me started on the maintainability mess that is z-index… better we have a system to centrally maintain an ordering list than a distributed one which only works reasonably consistently if you already know everything in the whole system
I like how z-index works, currently. And though I agree with the article, it should apply to all elements by default, I'm not sure how you'd do stacking differently in a way that'd work any better than the current situation?
You can't do away with stacking contexts, you need those to isolate content you don't control to prevent it from breaking the stacking order of content you do control.
I completely agree with you about h* tags, though. I wish html5 sectioning hadn't been killed by the browser vendors. As is there's no safe way to put headings inside custom elements. We almost had it, it was specified and everything.
webstrand commented on Perl's decline was cultural beatworm.co.uk/blog/compu... · Posted by u/todsacerdoti
I've been messing with sandboxing using "bwrap" for random itch.io games I download to play and it isn't trivial to get it working with least privileges. I have so far been unable to get "Microlandia" to run, but other Unity games are running just fine under "bwrap". I am excited to see more Landlock tools emerge that make this task easier.
- https://github.com/containers/bubblewrap
- https://codeberg.org/dannyfritz/dotfiles/src/commit/38343008...
I was just playing with bwrap for isolating npm project actions from the rest of my system.
bwrap --unshare-pid --dev-bind / / --tmpfs /home --bind "$(pwd)" "$(pwd)" bash
webstrand commented on New layouts with CSS Subgrid joshwcomeau.com/css/subgr... · Posted by u/joshwcomeau
Yeah this is a good callout. My understanding is that display: contents is not meant to impact the accessibility tree but there is a long and ongoing history of browser bugs that make me not want to use it for elements that have an accessible role
From my testing, as far as I've been able to tell it no longer has any impact on accessibility. The element itself does not appear in the tree, this makes sense display:contents is non-interactive. But all of the children correctly appear in the accessibility tree as if they did not have that shared parent element. But I am by no means an expert at operating screen readers, do you know of any specific issues with it?
webstrand commented on New layouts with CSS Subgrid joshwcomeau.com/css/subgr... · Posted by u/joshwcomeau
Yes, for that specific example it works. But in general, this essentially deletes the UL from the layout entirely. It won't be stylable[0] and it won't dispatch UI events that occur on it specifically.
One example of a reason you might want such an element to still participate in layout is to use that element as an area highlighter. Or you might make it a scrollable section; subgrid makes sticky-header tables rather trivial to implement now.
[0] Well, I can't remember right now if it's unstylable or if its height just ends up zero, but either way, it might not be what you expect.
Yeah, though I find in practice I use `display: contents` far more than I do subgrid. Contents effectively deletes the node for layout purposes, but it still participates in the CSS cascade so you can use it in selectors, even `:hover` works when a child gets hovered, or use it as the origin for inheritable properties.
webstrand commented on New layouts with CSS Subgrid joshwcomeau.com/css/subgr... · Posted by u/joshwcomeau
Isn't this also what container queries solve better? I guess maybe you want to be sure that the whole grid remains consistent instead of relying on individual containers possibly making their own decisions. So many new features to investigate, so little time :) https://codepen.io/web-dot-dev/pen/rNrbPQw
Container queries don't solve the responsive to sibling sizes issue that grid/flex can solve. And frustratingly container queries force your container element to be a new stacking context, unlike flex/grid.
I am sad that using containers and subgrids together doesn't work. Being able to query the size of the subgrid from a child element would be super powerful.
webstrand commented on New layouts with CSS Subgrid joshwcomeau.com/css/subgr... · Posted by u/joshwcomeau
Subgrid is really cool, but I want to note that for the first trivial example, you could make the children participate in grid layout by doing
ul { display: contents }
webstrand commented on OOP is shifting between domains, not disappearing blog.jsbarretto.com/post/... · Posted by u/ibobev
The essence of OOP to me is message-passing, which implies (hidden) local mutable state (there must be local state if a message can change future behavior). (Really, actor-based languages are purer expressions of this ideal than conventional OOP languages, including Smalltalk.) However, encapsulation is not at all unique to OOP; e.g. abstract data types are fully encapsulated but do not require all function calls to look like message passing.
And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP.
Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state.
And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.
Do you have anything specific in mind?
Any kind of downleveling, though that's less important these days most users only need polyfills, new syntax features like `using` are not widely used.
Minification, and bundling for web is still somewhat necessary. ESM is still tricky to use without assistance.
None of these are necessary. But if you use any of them you've already committed to having a build step, so adding in a typescript-erasure step isn't much extra work.