Are standard web components on the roadmap for this? They are expected to have wide browser support this year, so it’s a good time to start using them as a foundation (there is a polyfill for non-supporting browsers). For the uninformed, they will remove all the overhead of having to manually manage the style sheets and CSS classes; instead, the developer just inserts custom elements (e.g.<frend-accordion>) and everything is taken care of automatically.
Good question, Šime. We'd be open to a move to web components in the future. At their core, it seemed beneficial to keep the inner workings as visible as possible - transparent examples of each pattern based on specs. Although there is a maintenance trade-off, definitely.
Could you see a web component version living alongside the standard implementation?
Why would a web component not be a standard implementation? Web components are literally the standard way to create new HTML tags, and render and style the internals in an encapsulated way.
Yep. To clarify, these aren't _web_ components. Better to think of them more as vanilla UI widgets. Is it worth rewording on the thread/repo/website to avoid confusion?
I think the website is clear - any confusion over the HN submission title is my fault. I think of "web components" as distinct from "Web Components", but it looks like that's just me.
The bypass links are actually pretty neat.
Do many sites implement them this way? Seems like a win both for accessibility, and developers who love their keyboards.
As someone who has developed websites for many government projects where accssibility is mandated by law, yep this is generally how we've done bypass links for a while.
The code style here looks really weird - for example, the 4 space hard tab is a rarity with JS: https://github.com/frend/frend.co/blob/gh-pages/_components/... . Lot of rough edges there, such as not making use of Array.from(nodeList).forEach instead of brute forcing on the prototype. There's also some nasty DOM traversal as well in some of these components.
It should also be noted that these aren't web components in the Web Components sense - the title is very misleading. These are just vanilla components.
Agree on the NodeList.prototype reassign - not a well informed decision (see source comments around its inclusion). We think it's worth correcting: https://github.com/frend/frend.co/issues/64
A hard tab has no width. This is just how GH chooses to display it.
Not to get in a tab-vs-space war, but that's like the primary benefit of it: you can display a hard-tab however you want. A soft/spaces-tab is displayed how the author wants it.
(I use 2-space-tabs nowadays purely out of convention)
Absolutely. I'm currently working on an in browser IDE for a language I've created that compiles in the browser, and it has both a code view and a WYSIPCTWYG (what you see is pretty close to what you get) design view. Tabs work well as a separation between code and design, given the context. We also use an accordion for the controls which you drag onto the canvas, as there are more controls than we can fit into the palette in a comfortable layout. Granted, I created my own, but they're proven concepts.
I don't think I've once looked at my car and asked "Steering wheel? pedals?. Are car designers still using these things?"
