[HN Gopher] Is there too much CSS now?
___________________________________________________________________
Is there too much CSS now?
Author : daemond
Score : 103 points
Date : 2022-11-07 16:18 UTC (6 hours ago)
(HTM) web link (css-tricks.com)
(TXT) w3m dump (css-tricks.com)
| grepLeigh wrote:
| No, it's amazing what you can accomplish with CSS now! You used
| to have to listen for user events with Javascript (later jQuery,
| around 2006) to add/remove CSS classes. There was no :hover
| :focus etc.
|
| Today, CSS pseudo-classes cover just about every transition state
| you need when designing a web application.
|
| I appreciate the approach frameworks like Tailwind are taking to
| CSS. At first I found it awkward to include so many classes in my
| markup, but I've come to appreciate the flexibility (without
| surprising behaviors).
|
| 10 years ago, I caused all kinds of headaches for myself by
| trying to customize .btn with crap like a#sales-promo-1.btn
| a#sales-promo-2.btn - truly a mess.
| bryanrasmussen wrote:
| >There was no :hover :focus etc.
|
| All those were in the spec in 2006 (ok not sure about focus
| pseudo selector but I think so, I mean first-line was supported
| focus must have been), unfortunately due to MS they were not
| completely implemented for every element they were specified so
| and thus the jQuery hacks you remember.
| grepLeigh wrote:
| Thanks for the extra details here! I've largely forgotten
| everything except the intense feelings of frustration.
| [deleted]
| camtarn wrote:
| For anybody who's as confused as I was: :hover and :focus have
| been around since CSS2, which was released in 1998 ... but
| Internet Explorer only supported them on links for a long time,
| not on arbitrary elements, so that was where jQuery came in.
|
| Ahh, I really really don't miss those days, and I'm rather
| happy to have reclaimed the giant chunk of memory that used to
| hold things like quirks mode and hasLayout.
| grepLeigh wrote:
| Ahh thank you, I had forgotten the exact details! I still
| remember the burning frustration like it was yesterday
| though, hah.
|
| CSS/HTML were my gateway into the tech industry though, so
| I'm glad I pushed through it. In retrospect, I could see why
| most "real programmers" were happy to push this tedious work
| over to me.
| politelemon wrote:
| Too much CSS, possibly.
|
| Too much cognitive load, definitely, I do think so. As a whole,
| modern CSS features feel unintuitive and often require a
| historical knowledge of the problems this new feature X was
| trying to solve, which means to me, it's laden with baggage. Some
| new CSS feature pages on MDN are absolutely gigantic in their
| explanations, and that means that there is a lot of 'talking'
| required to overcome its unintuitive nature. Of course, once you
| start using it, it becomes just another tool.
| tikhonj wrote:
| I've just started playing around with CSS after a seven year
| break from web programming and have the _opposite_ impression.
| The two biggest additions I 've seen are flexbox and grid both
| of which massively decrease the cognitive load--compared to
| past options, it almost feels like cheating. Moreover, they do
| this by consciously _not_ building on top of past layout
| features but instead doing their own thing.
|
| CSS is still a mess of random features that can't be cleanly
| composed or extended--it's the complete opposite of a language
| that can grow[1]--but it's a more usable mess than it used to
| be.
|
| [1]: Wonderful talk on language design by Guy Steele:
| https://www.youtube.com/watch?v=_ahvzDzKdB0
| naasking wrote:
| > CSS is still a mess of random features that can't be
| cleanly composed or extended
|
| The lack of orthogonality and composability has always been
| the core issue. It's definitely better now, and atomic CSS
| makes this pretty close to simple.
| alwillis wrote:
| _CSS is still a mess of random features that can 't be
| cleanly composed or extended_
|
| If you separate old CSS from new CSS, it's not so bad.
|
| Yes, CSS has some technical debt from the olden times (like
| any programming language does) but these days, you need less
| and less of the old stuff.
|
| For example, all of the alignment stuff created originally
| for Flexbox (justify-content, align-items, justify-self,
| etc.) were broken out in their own specification [1] and now
| CSS Grid and any future specification uses the same
| terminology to describe how to align something in a box.
|
| Instead of every color model having it's own syntax, which is
| how CSS started, there's now color functions that can specify
| _any_ color in any color space [2].
|
| [1]: https://drafts.csswg.org/css-align/
|
| [2]: https://drafts.csswg.org/css-color-5/#color-function
| Frotag wrote:
| > As a whole, modern CSS features feel unintuitive and often
| require a historical knowledge of the problems this new feature
| X was trying to solve
|
| There's no real way to debug unexpected behavior short of
| digging through the W3 spec. For example you can't set height /
| width on inline elements, but you'll never see any error
| messages or warnings in devtools / IDEs when you try. It
| doesn't help that tutorials rarely discuss how "layout
| algorithms" [0] (block, inline, flex, grid) affect certain
| rules.
|
| [0] - https://www.joshwcomeau.com/css/understanding-layout-
| algorit...
| alwillis wrote:
| _you 'll never see any error messages or warnings in devtools
| / IDEs when you try._
|
| I've seem dev tools highlight code that either doesn't make
| sense or doesn't have any affect.
|
| I wonder if something like Stylelint [1] would catch this.
|
| [1]: https://stylelint.io
| sbf501 wrote:
| > Too much CSS, possibly. > Too much cognitive load,
| definitely, I do think so.
|
| That's a good way to put it. AFter reading those two
| statements, it started to occur to me that a well-organized
| concept can have breadth, but not tax one's cognitive
| facilities. I think of programming languages. They ALL started
| simple, but then accrete. Look at K&R's original C, then look
| at C2x. The cognitive load increases. Like you said, "require a
| historical knowledge"[1].
|
| Do you think this is inevitable? I tend to think languages need
| major overhauls and backwards-compatibility breaking in order
| to become "cleaner". Intel & the PC maintained massive
| backwards compatibility, but parts of the architecture are a
| nightmare (like the intel instruction decoder); whereas early
| Apple tossed backwards compatibility routinely for better tech
| (now they do it for profit, I'm afraid). Same with Windows v.
| (early) MacOS.
|
| When was the last time there was a major shift away from
| backwards compatibility in HTML/CSS? I don't think there has
| been... has there?
|
| [1] (there was a post the other day on HN where a programmer
| was talking about a text editor and how he used nonprintable
| unicode to indicate new pages: this young cub had apparently
| never heard of the first 31 characters of ASCII!!)
| Sohcahtoa82 wrote:
| > When was the last time there was a major shift away from
| backwards compatibility in HTML/CSS? I don't think there has
| been... has there?
|
| The W3Schools page for <frame> says it is not supported in
| HTML 5 [0]. The MDN page for it warns that it may be removed
| from browsers at any time, though the compatibility table
| says it's still supported in every browser.
|
| [0] https://www.w3schools.com/tags/tag_frame.asp
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/fr...
| thfuran wrote:
| >Do you think this is inevitable? I tend to think languages
| need major overhauls and backwards-compatibility breaking in
| order to become "cleaner".
|
| I think it's pretty much inevitable when use case and/or
| feature set significantly changes but there's not a
| comprehensive overhaul of existing work. I think programming
| languages, code bases, and even cities all have basically the
| same issue: if the goal or the environment has significantly
| changed after a lot of work has been done, you're likely to
| end up with a final product that isn't what you'd choose if
| you were starting today.
| alwillis wrote:
| _When was the last time there was a major shift away from
| backwards compatibility in HTML /CSS? I don't think there has
| been... has there?_
|
| Yes; in the early 2000's, the W3C created XHTML 2.0 [1], a
| strict XML-based re-implementation of HTML. Because it
| dropped backwards compatibility to HTML4, it created _a lot_
| of backlash that (eventually) resulted in the browser vendors
| forming their own standards organization (WHATWG) which lead
| to the creation of HTML5.
|
| [1]: https://en.wikipedia.org/wiki/XHTML#XHTML_2.0
| alwillis wrote:
| _As a whole, modern CSS features feel unintuitive and often
| require a historical knowledge of the problems this new feature
| X was trying to solve..._
|
| Disagree.
|
| The beauty of CSS Grid and Flexbox is that you don't need to
| know _anything_ about the hacks and work-arounds which were the
| industry standard to approximate what these specifications give
| us today.
|
| The reason why you see seasoned web developers go on and on
| about how it used to be is due to how unintuitive and fragile
| those methods were compared to today.
|
| It's similar to young people today: they don't need to know
| anything about using a modem to dial-up to an ISP to access the
| internet in the age of broadband and Wi-Fi.
| bob1029 wrote:
| No. It's finally getting to be reasonable. The hackarounds are
| being displaced in droves now.
|
| Ever since CSS grid became a thing, I dumpstered all of the 3rd
| party web framework stuff I had been using. Placing elements in
| the right parts of the viewport (across all target devices) has
| always been 95% of the reason I consumed 3rd party libraries.
| jancsika wrote:
| What's the best reference and tutorial for modern CSS grid
| compatible across the standard browsers?
| bob1029 wrote:
| Maybe start with MDN?
|
| https://developer.mozilla.org/en-
| US/docs/Learn/CSS/CSS_layou...
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/grid
| blueslurpee wrote:
| In addition to the sibling you might like:
| https://cssgridgarden.com/
| chiefalchemist wrote:
| Wes Bos has a freebie
|
| https://cssgrid.io/
|
| CSS Tricks also has
|
| https://css-tricks.com/snippets/css/complete-guide-grid/
| mumumu wrote:
| The official spec is quite good.
|
| See csswg
| alwillis wrote:
| https://gridbyexample.com
| petepete wrote:
| I found watching Kevin Powell's intro on YouTube really
| helpful. I already had a basic understanding of grid before
| watching it, but this helped me make sense of the snippets
| I'd pieced together in my brain over the last couple of
| years.
|
| https://www.youtube.com/watch?v=rg7Fvvl3taU
| quechimba wrote:
| His channel is really good, I've learned a lot
| ericmcer wrote:
| Do you find element placement to be a one and done solution in
| regards to using grid, flex or table? Or do each have their own
| use cases? I tend to default to flex for most things because I
| am very comfortable with it.
|
| I guess I find keeping all the css properties in my head for
| all the different placement solutions cumbersome, flex and
| especially grid have a huge amount of functionality and custom
| properties, and I have been achieving everything fine using
| flex and a table when I need a literal table of data.
| bob1029 wrote:
| The general rule is that grid is for 2d layout and flex is
| for 1d layout.
|
| I almost always combine the two by way of a nested hierarchy
| of elements. Grid is used for the strategic layout, and then
| within each area I may have flex (or more grid) as
| appropriate.
|
| As for a "literal table of data", I still use table elements
| for this exact purpose. I do _not_ use tables for layout
| anymore, unless its for HTML email.
| nathias wrote:
| flex everything, it behaves much smoother
| swagasaurus-rex wrote:
| I've struggled with children sizing in flex. Children take
| up more space depending on their content. If the content
| overflows, flex doesn't handle that well either.
|
| Grid seems to handle this better when you specify grid-
| template-column.
|
| Anybody know a good flex-specific solution?
| mumumu wrote:
| Maybe this: https://drafts.csswg.org/css-rhythm/
|
| The searchable keyword for that is "responsive".
|
| Using length units related to viewport size on max-widht
| may help.
| serpix wrote:
| Grid everything, it has everything flex has and mixing the
| two makes one want to rage quit.
| politician wrote:
| Yes, but consider that the broader web is littered with answers
| to questions predicated on old misunderstandings of CSS. How
| long will it take for outdated answers on Stack Overflow,
| Quora, and the SEO farms that rehash Q&A or use AI-generated
| text to drop from the search rankings?
|
| The information environment is absolutely saturated with
| pollution from outdated answers to outdated questions. So while
| CSS might be getting to be reasonable, good luck to the random
| newbie trying to get things to work.
| wnevets wrote:
| > Ever since CSS grid became a thing,
|
| I find myself having to relearn Grid every time I try to use.
| It actually reminds me a lot of RegEx. Super powerful and
| helpful but nothing about it sticks in memory.
| mumumu wrote:
| Me too. But nowadays you can define them with with something
| like a ascii table.
|
| Also, check "massonary".
|
| There are so many cool features in css being released today
| that soon that banner "Best viewed on Netscape 3 on 800*600
| resolution" may be common in some niche design sites.
|
| But more likely as "Best viewed on Google Canary xxx, on flip
| screen devices with 10 bit depth colorspace".
|
| By the way, did you know there is a css spec for rounded
| screen devices?
| rglover wrote:
| The youngins' have no idea how good they have it. I'm an IE6
| veteran and comparing now to then, today's CSS is a dream.
|
| I think most people dislike it nowadays because it requires two
| skillsets: visual creativity and technical aptitude (most people
| can only fulfill one of those halves).
|
| It can be easy to project shortcomings in visual creativity onto
| the language which I don't think is very fair but I tend to see
| often being at the root of people's dismissals of the language.
|
| If you're just taking designs from someone else and implementing
| them, the CSS part of front-end is comparatively _easy_ to what
| it was just a decade and change ago. It 's still not perfect (and
| never will be with competing browser vendors/rendering engines),
| but the time investment to implement complex designs is
| substantially less than it was. That's a win.
| SadWebDeveloper wrote:
| This is half-empty vs half-full glass of water problem... let me
| explain.
|
| CSS is bloated because it needs to be bloated, do you remember
| the days before CSS? no, well we use to relay a lot from the HTML
| Spec (thats why some ppl kept pushing for some weird things like
| xhtml), we had to put in the all the elements HTML all the styles
| for every element on the website (and it wasn't like today that
| you put style tag and of you go), we had specific pourpose html
| elements (marquee, center, etc) to do certain things and it was a
| mess, as soon as CSS was available every developer started
| demanding it, Microsoft/IE couldn't keep up with the other
| browsers so he delivered a half-assed implementation (because
| they were pushing for activex/com shenanigans), that's were the
| infamous "css hacks" were born, because every major browser were
| luring users with features that devs had to support if their
| website aimed to be worldwide accessible, m so old for this shit
| that i remember Opera being loud on the ACID thing, it even went
| to my school to promote the CSS level support.
|
| Now lets get back to 2022, all browsers politically agree to
| implement the things everyone wants, there are still half-assed
| solutions and workarounds (for older browser support, mainly
| Sucksfari), but the browser wars are over the winner was
| webkit=>chromium, now we live in the post war era, nobody wants
| to touch anything old because it might break the internet (and
| start another browser support war), so they keep pushing for new
| things build on top of old things (thats why we have a confusing
| state of what is better flex vs grid or the fact that we still
| need a css reset) because some old website (facebook, google,
| microsoft, etc.) has a vote on the w3c/whatwg table.
|
| The solution? you might not like... lets break the internet,
| start deprecating the things and start promoting the new ones.
| Lets get rid of Safari!
| antics9 wrote:
| Yes. Why?
|
| I'm going on a stretch here and say that the html part of the
| interwebs is transitioning back to simpler and less dynamic
| hypertext documents with a lot less UI fluff. The strength of
| html are it's textual hypertext capabilities.
|
| Also, with Webassembly I do not see the point of expanding the UI
| capabilities of html.
| tylershuster wrote:
| This article seems to think the CSS _spec_ is too big, which I
| don't think is the case. We should be able to access lots of
| rendering options via CSS. But CSS _stylesheets_ are definitely
| way too big.
| a3w wrote:
| Is disagree. I have no idea how to do CSS after five years of
| web programming, except using trial and error.
|
| Reading "what is new in CSS3" did not help much, but at least
| flexbox means I don't use howtocenterincss.com any more; while
| grids became my go-to for all problems, with four attributes
| that do something about margins and centering but I ignore them
| out of a lack of memorization.
| yamtaddle wrote:
| I was _really really good_ at CSS circa 2010 and understood
| and could apply a very broad set of its features, but I
| stepped away from web front-end around 2013 or 14 and when I
| look at a modern stylesheet I struggle to make any sense of
| it. And that 's without SASS or whatever in the mix.
| dtagames wrote:
| The shadow DOM in web components helps with this a lot.
| (size/complexity of stylesheets)
| lucasmullens wrote:
| The article doesn't think that. Did you get to the end of the
| article? They agree with a tweet arguing the features are worth
| it.
| tonerow wrote:
| Since this went by the HN wayside earlier today I thought I would
| share it amongst people with thoughts on CSS. I made a very
| absurd hommage to CSS (the language, itself) over the weekend -
| https://css-magnetic-poetry.tone-row.com/
|
| Definitely not too much CSS IMO. It's a language in flux for
| sure, but as someone who has been doing frontend for more than a
| decade, I would rather have 5 ways to accomplish something than 1
| way that's a hack and only works on some browsers.
| throw_m239339 wrote:
| I still remember a time where CSS pundits claimed that the box
| model was "simple" and if you didn't understand how to make a
| layout with "float" you were an idiot.
|
| There is a reason why people resorted to tables at the time,
| because tables were simple to reason about. Grids are kind of
| tables 2.0 and that float stuff was never good nor simple. So F.
| you to all the people all these years that claimed there was
| nothing wrong with CSS, float layouts were a hack and it was bad.
|
| CSS is now actually much much simpler than it used to be, all you
| need to know as a developer is basically flexbox and/or grids to
| make beautiful layouts.
|
| CSS can succeed where the DOM failed: CSS can become a great tool
| that makes using CSS frameworks _unnecessary_, it just needs some
| kind of module system for scoped CSS rules, which AFAIK doesn't
| exist in the spec yet.
| notmysql_ wrote:
| Previous Discussion (22 comments)
| https://news.ycombinator.com/item?id=33455993
| karaterobot wrote:
| I don't think so. New CSS features are pretty low overhead to
| learn, and save me a ton of time. I used to use all those black
| magic tricks they mention at the beginning of the article, and it
| was _way_ harder to create layouts back then. Not even close.
| Adding more features has mostly just made it easier, so it 's
| worth the tradeoff.
| ohCh6zos wrote:
| Yes, because the whole web has become infected with the server
| side dictating rendering for you instead of just delivering
| documents and letting the user render how they desire.
| ramesh31 wrote:
| >Yes, because the whole web has become infected with the server
| side dictating rendering for you
|
| This makes me feel old. We've come full circle. The rediscovery
| of SSR in the JS community is now considered "new" again.
| tiborsaas wrote:
| > And that's where I, myself, land in the end. I've made my peace
| with the fact that I will probably never use -- or even know
| about -- all possible CSS features.
|
| Do painters also complain that they are not using all possible
| colors, shapes and techniques?
| pornel wrote:
| On the upside, all the basic properties and selectors work now
| across browsers. You don't need to know about hasLayout,
| mysterious 3px margins or inline-table hacks. If you don't follow
| the latest hotness of the week, you can develop in one browser,
| then just quickly check in a couple of others, and 99% of the
| time it's fine.
| tannhaeuser wrote:
| May have more to do with only two CSS renderers left (counting
| blink and webkit as one).
| tpmx wrote:
| The web standards stack has become too large, period. Google has
| way too many people working on Chrome/Chromium. CSS is a
| relatively small part of the insane strategic complexity they
| have orchestrated.
|
| By the way, it would interesting to know how many they are now.
| Has anyone done any stats via Git lately? It was 2000+ in 2015 or
| so, iirc.
| danielovichdk wrote:
| I have been away from css for many years but then the last month
| I was tasked with helping a junior developer understanding web
| dev.
|
| It has been an amazing journey only to learn the language has
| evolved gracefully and with a delicacy I really like.
|
| Working with alignment of layout and positioning is much easier.
| It's implemented nicely.
|
| Another really great thing about css imo is that it has no
| competition or the same crazy amount of libraries as javascript.
|
| I like where its going.
| jonny_eh wrote:
| As long as I can google "how to do X with CSS" and I get a
| straight-foward answer (usually from css-tricks) I'm happy.
| jopsen wrote:
| I've started to add css-tricks to me Google queries, because
| there is so much other garbage out there.
| tannhaeuser wrote:
| 1. CSS should've been split into app-y styles and doc-y styles a
| looong time ago; meaning that when you need JavaScript to make
| use of a feature anyway, there's no point in using CSS and it's
| better to set styles, layout using JavaScript rather than bloat
| CSS. The Houdini API was on the right track years ago.
|
| 2. The CSS WG at W3C must deliver formal specification rather
| than the prose they're writing up now. For an idea how a
| (partial) formal spec for CSS rendering looks like, see eg. [1],
| [2] (with limitations).
|
| The one way complexity that both W3C and WHATWG have delivered
| over the past 15 years with complete lack of mental discipline
| due to financial dependency/job security will be a major source
| of confusion for generations to come, and will not be looked at
| favorably.
|
| [1]: https://github.com/uwplse/cassius
|
| [2]: https://github.com/lmeyerov/sc
| racl101 wrote:
| Being a backend web developer, for the longest time I felt I
| could get by using CSS frameworks but now it's so bloody
| complicated even with the framework.
|
| While I'm glad that CSS is more expressive and hacks are becoming
| a thing of the past I feel that it is a discipline that I can no
| longer half ass.
| [deleted]
| conaclos wrote:
| One missing thing is the possibility to deprecate old features
| and change default behavior. A king of edition could be really
| nice to have.
| yamtaddle wrote:
| Oh god, yes. It's an overlooked culprit (though far from _the
| only_ culprit, obviously) in web performance and resource use
| being clown-shoes. We used to be aware that using some CSS
| features had a serious resource cost on the client side and keep
| things halfway sane, but it never comes up anymore, while we 've
| added even more ways to eat resources with it.
| perardi wrote:
| There is a _lot_ of CSS now...but so many of the recent additions
| have been useful. Really useful. Like, solves real-world
| problems, easy to understand, on their way to being very well-
| supported.
|
| For example...
|
| ...Container Queries.
| (https://www.smashingmagazine.com/2021/05/complete-guide-css-...)
|
| ...Cascade Layers. (https://css-tricks.com/css-cascade-
| layers/#browser-support-a...)
|
| ...the :has() selector. (https://www.bram.us/2021/12/21/the-css-
| has-selector-is-way-m...)
| alwillis wrote:
| Good point.
|
| For example, :has() has nearly 83% _global_ support already
| [1]. Once Firefox enables it by default (it's behind a flag
| currently) and more upgrade to the latest versions of macOS and
| iOS, we'll soon exceed 90%.
|
| [1]: https://caniuse.com/?search=%3Ahas
| pjmlp wrote:
| Yep, that is why I hanged my boots for Web FE development, no way
| to master it without being a full job, long gone are the days
| when could do well sites end to end.
|
| At least I can have fun with WebGL/WebGPU, even if they lag
| behind native 3D APIs.
| DerekBickerton wrote:
| CSS has become like a scripting language now. You can do things
| like nested CSS[0], keyframe animations[1], calc operations[2],
| etc
|
| It has become very JavaScript-like and this is why I always try
| to see if I can do something in CSS _first_ before I resort to
| JS.
|
| [0] https://www.w3.org/TR/css-nesting-1/
|
| [1] https://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes
|
| [2] https://developer.mozilla.org/en-US/docs/Web/CSS/calc
| FigurativeVoid wrote:
| CSS also performs better than JS in many cases. It's also
| easier to write and manage.
| autoexec wrote:
| I already want an add-on that allows me to disable certain CSS
| features just like I block JS by default. It's becoming a
| problem for sure.
| mumumu wrote:
| In about:config you can enable or disable features
| individually.
|
| Recently they added ":modal" that will make paywalls harder
| to bypass. Most sites haven't implement yet, but I've already
| disabled this "feature" on config.
| autoexec wrote:
| thanks for this! I've already got a huge list of changes I
| make in about:config on every install but it looks like
| it's time for an update
| alwillis wrote:
| _I already want an add-on that allows me to disable certain
| CSS features just like I block JS by default. It 's becoming
| a problem for sure._
|
| You've pretty much always been able to do this via user style
| sheets [1], which override author (the author of the website
| you're viewing) stylesheets.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/CSS/Cascade#use...
| autoexec wrote:
| What I'm missing is a sane set of defaults applied to every
| page automatically with a nice UI so I can enable specific
| features on a per-domain basis with a couple clicks. If I
| get the time I'll write the firefox add-on myself, but in
| the meantime I'm hoping someone else will save me the
| trouble
| agumonkey wrote:
| and there's the vulkan like layer coming up, it's gonna become
| a rendering pipeline (for better or worse)
| atoav wrote:
| I mean some of those things just make sense. Why _shouldn 't_
| CSS allow you to mix units and do some basic maths like with
| calc? Having had to resort to JS for that stuff is the real
| issue there.
|
| CSS in my eyes should be able to handle 99% of visual style
| related needs with ease, JS should be there for the rest.
| rrwo wrote:
| I don't think of nesting or calc as scripting like.
|
| Animation control is where things start to get weird.
| derefr wrote:
| I wouldn't compare it to a _scripting_ language specifically;
| it 's maybe _powerful_ like JS, but I wouldn 't say it's "very
| JavaScript-like" in any other way. I'd compare modern CSS more
| to a logic language like Prolog or SQL; or maybe to whatever
| you'd call Excel (dataflow programming?)
|
| In places where CSS takes expressions, they're always
| declarative, functional expressions; and they're always
| guaranteed to auto-update when their dependent values update,
| instantaneously as part of the update to the dependent values.
| Like an Excel grid-cell.
|
| To me, however constrained "programming" in CSS still is, this
| makes for far _better_ "programming ergonomics" than JS could
| ever give me -- which, as you say, has me always reaching for a
| CSS solution before one in JS.
| bobthepanda wrote:
| CSS is also, notably faster for many equivalent operations,
| because JS has its whole single-threaded, interpreted
| bottleneck.
| naasking wrote:
| CSS is also interpreted. CSS is faster because it's not a
| general purpose language and so its expressions have many
| optimization opportunities for reusing partial computations
| and parallelization.
| alwillis wrote:
| _CSS is also interpreted._
|
| CSS _is_ actually compiled. WebKit uses a Just In Time
| (JIT) compiler [1]; I suspect all modern web engines do
| something similar.
|
| [1]: https://webkit.org/blog/3271/webkit-css-selector-
| jit-compile...
| naasking wrote:
| By that argument JavaScript is also compiled, so this
| point is wrong no matter how you interpret it: if
| "interpreted" means source code is transmitted and then
| executed in whatever fashion, then both JS and CSS are
| interpreted, if "interpreted" means a specific execution
| model on the client machine, then they are both JIT
| compiled and neither are interpreted.
| alwillis wrote:
| _By that argument JavaScript is also compiled, so this
| point is wrong no matter how you interpret it..._
|
| The primary difference between a traditionally compiled
| language (like C) and CSS and JavaScript is C is compiled
| _before_ execution and CSS and JavaScript are compiled
| _during_ execution.
|
| There's a reason why JIT stands for Just In Time
| _compilation_ [1].
|
| [1]: https://en.wikipedia.org/wiki/Just-in-
| time_compilation
| naasking wrote:
| Yes I know the difference, the point is that the original
| poster said CSS is faster because JS is interpreted.
| There is no way to intrepret that statement in a way that
| makes sense.
| bryanrasmussen wrote:
| >By that argument JavaScript is also compiled, so this
| point is wrong no matter how you interpret it:
|
| If JavaScript is not compiled how does hoisting work?
| clairity wrote:
| yes, _declarative_ is exactly how i 'd describe css
| "programming". you supply constraints and the css engine
| applies them as best it can. the constraint declaration
| language of css is becoming more sophisticated, which is much
| needed and welcome, but it's not anywhere close to scripting
| (as in, providing a precise flow of instructions).
| alwillis wrote:
| >CSS has become like a scripting language now. You can do
| things like nested CSS[0], keyframe animations...
|
| The WebKit team first proposed keyframe animation in 2009 [1],
| so that's been here for a while.
|
| [1]: https://webkit.org/blog/324/css-animation-2/
| seydor wrote:
| I wonder where it goes from here. Maybe at some point the whole
| thing will implode, and chrome will come up with a simpler
| skinning toolkit and people will start using that one and css
| gets forgotten
| stemlord wrote:
| The css tricks website definitely has always had _way too much_
| css. Imo a very jarring user experience that often had me hitting
| the back button and clicking the adjacent w3schools article for
| whatever "css trick" I was searching for.
| jhp123 wrote:
| there's a very old argument in computer science between minimal
| standards and "batteries included" standards -- RISC vs CISC, C
| vs C++, scheme vs common lisp, Algol W vs Algol 68 etc.
|
| The web community, for whatever reason, is _firmly_ in the
| "batteries included" camp. CSS alone is approaching the number of
| built-in symbols as a "big" language like common lisp or Perl.
| New features are always loudly celebrated, even if they overlap
| with existing features, are very complicated, and/or serve very
| niche use cases.
|
| Personally I think we need a "scheme" for the web -- a little
| language that handles all the important pieces (layout,
| interaction, accessibility) with as little surface area as
| possible. It would be easier to learn, easier to understand
| others' code, easier to implement.
| tines wrote:
| Big languages are optimized for copy-and-paste; the more built-
| in features your language has, the fewer characters you need to
| steal from a StackOverflow answer. This meshes well with the
| copy-and-paste culture of web development, so it's likely that
| web technologies will always be complex this way.
| imbnwa wrote:
| That doesn't seem fair, CSS is a visual design DSL, whats the
| point of a DSL if it doesn't have batteries included?
| jancsika wrote:
| > Personally I think we need a "scheme" for the web
|
| Yes!
|
| And since it's the web, perhaps put some training wheels for
| newcomers: easy global variables, more familiar syntax... let
| me time-travel and see how it goes:
|
| _time travels_
|
| Sorry, turns out those training wheels were a _bad_ idea!
|
| Other than that, please open up your devTools console and tell
| me: what do you think?
|
| :)
| pessimizer wrote:
| Is Scheme known for its training wheels?
| jancsika wrote:
| I meant that Brendan Eich took something like Scheme and
| put the training wheels of automatic globals and familiar
| syntax on it.
| Mikeb85 wrote:
| Nope. Flexbox makes it easy to just use plain CSS nowadays. No
| more SASS or any other preprocessor nonsense. Not even a fan of
| Tailwind (too much complexity for dubious benefit).
|
| CSS has never been better and now there's just the right amount
| of it. Also now that there's no more need for crazy JS hacks, you
| can have _just a little bit_ of JS for interactivity and that 's
| it. Front end development is finally pleasant again.
| djfobbz wrote:
| I'm personally more annoyed at the SVG pollution in modern day
| frontends. I'm not saying I hate SVGs but why in the heck are we
| producing 10k like html files by incorporating SVG paths directly
| into the HTML? There should be a standardized browser protocol to
| be able to insert SVG via filename and pass it any styling
| references.
| hbn wrote:
| What's wrong with having the SVG embedded in the HTML?
|
| Someone who knows more about the inner workings of network
| technologies can correct me if I'm wrong, but I would have
| figured it's better to send a single large file than a bunch of
| smaller files.
| SuperCuber wrote:
| Apparently HTTP2 makes multiple small files much less of a
| performance issue (or maybe even turns it into a performance
| gain, I haven't looked into it too closely)
| djfobbz wrote:
| See example here: https://imgur.com/a/XMEkAu1 it's 28 lines
| total...1 button + 2 svg images, should total 6 lines of code
| tops! This is my frustration and this is what I call SVG
| pollution.
| hbn wrote:
| It's 28 lines because it's formatted to have every
| attribute on a different line.
|
| I'd put the <svg> tag and all its attributes on a line, the
| entirety of the path on a single line, and then with the
| closing </svg> tag it's reduced to 3 lines.
|
| This is how I do embedded SVGs:
|
| https://imgur.com/a/zVVEVps
|
| Note your example also looks way worse because of line wrap
| mung wrote:
| And yet styling form elements is still pretty limited.
| irrational wrote:
| >This may seem like a negative attitude, but I think it's
| understandable. Nobody can be expected to keep up with so many
| new features!
|
| I have similar feelings about javascript. But, I figure I can
| ignore all new features and worry about learning them when the
| need for them arises.
| Julesman wrote:
| This take is a disaster. So we get a decade of bloated frameworks
| to compensate for missing properties and then just when browsers
| are about to catch up and make all that cruft pointless we get
| people complaining about it. This isn't a thing. This is some
| software engineer edgelording. Yeah, we get it, you don't like
| CSS because you aren't good at it. Just stop.
| jakub_jo wrote:
| You're somewhat right. I either don't like the attitude of the
| whole article.
| iquerno wrote:
| This reminds me of how the whole philosophy of python is
| 'simplicity', but the moment you want to start building
| something you must be reminded of how you haven't updated to
| the latest version of gnu-anaconda-conda-py-
| pip3-x86_64-cpython-limited-edition and are consequently
| prompted to download 5 Gigabytes of inference APIs to print
| hello world on a distributed multi-cloud pay-for-what-you-use
| Kubernetes instance .
| camtarn wrote:
| ...what mirror-universe version of Python are you using?
|
| One of my two main languages nowadays is Python, mostly
| deployed on single cloud instances, and it's still a case of
| writing a text file, sticking a #!/usr/bin/python at the top,
| and running it.
|
| Obviously if you're doing something that pulls in a ton of
| dependencies and uses live ever-changing APIs, you're in a
| much more complicated situation, but Python has never stopped
| being really darn simple for the simple use cases.
| di456 wrote:
| Dockerized environments are a godsend for this problem. I
| keep a generic docker env that I can clone into a new project
| in a few keystrokes. Hello world from local in minutes or
| less, on a recent version of python.
| bobthepanda wrote:
| the difference seems to be
|
| * the burden of CSS implementation of standards, is mostly on
| browsers
|
| * the new standards are supposed to be reducing complexity.
| Nobody wants to go back to hacking rounded corners together.
| CSS Grid finally gave us a sane way to specify 2D layouts,
| which were previously all designed by hacking 1D-priority
| things.
| _aleph2c_ wrote:
| What is an edgelord?: https://www.merriam-webster.com/words-at-
| play/what-is-an-edg...
| jbreckmckye wrote:
| > This is some software engineer edgelording.
|
| This is _Chris Coyier_ , who launched css-tricks back in 2007
| and codepen in 2012. He's worked in this field for over 15
| years and is one of the most recognisable figures in the webdev
| community.
| jakub_jo wrote:
| No, it's not Chris Coyier.
___________________________________________________________________
(page generated 2022-11-07 23:02 UTC)