[HN Gopher] CSS findings from the Threads app
___________________________________________________________________
CSS findings from the Threads app
Author : davidbarker
Score : 200 points
Date : 2023-07-16 10:13 UTC (12 hours ago)
(HTM) web link (ishadeed.com)
(TXT) w3m dump (ishadeed.com)
| mgaunard wrote:
| Looks like normal CSS to me.
|
| Any CSS work eventually devolves to adjusting numbers until
| everything falls in line, adjusting for the 2 pixels of padding
| there or the borders of some other thing. Maybe nowadays there is
| calc where you don't need to do that, but it didn't exist back
| when I did CSS.
| dawnerd wrote:
| Yeah this read like it came from someone that hasn't done any
| real development based on designs. Not everything is going to
| be even numbers.
| swader999 wrote:
| On the plus side, CSS has fed a lot of children.
| Levitz wrote:
| To who?
| BiteCode_dev wrote:
| You mean a lot of :child()
| sksasi wrote:
| Is it still ok to use px unit?
| zamadatix wrote:
| px in CSS/web is just shorthand for 1/96th of an inch,
| regardless how many actual pixels that ends up being. This
| means it's functionally the same as any other absolute value of
| measurement on the web, since they are all based in some
| mapping to physical size as well.
| innocenat wrote:
| That's only true on (most) mobile devices. px is still 1
| pixel on Desktop with 100% system UI zoom (e.g. non-hidpi
| monitors).
| zamadatix wrote:
| It's still 1/96th of an inch in those cases, that's what is
| meant by "regardless how many actual pixels that ends up
| being".
| innocenat wrote:
| If you change system UI zoom setting then the 1 pixel
| size in the browser change with zoom. At 200% web 1px is
| actual 2px. I am not sure how it could be "1/96th of an
| inch" when it can change size depend on the system
| setting.
| zamadatix wrote:
| 1/96th an inch based on what the browser/system report
| the pixel density to be. There is no man coming out of
| your computer with a ruler to verify the reported value,
| so you're free to use a scaling value that isn't true.
| Zooming the browser or changing the system scaling will
| change the reported size of the pixels to the renderer.
|
| Don't take my word for it, it's how it's defined in the
| CSS spec: https://www.w3.org/TR/css-values-3/#absolute-
| lengths
| innocenat wrote:
| I know that is how its defined in the spec. But your
| original comment imply that it's literally 1/96 of an
| inch everywhere regardless of the device.
| zamadatix wrote:
| -\\_(tsu)_/-, to the browser - it is. It is a good note
| to point out the browser may not have an accurate sizing
| of the display and would produce incorrectly sized
| outputs in those cases, but it doesn't change how px
| sizing works.
| system2 wrote:
| I stick to percent personally. Easier to adjust if I am working
| on someone else's messed up css. rem/em depends on global
| values but many sites override these with different classes and
| manually entered pixel values. I find % to be safer than
| em/rem.
| shortcake27 wrote:
| I use relative units (ems/rems) for font sizes and absolute
| units (px etc) for everything else such as
| margins/paddings/borders. I also set the html font size to
| 62.5% which makes the math easy (1rem = 10px).
|
| This ensures that if a user adjusts their browsers font size
| for accessibility purposes or uses dynamic type, only the text
| will scale. You don't want margins/paddings to scale with font
| size (at least not linearly) otherwise the layout gets
| cramped/unusable very quickly.
|
| As others have mentioned CSS pixels have nothing to do with
| hardware pixels. So there are no issues with the differences in
| screen densities between devices.
| [deleted]
| Zren wrote:
| TIL about the dvh units used for the splash. The article even has
| a video of scrolling down with it.
|
| https://ishadeed.com/article/new-viewport-units/
|
| https://caniuse.com/viewport-unit-variants
| zagrebian wrote:
| For position:fixed elements, width:100dvh produces the same
| result as bottom:0. The dvh unit was not needed for this case.
| wackget wrote:
| Splitting mobile viewports into 3 separate properties seems
| incredibly hacky to me. I really can't believe it's an official
| CSS spec.
|
| IMO the browser makers are at fault for making the viewport be
| partially obscured under the UI.
|
| The viewport should be just that: viewable.
| bhouston wrote:
| The webgl effect on the threads website is called
| BarcelonaGalaxy:
| https://twitter.com/benhouston3d/status/1676939096122327045?...
| yosito wrote:
| Barcelona is also the name of the protocol for linking to
| Threads on iOS. A link to barcelona:// will open in Threads.
| madeofpalk wrote:
| Neat.
|
| Barcelona is/was the internal name for Threads.
| blowski wrote:
| I heard it was also called "Project 92", which is also the name
| of a (ostensibly unrelated) Tesla project.
| 4lejandrito wrote:
| The 92 Olympics were in Barcelona.
| cubefox wrote:
| Why do people find this interesting? It looks like perfectly
| normal usage of CSS.
| system2 wrote:
| [flagged]
| hobofan wrote:
| What an ignorant statement.
|
| This blog wasn't written _by_ a newbie, but _for_ newbies, to
| help them in breaking down a real world example of otherwise
| abstract CSS features.
|
| That blog is as far as I'm concerned the best blog about CSS
| and its new features that exists today.
| programmerbyd7y wrote:
| But did you actually read the blog post about "BS blogs"?
| Because it's not actually about blogs being BS and how one
| cares. It's about how you should care about what you are
| writing and tell everyone else to f-off.
|
| > This post likely was written by a newbie who is trying to
| enter programming world and by writing a blog about CSS
| paddings thus keeping his ego inflated
|
| What a weird statement to make. Like mindboggling weird.
|
| There's nothing wrong with newbies documenting things and
| writing up details on how things work. Because other newbies
| need it. And besides, haven't we all here figured out by now
| that the best way to learn something is teach others?
|
| I'm seriously at a loss for why you are arrogantly bashing
| and trying to shame for someone putting effort into
| understanding more about the world around them and trying to
| help others at their level understand. Your time is better
| off spending time understanding that the world doesn't
| revolve around you.
| mmcnl wrote:
| It's interesting to see how a big company with a lot of
| talented engineers would build a brand-new web app, since
| there's so many ways to achieve similar results.
| adamleithp wrote:
| CSS is a big part of the web and lots of people use it every
| day. I find this post interesting because it inspects a world-
| class app used by millions of people, and it showcases some of
| CSS's latest capabilities, plus it has nice graphics
| illustrating the findings!
| diamondfist25 wrote:
| I got asked how to center a div in an interview and got dinged
| for some class naming issues
|
| Tech interview industry really misses the point sometimes
| skrebbel wrote:
| I wasn't there so I can't judge, but if you got dinged about
| naming then maybe they interpreted that as you caring about "it
| works" but not about "team member reading the code understands
| why it works".
|
| Personally I'd be hard-pressed to move an applicant with a
| less-than-obsessive attitude to naming forward to the next
| round.
| lapcat wrote:
| > Personally I'd be hard-pressed to move an applicant with a
| less-than-obsessive attitude to naming forward to the next
| round.
|
| Why would you assume that impromptu interview code would be
| the same as production code?
| Kiro wrote:
| I would assume it to be much better than production code.
| stanleydrew wrote:
| It's of course not the same. But technical interviews
| aren't always just about "does this solution you wrote
| actually work." A good interviewer will be paying attention
| to how you solve the problem and how you communicate the
| choices you make along the way. Good naming is part of good
| communication.
| lapcat wrote:
| Except every interviewer has their own idiosyncratic
| criteria in their own mind, and they rarely practice good
| communication themselves by telling the job application
| ahead of time what those idiosyncratic criteria are
| exactly.
| ZanyProgrammer wrote:
| Nice, another comment showing the utter obnoxiousness of
| programming interviews.
| skrebbel wrote:
| Come on, naming is table stakes. It's nothing like the
| usual "please sort this red-black tree" that comes up
| during stupid interviews but never on the job. Naming comes
| up on the job _all the time_ and if you routinely get it
| wrong then over time you're likely to create more problems
| for your colleagues than you solve yourself, because they
| can't easily understand or refactor what you built. Ie
| you'll have negative productivity.
|
| When you're an interviewer you have to make a decision
| based on way too little signal. This means you zoom in on
| the things you do see, and you accept the chance that you
| might reject a great candidate. I can completely imagine a
| company rejecting a candidate because they didn't care
| about naming.
|
| Now if you think "worried that candidate might have
| negative productivity due to careless attitude, soft
| reject" is obnoxious then fine but I think that makes you
| spoiled. You're not entitled to a job, even a junior
| position, simply because you can write a loop or center a
| div. Real world engineering has more going on. Interviewers
| look for those signals, so better work on getting them
| right.
| lapcat wrote:
| > Come on, naming is table stakes.
|
| Every interviewer seems to have their own idiosyncratic
| version of what they consider "table stakes". So table
| stakes ends up being everything and nothing.
|
| > I can completely imagine a company rejecting a
| candidate because they didn't care about naming.
|
| Didn't "care" about naming, or didn't focus on naming in
| some little throwaway sample code for a job interview?
| tremon wrote:
| Naming is also something that the _team_ needs to decide
| on. As an interviewee applying for a position in an
| existing team, I would not expect to get dinged on my
| naming of variables for a piece of demo code. I would
| expect to conform to the team 's existing naming
| standards, so bringing and displaying my own
| preconceptions would be completely useless.
| skrebbel wrote:
| I'm not talking about capitalization, I'm talking
| descriptiveness, meaning, precision etc. You know,
| naming.
|
| The idea that naming is about someMethod vs Some_Method
| is nuts to me. Just choose a thing and do it. Naming is
| about words and meaning. It's hard, and it's important.
| gl-prod wrote:
| I mean if there is no format to follow I should use my own.
| Once inside the company I would follow their format or
| whatever.
| Theodores wrote:
| I would have failed too, however, the reason would be because
| of my insistence that there is always a better element to
| use. It even says so in the specification.
|
| With CSS grid you don't need div elements, ever.
| intrasight wrote:
| Article didn't have a link to the Threads site with this CSS.
| sarasasa28 wrote:
| https://www.threads.net/@zuck/post/CuP48CiS5sx
| dt3ft wrote:
| I'd love to be able to hire this guy to help me fine tune the UI
| of FlingUp :)
| hobofan wrote:
| Well there is a "hire me" button in the header, so it looks
| like you are in luck!
| dmix wrote:
| This sort of blog showing dominance of advanced CSS is a really
| great job-getting tool. He will surely be in demand.
| lapcat wrote:
| > This sort of blog showing dominance of advanced CSS is a
| really great job-getting tool. He will surely be in demand.
|
| Hiring managers: "We don't have the time to read the blog
| posts of job applicants".
| dmix wrote:
| Getting HR people to choose developers is a terrible
| strategy lol
|
| We get our programmers involved in that process since they
| are the only ones capable of knowing. Although we're a
| small company.
| tester756 wrote:
| Cool to see grid example in the article!
|
| When I've witnessed Flexbox and Grid (esp. templates) for the
| first time I liked Grid more, but as I've seen Flexbox more
| commonly used in the industry grid-template-
| areas: "avatar header" "avatar body" ".
| body" ". footer";
| sarasasa28 wrote:
| When I learnt css for the first time, floats was the standard
|
| 10 years later, kind of, I got back into web dev and css and
| learnt about flexbox, what an incredible difference. I was so
| thankful I wouldn't have to deal with floats ever again
| bruce511 wrote:
| I built a web framework in 2005 based on table layouts. Years
| later I switched to Flex (when it was available, and when Grid
| was still poorly supported.) Some years ago I switched to Grid
| because it was more generally supported.
|
| So I expect that what you are mostly seeing is the evolution of
| CSS, from table to flexbox to grid. Table has no real
| responsiveness (to screen size), Flex does it _really_ well
| (especially for cases where the target is both PC and Phone
| etc.) But it has some limitations (mostly for me around column
| widths and the concept of "relative" column widths.)
|
| Grid is really nice, it's a lot more like tables in concept,
| but at the same time has responsive abilities. These days I'm
| grid-first, although there are still a few places (depending on
| context) where flex is more appropriate.
|
| Of course flex is also more "well known" (because it's older.)
| I feel a lot more comfortable there still, and until we have
| sub-grids I'm also a fan of using Grid layout for the "outside"
| and using Flex inside specific cells.
| tough wrote:
| Thanks I ususally default to Flex because is what I know
| better, I have to fill the gaps with grid knowledge in there.
| innocenat wrote:
| I love grid because it allow me to position elements anywhere
| in the grid without needing wrapper elements like with
| flex/float. That allow nearly full freedom in layouting the
| same HTML for different complex layouts targeting different
| screen width.
|
| Though while grid borrowed a lot of ideas from flex, the
| creative usage of the grid template is so vast that you
| probably need to also learn by examples.
| laurels-marts wrote:
| Maybe a stupid question but what do you use for the outermost
| wrapper div that controls the main page layout? Flex or Grid?
| ThatMedicIsASpy wrote:
| Depends on the content and amount of content. I would say
| you can do the same layout with both. The main advantage of
| grid and named layouts is that you can move them anywhere
| you want. You are not bound by the order of html elements.
| bruce511 wrote:
| Yeah, it varies. Sometimes gris, sometimes flex.
| stefanfisk wrote:
| The top padding in the avatar is probably to align it with the
| cap height of the username.
| ibiza wrote:
| I find the bifurcation between HTML elements and CSS statements
| maddening. Structural things like flexbox and grid would be far
| clearer as HTML element types.
| stefanfisk wrote:
| How would that work when you need to switch stuff like
| `display` responsively?
| manuelmoreale wrote:
| Care to share an example of what you mean? Because I don't
| understand how that would look honestly.
| c-hendricks wrote:
| See any grid component in a library for React for example.
| manuelmoreale wrote:
| Ah so everything kinda inline? But how do you deal with
| change of layouts then? Like, sometimes I code sites where
| the inner structure changes a lot and that's trivial when
| paired with media queries but it would be a pain to handle
| if everything is inlined or tied to the markup.
| [deleted]
| c-hendricks wrote:
| the Grid from Mui / joy UI, for instance, let's you set
| sizes for different screen witdhs via props:
| https://mui.com/joy-ui/react-grid/#introduction
|
| Since it's done with JSX/Props, it's API is a 1:1
| translation to a new HTML element.
| buskila wrote:
| Are all these things mentioned in the article implemented in
| native apps or the web version is just nicely embedded in a
| webview?
| mkoubaa wrote:
| I've found that with enough effort and time I could eventually
| learn any programming concept.
|
| The only exception I've encountered in my career is CSS. I'm no
| more effective at it than I was when I first tried using it.
| zagrebian wrote:
| How often do you read the CSS specs?
| mkoubaa wrote:
| From start to finish, never. When I had a problem I googled
| what to do and read the specs of the suggestions that I saw
| to try to make sense of them. Usually they were not helpful.
| millerm wrote:
| CSS seems like it was "designed" by several teams in an "agile"
| environment with no plan and simply didn't consult the people
| that would actually be using it.
| afavour wrote:
| I've still not gotten to grips with CSS grid, mostly because
| flexbox does what I want so I end up falling back on it at the
| first hurdle. But the rest of it is very clear to me these
| days.
| FireInsight wrote:
| Most, even 2D layouts map easily into nested 1D flexbox in my
| head. I feel like a single dimensional approach to layouts is
| way easier to wrap my head around and design with.
| renegade-otter wrote:
| Rachel Andrew has a very good 3-part tutorial that helped me
| actually understand what I am doing:
| https://www.smashingmagazine.com/2020/01/understanding-
| css-g...
|
| It will take you from a n00b to a Grid pro in no time.
| quietbrain wrote:
| This is a really surprising take for me, grid is by far the
| most sane of the layout models in my experience.
| nicoburns wrote:
| IMO CSS Grid is actually much simpler and better designed
| than Flexbox. I'd recommend taking a proper look when you get
| a chance.
| brigadier132 wrote:
| They solve different problems.
| quietbrain wrote:
| Correct. but grid is simpler to take in on the face. flex
| needs a bit of understanding.
| ZanyProgrammer wrote:
| This is the kind of HN comment I come for in these kinds
| of threads. One person saying one thing (CSS Grid is the
| one thing keeping me sane!) Another person coming in to
| say the exact opposite.
| brigadier132 wrote:
| I'll be a little more helpful since I wrote a one liner
| without really explaining anything...
|
| One explanation people like to give is:
|
| CSS Grid is for layouts in 2 dimensions, Flexbox is for
| layouts along one dimension.
|
| Which can be confusing because you absolutely can use
| Grid for layouts along one dimension too.
|
| Here is my stupid sounding rule of thumb that I think is
| more useful: If you want a grid layout use grid, if you
| want a flexible layout use flexbox.
|
| Grid quite literally splits the area into a grid but what
| if you want to just say "I want these two elements to be
| as far apart as possible within the container they are
| in" (ie a navbar, you want the logo on the left about 20
| pixels away from the left of the viewpoert and you want
| the actual navigation to be on the right with the
| rightmost element 20px away from the right of the
| viewport). Flexbox is better for that.
| nicoburns wrote:
| I do often end up using Flexbox for 1-dimensional
| layouts, but IMO Grid's fr units are a lot more intuitive
| than Flexbox's combination of flex-basis/flex-grow/flex-
| shrink. If CSS added a 1-dimensional layout mode based on
| these principles then I'd switch to it in a heartbeat.
|
| (I'm considering proposing one myself).
| jakear wrote:
| What bugs me the most is Flex centering absolutely sucks
| at handling overflow. Have a flex box with content that
| is supposed to be centered? Great, looks perfect for the
| first few items. But then try it on a smaller window or
| with more items and the content overflowing to the left
| of the border will be _entirely inaccessible_.
|
| Allowing scrolling both ways would have been perfect.
| Switching to left-aligned when content overflows would be
| acceptable. But completely prohibiting access to half the
| content when an overflow occurs? Absolutely asinine.
|
| I believe there may be ways to get around this with
| layers of inner divs and weird `overflow: ` incantations,
| but that's exactly the kind of bullshit flex was supposed
| to solve.
|
| See https://developer.mozilla.org/en-
| US/docs/Web/CSS/align-items. If you need to enable a
| "safe" mode to _prevent data loss_ , and that isn't
| supported on _any_ mainstream browsers... you fucked up.
| hoosieree wrote:
| CSS grid feel like someone asked TikTok to design a rectangle
| and said yes to every suggestion.
| ipaddr wrote:
| What does this meab?
| shortcake27 wrote:
| I think they mean it's a complicated solution for an
| uncomplicated problem.
|
| Grid systems existed long before CSS grid and were dead-
| easy to understand and use (960, Bootstrap etc). CSS
| grid, by comparison, is completely unintuitive. Sure,
| it's definitely more powerful, but the barrier to entry
| is way higher.
| hoosieree wrote:
| Exactly. "Align things to a grid" seems like a simple
| concept, but CSS grid seemingly has at least 3 ways to
| place the top-left corner of an element, and it just gets
| worse from there. I tried it for a simple layout with 3
| elements and quickly decided I prefer flexbox, tables, or
| even floats.
| aardshark wrote:
| I think when you come across situations that only grid
| can solve, then you appreciate it a bit more.
|
| Flexbox complements grid imo, it's not an alternative.
| ripley12 wrote:
| I found that Tailwind helped me get more comfortable with CSS.
| If you put the mechanics of using classes aside, it's
| essentially just a well-curated subset of CSS with great
| documentation. Way more approachable than the sprawl of CSS
| itself.
| renegade-otter wrote:
| I only do UI for business-facing apps and my own projects. CSS
| Grid _massively_ improved my frustration with CSS. It makes it
| much easier to reason about how your page layout works.
|
| I will never ever do another layout without it, stuck together
| by glue, snot, and magical trial-and-error.
| mundiff wrote:
| It's one of those things that frameworks had been doing since
| (before?) 960gs. A Grid really needed to be incorporated into
| CSS and I'm happy to use it or flexbox for layout purposes
| depending on my use case.
| manojlds wrote:
| Try tailwind. It can help you get better at CSS itself.
| moltar wrote:
| It's because CSS is a constantly moving target of massive
| conceptual differences from the last one. Plus all the tooling
| changes frequently as well.
| gardenhedge wrote:
| I'm the same. I just use ChatGPT to fix my layouts now.
| mkoubaa wrote:
| Colleagues have suggested the same. My strategy has been to
| try to avoid frontend and when I must do it I make sure
| everyone involved understands my limitations.
| code_runner wrote:
| The secret for me was working with something like tailwind etc
| and in a componentized framework.
|
| the framework part isn't mandatory, but I suppose very small
| tweaks with something like tailwind do the trick for me.
|
| I can't work with css if there are massive classes and nested
| stuff etc. I guess composition over inheritance
| pavlov wrote:
| I feel the same way, and I first wrote CSS in 1998 when it was
| so new that Netscape misinterpreted even the font size
| property.
|
| There are now thousands of properties and their values, and
| browser engines have gone to heroic lengths to produce mostly
| consistent results from these often conflicting directives. But
| I still keep looking up basic things because the API is
| simultaneously sprawling and inexpressive and context-
| sensitive.
|
| IMO, the core sin of CSS is mixing up three separate concerns:
| element styling, layout, and compositing. It's mostly ok for
| the first. It's insanely confusing for the second. And it
| mostly tries to pretend it's not about the third at all, which
| leads to weird situations around implicit compositing groups.
|
| We ended up here because CSS started as basically a copy of a
| handful of Microsoft Word dialog boxes (hence "float" etc.) And
| as soon as we had got the word processing use case barely
| working, everybody decided they wanted to build dynamic
| applications with this same engine instead.
| tannhaeuser wrote:
| The core sin 0 of CSS is introducing another item-value
| syntax to the stack when there are regular markup attributes
| for that exact purpose already. Then it gets worse by taking
| this simplistic syntactic device ad absurdum, only to then
| finally also start introducing expressions (calc(), custom
| properties, media queries). Really, CSS should've been sealed
| a long time ago, with a low-level API a la Houdini available
| for programmatic layout from JS rather than bloating the
| language to become accidental Turing, when these highly
| dynamic styling features are useful for JS apps anyway.
| Anyway, considering its complete lack of mental discipline
| and basic CompSci, the CSS WG at W3C has no business
| designing languages IMNSHO.
| brigadier132 wrote:
| I completely disagree. If CSS were "sealed" it would be
| absolutely terrible and we'd still be dealing with floats
| and absolutely positioned elements. The problem with CSS is
| the weird implicit behavior and edge cases that remain due
| to compatibility.
|
| Computed properties, custom properties and media queries
| are well designed.
| philistine wrote:
| What CSS needs is a refactor. Make a much smaller Strict-
| CSS that uses the same code paths in browsers, but
| provides far less options to the user, sticking to modern
| tools (grid, flex) with simplified naming schemes, while
| deprecating old ways of doing (float). That would finally
| allow a manageable mental model.
| gorbypark wrote:
| That's one of the great things about react native and
| react native web. It's like CSS with about 25 years of
| crud removed.
|
| Of course there's some downsides, but it's refreshing to
| use.
| mkoubaa wrote:
| What do you think can be done about this, at the browser,
| tooling, or library level?
| ChatGTP wrote:
| I solved it by using tailwind css :)
| programmerbyd7y wrote:
| What options exist today for making CSS easier? (It's been a
| long time since I've done front-end work)
|
| Seems like there would be some sort of layer on top of it that
| someone built that makes things more consistent and then will
| compile down to the inconsistencies and odd behaviours for how
| CSS is supposed to be implemented.
| FireInsight wrote:
| There's supersets and siblings like scss, sass, less, there's
| different modes entirely like utility classes (Tailwind) and
| css-in-js.
|
| I don't think any of those make CSS much easier, though.
| Quicker to use, easier to write certain things, sure. But you
| still need to know your way around CSS atleast somewhat
| before you jump in to some augmentation or replacement.
| _a_a_a_ wrote:
| Try XSLT. The only programming language that ever defeated me
| and I've used quite a few including Haskell.
| mkoubaa wrote:
| If I have a reason to I will. Im generally not motivated to
| learn things to pad my ego, I need a more tangible reason.
| throw_m239339 wrote:
| XSLT is a functional language. I say writing DTD and stuff
| like that is harder than XSLT. XSLT is actually pretty fun to
| write.
| gmac wrote:
| I found XSLT kind of mind-bending, but also extremely
| satisfying and quite productive. Like SQL, it's declarative,
| so you have to get into the mindset of telling the computer
| what you want, not what to do.
| _a_a_a_ wrote:
| You may be a smarter person than me, but I couldn't handle
| it and quite possibly that was partly related to its truly
| appalling XML-based syntax. I'd like to point out that no
| other language I'm aware of is so syntacticallyvile that
| they have to add a new mechanism just to pass parameters
| around - parameter tunnelling.
|
| https://www.w3.org/TR/xslt20/#tunnel-params
| aidos wrote:
| Oh Lord. You've just triggered a horrific memory of how in
| my first job we used XSLT to convert xml files of job
| applications into sql that was then executed to import them
| into the db. That truly was mind bending.
| dmix wrote:
| The "fun" part of being a frontend dev who naturally gets
| pushed into fullstack as part of the realities of the job is I
| have to keep on top of developments in CSS, UI frameworks,
| Typescript, Vue, testing frameworks, Ruby, Rails, etc. Not to
| mention the build tooling (Vite/webpack) and deployment /
| operating system stuff. Fortunately the database stuff rarely
| changes with Postgres.
|
| I wish I could specialize on any one of these sometimes...but
| such is life at a startup. It's more interesting being able to
| do them all anyway and be able to build entire apps yourself.
| Just occasionally frustrating.
| crosen99 wrote:
| Same here. I think it's because you typically conquer a
| language by developing a fairly complete mental model of that
| language's behavior, but with CSS there are just too many nooks
| and crannies to get your had around. While it's uncomfortable
| for me, I find that I do best with CSS when I take a more
| practical approach and just try to use best practices to
| accomplish what I want without having the deep understanding
| that I crave.
|
| I've found that Kevin Powell [1] is a great resource for this
| approach, and he also helps with the model model aspect as a
| bonus.
|
| [1] https://www.kevinpowell.co/
| madeofpalk wrote:
| Is there another layout language/engine that you've found more
| intuitive and flexible?
| mkoubaa wrote:
| After a couple hours of using xaml I felt like I learned
| something. But I didn't spend more time on it.
| DHPersonal wrote:
| I really benefit from reading comments like this, so I
| appreciate your honesty. I didn't start learning JavaScript
| until very recently, even though I was making my own personal
| websites back when Angelfire, Geocities, and Tripod were still
| a thing. Instead, I focused on the frontend HTML/CSS combo,
| constantly learning and implementing new CSS technologies
| whenever I had an excuse to try them out. Because of that
| specialization, CSS feels understandable to me. My insecurities
| about my own abilities often present themselves as a belief
| that investing time in CSS was the growth of a cheap and
| relatively useless skill for a web development team. Whenever I
| see that someone who likely knows incredibly more about
| JavaScript and other programming languages -- things that I
| feel are far harder to understand than CSS -- share about how
| either HTML or CSS is difficult to use, I feel a little more
| confident that I do bring some value to the team with whom I
| work at the office.
| fendy3002 wrote:
| Because most css without context are useless. A div with width
| 100% may not stretch depending on it's content and parent css.
| It's even worse on positioning, margin and responsiveness.
|
| Which is why if you don't interact with it day to day basis,
| you'll need some trial and error, as well as references and
| examples.
|
| Opposite to backend or usual programming where `foo = foo + 1`
| is most of the time do an increment by one (exception apply)
| gochi wrote:
| Backend or usual programming without context is also useless.
| Is foo even mutable? Is it the same type? How does type
| conversion work here?
|
| CSS and usual programming are identical. If you don't give
| yourself the time to learn the fundamentals, you'll always
| run into tedious problems.
| bombolo wrote:
| I know the fundamentals. Doesn't help :D
| alwillis wrote:
| A lot of people learned the fundamentals incorrectly.
|
| A good place to learn how CSS was designed to work is
| Every Layout at https://every-layout.dev/.
| gochi wrote:
| Maybe it's time to relearn the fundamentals! web.dev and
| MDN are great resources to do so. Start with the Box
| Model.
| XajniN wrote:
| Fundamentals don't help when you are 15 divs deep.
| marcosdumay wrote:
| You have made some bad decisions if you find yourself 15
| divs deep.
|
| There is a surprisingly small amount of content out there
| on how to competently engineer your CSS (and a lot of it
| is bad). Most people don't even think it's something you
| do.
|
| But basic things like making your general rules generic
| and pushing context descriptively into the HTML go a long
| way into making your code understandable.
| bombolo wrote:
| > You have made some bad decisions if you find yourself
| 15 divs deep.
|
| Open instagram.com in a browser :D
| XajniN wrote:
| Not my choice, that's what you get when you inherit an
| Angular website.
| dmix wrote:
| There's a lot of unpredictable stuff too. I was trying to
| change the border color of a checkbox to match a framework
| being used elsewhere and for the life of me couldn't figure
| out why neither setting outline or border changed it. But on
| the framework's website demo it was doing it just fine.
|
| Combing through the CSS and the computed styles panel in dev
| tools gave me nothing.
|
| It turned out there is an option to disable the standard OS
| form theming which isn't communicated at all in dev tools for
| that element (and I hadn't seen --webkit-apperance used
| before as the guide says you really shouldn't mess with it):
| https://developer.mozilla.org/en-US/docs/Web/CSS/appearance
| aidos wrote:
| Weeeeeeeell a div is 100% width by default. It will always
| fill the width of the parent container unless you explicitly
| change the width.
| fendy3002 wrote:
| Afaik div width property is almost useless if the parent
| set the display as flex, or if the div has no content.
| aidos wrote:
| That's kinda the point of flex though. The width is
| determined by the flex rules; width 100% doesn't make
| much sense in that context.
| have_faith wrote:
| 100% isn't the default value, 'auto' is. Which has the
| effect of appearing 100% in many scenarios. But not all.
| aidos wrote:
| Fair, but actually that just means that the border and
| margin etc are pushed outside the container. In either
| case the div is operating by taking up the full width of
| the container.
| truckerbill wrote:
| Not if the parent or ancestors don't have a width set...
| Hence why you need context.
| aidos wrote:
| The parent has _some_ width, even if it's not explicitly
| set.
| gravitronic wrote:
| I was like you until about a year or two ago, and then set out
| to learn it enough to implement a site layout without having to
| resort to copy and pasting things I don't understand.
|
| It wasn't that hard, once you accept that it'll require it's
| own study and practice. I put in maybe 20 hours dedicated study
| and got a lot better out of it.
|
| I did a few video courses on LinkedIn Learning (formerly
| Lynda.com) through my public library. I did a general CSS
| course and a flexbox CSS course. Then I set out to design pages
| I needed without pulling some random blog theme and calling it
| a day.
|
| I've gotten a bit better at design as well, although it is a
| much intrinsic field than CSS and requires a lot more study.
| The biggest difference was once I treated the design stage with
| respect as its own discipline and started designing in a design
| tool (figma) instead of "doing it live" by trying to tweak the
| design in code as I went. It made me 100% focused in that stage
| at the design problems and the feedback loop got a lot tighter
| compared to editing and running code to see how it looked.
| mkoubaa wrote:
| I admire your dedication. In my case I saw no improvement
| when I tried to learn it
| draw_down wrote:
| [dead]
| MildRant wrote:
| CSS is a lot like Regex to me. I learn enough to do what I need
| to do then immediately forget everything.
| eutropia wrote:
| if css made as much sense as regex I might actually enjoy
| front end work - there's no underlying mathematical theory
| that explains css
| nicoburns wrote:
| > there's no underlying mathematical theory that explains
| css
|
| There's a well-defined algorithm (well, set of algorithms)
| that explain it, which you can learn if you so choose.
| gochi wrote:
| Understand the Box Model and you'll understand all of CSS.
| tremon wrote:
| Hogwash. Where in the box model are the precedence rules
| for selectors defined? How does the box model help with
| page layout and positioning? Animation? Transformations?
| Pagination?
|
| Sure, the box model is a prerequisite to understand CSS
| properly. But if you think the box model covers all
| aspects, you really don't know very much about CSS.
| never_inline wrote:
| Usually it's not the Automata theory parts of Regex that
| people find hard. It's the syntax.
___________________________________________________________________
(page generated 2023-07-16 23:02 UTC)