4 ms·

Could you be more specific about which part of CSS you find the most un-intuitive and sub-optimal for solving basic design problems? I want to remind you that t

Could you be more specific about which part of CSS you find the most un-intuitive and sub-optimal for solving basic design problems? I want to remind you that the basics of CSS are targeting some piece of layout and applying styles to it, separate from the element itself. Basic HTML + CSS is like an hour or two worth of learning for an absolute beginner (especially with the simplicity of HTML5), and after that you're mostly limited by your imagination, for simple things. I'm just assuming you mean cascading and/or specificity as the thing that's unintuitive and sub-optimal, but other than that I'm having trouble differentiating basic CSS (e.x. using only element ids and styling rules) and how you end up styling components on mobile now... Maybe where we're differing is on a more fundamental level as far as whether styling should be separate from layout in the first place? But even then you have access to `style` attributes in HTML...

skohan 8y ago
Just look at the CSS spec (or collection of specs): https://www.w3.org/TR/css-2017 https://www.w3.org/TR/css-2017 It's enormous! How could anything be intuitive when there are hundreds of keywords? To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: #MyDiv { clear: both; } "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases. By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.
- hardwaresofton 8y ago
  > Just look at the CSS spec (or collection of specs): > https://www.w3.org/TR/css-2017 https://www.w3.org/TR/css-2017 > It's enormous! How could anything be intuitive when there are hundreds of keywords? But I covered this though -- you don't have to take the whole HTML/CSS spec, because if you did you'd just be making a browser. Even if there are hundreds of keywords, you generally don't have to know (or support, as an implementer) every single one. > To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: [example] The example you gave is pathological -- a more reasonable one for a "basic design problem", which is what you said CSS was bad for: #MyDiv { background-color: black; } Your very next sentence betrays how pathological the case is: > "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases. "clear" isn't magic, it requires knowing what a float layout is, and having used a float layout before. It is a special case reserved for building float layouts, that is necessary because of how they work. I don't disagree with you that float layouts are terribad and shouldn't be used these days, but that's the beauty all those keywords in the CSS spec -- you don't have to use it. These days we have Flexbox & Grid, decently engineering solutions for layouts. > By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want. Could you de-jargon these sentences? Maybe this is where we differ, I think what you just described is more complex than CSS from principles. Also, I want to note that not many in this thread have stuck up for the simplicity/ease of use of AutoLayout.
  - skohan 8y ago
    > These days we have Flexbox & Grid, decently engineering solutions for layouts. Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts). Moreover, if mobile did just use a subset of CSS for it's layout system, you'd just worsen the fragmentation problem that CSS currently suffers from: in order to write "cross-platform" css, which you cited as one of the benefits of this approach, you would need to account for _even more_ platforms with slightly different APIs. To make a layout which works on, say, IE 9 and Android you would still have to implement twice, or resort to workarounds like polyfills. > Could you de-jargon these sentences? If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them. The point is that with autolayout, the total number of things you can do could be written on one page. You have a hand-full of general-purpose building blocks, and you compose them together to do whatever layout you want. That's compared to CSS where there's a large collection of tools, each of which has holes.
    - hardwaresofton 8y ago
      > Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts). And when was AutoLayout introduced? Even with that, it's evolved and been improved over time -- I bet you wouldn't want to use AutoLayout from 2016 today if you could avoid it. Either way, Apple could have introduced AutoLayout as a private extension of CSS that doesn't worry about being spec-compliant, without completely rebuilding their own framework for styling. Are you implying the android layout systems are older than CSS itself? Because one of the "good" parts of CSS I was talking about was basic targeting and separation of concerns between styling and layout. That's fundamental CSS, and long predates any mobile platforms. People writing mobile apps, especiallly native ones don't give a shit about cross-platform anything, I don't understand why you'd all of a sudden start worrying about that if you used CSS. I keep repeating this, but they can make their own private subset of the CSS spec that only their developers have to care about. You've framed the burden of cross-platform support as a bad thing, but it's a good thing -- whatever that cost is, you pay it once, for everyone -- you prefer a world where cross-platform support is just impossible? > If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them. This a common mindset that I've never agreed with. If you can't explain the simplest uses of your abstraction without a sentence full of jargon, this is a red flag for me, it's a shitty abstraction. Jargon is calcified complexity that is so burdensome to try and explain/analogize that you just pick a word and say it instead. This is like what people say who build ridiculous Java class/pattern riddled sand castles all day, then say that if I don't understand why they needed a AbstractThingFactoryMakerService then I didn't learn the basics. This is precisely why I will never willingly enter the quagmire that is fully native development, there are people like you in the wild waiting to justify any bad design decision the native platform makes once they've paid the cost of learning a subpar abstraction/re-engineering of a mostly solved problem that's been foisted upon them. You'll to shout how good AutoLayout is from the rooftops while devs flock to alternatives because of the BS. NativeScript and Flutter are gaining popularity because the platforms have issues. You can ignore it for however long you want.

