5 ms·

I'm currently trying to do as much as possible (without crazy hacks) in HTML / CSS alone, just because it's easier. Things like "position: sticky" are easier th

I'm currently trying to do as much as possible (without crazy hacks) in HTML / CSS alone, just because it's easier. Things like "position: sticky" are easier than anything JS could do.

SilverRed 5y ago
Not only easier, but more performant. You don't end up with one element lagging behind as you scroll.
brundolf 5y ago
It’s also easier to debug, because state is so minimal and visible
- Dylan16807 5y ago
  Sometimes. Is there any good way to see why an element is a certain size? I often end up digging back and forth through children and parents and wanting to tear my hair out.
  - brundolf 5y ago
    It's easy to see computed CSS properties and which selectors they come from (and what the order of specificity is that caused those properties to take effect) Given the properties, I personally find sizes to be pretty predictable based on the rules of block or flex sizing
    - Dylan16807 5y ago
      I'm talking about sizes that aren't coming from properties in that specific element. I can see that it's height 20 and I can see that it's not set directly, but how do I know if it's coming from the parent element or a child element, and for the latter how do I know which children/grandchildren/greatgrandchildren are causing it to be that size? And every one of those elements has 100 rules applied because it's a mess I didn't create, so brute force searching is a giant pain.
      - brundolf 5y ago
        I'm also talking about sizes that aren't hardcoded. I don't really know what to tell you except that in my experience the rules governing the sizing of CSS elements don't tend to be very complicated. If you're in a default (block/inline) context, and no width or height is set, then if it's display: block it will be the full width of its parent and its height will be determined by its content. If it's inline or inline-block, its width will also be determined by its content. Flex contexts have their own rules that are a bit more complicated but remain very predictable once you learn them. Etc. Generally, nearly every element's size comes down to some combination of: 1) Explicit width/height properties (and padding/margin) 2) Special layout mechanisms like filebox or grid 3) The element's contents 4) Its direct parent's dimensions That's pretty much it. There's really no case I can think of where a grandparent directly drives an element's size (it may drive the parent's size which drives the child's size, but the reach at each individual stage remains short)
        Dylan16807 5y ago
        I tried to recreate my original full set of grievances, but firefox has changed the CSS around too much. But I can still go with this: I inspect the tab toolbar. I pick a tab and look at the contents of the div. Just inside the actual tab div is a "stack" element, whose width is being set to the size of its contents right now. The stack is size 50.5x44, and it's display:grid. It has two visible children. Both of them are 50.5x44, and are display: -moz-box. I can tell from deep inspection and trial and error that one of those children is setting the size, and the other child is inheriting the size. But if I don't want to dig around every single sub-div, what can I do to figure out which one is which? They look the same in the layout inspector, and neither of them has any computed properties relative to width. For bonus difficulty: If the parent div of the "stack" element tries to grow wider than the stack, the stack will grow to match its width, and the child divs of the stack will also grow to match it. All without any computed properties changing, or the layout inspector noting that anything is different. So the size of the "stack" element could be set by either its parent or one of its children and I have no idea how to figure out which one except by experimentation. This is not a very pleasant experience. Ideally, I could get a list of every element competing to set the width of a div, and which one(s) are winning. Less ideally, I could see just which element(s) are currently responsible for the size of a div. But as far as I can tell there's nothing, and I have to blindly search every other related element that has a suspiciously similar size.
recursivedoubts 5y ago
if I may recommend my own library: https://htmx.org https://htmx.org it extends the expressive power of HTML as a hypertext and allows you to do quite a bit more within the hypertext paradigm.
- speg 5y ago
  Like the parent I am trying to DIY most things on my personal projects. Standard library for everything except the database driver and… htmx ;) Thank you!
- leephillips 5y ago
  htmx is great. Thank you for making it.
- k1rcher 5y ago
  Wow, this looks bloody brilliant. I’ve only recently begun feeling more “comfortable” writing JS on the fly for frontend development (previous roles were nearly all backend-centric), but one big issue I’m facing is managing the ever-growing ecosystem in a way to minimize complexities in a timely and efficient manner. HTMX seems as though it will catalyze those efforts.
- pjerem 5y ago
  Wow, that's impressively cool ! Well done
- armchairhacker 5y ago
  Wow thanks! I am definitely checking this out. HTMX + TailwindCSS, so almost everything client-side is in HTML. And I use FreeMarker macros to generate the HTML components.

