4 ms·

> now we are down to “place-self: center;” `place-self` still requires the parent to be a flex-box container, though. You can't just apply it to an arbitrary e

> now we are down to “place-self: center;” `place-self` still requires the parent to be a flex-box container, though. You can't just apply it to an arbitrary element to make it center in its parent. `place-self` is just shorthand for setting both `align-self` and `justify-self` in a single proeprty - I don't see how this is necessarily an improvement: CSS is already (unfortunately, necessarily) confusing at it is, so adding a literally redundant CSS property with a distinct name is not going to reduce confusion nor make CSS any more accessible. CSS's shorthand properties work best when the shorthand version actually aids comprehension, rather than making you think: for example, `border: <width> <style> <color>;` and `margin: <top> <right> <bottom> <left>;` are great examples of how they should be: either because each parameter is unambiguously typed (in `border`'s case: widths, border-style and colors are very distinct) or uniformly-typed but follow a familiar pattern (e.g. `margin:`'s parameters are all length-values but are in a clockwise sequence) - this is not something we see in some of the more modern shorthand properties like `flex` and `box-shadow` where you need to have pre-memorized which parameter corresponds to each longhand property, e.g. it's non-obvious that the `2` in `flex: 1 2 3px` is for `flex-grow` - or that the `3px` in `box-shadow: 1px 2px 3px 4px rgba(0,0,0,0.2);` is for `blur-radius` and not `spread-radius`. > It’s good to see that the problem of anchoring tooltips is progressing through this process! I'm also strongly in favour of this CSS feature, it's a long-time coming - BUUUUT I also really would have liked some browser-native tooltip/title feature that allows for rich-content without resorting to hacks like `foo[title]::after { position: absolute; content: attr(title); etc }`

nailer 4y ago
> You can't just apply it to an arbitrary element to make it center in its parent. You can with grid-first. With the proviso that third party components may not work (which is fine, third party components are usually very low quality). I'd recommend, right after your existing: *, *:before, *:after { box-sizing: border-box; } Adding: div { display: grid; } You can now remove: - all margins (there's just padding and gap now) - margin auto centering hacks - clearfix hacks - translateY -50% hacks - a billion wrappers around every UI element (per all those low quality third party components, particularly common in the react space which seems to have a culture of "add divs until it looks right") plus a bunch of other code. In 99% of cases, using grid-first, there will be a 1:1 match of element to UI - getting around the div-soup of older web apps. The app I'm developing now is 1:1 with the exception of rounded gradient borders, which still needs a hack.
- DaiPlusPlus 4y ago
  > ...your existing I don't use CSS Reset techniques: don't try to fight the browser. > div { display: grid; } I'm concerned this will have a nontrivial impact on browser layout performance. Existing browser layout engines are heavily optimized for flow/block layout, but defaulting every div to grid breaks that major assumption all the browser-makers made and... for what gain? I actually don't want every div to potentially be a grid layout container by default. > You can now remove $things: I don't use any of those tricks/hacks anyway - and clearfix hasn't been relevant since IE8 came out. > rounded gradient borders Just use border-radius combined with `border-image: some-gradient-function()`. No hacks or tricks required.
  - 867-5309 4y ago
    >some-gradient-function() >which still needs a hack
  - nailer 4y ago
    I've been doing grid-first for a few years now (last major update was when buttons hot grid support) across apps including high performance google docs-type collab interfaces. It's fine. Optimising for existing behavior reminds me of when people didn't want to use async/await as V8 'wasn't optimised' for it. await never felt slow in their apps anyway, but now it's similar fast to what callbacks were. Skate to where the puck going to be. > for what gain? I don't use any of those tricks/hacks anyway OK. Everyone else does but maybe you're the exception. > For rounded gradient borders... just use border-radius combined with `border-image: some-gradient-function()`. No hacks or tricks required. Are you sure? https://stackoverflow.com/questions/51496204/border-gradient-with-border-radius https://stackoverflow.com/questions/51496204/border-gradient... - judging by the views on that question, if you have a codepen there's at least 42,000 people who'd love to see, it my understanding is that the W3C spec says it shouldn't work. Probably obvious, you sound like you know what you're doing but: adding additional elements, pseudoelements etc counts as hacks. Here's border-radius combined with `border-image: some-gradient-function()`: https://codepen.io/mikemaccana/pen/QWVpdmo https://codepen.io/mikemaccana/pen/QWVpdmo
javajosh 4y ago
Parent element "modes" that affect child layout and "enable/disable" child available properties is what makes CSS tricky. To do CSS well you end up having to learn all the modes and all the properties, which makes CSS a defensible professional specialization, but its less good for drive-by designers who just want simplicity. (My personal favorite remains the good old "absolute layout".) (Aside: another technology in the thankfully small know everything before you can do anything set is gradle, a popular build tool in the Java universe. These tools are capable, but quite demanding of the user. Git may also qualify.)
- DaiPlusPlus 4y ago
 Right. Prior to CSS, it used to be that literally anyone could (and should!) write HTML: web-pages were just simple documents (by design) using only paragraph-flow content with inline objects (like images, Java applets, ActiveX on Windows), and appearance was directly set inline with , , etc. This is fine for web-page documents, but not web-page applications, and it turns out that defining a layout system for a medium as flexible as a web-browser viewport is very, very hard. It's the same thing with desktop software: previously it was perfectly acceptable for a VB6 application to consist entirely of fixed-size windows with controls placed at fixed-positions, with no resize logic - or to handle re-flow when the text changes, or high-DPI for that matters. Users, today, have much higher expectations, and now it's now basically impossible for a "citizen programmer" to meet the expectations of normal users, and I feel this is a bad trend for everyone: we all love to grimmace at a giant Excel VBA macro doing 20 things at once that still somehow works, but the person or company that actually has that macro really is better-off than someone without it. ------- The complex layout systems in modern UI frameworks (like WPF/XAML, Cocoa Touch, etc) are converging with CSS (or vice-versa, depending on your experience) in their expressiveness - which necessitates complete abstraction-away from fixed-layout WYSIWYG systems that were the key component of the democratization of desktop computers since the late-1980s, and while HTML was never WYSIWYG an average person could still immediately understand what `` did - and could immediately see how their fixed-layout VBA Form would look when it runs. Unfortunately I don't have a solution to this problem: citizen-programmers are going to need a WYSIWYG fixed-layout design tool, but such a tool is fundamentally incompatible with end-user expectations - and essential things like accessibility and device-portability. I guess we'll be stuck with proprietary, half-arsed, "low-code"/"no-code" tools for a long while.
fwlr 4y ago
I completely agree with your take on what makes for a good shorthand property, I would also have pointed to border: as a good shorthand and flex: as a bad shorthand. I think place-self: is a good shorthand, though - the fact that it’s a redundant way to specify two separate properties in a single line is good in this specific case because it matches the developer’s mental model of “center this div please” being a single and simple request. Yes, the truth of layout is that centering stuff is not actually simple and does not involve one single operation, and so we have had to build complex layout systems to handle all the edge cases and complexities, but now that we’ve built those systems it makes sense to offer a shorthand for this common request that resolves to the set of commands required to achieve the result. (e.g. I think ES6’s for-of iteration construct is a good idea, despite redundancy/confusion with the existing C-style for-i++ iteration construct.)
fleddr 4y ago
Fully agree with your take. CSS should have more straightforward properties that actually do what people intuitively expect it to do without additional dependencies and weird side effects. Even the supposedly favorable case of having a flexbox container with place-self: center in many cases still does not correctly center the child element. For example, a label inside a button. The label is typography, which means it has its own vertical spacing (line-height, top-cap, bottom margin) that may be unevenly distributed. Fixable, but now you're into the 3rd rabbit hole, just to center something.

nailer 4y ago

> You can't just apply it to an arbitrary element to make it center in its parent. You can with grid-first. With the proviso that third party components may not work (which is fine, third party components are usually very low quality). I'd recommend, right after your existing: *, *:before, *:after { box-sizing: border-box; } Adding: div { display: grid; } You can now remove: - all margins (there's just padding and gap now) - margin auto centering hacks - clearfix hacks - translateY -50% hacks - a billion wrappers around every UI element (per all those low quality third party components, particularly common in the react space which seems to have a culture of "add divs until it looks right") plus a bunch of other code. In 99% of cases, using grid-first, there will be a 1:1 match of element to UI - getting around the div-soup of older web apps. The app I'm developing now is 1:1 with the exception of rounded gradient borders, which still needs a hack.

DaiPlusPlus 4y ago
> ...your existing I don't use CSS Reset techniques: don't try to fight the browser. > div { display: grid; } I'm concerned this will have a nontrivial impact on browser layout performance. Existing browser layout engines are heavily optimized for flow/block layout, but defaulting every div to grid breaks that major assumption all the browser-makers made and... for what gain? I actually don't want every div to potentially be a grid layout container by default. > You can now remove $things: I don't use any of those tricks/hacks anyway - and clearfix hasn't been relevant since IE8 came out. > rounded gradient borders Just use border-radius combined with `border-image: some-gradient-function()`. No hacks or tricks required.
- 867-5309 4y ago
  >some-gradient-function() >which still needs a hack
- nailer 4y ago
  I've been doing grid-first for a few years now (last major update was when buttons hot grid support) across apps including high performance google docs-type collab interfaces. It's fine. Optimising for existing behavior reminds me of when people didn't want to use async/await as V8 'wasn't optimised' for it. await never felt slow in their apps anyway, but now it's similar fast to what callbacks were. Skate to where the puck going to be. > for what gain? I don't use any of those tricks/hacks anyway OK. Everyone else does but maybe you're the exception. > For rounded gradient borders... just use border-radius combined with `border-image: some-gradient-function()`. No hacks or tricks required. Are you sure? https://stackoverflow.com/questions/51496204/border-gradient-with-border-radius https://stackoverflow.com/questions/51496204/border-gradient... - judging by the views on that question, if you have a codepen there's at least 42,000 people who'd love to see, it my understanding is that the W3C spec says it shouldn't work. Probably obvious, you sound like you know what you're doing but: adding additional elements, pseudoelements etc counts as hacks. Here's border-radius combined with `border-image: some-gradient-function()`: https://codepen.io/mikemaccana/pen/QWVpdmo https://codepen.io/mikemaccana/pen/QWVpdmo

javajosh 4y ago

Parent element "modes" that affect child layout and "enable/disable" child available properties is what makes CSS tricky. To do CSS well you end up having to learn all the modes and all the properties, which makes CSS a defensible professional specialization, but its less good for drive-by designers who just want simplicity. (My personal favorite remains the good old "absolute layout".) (Aside: another technology in the thankfully small know everything before you can do anything set is gradle, a popular build tool in the Java universe. These tools are capable, but quite demanding of the user. Git may also qualify.)

DaiPlusPlus 4y ago
Right. Prior to CSS, it used to be that literally anyone could (and should!) write HTML: web-pages were just simple documents (by design) using only paragraph-flow content with inline objects (like images, Java applets, ActiveX on Windows), and appearance was directly set inline with , , etc. This is fine for web-page documents, but not web-page applications, and it turns out that defining a layout system for a medium as flexible as a web-browser viewport is very, very hard. It's the same thing with desktop software: previously it was perfectly acceptable for a VB6 application to consist entirely of fixed-size windows with controls placed at fixed-positions, with no resize logic - or to handle re-flow when the text changes, or high-DPI for that matters. Users, today, have much higher expectations, and now it's now basically impossible for a "citizen programmer" to meet the expectations of normal users, and I feel this is a bad trend for everyone: we all love to grimmace at a giant Excel VBA macro doing 20 things at once that still somehow works, but the person or company that actually has that macro really is better-off than someone without it. ------- The complex layout systems in modern UI frameworks (like WPF/XAML, Cocoa Touch, etc) are converging with CSS (or vice-versa, depending on your experience) in their expressiveness - which necessitates complete abstraction-away from fixed-layout WYSIWYG systems that were the key component of the democratization of desktop computers since the late-1980s, and while HTML was never WYSIWYG an average person could still immediately understand what `` did - and could immediately see how their fixed-layout VBA Form would look when it runs. Unfortunately I don't have a solution to this problem: citizen-programmers are going to need a WYSIWYG fixed-layout design tool, but such a tool is fundamentally incompatible with end-user expectations - and essential things like accessibility and device-portability. I guess we'll be stuck with proprietary, half-arsed, "low-code"/"no-code" tools for a long while.

fwlr 4y ago

I completely agree with your take on what makes for a good shorthand property, I would also have pointed to border: as a good shorthand and flex: as a bad shorthand. I think place-self: is a good shorthand, though - the fact that it’s a redundant way to specify two separate properties in a single line is good in this specific case because it matches the developer’s mental model of “center this div please” being a single and simple request. Yes, the truth of layout is that centering stuff is not actually simple and does not involve one single operation, and so we have had to build complex layout systems to handle all the edge cases and complexities, but now that we’ve built those systems it makes sense to offer a shorthand for this common request that resolves to the set of commands required to achieve the result. (e.g. I think ES6’s for-of iteration construct is a good idea, despite redundancy/confusion with the existing C-style for-i++ iteration construct.)

fleddr 4y ago

Fully agree with your take. CSS should have more straightforward properties that actually do what people intuitively expect it to do without additional dependencies and weird side effects. Even the supposedly favorable case of having a flexbox container with place-self: center in many cases still does not correctly center the child element. For example, a label inside a button. The label is typography, which means it has its own vertical spacing (line-height, top-cap, bottom margin) that may be unevenly distributed. Fixable, but now you're into the 3rd rabbit hole, just to center something.