skohan 8y ago

Just look at the CSS spec (or collection of specs): https://www.w3.org/TR/css-2017 https://www.w3.org/TR/css-2017 It's enormous! How could anything be intuitive when there are hundreds of keywords? To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: #MyDiv { clear: both; } "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases. By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.

hardwaresofton 8y ago
> Just look at the CSS spec (or collection of specs): > https://www.w3.org/TR/css-2017 https://www.w3.org/TR/css-2017 > It's enormous! How could anything be intuitive when there are hundreds of keywords? But I covered this though -- you don't have to take the whole HTML/CSS spec, because if you did you'd just be making a browser. Even if there are hundreds of keywords, you generally don't have to know (or support, as an implementer) every single one. > To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: [example] The example you gave is pathological -- a more reasonable one for a "basic design problem", which is what you said CSS was bad for: #MyDiv { background-color: black; } Your very next sentence betrays how pathological the case is: > "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases. "clear" isn't magic, it requires knowing what a float layout is, and having used a float layout before. It is a special case reserved for building float layouts, that is necessary because of how they work. I don't disagree with you that float layouts are terribad and shouldn't be used these days, but that's the beauty all those keywords in the CSS spec -- you don't have to use it. These days we have Flexbox & Grid, decently engineering solutions for layouts. > By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want. Could you de-jargon these sentences? Maybe this is where we differ, I think what you just described is more complex than CSS from principles. Also, I want to note that not many in this thread have stuck up for the simplicity/ease of use of AutoLayout.
- skohan 8y ago
  > These days we have Flexbox & Grid, decently engineering solutions for layouts. Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts). Moreover, if mobile did just use a subset of CSS for it's layout system, you'd just worsen the fragmentation problem that CSS currently suffers from: in order to write "cross-platform" css, which you cited as one of the benefits of this approach, you would need to account for _even more_ platforms with slightly different APIs. To make a layout which works on, say, IE 9 and Android you would still have to implement twice, or resort to workarounds like polyfills. > Could you de-jargon these sentences? If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them. The point is that with autolayout, the total number of things you can do could be written on one page. You have a hand-full of general-purpose building blocks, and you compose them together to do whatever layout you want. That's compared to CSS where there's a large collection of tools, each of which has holes.
  - hardwaresofton 8y ago
    > Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts). And when was AutoLayout introduced? Even with that, it's evolved and been improved over time -- I bet you wouldn't want to use AutoLayout from 2016 today if you could avoid it. Either way, Apple could have introduced AutoLayout as a private extension of CSS that doesn't worry about being spec-compliant, without completely rebuilding their own framework for styling. Are you implying the android layout systems are older than CSS itself? Because one of the "good" parts of CSS I was talking about was basic targeting and separation of concerns between styling and layout. That's fundamental CSS, and long predates any mobile platforms. People writing mobile apps, especiallly native ones don't give a shit about cross-platform anything, I don't understand why you'd all of a sudden start worrying about that if you used CSS. I keep repeating this, but they can make their own private subset of the CSS spec that only their developers have to care about. You've framed the burden of cross-platform support as a bad thing, but it's a good thing -- whatever that cost is, you pay it once, for everyone -- you prefer a world where cross-platform support is just impossible? > If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them. This a common mindset that I've never agreed with. If you can't explain the simplest uses of your abstraction without a sentence full of jargon, this is a red flag for me, it's a shitty abstraction. Jargon is calcified complexity that is so burdensome to try and explain/analogize that you just pick a word and say it instead. This is like what people say who build ridiculous Java class/pattern riddled sand castles all day, then say that if I don't understand why they needed a AbstractThingFactoryMakerService then I didn't learn the basics. This is precisely why I will never willingly enter the quagmire that is fully native development, there are people like you in the wild waiting to justify any bad design decision the native platform makes once they've paid the cost of learning a subpar abstraction/re-engineering of a mostly solved problem that's been foisted upon them. You'll to shout how good AutoLayout is from the rooftops while devs flock to alternatives because of the BS. NativeScript and Flutter are gaining popularity because the platforms have issues. You can ignore it for however long you want.