I'm fond of data-URI's (MDN Link). 12 years ago I reappropriated a tool that stored a webpage with its related resources in a Microsoft specific format and rewrote it into something that would store it in normal HTML where the related resources were encoded in data URI's. Recently the topic came up again at a project I was working in, where microservices are still a thing. And while discussing it with colleagues it seemed as if knowledge about this quite useful URI-scheme wasn't on top of everyone else's mind. Instead, the original idea was, we could upload the resource to S3, pass the link, download the resource from S3 at the receiving end, and then have some policy that takes care of deleting it… nah…
This is the most simple data-URI:
data:,Hello%2C%20World%21
You [can open it in your browser](dat…
Recently I was reviewing a merge request of some front-end code, and a simple div, that changed a bit of the custom appearance of a block of text through a few custom classes, was changed in a call to a view component that then applied the same classes, passed onto the component through a more deeply nested hash.
> -
> +
’itis ](https://en.wiktionary.org/wiki/divitis) you get ‘TextComponent’-itis.. we don’t add better semantic or structural information to the page layout
Keep the code as is. And perhaps create a ticket (or annotate it with TODO:
) that you perhaps want to extract this ‘custom-class’ call into a true reusable component. While I don’t think there is something inherently bad with offering the option to override or add some custom classes to a component, a component should only be used if it adds structural meaning either from the developer's side of things or (better) from the consumer’s side of things (e.g. semantic output that can be p…
Some observations on headings in sections elements in HTML.
Below demonstrates that the h1-element adjusts it's appearance level based on the section element. This is conform the standard. It is behaving like the h-element as I remember it being proposed with XHTML2. When inspecting the attributes in Firefox's accessibility inspector, however, the level attribute is still equal to the element's number. Also, this increase in appeared header-level doesn't change for h2-elements and up.
h1 in div-element h2 in div-element h3 in div-element
h1 in section-element Not all h1 are equal h2 in section-element Notice how the h2 is like the h1 within the section h3 in section-element
Sorry, even wat borstklopperij, maar ben wel een beetje trots hierop. Enkele jaren geleden werd ik door een oud collega van mij geïnformeerd: hij had gehoord over een project waarvoor ze eigenlijk iemand zochten met mijn profiel (mijn naam was zelfs genoemd). Interaction design achtergrond, in staat zelfstandig een UI neer te zetten op basis van moderne standaarden. De opdracht: een oude extranet applicatie, met een historie uit begin jaren nul even een nieuwe smoel geven (en responsive maken). De opdracht werd gepubliceerd, ik reageerde, en uiteindelijk werd besloten dat ik deze mocht uitvoeren.
Het bleek te gaan om een verzameling oude stijl PHP en CGI scripts. Met een op framesets gebaseerde layout, zoals je dat rond 2000 wel vaker zag. Ik ken veel collega’s die liever wegrennen bij een dergelijke opdracht, zoveel oude code, zoveel historie, maar ik had het idee dat ik het wel kon doen. Een aanbestedingstraject voor een volledige nieuwbouw bleek jaren geleden mislukt omdat de …
I’m a sucker for standards. Especially those more theoretical standards: peak theoretical standards era for the web is the era that promised the semantic web; early 2000’s.
In that time, the first version of this site was built using an XML-based index file, XML files that provided meta data on certain topics and XHTML files that featured the content. With PHP-code to tie requests and responses together, the site was mainly powered by several (big) XSL-Transforms that rendered the pages (it (c|sh)ould’ve been a static site).
Fast forward to today. While WebAssembly is gaining traction, these days the focus is on JavaScript for components. Popularised by frameworks such as React, new elements are defined in JavaScript that can be used in the DOM (the latter is not what React uses btw). The (promoted as) ‘standard’ way to make custom elements is using WebComponents. Yet this effort is driven primarily by Google.
And I’m still closing my ``’s and write `…
Some excerpts I created from the transcript of the Design System Podcast, hosted by Chris Strahl, which in Episode 11 featured Brad Frost and Evan Lovely.
The traditional process starts with the design of comps, comps, non-interactive previews, which are generated by the design team and undergo a rigid design review process up to a design director or VP, and is only then passed on to the developers who need to implement that initially static comp pixel perfect. But Evan Lovely notes that while there is nothing wrong with comps, there is something wrong with mistaking it for the final product. That’s why he likes tools like pattern lab, storybook or knapsack, because they really allow someone to quickly mock up a comp that actually works within the final environment.
To some companies this is a problem; because the formal approva…
Since his talk at Fronteers I was interested in the thinking of Brad Frost, his blog posts, etc., but never actually read his book Atomic design until recently, as it got more and more relevant to an internal discussion at an organization I was working for. A few notes:
Tippy.js is a nice library to show popups. It may, however, not always be obvious how to use Tippy.js with Turbolinks (or any other library that modifies the DOM). The basic ingredient is somewhat hidden in the docs: deffered
. But loading a HTML template requires a slight adaptation of what is presented in their documentation to make loading of these templates deferred.
From beginning to start. Add the library:
$ yarn add tippy.js
Add a CSS-class for your templates to be hidden by default:
.tippy-template-content {
display: none;
}
And then add the following to your application.js (or equivalent in your setup):
import {delegate} from 'tippy.js';
delegate('html', {
content(reference) {
const id = reference.getAttribute('data-tippy-template');
if (id) {
const template = document.getElementById(id);
return template.innerHTML;
}
},
allowHTML: true, ...
Below is a simple, lazy, technique I applied in a collection management tool where its users wanted to browse over 10.000 images without scroll-hijacking or pagination. Sure, only the HTML weight several MB’s at once, but for this particular application used by professionals it is worth the weight. But performance was too heavily affected by downloading all these separate images.
So let’s have a look how I solved this.
What does the code below do?
You rightly guessed that it won’t display any image to say ~95% of the users. The 5% who have disabled Javascript however, will see it.
The 95% who do have Javascript can enjoy the image simply by moving the img tag out of the noscript tag using a bit of JavaScript:
ELEMENTS_QUERY = "noscript[data-lazy=\"lazy-load\"]"
decode_entities = (encodedString)->
## required for IE and Safari
textArea = document.createElement('textarea')
t...
Any HTML is legal, so you can just write a regular link, but if you want to have a fast response, it is recommended that you include Vue Router. This brings two important tags: , which this post is mainly about and
.
Creating a link in Vue is as simple as:
Home
This renders a perfectly correct link, using the earlier mentioned a-tag. It even adds a nice bonus, adding an ‘active’ class when that route is active. If you prefer this class on the containing element, do this:
Home
This will render something along the lines of:
Home
Be aware: this is the only valid use-case for the tag-property in vue’s router-link component. Hence be wary if you come across any use of the tag-property, but Vue’s default is good.
You pick up on this link by defining the route ‘home’, make sure your app contains a and attach a component to this route. In the most basic form:
…
Congratulations, you started working with one of the popular front-end frameworks. Both Vue and React are excellent choices to create rich and reactive applications. But sometimes, you 'just' want to show the user another page. Whether it is a simple about page, or another 'section' in the app. In this post I will cover both Vue en React and, little bonus, “React on steroids”, NextJS.
It is important to know that you need a router to make in-app pagination work. If you look up router and your favourite framework you're probably find a way to do it, accompanied with some ways to actually not do it. Hence, here I'll focus on the right way.
While you can make everything clickable (or touch-able), it is important that enabling navigation between pages was already a core concept when the web was invented. Even when writing webpages using React, Vue, or most other JavaScript frameworks, it ends up as HTML to the browser (with JavaScript & CSS). HT…
I haven't had much need for isolating services, something that Docker is really good at. Most dependencies of my Rails apps are covered by Gemfile
anyway (and packages.json
for JavaScript) and reasonably isolated with rbenv
. I don't experience version related issues very often, as I try to stay reasonably up to date and not rely too much on the very state of the art. For temporary projects, however, Docker is a great solution, even for me :o I don’t want an entire JBoss suite running on my machine, so when I had to develop a Keycloak template I knew that Docker would be the right tool. While I’m going to discuss the specifics of getting started with a Keycloak image, the workflow described is replaceable by any other.
So what about Keycloak? Keycloak is a role based authorization and authentication tool …
To put it in some context: these days recruiters call you whether you know this or that framework. Well not really, really well. But it is just JavaScript. Or ECMAScript (or a flavour of it by Microsoft called TypeScript). But above all it is just a tool to get stuff done. Not every job needs a bulldozer. And besides the bulldozers React and Angular there is Vue.js and plenty more. Choose your tools wisely.
My guiding principle in web-development is (still): Always make things work without (client side) JavaScript first.
Aside from offering a graceful degradation of the experience by progressively enhancing it leads to better code. Three reasons why:
Yes, I do shiver when I hear things like CSS in JS, KISS!
Photo by [Dmitry Baranovskiy](https://www.flickr.com/photos/dmitry-baranovsk…
To the ruby-folks (ruby is a programming language). Just a quick note to inform you that I've coded a new ruby gem:
> Web page archiver is a gem for creating web page archives: single files that contain images, Javascript, CSS, and the actual HTML. Of course you may zip these files, but there is hardly any support for opening and viewing such files without first requiring the user to extract the files before viewing. The solution offered in this gem is either MHTML or HTML with no external references. MHTML (or MIME HTML) is the default archive format for Internet Explorer and Opera, and can also be read in these browsers. HTML with no external references is not written by any browser as a standard archive format (that I know of) but can be read by any browser, as long as it has support for the Data URI-scheme (all modern browsers, although size limits apply to IE8).
More on the Web Page Archiver github page.
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .