If you want an element to fully contain margins (and floats, remember them?), but you don't want the contents to be clipped, display: flow-root is what you're looking for. https://jsbin.com/hafawud/edit?html,css,output
@jaffathecake I’m trying to wrap my head around it (on my mobile so can’t experiment at the moment) as it almost feels like it should be an overflow property, or a feature you would want to apply to something that is a part of another display structure (I.e. grid or flex).
@jaffathecake it's more explicit, which is good and would theoretically be easier to parse except parsers cannot really on it because HTML is so forgiving and people exploiting that.
🧶 ICYMI, here's the latest episode of OTMT, where me and @surma chat about service worker static routes, and whether it's ever ok to throw away most of the web platform and do everything in <canvas>.
I get it. I get the whole point of it. But CSS logical properties are so confusing. Even after reading the first two paragraphs of https://developer.mozilla.org/en-US/docs/Web/CSS/block-size I'm left thinking ENOUGH WITH THE FUCKIN RIDDLES.
Ok, so if display: block makes the thing full width, block-size will change the width.
@jaffathecake I would prefer if I could continue to write ”width”, etc. in my code, but then have a tool that automatically converts my CSS to the logical version, if that’s possible.
@jaffathecake This is a reference to the direction of flow. Which is to say:
the axis where elements expand based on content size
the axis where the next element will be added
The fact that blocks go full-width by default is a reminder that it's not the block axis. Block elements can't flow on an axis where they are always full-width.
The only recent spec activity on this is a headinglevelstart attribute which can be set to a number. I proposed an 'auto' value for this, but it was dismissed for the initial feature (but may happen later) https://github.com/whatwg/html/issues/5033#issuecomment-1733292070
@jaffathecake this is all just retcons. Hixie didn't do any serious research before he invented a grand new plan for HTML, and the attempts to fit new meaning back into old skins has gone as poorly as (some of us) expected.
The better way forward is to just invent elements that fucking do things by default, not by subterfuge or through a11y side-doors.
I'm currently pushing the idea that our component library's tests should be a separate package (in a monorepo), so we're testing the real built version of the library, and also the package.json exports.
Folks are a little uncomfortable that the component's tests are in a different folder to the implementation.
Is there a solution to this that isn't… very hacky?
@jaffathecake your suggestion feels the most sensible for components lib that is consumed by many packages. Testing package.json and the way how it is imported/exported is a valuable thing to test.
If there is only one package that consumes it, I think it is fine being together with the consuming package. Probably there is not much value in testing package.json in case or a single consumer.
@paularmstrong the thing we're delivering is a built package. Testing something else means we're testing something other than the thing we're delivering. Build time is currently one second.
> When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.
Really sad that the Navigation API isn't being included in interop 2024. This API makes a night-and-day difference to handling navigations. It cannot be polyfilled, and cannot really be used as progressive enhancement. We need it yesterday. https://github.com/web-platform-tests/interop/issues/435#issuecomment-1921896911
@passle@tbroyer@jpzwarte my gut feeling is that the polyfill would be lacking (similar to runtime CSS polyfills). But that's just a guess based on the history API vs the navigation API
@jaffathecake Honestly super bummed at this year's Interop 24 list as well, especially after last year was so promising. Just kinda hoping we get some of the big ones like navigation API and view transitions to come at least to webkit even if they didn't make the list.