Wow! Just realized I've been blogging for over 20 years, starting way back in August 2004 on kinlan.co.uk with Blogger. The journey has taken me through Posterous and landed me here on paul.kinlan.me with Hugo (and maybe Jekyll at some point). Sure, there's some cringe-worthy stuff in the archives, but it's my history. And honestly, I wouldn't be where I am today without this little corner of the internet. Huge thanks to Tim Berners-Lee and everyone who's made the web what it is!
I presented "Aiming for the Future" at Bangor University, exploring computing's evolution from the Difference Engine to the modern era, focusing on content/data delivery shifts. I proposed that Machine Learning, especially Generative AI, is the next major computing wave, akin to the Web's rise in the early 2000s, potentially mechanizing mental labor. The Student Expo showcased many final-year projects incorporating AI, from creative tools to practical problem-solving, indicating the growing importance of AI in various fields.
In this post, I explore the potential of the File System Access API to create local-only web experiences. I discuss how this API, combined with tools like Logseq, allows for on-device data storage outside the browser sandbox. While exciting, I also acknowledge the current limitations, such as the need to re-grant file access on refresh, the lack of a visual indicator for local-only sites, and the difficulty of preventing data exfiltration entirely. Despite these challenges, I believe this area holds significant potential and deserves further exploration.
I'm so excited by the renewed interest in web development sparked by Wordle! It's a simple, fun game that highlights the power of the web. It's accessible, fast, user-friendly, and has inspired countless developers to create their own versions and variations. This post celebrates Wordle's impact, lists various Wordle-inspired projects (including different language versions, framework implementations, and even tools), and encourages readers to share their own discoveries.
The web's organic growth, with examples like Google Maps' early API and widespread embeddability, leads to questions about its current design. Would we recreate this structure today? Likely not. This suggests a need for change and migration, but how can this complex transition be managed effectively, especially considering the scale and interconnectedness of the web?
This post explores the ever-evolving landscape of web technologies and their compatibility across different browsers and platforms. It examines tools like iwanttouse.com and other resources to determine what web features can be safely used in 2021. The discussion will also include insights from industry experts like Jason and Mathias Bynens regarding JavaScript best practices. Finally, the post proposes the innovative concept of adopting a "quirks mode" but tailored to specific years, which could offer greater control over web development.
I'm starting to think about Chrome Dev Summit 2022. Top of mind is everyone's safety with the ongoing pandemic and how to make the event as inclusive as possible. I really value the connections and hallway track of in-person events, but also the reach of online. I loved the CDS 2020 workshops and office hours, and believe we should expand on those. Content-wise, I want to focus on what makes the web amazing, showcasing great experiences, and exploring key technologies like Core Web Vitals, Privacy Sandbox, PWAs, and Project Fugu. Also, more content alongside talks, please! And maybe shorter, more impactful online presentations?
This post explores the concept of web compatibility and whether it can be quantified. It draws parallels to the Receiver Operating Characteristic (ROC) curve, questioning if a similar metric could represent the trade-off between compatibility and feature availability. The post also examines how browser vendors' incentives influence feature adoption and proposes leveraging compatibility data sources like caniuse and web platform tests (WPT) to prioritize compatibility improvements. Potential tools, such as a compatibility bot and automated blog updates, are suggested to highlight these improvements.
Check out Browser Bug Searcher, a tool created by Robert Nyman and Eric Bidelman that helps you easily search for bugs across major browser engines. It's a super handy resource for staying up-to-date on the status of web platform features. I wish more bug trackers, like crbug and webkit, had easy RSS feed options like this so I could integrate them into my personal dashboard.
While building a web-based video editor, I encountered an issue with handling multiple video tracks in a MediaStream. I wanted to switch between different video sources (desktop and webcam) on a single video element without interrupting the MediaRecorder. Attempting to do this by toggling the 'selected' property on the videoTracks object of the video element failed. The videoTracks array only contains the first video track added to the MediaStream, even though the stream itself contains both tracks. This prevents seamless switching between sources within the video element.
In this post, I explore importing npm modules into web projects using ES6 modules. I needed a quick way to use the 'get-urls' npm module in my ES6 project without resorting to CommonJS bundling. My solution involves creating a wrapper file to import the module, using Rollup to handle Node globals and builtins, converting to ES modules via the CommonJS plugin, and finally, including the bundled file. This highlights a larger issue: much of the Node ecosystem, though not inherently Node-specific, is tightly coupled with it through CommonJS and APIs like 'Buffer' and the old 'URL.' Transitioning to ubiquitous ES modules will require effort and potentially be painful. Until the ecosystem adapts, we'll rely on conversion tools and bundlers for cross-platform code sharing. While using '.mjs' as a standard extension is promising, the lack of infrastructure recognizing it as 'text/javascript' necessitates further server-side configuration, which adds complexity.
I explored the power of hyperlinks beyond traditional web pages, emphasizing their potential to connect apps and websites more seamlessly. Current linking methods, while fundamental to the web's interconnected nature, fall short of the ideal. I advocate for expanding the capabilities of registerProtocolHandler to access native schemes system-wide, enabling websites to handle various content types and register as system file handlers. Furthermore, I propose a richer vocabulary of link actions beyond 'VIEW', such as 'PICK', 'SAVE', and 'EDIT', to better define website and app capabilities, similar to Android Intents and Siri's functionality. Tools like Comlink inspire this vision by simplifying cross-app communication, paving the way for link-driven function discovery and a more integrated online experience.
This post discusses the problem of content silos on the web, particularly how native apps dominate sharing functionalities, limiting the web's reach. It highlights the irony of navigator.share, which, while enabling web sharing, still directs users towards native apps. The post emphasizes the need for the web to participate more actively in user interactions. It celebrates the 'Improved add to home-screen' feature for PWAs on Android, generating APKs and making them function more like native apps. Finally, it introduces the promising 'Share Target API', allowing PWAs to receive shared content, including links, thus breaking down silos and fostering a more inclusive web ecosystem.
I've always been fascinated by the potential of the web as an API, an idea I first encountered through Michael Mahemoff's work with microformats and CORS. While technologies like Web Intents explored similar concepts, they proved more complex. The core idea remains powerful: enabling direct client-side interaction between websites to bypass the complexities of server-side integrations. Although CORS is widely supported, its complexity hinders adoption. With the rise of client-side generated sites, the need for decentralized integration is stronger than ever. Tools like Comlink, by abstracting the complexities of postMessage and MessageChannel, make it easier to expose and consume client-side APIs. I demonstrated this with a simple example integrating a pubsubhubbub endpoint with a push notification service. This approach offers several advantages, including simplified data transfer, offline capabilities, and secure, controlled exposure of functionality. Looking ahead, I envision a future where every website exposes a consistent, discoverable API, enabling a more interconnected and modular web experience.
I'm excited to share the latest addition to the Shape Detection API: the Text Detection API! This API allows you to detect text within images in real-time, right in the browser. It's still experimental and currently works on Chrome Canary for Android, but it opens up amazing possibilities. Imagine real-time translation, assistive technologies for parsing image content, or even grabbing URLs from slides at conferences. I've built a demo where the API detects text, draws a box around it, and reads it aloud when clicked. Check out the code and demo to experiment yourself. I can't wait to see what you build with this!
Following on from my list of the things that I am [excited about on the web in 2017](/2017-exciting-times/) here are three predictions of things that I think will happen in 2017 based off reading tea-leaves and random musings of things that I have 0 direct knowledge of but I might do if I was 'them'.
Measuring the impact of autofill is crucial. In WebKit/Blink browsers, the -webkit-autofill pseudo-class helps track autofill, but it's not supported in Firefox. I've found a workaround in Firefox using the input event, checking for the absence of keyboard interaction. Ideally, a standardized :autofill pseudo-class and a dedicated onautocomplete event would simplify this process, allowing developers to measure and manage autofill effectively.
I'm excited to share a new, simple API for sharing on the web called navigator.share! It's available in Chrome Dev Channel on Android and allows websites to connect with native apps for sharing. This is a step towards a better inter-app communication system, simplifying sharing and potentially extending to other app interactions. You can try it now on my blog by clicking the share button. I've updated my blog to use it, falling back to my existing solution if the API isn't available. Check out the ChromeStatus page and other linked resources for more information and give us feedback!
There's a growing interest in using socket APIs directly within web browsers for various applications, both client-side and server-side. This post lists potential use-cases for outgoing and incoming socket connections, eliminating the need for proxying through web servers. Examples include email clients connecting directly to IMAP/POP3/SMTP, SSH/RDP clients, real-time communication tools like IRC and XMPP, P2P applications like BitTorrent, and direct connections to servers for various purposes like video streaming, Bitcoin, and game multiplayer functionality. For incoming connections, use-cases include hosting servers for many of the aforementioned services (IRC, BitTorrent, HTTP) directly within the browser.
Custom URL schemes for launching apps have limitations: single app handling, one-way data flow, lack of fallback, and limited mobile support. A better approach is needed, one that offers user choice, developer fallback, diverse data transport, web app registration, and online/offline functionality. Android's 'intent:' URL syntax offers a good starting point, abstracting service discovery and supporting fallback URLs. I propose exploring a new 'action:' scheme or 'web+action' to bridge web and native apps, providing a unified service resolution and registration system for a richer, more integrated user experience.
Sharing content between web and apps is difficult due to platform incompatibility. Android's intent system offers a potential solution, but it lacks portability. This post explores a workaround for sharing actions, using a server-side redirect to handle intent URLs for Android users while providing a fallback to a web service like Twitter for other platforms. This approach allows cross-platform functionality while leveraging Android's intent system when available.
This story starts a long time, was tickled into existing after I visited FlipKart in Bangalore and was finalized after an internal conversation about the fact that it is impossible to trigger the share dialog in Android from the web. Lots of people want it, it turns out everyone thought it wasn't possible. It is.*
Web Intents is a new project designed to solve the problem of web application integration. Inspired by Android's intent system, it allows developers to build features without needing to integrate with every possible 3rd party service. Web Intents lets users choose their preferred service for actions like image editing or sharing. The project has been revised with a simplified API to make integration easier for developers, requiring minimal code. Service registration is done via a new tag, and client initiation is also streamlined. Check out the examples at http://examples.webintents.org/ and share your thoughts as we work with Mozilla to refine this game-changing approach to web development.
I've been working on Web Intents, a project to simplify client-to-client service discovery and communication on the web using technologies like IFrames and SharedWorkers. It addresses the current issue of apps needing to integrate with third-party services, which restricts user choices. However, I recently discovered a similar project, Web Introducer, also by a Googler. It tackles the same problems with more in-depth security considerations. So, I'll be shifting my focus to contribute to Web Introducer. Web Intents remains a valuable example of using SharedWorkers and messaging effectively within web apps. More on Web Introducer and SharedWorkers coming soon!
2010 was a big year! Benjamin joined our family in June. I also joined Google as a Developer Programs Engineer, later transitioning to Developer Advocate, which has been an amazing experience. I've met tons of talented people, traveled a lot, and worked with developers worldwide. I've been busy with projects like creating a Chrome Web Store app, Chrome extensions showcasing the Management API, HTML5Rocks tutorials, and WebIntents. I even got a new LCD TV after years of waiting! In 2011, I'm aiming to code more, release more code, meet more developers, speak at more events, and most importantly, spend more time at home with my family.
I'm looking for a few web services that don't seem to exist yet. First, a way to save my Twitter favorites to Instapaper (or similar services). Second, a webhook that sends content to Instapaper, as I dislike relying on third-party app integrations. Finally, a service that sends full RSS feed content directly to my email inbox in near real-time using pubsubhubbub. Existing services only send partial archives. If I can't find these, I might build them as open-source projects.
I've updated my AJAX application, DeliTag (The Delicious Tag Poster)! Now, when you select text within the IFRAME, the application will analyze only the selected text instead of the entire page. This makes tagging much more precise.
I have a new program idea: an automatic tag creator for Del.icio.us, similar to my Ajax Tagging Application. It would analyze a webpage's content to suggest relevant topical tags, which you could then select and use to upload the URL and tags to Del.icio.us. I believe this would be a useful tool. What are your thoughts?