I'm currently trying to do as much as possible (without crazy hacks) in HTML / CSS alone, just because it's easier. Things like "position: sticky" are easier than anything JS could do.

SilverRed 5y ago

Not only easier, but more performant. You don't end up with one element lagging behind as you scroll.

brundolf 5y ago

It’s also easier to debug, because state is so minimal and visible

Dylan16807 5y ago
Sometimes. Is there any good way to see why an element is a certain size? I often end up digging back and forth through children and parents and wanting to tear my hair out.
- brundolf 5y ago
  It's easy to see computed CSS properties and which selectors they come from (and what the order of specificity is that caused those properties to take effect) Given the properties, I personally find sizes to be pretty predictable based on the rules of block or flex sizing
  - Dylan16807 5y ago
    I'm talking about sizes that aren't coming from properties in that specific element. I can see that it's height 20 and I can see that it's not set directly, but how do I know if it's coming from the parent element or a child element, and for the latter how do I know which children/grandchildren/greatgrandchildren are causing it to be that size? And every one of those elements has 100 rules applied because it's a mess I didn't create, so brute force searching is a giant pain.
    - brundolf 5y ago
      I'm also talking about sizes that aren't hardcoded. I don't really know what to tell you except that in my experience the rules governing the sizing of CSS elements don't tend to be very complicated. If you're in a default (block/inline) context, and no width or height is set, then if it's display: block it will be the full width of its parent and its height will be determined by its content. If it's inline or inline-block, its width will also be determined by its content. Flex contexts have their own rules that are a bit more complicated but remain very predictable once you learn them. Etc. Generally, nearly every element's size comes down to some combination of: 1) Explicit width/height properties (and padding/margin) 2) Special layout mechanisms like filebox or grid 3) The element's contents 4) Its direct parent's dimensions That's pretty much it. There's really no case I can think of where a grandparent directly drives an element's size (it may drive the parent's size which drives the child's size, but the reach at each individual stage remains short)
      - Dylan16807 5y ago
        I tried to recreate my original full set of grievances, but firefox has changed the CSS around too much. But I can still go with this: I inspect the tab toolbar. I pick a tab and look at the contents of the div. Just inside the actual tab div is a "stack" element, whose width is being set to the size of its contents right now. The stack is size 50.5x44, and it's display:grid. It has two visible children. Both of them are 50.5x44, and are display: -moz-box. I can tell from deep inspection and trial and error that one of those children is setting the size, and the other child is inheriting the size. But if I don't want to dig around every single sub-div, what can I do to figure out which one is which? They look the same in the layout inspector, and neither of them has any computed properties relative to width. For bonus difficulty: If the parent div of the "stack" element tries to grow wider than the stack, the stack will grow to match its width, and the child divs of the stack will also grow to match it. All without any computed properties changing, or the layout inspector noting that anything is different. So the size of the "stack" element could be set by either its parent or one of its children and I have no idea how to figure out which one except by experimentation. This is not a very pleasant experience. Ideally, I could get a list of every element competing to set the width of a div, and which one(s) are winning. Less ideally, I could see just which element(s) are currently responsible for the size of a div. But as far as I can tell there's nothing, and I have to blindly search every other related element that has a suspiciously similar size.

recursivedoubts 5y ago

if I may recommend my own library: https://htmx.org https://htmx.org it extends the expressive power of HTML as a hypertext and allows you to do quite a bit more within the hypertext paradigm.

speg 5y ago
Like the parent I am trying to DIY most things on my personal projects. Standard library for everything except the database driver and… htmx ;) Thank you!
leephillips 5y ago
htmx is great. Thank you for making it.
k1rcher 5y ago
Wow, this looks bloody brilliant. I’ve only recently begun feeling more “comfortable” writing JS on the fly for frontend development (previous roles were nearly all backend-centric), but one big issue I’m facing is managing the ever-growing ecosystem in a way to minimize complexities in a timely and efficient manner. HTMX seems as though it will catalyze those efforts.
pjerem 5y ago
Wow, that's impressively cool ! Well done
armchairhacker 5y ago
Wow thanks! I am definitely checking this out. HTMX + TailwindCSS, so almost everything client-side is in HTML. And I use FreeMarker macros to generate the HTML components.