8 ms·
CSS Web Components for marketing sites (2024)
- vaylian 9mo agoI've never been deep into XSLT, but I kind of have the impression, that this would have solved the issue.
- hyperhello 9mo agoThe reason fixing ads from the inside won’t work is that they are designed to disrupt. An ad that ruins your scrolling for three seconds is preferable to one that ruins your scrolling for 2.5 seconds. All ads are designed to wreck the environment that they are in, to create a space for irrationality to enter.
- pier25 9mo agoWhy not just use CSS?
- deleted 9mo ago[deleted]
- etchalon 9mo agoIt is using CSS.
- pbowyer 9mo agoWhy not use CSS without the custom element? From this post I don't see the benefit of using <swim-lanes> over <section class="swim-lanes"> for example.
- etchalon 9mo agoA handful of benefits: 1. Specificity - swim-line.buttons vs .swin-lines.buttons vs .buttons.swim-lanes. 2. Future pathing - Maybe you don't need a Web Component today, but you might need one tomorrow. 3. Cleaner - <swim-lane /> is just better than <div class="swim-lane" />
- smrq 9mo ago"Clean" is the biggest lie in software development. It's an aesthetic opinion dressed up as objective fact. You think components are clean, someone else thinks classes are clean, and neither of you are wrong, except for believing that "clean" is a property of the code and not something entirely in your own mind.
- etchalon 9mo agoI'm going to start using this logic whenever my wife talks about my office.
- pier25 9mo ago> Specificity :where() gives you zero specificity. > Future pathing Sounds like premature optimization. And I say this as someone who has been using custom elements and web components in production since 2016. In fact one of my products offers WCs for our customers: https://docs.wavekit.app/web-components-wavekit-audio/ https://docs.wavekit.app/web-components-wavekit-audio/ > Cleaner Debatable. Personally I find it cleaner to simply rely on CSS to solve something rather a combination of CSS, JS, and some custom markup.
- etchalon 9mo ago1. ... I do not understand what you mean. 2. One person's "premature optimization" is someone else's "this was literally something I dealt with this week." 3. This method relies on CSS and HTML, just as any other styling solution would.
- grodriguez100 9mo ago2. Yet it was you who said “future” in the first place…
- Kerrick 9mo agoArguably, that would be misuse of the semantic meaning of "section." While <section> is nearly as generic as <div>, they should always have a heading of their own. The author's <swim-lane> already has a nested <section> with its own <h2>, but the <swim-lane> itself doesn't get (or need) its own even-higher heading. And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
- akst 9mo agoWeb components come with additional complexity, heavy use of custom element definitions are more complicated to manage. It’s more than just an aesthetic preference But if you’re not really using web components it’s harmless but it’s a bit odd and pointless.
- Kerrick 9mo agoHTML had custom elements before Web Components (the complex modern JavaScript & Shadow DOM thing) came into being. https://www.w3.org/TR/2016/WD-custom-elements-20160523/ https://www.w3.org/TR/2016/WD-custom-elements-20160523/
- akst 9mo agoIn case you’ve forgotten this is a thread on an article about web components. If the underlying premise of your point was entirely independent of web components you’ve done pretty poor job of communicating it. So you actually do that? Use custom elements without web components instead of using classes? Are you using in something like react with custom elements foregoing type safety to avoid a div element? Or is this just in plain HTML? How many custom elements does your typical web project have? Or are you fixating on an irrelevant technicality to make an irrelevant point?
- Kerrick 9mo ago...? The article is literally about not using web components. FTA: > What would happen if we took the ideas of HTML Web Components and skipped all the JavaScript? [...] Okay great, we styled some HTML nested inside a custom element.
- spartanatreyu 9mo agoIf you're not actually getting anything semantically useful out of the element, then you may as well use a custom element. Also by using a custom element instead of a class, you're saying this isn't anything else other than what I say it is. It's not a <section class="swim-lanes">, it's not a <form class="swim-lanes">, it's not a <blockquote class="swim-lanes">, it's a <swim-lanes>. If you make something only a class, people end up misusing it in odd places.
- spankalee 9mo agoI'm a big web components guy, but calling these web components is a massive stretch of the word component. The word "component" has to mean something ultimately, and to me the defining feature of a web component is that it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS, etc. Web components shouldn't require an external framework or external CSS (except for customization by the user) - those things should be implementation details depended on directly by the component. This here is just CSS using tag names for selectors. The element is doing nothing on its own. Which is fine! It's just not web components. edit: Also, don't do this: <link-button> <a href="">Learn more</a> </link-button> That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. Too many HTML elements can slow the page to a crawl. Use classes: <a class="button" href="">Learn more</a> They're meant for this, lighter weight, and highly optimized.
- rafram 9mo ago> To many HTML elements can slow the page to a crawl. You can read the entirety of War and Peace in a single HTML file: https://standardebooks.org/ebooks/leo-tolstoy/war-and-peace/louise-maude_aylmer-maude/text/single-page https://standardebooks.org/ebooks/leo-tolstoy/war-and-peace/... A marketing page, SaaS app landing, etc., will not even begin to approach that size, whether or not you add an extra wrapper around your <a>s.
- shimman 9mo agoAlmost 15,000 elements! I do agree that too many elements can slow a page but from my experience that starts to happen a few hundred thousand elements, at least that's what we'd run into making data visualizations for network topologies (often millions of nodes + edges) but the trick for that was to just render in canvas.
- atoav 9mo agoThis is a wonderful example how people live in the inverse-world. Marketing is in the end a way of trying to get people to listen, even if you have nothing substantial to say (or if you have something to say, potentially multiply the effect of that message). That means you have to invent a lot of packaging and fluff surrounding the thing you want to sell to change peoples impression independent of the actual substance they will encounter. This to me is entirely backwards. If you want people to listen focus on your content, then make sure it is presented in a way that serves that content. And if we are talking about text, that is really, really small in terms of data and people will be happy if they can access it quickly and without 10 popups in their face. Not that I accuse any person in this thread of towing that line, but the web as of today seems to be 99% of unneeded crap, with a tiny sprinkle of irrelevant content.
- senfiaj 9mo agoI'm not a fan of these custom elements. Unless you do something really interactive, dynamic and reusable (an element with complex behavior), I don't think it's worth to use them. The SEO / accessibility becomes more challenging. Also, worth to noting, web components require JS, so they are not pure "CSS" web components. Web components are useful for isolation, when used with shadow DOM.
- jakelazaroff 9mo agoUsing custom elements as the article suggests doesn't require JavaScript, so they are "pure" HTML and CSS (though whether they count as "web components" is up to you). More to the point, all of the technologies that the term "web components" includes — custom elements, <template> tags, shadow DOM — can be used without JavaScript. <div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
- senfiaj 9mo agoMy point is that defining a complex behavior for a custom tag is not possible without js. For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>. I mean you can use something like <host-element> (html5 allows that), but it will just be an inline element, almost like <span>, but without semantics. It's not a full web component. > "shadow DOM — can be used without JavaScript" Yes, shadow DOM can be used without JS, but I was talking about web components. > "I'm not sure what SEO and accessibility challenges custom elements would introduce?" If you replace standard elements (such as 'p', 'a', 'button', etc) with custom ones it can hurt SEO and accessibility. There are very few reasons to use custom element names and attributes if they are not full web components. What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
- deleted 9mo ago[deleted]
- deleted 9mo ago[deleted]
- kelvindegrees 9mo agoIs this not exactly what DaisyUI (https://daisyui.com https://daisyui.com) is?
- spartanatreyu 9mo agoNo, daisyui is a bandaid over the class soup that is tailwind. It's treating the symptom rather than the cause. The solution is not to use tailwind in the first place.
- hawkticehurst 9mo agoAuthor of the blog post here! Since this blog post, I put this idea to practice on the VS Code website (https://code.visualstudio.com/ https://code.visualstudio.com/) to create all the interactive graphics on the homepage. Which is a slightly different use case than what I described in the post, but cool and effective none-the-less. What woud have been a soup of `div` elements with various class names are now more meaningfully named elements like `<top-bar>`, `<chat-container>`, etc. that were mixed and remixed to create all the graphics. Also no issues regarding performance that we've seen up to this point, which makes sense; browsers are very good and fast at rendering HTML elements (native or custom).
- megaman821 9mo agoI have flirted with this in the past and an important note that you are missing from the post, that this type of custom element should only replace divs and spans. These new elements will have no meaning to the document outline or for accessibility.
- dgb23 9mo agoI like that the author came to the idea by cross pollination via web components. However, it's basically describing the "modifiers" part of BEM, which is a pattern that emerged from structuring CSS. Neither custom element or attributes are needed, even though they might feel different. If you like that kind of pattern to structure CSS, then combining it with custom CSS properties (often called "variables", example: --block-spacing: 2rem) makes it even more modular. These properties follow the cascade rule.
- deleted 9mo ago[deleted]
- Zardoz84 9mo agoUsing a expression from Spain : Es mas viejo que el cagar.
- Footprint0521 9mo agoThis feels like saying “what if we just coded in raw HTML CSS instead of JS library bloat.” Which is valid but also this article idea seems to make the rounds every two weeks
- sublinear 9mo agoMy experience with marketing pages is that they usually have a ton of inconsistent design requirements and change frequently. Most "frameworks" are the wrong tool because they assume that the markup and design (HTML/CSS) won't change as much as the functionality (JS) when it's exactly the opposite situation. All the consistency needs to be concentrated in the JS without the baggage of any particular HTML/CSS in mind. The only aspects of a framework you should want are a flexible way to register event listeners onto the elements, and organizing the styles and callbacks. In practice, this ends up looking like a static HTML file that is not up to the developers how to organize apart from the usage of CSS classes because it will be audited by many non-devs, a Sass build derived from design guidelines with some alt classes to contain the mess when people change their minds, and some very robust JS that you're gonna have to write almost entirely from scratch. I still don't get why this scares some people off though. You won't ever need to (re)write that much JS. Every new page design is just remapping existing functionality to the new HTML IDs, and maybe every now and then adding new functionality. Most of your time will be spent in CSS which just plain makes sense!
- dannye 9mo ago<tag-name> Browsers create ANY tag with at least one dash as a *Custom Element* They come in TWO flavours, and since they ARE HTMLElement, can be used for layout AND styling with CSS. The official names are: ► UNdefined Custom Elements (the article calls these "CSS Web Components") - shadowDOM optional with Declarative ShadowDOM ► Defined Custom Elements - Defined with the JavaScript Custom Elements API - shadowDOM optional - A new Element, or an UPGRADED existing UNdefined Custom Element --- ### Good to know about UNDEFINED Custom Elements: * Absolutely NO JavaScript required, it is only HTML and CSS * This is STANDARD behaviour in all browsers for nearly a DECADE now: Chrome (2016) Safari (2017) FireFox (2018) * The W3C HTML Validator accepts ALL <tag-name> Custom Elements with a dash as HTMLElement. It does not accept <tagname> (no dash), those are HTMLUnknownElement * Custom Elements do not inherit the standard [hidden] behaviour; so you have to add that behaviour yourself in your stylesheet. * Same for DIVs display:block. You have to set the display property on these Custom Elements yourself. (You will forget this 20 times, then you never make the mistake again) * The :defined pseudo selector targets standard HTML tags and JavaScript defined Custom Elements * Thus :not(:defined) targets the UNdefined Custom Elements; again... they are still valid HTMLElement so CSS applies like any element * <you-are-not-bound-to-one-dash> * Declarative ShadowDOM <template shadowrootmode="open"> creates the same UNdefined Custom Elements WITH a shadowDOM * The Custom Elements JavaScript API upgrades UNdefined Custom Elements TO defined Custom Elements. * You can't UNdefine defined Custom Elements * You can't REMOVE a set shadowRoot * for now, only Safari supports multiple custom element registries (duplicating Custom Element names) ---- Why? ► Try to find that closing </div> in a long HTML page. </tag-name> is always just there. ► Built a UI that doesn't FOUC, and UPGRADE it lazy-loaded with more logic and interactivity... you can not do this with technologies that CREATE HTML AFTER DOM was parsed. Custom Elements/Web Components ARE HTML; Frameworks CREATE HTML We will forever call Custom Elements: Web Components, and vice versa...
- Kalabasa 9mo agoSee also https://jordanbrennan.hashnode.dev/tac-a-new-css-methodology https://jordanbrennan.hashnode.dev/tac-a-new-css-methodology