[HN Gopher] The continuing tragedy of CSS
___________________________________________________________________
The continuing tragedy of CSS
Author : headalgorithm
Score : 68 points
Date : 2023-06-12 17:59 UTC (5 hours ago)
(HTM) web link (paulrobertlloyd.com)
(TXT) w3m dump (paulrobertlloyd.com)
| pauljonas wrote:
| It seems we need a _CSS: The Good Parts_ guide here.
| gherkinnn wrote:
| I don't follow. Don't like trigonometry functions, don't use
| them.
|
| Scumbag SV giants need to get snipped no matter how many relative
| units we have.
| kazinator wrote:
| > _Yet when aspects of frontend development not involving
| JavaScript are seen as ignorable by employers, few will get this
| opportunity._
|
| That strikes me as fallacious. Let's change some words around:
|
| "Aspects of embedded programming not involving C coding, such as
| maintaining complex make files or boot scripts, are seen as
| ignorable by employers, so few will get the opportunity."
| danielvaughn wrote:
| I've been writing CSS since 2009 and though it's always been a
| love/hate relationship, I didn't feel this way until last week.
| Not sure how new this is, but "dynamic viewports" are now a thing
| in CSS. The "dynamic viewport" is the area not obstructed by the
| browser UI.
|
| Literally the only reason I can see for this to exist is because
| iOS Safari obstructs the browser UI with its stupid toolbar. So
| we're building new additions to the language purely because Apple
| builds user-hostile features for their mobile web browser.
| Lovely.
|
| </rant>
| SebastianKra wrote:
| I've seen much hate for the iPhone notch, but "user-hostile" is
| a first.
|
| (I assume you are talking about the notch, because Safari
| doesn't have a toolbar that obstructs the page)
| [deleted]
| imauser wrote:
| I think he meant the bottom address/controls bar.
| SebastianKra wrote:
| Yep, but that doesn't obstruct the page.
|
| Except for a version from 2 years ago that never even made
| it out of beta ;)
| imauser wrote:
| It does before user scroll down the page a little. That's
| what he called dynamic viewport being added to spec. It
| was to address issue of incorrect viewport height (100vh)
| when the toolbar is visible. So units such as svh, lvh,
| and dvh are added.
| SebastianKra wrote:
| Ah gotcha.
|
| But that has been the default behaviour in any mobile
| browser since forever. I don't know why he would blame
| Apple for this.
|
| (Though I don't know how it used to interact with vh)
| danielvaughn wrote:
| Yeah this is what I was referring to, thanks.
| imauser wrote:
| Not just iOS safari. I believe Firefox on Android is also the
| same.
|
| Can't believe showing user either controls or address bar at
| the bottom is consider "user-hostile".
| zerocrates wrote:
| It's just... vexing to have "viewport" units in the spec, but
| then the user agents are just drawing stuff on top of the
| "viewport" but not changing its reported size, so now we need
| additional "real viewport size" units...
| danielvaughn wrote:
| Yes exactly, we're adding features specifically to the
| language to accommodate vendors who aren't respecting the
| spec. Feels very backwards.
| danielvaughn wrote:
| Having controls at the bottom isn't user hostile, it's the
| fact that it obstructs the space allotted for developers.
| This makes it much harder to develop mobile sites - in my
| experience a very large minority of sites fuck it up, and it
| makes the mobile browser feel like a worse experience.
| bamfly wrote:
| Does the viewport reflect reality on desktop when e.g. http
| login controls cover part of the page, or another window is
| covering part of it?
| danielvaughn wrote:
| Yep, and it always has. It's super reliable on desktop.
| bamfly wrote:
| Like, you drag a window over your browser, and the
| viewport values change? I'd not have expected that, and I
| don't think I've ever noticed that behavior. How does it
| account for all of those sorts of things (browser-
| provided login prompts, or browser settings windows, or
| certificate-info pop-downs, or non-browser windows being
| dragged on top of part of the browser window) not
| necessarily resulting in a viewable area describable as a
| rectangle?
| post-it wrote:
| The Opera mobile app used to have an appearing/disppearing
| navigation bar too, as I recall. It's a handy standard to have.
| marcellus23 wrote:
| What Safari behavior are you complaining about, exactly?
| ("obstructing the browser UI with a toolbar" doesn't make any
| sense to me)
|
| And why is it user-hostile?
| [deleted]
| danielvaughn wrote:
| You often need to base your styles on the height of the
| viewport, for example if you need to pin an element to the
| bottom of the screen, or if you need an overlay to fill up
| the entire screen.
|
| You can do this in CSS with a dimension called "vh" and "vw"
| (viewport height and viewport width). If you're using JS, you
| can use "window.innerHeight" and a few other methods.
|
| The problem is that in virtually every browser, this screen
| space is respected as the space that belongs to the
| developer. It would be extremely inconvenient if the "vh"
| value didn't take into account the browsers own UI. Because
| then you'd need to adjust your style value to account for
| that height. Well, iOS Safari does exactly that, and it's
| been a major source of frustration for web developers for
| years.
|
| It's hostile to users because it makes developing for the
| mobile web fairly difficult, and thus degrades the
| experience. I honestly don't know why they do it, but my more
| cynical side says that they don't mind sacrificing UX on the
| mobile web because it competes with their app store.
| manicdee wrote:
| The more realistic explanation is that the toolbar takes up
| space and every pixel has value on smaller screens. Moving
| the toolbar out of the way when the user is not likely to
| be using tools makes sense when understanding the web from
| the perspective of someone reading articles.
|
| This behaviour is hostile to developers, not users. A more
| cynical commenter might suggest that you're the one
| engaging in user-hostile behaviour with hovering elements
| and overlays.
| danielvaughn wrote:
| (1) the browser is an application platform so devs are
| users as well, (2) making it harder to develop good UX by
| not following the spec _does_ make the experience worse
| for end users, and (3) "hovering elements and overlays"
| were just a couple of examples - there are tons of
| reasons why devs need to reliably know where the boundary
| of the fucking screen is.
| azangru wrote:
| I don't understand these attacks on Google and Chrome. Yes, Blink
| in general and Chrome in particular are dominant. Yes, Google has
| a shitload of money. But at least it invests its money in the web
| platform, which, if you are a web developer, you ought to be
| grateful for. Apple, in comparison, also has a shitload of money;
| but until a couple of years ago, didn't seem overeager to invest
| in web. As for shrunken browser xhoice, isn't it easier for
| developers to target a few platforms than a host of diverging
| ones? When you are not in control of the client platform isn't it
| a relief to have as little variability - and hence as much
| predictability - as possible? Isn't this the closest thing to
| being in control?
| DHPersonal wrote:
| Google has contributed many good things to the web, but they
| should always be scrutinized and challenged to prevent them
| taking over the platform to serve only their purposes. This is
| the same complaint leveled at Apple.
| LukeBMM wrote:
| Exactly. Apple's lack of contribution to the internet
| ecosystem exactly aligns with their profit motive: Selling
| hardware.
|
| Google's involvement in the internet ecosystem exactly aligns
| with their profit motive: Putting relevant ads in front of
| individuals based upon data they've gleaned from relatively
| "un-sexy" sources like search, analytics, libraries, font
| hosting, email, chat, etc.
|
| I'm not opposed to companies making a profit. I try, however,
| to keep in mind conflicts of interest when choosing my
| sources of information. Everything anyone at Google says
| about the web is suspect because that is a conflict of
| interest. Google, as an organization, exists to turn web
| traffic into profit and should always be considered
| accordingly.
| kitsunesoba wrote:
| Yes, there's a very real conflict of interest between their
| line of business and the level of control they have over the
| web, and they've not proven themselves willing to abstain
| from inappropriately leveraging that control.
| pphysch wrote:
| Exactly -- in a Web 2.0 world where everything is siloed into
| proprietary, closed platforms like Reddit, Facebook, Twitter,
| etc., Google AMP looks like an angel.
|
| Yeah, you get corporate fingers in the cookie jar, but at least
| you can still recognize the cookies (i.e. webpages).
|
| This is particularly pertinent with what is going on with
| Reddit. Imagine if subreddits were actually just portable
| HTML+CSS+JS websites built on a common framework produced by
| Reddit Inc, instead of bits of data in their proprietary
| databases.
| croes wrote:
| Apple didn't invest in web because their ecosystem is already
| their walled garden.
|
| Google tries the same with web and Chrome as it's de facto
| standard browser.
|
| It should be one HTML standard not one browser's interpretation
| of it.
| cma wrote:
| >Apple didn't invest in web because their ecosystem is
| already their walled garden.
|
| Can see why they didn't invest in web when they didn't want
| linking to work in apps on the iPad, except in specific
| cases:
|
| https://twitter.com/TechEmails/status/1667990407085711360
| croes wrote:
| Don't they also hinder PWAs on iOS?
| agos wrote:
| they took their time, but the next iOS/MacOS release
| brings them to the OS with full support as far as I can
| tell
| cma wrote:
| I guess not as much as Facebook, who announced PWAs on
| Meta headsets will be subject to the 30% tax and have to
| go through the store.
| JohnFen wrote:
| > if you are a web developer, you ought to be grateful for.
|
| As a web _user_ , I'm definitely not grateful for this.
| hitchstory wrote:
| >As for shrunken browser xhoice, isn't it easier for developers
| to target a few platforms than a host of diverging ones?
|
| You dont remember IE6 do you?
| Kye wrote:
| There's a growing number of people who are adults years into
| their careers who have only known a world with a dominant
| Chrome. Stuff like this is cyclical because new generations
| come, and no one tells them about this stuff. Or if someone
| does, they don't take it seriously.
| azangru wrote:
| The IE6 situation happened because Microsoft lost interest in
| the web. Plus, Microsoft was developing its browser in
| disregard of web standards. With Google, at least for now, we
| have a company that is heavily invested in web, AND, what the
| article strangely complains about, is heavily involved in web
| standards, to the point where it becomes a driver for some of
| them.
|
| IE6 was stagnant and non-standard-compliant. The horror for
| developers, as far as I understand, came from the fact there
| was another, much more rapidly evolving, web browser, and
| they had to maintain compatibility between the two.
| kitsunesoba wrote:
| Part of the problem is that when Google really wants a
| feature for themselves, they'll plow through and implement
| it in Chrome regardless of any concerns raised or input
| offered by Mozilla and Apple, creating "nonstandard
| standards" much like those created by IE.
| taeric wrote:
| This is a bit inaccurate, oddly. At least, for my memory,
| IE6 was genuinely better than Netscape at the time. They
| did make some odd choices, such as border-box, but by and
| large Netscape was stagnating hard. That said, I remember
| the fieldset and legend styling was much better in IE than
| it was in Firefox. And, amusingly, I have grown to prefer
| border-box for sizing.
|
| Now, as time went on, IE became very stagnate and upset
| folks by not adding more and more. So maybe it depends what
| time we are talking about here?
| icedchai wrote:
| Yes, there was a dark period (early 2000's) where IE 6
| was basically the only usable browser. Netscape was far
| behind, and also incredibly unstable (crashing hourly.)
| Firefox wasn't out yet. Chrome was years and years away.
| RadiozRadioz wrote:
| I didn't find there to be much substance in this article. I would
| have preferred more examples of ways in which there are "too much
| CSS", and the ways in which it is a "continuing tradgedy",
| instead of a retrospective about the wider state of the web. The
| measurement units section was interesting, the introduction had
| me primed to expect more of that, but I was left generally
| wanting.
| willio58 wrote:
| Fully agree. Seems like the author pointed out one thing - that
| there are increasing numbers of units usable in CSS, doesn't
| really talk about why that's bad, and then wraps it up.
|
| I think there's a general anxiety some devs have about how much
| CSS has been developed in the past few years, and I think that
| partially comes from not being able to keep track of all the
| changes anymore. Like it wasn't uncommon a few years ago to
| have a few CSS _experts_ on your team that felt comfortable
| with every single thing in the CSS spec, but now that 's
| becoming a little less common as the spec and implementation in
| browsers evolve and grow. But I think that doesn't mean there's
| a "tragedy" of CSS. I think it means CSS is becoming more
| complex, but to me it's generally been in the right direction.
| coding123 wrote:
| I fear that, basically, decloak's little hot sauce and menu
| website might be the cause of this. His basic premise seemed like
| he was arguing that tables can easily describe the UI's we seek.
|
| CSS was indeed, very difficult to make lines go from the top to
| the content bottom. Or 15 to 20 other various quirks that only
| worked in IE or only in Firefox or what have you.
|
| I can only guess that Chrome programmers hated that website so
| much they decided to use it as a way to champion new CSS
| features. Thus instead of having 0.89 ways (a.k.a. almost there +
| hack) to accomplish something in CSS, there are 15 ways to do it
| now.
|
| Is that good? Maybe
|
| Also I HAD to know if he was still around and YES he is. And his
| main product is STILL for Dreamweaver! That's wonderful I was so
| worried about that for some reason.
|
| http://www.decloak.com/dev/csstables/CSS_Tables_16.aspx
|
| His extremists update has HN posts from 2019!!!!!!
| JakeAl wrote:
| I still prefer good old fashioned plain HTML. If you want an app,
| write an app. Keep the web HTML and accessible to author by
| anyone rather than require one become a programmer of someone's
| proprietary scripting language.
| Julesman wrote:
| I'm pretty good at CSS. Getting good at it is not a straight line
| with perfect logic, like say Python. Browser issues, different
| ways of doing the same thing, cascading in general. I get the
| issues. But a) we have no serious alternative at this point, and
| b) the answer isn't frameworks.
|
| I hate CSS frameworks as much as coders hate CSS. Web
| architecture is fairly organized when you have HTML, CSS, and
| Javascript files. I appreciate the modular nature of React, but
| otherwise, frameworks like Tailwind basically entirely muddy that
| separation. I can no longer know whether the style of an element
| needs to be changed in the html or css file. And the html become
| much harder to read. That's just not better.
|
| I know at some scale, with a very static design system, that
| Tailwind can speed up deployment. But half-decent semantic HTML
| with some custom helper classes can make Tailwind entirely
| unnecessary for most tasks.
|
| I wake up every day happy I'm never using Bootstrap again. Say
| yes to CSS. lol
| datavirtue wrote:
| "But half-decent semantic HTML with some custom helper classes
| can make Tailwind entirely unnecessary for most tasks."
|
| True but it never happens. Where is CSS going? Tailwind. Ninjas
| like you that want to tinker with CSS can work on tailwind...or
| bootstrap...or something else.
| samwillis wrote:
| All the additions to CSS, JS, HTML, and even the continued growth
| of frameworks and abstractions, are a choice. You have a choice
| to limit yourself and your team to a subset of the available
| tools, and it's a good idea to do so. The web as a platform is a
| lot of different things to a lot of different people, it needs to
| expand and grow in order to cater to all. Restricting the tools
| for your project makes it easier to maintain, and easier to
| onboard new contributors.
|
| I do this with TypeScript on my current contract, I limit its use
| to almost "JavaScript with Types", only using features (other
| than types) that have made it into core JS.
|
| I understand the anxiety over the ever increasing pressure to
| have knowledge of all these APIs and features, but you don't need
| to. Being a good developer is having a wide but shallow (even
| only knowing the existence of something) understanding of the
| platforms. Enough to start. No "real" developers code without
| constantly referring to docs, or Googling (or using chatGPT) to
| help.
|
| Personally there are a few new things coming I am super excited
| about. To call out one, the new "popup" element will apparently
| have its own stacking context, elevated to the top compositing
| layer, no mater how nested within other stacking contexts the
| node is. That's going to be the best things since sliced bread,
| lots of code I can simplify, bugs that will be easier to close.
| Other people won't have a need, and so don't need to even touch
| it.
| sebzim4500 wrote:
| What other features does TypeScript have? Genuinely curious, I
| haven't used TS much so I'm probably missing a bunch.
| dabber wrote:
| There aren't many. Enums[0] are probably the most common.
|
| [0] https://www.typescriptlang.org/docs/handbook/enums.html
| nayuki wrote:
| Enum, namespace, type-oriented programming (e.g.
| https://type-level-typescript.com/ ), easy de-sugaring down
| to earlier versions of ECMAScript (e.g. converting async-
| await to switch statements).
|
| Plus, whatever you can find under the "Reference" section:
| https://www.typescriptlang.org/docs/
| FireInsight wrote:
| How do you express option/enum types without enums? And if
| you do that, isn't it more of an unsupported way of doing
| things than using the native enum type?
| jauco wrote:
| I guess unions of string or number literals?
| type Option = "foo" | "bar"
| dabber wrote:
| const assertions work well:
| https://devblogs.microsoft.com/typescript/announcing-
| typescr....
|
| There is an example in the "Objects vs Enums" section of
| the Enum docs, at the bottom of the page: https://www.types
| criptlang.org/docs/handbook/enums.html#obje...
| dschuessler wrote:
| Enums are one example. They are compiled to objects existing
| at runtime rather than stripped out like types.
| jancsika wrote:
| > That's going to be the best things since sliced bread, lots
| of code I can simplify, bugs that will be easier to close.
| Other people won't have a need, and so don't need to even touch
| it.
|
| Just glancing it looks like it would simplify tooltips. Does it
| have wider implications than that?
| samwillis wrote:
| Downdown/context menus that are attached to a node inside an
| "overflow: scroll" element. The common solution is to use a
| React "portal" or Vue "teleport" to move the element to the
| root of the body, but this has its own problems around
| accessibility and can often result in bugs during page
| transitions.
| jraph wrote:
| Unless you write a browser engine. You can choose what to
| implement, but you are highly encouraged to implement what
| people use in the wild.
|
| (this does not concern many people though - this is still
| somewhat important, a complex spec reduces potential
| implementations)
| TheRealPomax wrote:
| Come on, man. "There were three units (and 5 more that that I
| personally never used and didn't realize were critical for proper
| print.css stylesheets because I never printed anything). Today
| there are 18! A six-fold increase"
|
| You mean two-fold. Hyperbole doesn't work when you're flat out
| lying about the numbers with the evidence for that lie in the
| same sentence.
|
| And how many of those 18 are commonly used? Because it's not "all
| of them", not everything on the web needs all of them (a web page
| doesn't need physical dimensions, an app doesn't need pixels, you
| don't use every unit for everythi9ng).
|
| Complaining about "what it can do" when you don't _use_ what it
| can do doesn 't make a whole lot of sense. Learn what you need to
| use, ignore the parts you don't need. Learn those through trivia
| and incidental "oh huh I didn't know that" moments.
| samwillis wrote:
| I don't think the OP is necessarily arguing against the growth
| of CSS per se, I think they are arguing that CSS development is
| being pushed forward by an increasingly small group of people
| and companies.
|
| CSS growth is in my view good, but it does sound like having
| more diverse people and organisations influencing it would be
| good for the community.
| czx4f4bd wrote:
| The post doesn't say "There were three units". That's a quote
| you made up. The post says "the original CSS specification
| included 3 _relative_ units ". That is factually true. The
| original CSS spec lists only em, ex, and px as supported
| relative units, which are distinct from the five absolute units
| you accused them of leaving out.[0] Accusing someone of lying
| while lying about what they said is a bad look.
|
| The author also has a footnote mentioning that there are
| actually 36 relative length units in CSS now, so it's actually
| a 12-fold increase in relative unit types.
|
| Lastly, I don't think the author is even complaining about the
| number of units. He obviously has reservations about it, but
| the main point is to illustrate the growing complexity of CSS
| over time.
|
| > These raw numbers tell an underlying story; websites now
| appear in a number of different shapes, sizes and dimensions,
| and CSS needs to account for that.
|
| [0] https://www.w3.org/TR/REC-CSS1/#length-units
| wwweston wrote:
| > developers no longer needing to understand pre-processors or
| other tools. Sass served the community well, but as CSS slowly
| morphs into a (more evident) programming language, its days seem
| numbered.
|
| Is there a browser-native way of doing mixins now?
| samwillis wrote:
| No, unfortunately.
|
| The issues is that mixins applied via a pre-processor don't
| need to take into account the complexities of the cascade.
| Designing a mixin system that works as part of the cascade is
| hard, and so no one has yet proposed a system that everyone is
| happy with.
|
| This is the same reason we can't use var() within media queries
| to define breakpoints. Custom properties are part of the
| cascade and so are attached to a dom element, media queries
| have no dom element attached to them. (The proposed custom
| environment variables with env() will solve this one)
| FigurativeVoid wrote:
| I work on part of a pretty CSS heavy team as part of a large
| application.
|
| CSS has gotten a lot more powerful and more complex with that
| added power.
|
| What has struck me most really learning BEM, CSS pre/post-
| processing, and Web Components is that writing well maintainable
| and reusable styles is really difficult and different from stock
| OOP. Not to mention you can make something that looks great and
| is completely inaccessible.
|
| I tend to lean toward a more simple and brutalist web design, but
| I am happy that I have the option to do something more complex
| with CSS if needed.
| leokennis wrote:
| There are probably 200 ways to manipulate text on Unix. Does this
| limit anyone in using the tried and trusted awk, sed, cut, grep
| etc.?
|
| I define my font sizes in em and rem. It bothers me exactly 0%
| that someone else is able to define his fonts in millimeters or
| pica's.
| B1FF_PSUVM wrote:
| One of the mysteries of life I cannot begin to fathom is how
| "style sheets" have come to include "page layout".
| tabtab wrote:
| They have everything else in there, might as well add the
| kitchen sink. CSS is Swiss Army Rocket Surgery.
| kazinator wrote:
| The proliferation of units strongly suggests that programmers
| should instead be able to define the ones they need.
| taeric wrote:
| Ok, 36 relative units does feel excessive. Reading each of the
| names, I can understand why many were added. Still, that is a lot
| and I can't imagine there are more than a handful of folks that
| can correctly use most of them. I'd also wager that the odd
| interactions that you are certain to get with them has to be a
| nightmare on large teams.
| jozzy-james wrote:
| outside of Q, I think I've used most all of these in one way or
| another for various reasons. Most can be done with calc() and
| whatever the nearest root value is - but some of them are
| handy, even if they don't appear so.
| taeric wrote:
| Again, going on the name, I can see easy justifications for
| most of them. I, sadly, can also imagine the rabbit hole that
| is justifying any particular one for a document. :(
| johannes1234321 wrote:
| For implementors it is probably a lot (while it's trivial math
| usually once resolution etc. is known)
|
| But for users:
|
| > a handful of folks that can correctly use most of them
|
| That doesn't really matter. For most developers a simple guide
| is enough, the ones with special needs have to know. They don't
| have to know all either, but different folks with different
| subsets.
|
| Everybody else just has to know "there is more" and read up if
| they encounter something special.
| PaulHoule wrote:
| ... isn't it thanks to AMP that we have so many "readers" that
| unlock paywalled news sites?
| Freebytes wrote:
| Being able to bypass paywalls does not justify AMP. AMP is a
| threat to decentralization of the web.
| PaulHoule wrote:
| What I am seeing is that AMP-like technology lets you
| incorporate readers into social platforms or document
| classifiers to make very interesting applications. Granted
| you used to be able to make things like Stumbleupon with
| <iframe>s but note you were always free to write AMP
| consumers but I've only seen people really try it recently.
| If you quit hating on it you might realize it's a way to
| reverse ten years of enshittification of news sites.
| bob1029 wrote:
| This reads exactly like most pieces on why C# & Microsoft bad.
|
| Step 1: Establish an implicit narrative that additional language
| features are _mandatory_.
|
| Step 2: Identify a gigantic, corporate boogeyman who somehow
| seeks to use these additional features to control your life.
| centmot wrote:
| The more complex the languages for building web pages become, the
| more complex browsers become, the harder it is for someone to
| build or continue to build a Chrome alternative, the harder it
| becomes to challenge Google.
|
| The more complex these languages are, the more SEO content gets
| generated ad nauseum.
|
| Yet it is impossible to learn CSS from searching Google.
| PaulHoule wrote:
| The CSS specification refers to roughly 50 documents describing
| CSS
|
| https://www.w3.org/TR/css-2022/
|
| Note it is a common structure for standard documents to be
| written like
|
| "Dates are formatted like the ISO 8601 standard (which nobody
| has ever read because nobody thinks it is worth 166 swiss
| francs) except that instead of a four digit year it is a six
| digit year"
|
| which is absolutely mind bending for people to understand.
| Maybe with LLMs we can merge a standards documents and 50
| amendments into a single coherent document, a prospect I was
| thinking of attacking with knowledge graphs a few years ago.
| nicoburns wrote:
| > The more complex the languages for building web pages become,
| the more complex browsers become, the harder it is for someone
| to build or continue to build a Chrome alternative
|
| I think the way forwards here is to make everything modular.
| Then people can fork a browser and easily replace a single
| component. The Servo project has made a very good start on
| this.
| waboremo wrote:
| It's never been easier to build web pages. Never been easier to
| build a browser.
|
| Where problems arise is when people expect to challenge
| behemoths right from launch. Like demanding your burgers be
| adopted by all mcdonalds consumers when you haven't done
| anything to actually compete with them.
| gtirloni wrote:
| _> It 's never been easier to build web pages. Never been
| easier to build a browser._
|
| And yet, Microsoft ditched its own engine and went with
| Chrome's. So did Brave and others.
|
| _> Where problems arise is when people expect to challenge
| behemoths right from launch. Like demanding your burgers be
| adopted by all mcdonalds consumers when you haven 't done
| anything to actually compete with them._
|
| So they should start small and slowly build up the artificial
| complexity that accumulated over decades in incubent browsers
| until it reaches feature parity? By then, the other browsers
| will have another 10+ years of more complexity than you.
|
| I don't quite get what's your point here. Could you give
| examples?
| waboremo wrote:
| Yes they did. Because they do not care about a good browser
| engine product. They care about selling services on top of
| that. So whether it's Chromium or something else entirely,
| they don't care. They went with what had the most external
| developers working on it because again, they do not care
| about the engine.
|
| >So they should start small and slowly build up the
| artificial complexity that accumulated over decades in
| incubent browsers until it reaches feature parity?
|
| No, they should find a new angle. What are they building a
| browser engine for? To go back to the burger example, you
| cannot compete with McDonalds by trying to do everything
| they do. Everyone understands this about general products,
| you can't compete with Apple by making an iPhone clone. You
| can't compete with Marvel by making funny light hearted
| hero movies. Yet, when it comes to browser engines people
| short circuit.
|
| Do you know about Steam? The video game launcher/store.
| This store is so successful that it's spawned many
| competitors who struggle to compete. Why is this? Because
| they do not want to change the status quo too much, they
| just want their company to be where Steam is. So they spend
| so much time and money trying to add features Steam has had
| for years now, all while people refuse to budge because
| "why use a steam clone that's worse?" Sound familiar?
|
| This is the current problem with browser engines. Everyone
| just wants to be Chrome, to have Chrome's userbase, but
| they don't want to actually think about a product. They
| don't want to find a niche, or make people rethink what a
| browser should be/do.
|
| Therefore, it's not a problem that people keep failing to
| be Chrome. I say good riddance. We don't need a Chrome
| alternative; we need something else entirely.
| gtirloni wrote:
| The only issue I see is that people don't want something
| else entirely, they want their web pages. CSS/HTML
| features are deprecated but browsers continue to support
| them forever and make their engines more complex
| because... people won't adapt (for good and bad reasons).
|
| What you're proposing is basically telling someone
| willing to build a better web browser to compete with
| Chrome that they should actually build, say, a music
| player instead and change the game completely. Even a
| less extreme example: a browser with a completely
| different UI still would need to support HTML/CSS and
| have a super complex engine so we're back to square one.
| I don't see how that makes sense.
|
| We need more energy and money to be spent into moving
| this distributed codebase to use newer features so
| engines can drop support for old stuff and be less
| complex. Who's going to drop features from their browser
| only to see people say "use browser X, that one still
| works with all your existing pages" and then lose their
| userbase.
|
| If this was easy as ever, as you say, people would have
| done it already. In reality, it's a multi-billion dollar
| problem and the incentives don't align.
| samwillis wrote:
| Andreas Kling would beg to differ, it's absolutely possible for
| a small team to build a completely new browser from scratch.
|
| https://awesomekling.github.io/Ladybird-a-new-cross-platform...
| dahwolf wrote:
| I consider the web's growth in capabilities a positive because
| it's the only independent computing platform we have, despite
| Google's large influence on it.
|
| Even if web tech is sometimes messy, these days it can be used to
| build almost anything you can think of, which is good, as it
| should cater to a very broad set of needs. I'm fine with there
| being 26 size units, even if I only use 2.
|
| I think the true tragedy of CSS is that most developers suck at
| it. They only know it superficially or feel they don't need to
| learn it deeply because they're using a CSS framework or some
| crude CSS-in-JS hack. Others might be genuinely interested in
| learning it, but can't find the time for it, and stick to what
| they know.
|
| As a result, many spectacular improvements in CSS largely go
| unused. Even something that can be used for 5 years now (CSS
| grid) is rarely used today and you'll be hard-pressed to find a
| developer that deeply understands its possibilities.
| tabtab wrote:
| I'd like to see vector-driven challenges to web standards. For
| one, we could bring back WYSIWYG under vectors by having grids
| with "stretch zones" that allow for larger devices. Constraint
| and flow-based layouts often grow highly convoluted for those of
| us who need to be generalists (full stack devs). Not every
| project should have to hire a CSS Sheldon Cooper to get Hello
| World in the right spot. (SVG and Canvas lack most the Input
| elements.)
| recursivedoubts wrote:
| i'm a reasonably smart guy
|
| i made htmx.org and hyperscript.org, and I've been using CSS on
| and off for two decades now
|
| still spend an inordinate amount of time making things look/work
| right in a way I never did when I used the old apple UI layout
| system (springs/struts)
|
| -\\_(tsu)_/-
| pupppet wrote:
| Just curious, if you could throw out CSS and start from scratch,
| what would you do? What's the alternative?
| pavlov wrote:
| The fundamental problem with CSS is that it conflates element
| content styling, layout directives, and compositing
| configuration into an unholy mess.
|
| One way out is to rethink each of these separate problems
| individually. Element styling is typically about configuring
| attributes, while layout is more closely related with
| programming (even if it's a non-Turing complete environment
| like constraints). There's no reason why the same language
| should try to do both.
| giantrobot wrote:
| You could go back to JavaScript style sheets[0]. I'm joking
| please don't do this it's stupid.
|
| [0] https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets
| TheOtherHobbes wrote:
| Have a single common bytecode language for all web dev,
| including scripting, content definition, and UI.
|
| But not js.
|
| Support programmatic control of content generation, styling,
| composition, animation, UI events, backend connections, and
| object-based component reuse with standard libraries that
| implement each feature across multiple platforms.
|
| Basically the visual/UI part of iPhone/Android dev but in a
| browser, perhaps with some standard backend APIs.
|
| The amount of duplication in modern CRUD development is just
| insane. Every project reinvents the same wheels. CSS is part of
| that because it's so disconnected from the content and the UI
| that it has to be customised for each project and can't be
| reused - except as a reset file, which shouldn't even be
| needed.
| icedchai wrote:
| This sounds like Java w/more modern UI.
| lagniappe wrote:
| I have a suspicion that on a long enough timeline, eventually CSS
| will subsume the interactivity of JS for the frontend.
| bamfly wrote:
| I've not investigated it to prove my hypothesis, but I've long
| suspected that CSS doesn't get enough of the blame for the
| modern Web being so bloated and resource-hungry.
|
| But then, I still remember when it was considered disrespectful
| to the user and generally ill-advised to ship vector graphics
| unless absolutely necessary, because it'd offload too much
| processing on the client and harm performance. Now people do 3D
| transforms of DIVs and apply blur and such with CSS on every
| page load because pre-calculating it would be more work (or
| practically impossible). And they think nothing of doing this,
| maybe dozens of times on a single page.
| douglee650 wrote:
| This is probably the right answer ... for ex. why does css need
| trig? Well, if you want to transform and animate things, math
| is very useful.
| PaulHoule wrote:
| I wish people used CSS for semantic tagging, to take over some
| of the role that JSON-LD and all the other half-baked standards
| for adding metadata and annotations to HTML. Why do we have the
| Rube Goldberg machine called ARIA when we could use CSS
| attributes to express the same information quite naturally?
| jack_the_dev wrote:
| Found this article click-baity with its title. It doesn't deliver
| on the premise of CSS becoming worse. And it doesn't either with
| its claim that it's led by out of touch dictators.
|
| CSS is becoming more complicated with new features. But these
| features are much better than rolling your own solutions to
| styling with JS. It also makes the web more performant and
| accessible.
|
| I've also found the CSS implementers to be very responsive to
| user input. As an example, check out their survey for designing
| nested CSS: https://developer.chrome.com/blog/help-css-nesting/
___________________________________________________________________
(page generated 2023-06-12 23:03 UTC)