From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 60AF8240B9 for ; Thu, 4 Apr 2024 04:24:54 +0200 (CEST) Received: from mail-lj1-f181.google.com ([209.85.208.181]) by 9front; Wed Apr 3 22:23:26 -0400 2024 Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2d4a8bddc21so6323951fa.0 for <9front@9front.org>; Wed, 03 Apr 2024 19:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712197401; x=1712802201; darn=9front.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=CphQkitoXubZPTV0pFIYASGXLkv9DdaPJBnYzJrUwTQ=; b=CPcw44WalCBEsgrZylFMM6ECx/P+/Y+0sFE+t57u6XJkfdUzuYj0Vh/ih3WRGpopZ2 +Ui0SI/0cizUqjsHsYk0LVD/I01fF6Zpchf/B5DFRKsx+OwHiL/rqXB62QELvTIn0CJW Vbbpi+/FZR4sRlid0gcMQ/ocQcVsrnWidO6cI8Zj9BBlAv9iG9uxnDJmwhL6A3hNQkRs e7nVvaxCIeHz81ONUYJoDX0Pz0Vdnba4DN+gGl3B9O3Ym8nmk6XMozmm+ygPPurK9TUj t+QyQn2/nE7gG19n/z47hpvOzIN7iSUnM1zp6zlNVbMWDSUq3I7ZOfZcv8hmnF9WWSn5 POtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712197401; x=1712802201; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CphQkitoXubZPTV0pFIYASGXLkv9DdaPJBnYzJrUwTQ=; b=nm8mHC47uhhl1DUMu5E8QqJa+wLboB66fPW9Dg6CGxoDkKefx9PM+zb7vTt9ktnpKT Pub1gly4Q3MhASRqG3+YnCDlMdtTmM69Q4ijJQPUcTIyyz6y4FHX4HCXqLxLkm+UWEtQ EQ0QomMKzXpVxEO/XApBB2VZSArTCpFPXyhQVW6raVjhBidf43BudahaoaaKRs6Jt+it VDgreTKOJKsHuFWVpKROZ9pYi1FDmyVXk1k62PzYpL+ycKUZqifZAgVSnxPdz0Ro73Lu L9AXRSAU9iMUEhVWSg47pKq55MgoKdfVbLE0aMkBH5kRrcymQVU+i3hu4YoF+CCDTyOc xbVA== X-Gm-Message-State: AOJu0YycBvfTxJa4qy3aelP/eTem7nbNSj1tOAod+4KmyzNuduPVEUh7 HNmbdnPS+yhcfMYPlauRI1tVx7PVbkakaZMyBo8LORu/9k/8iuUfCvYAHe2+ X-Google-Smtp-Source: AGHT+IHxNZrE0KwzhIf6+zgRjs7ECLO7kJx0tbGDt36Qnge6IWxEG5H2wKnet/EOvKyaTzklYhGzeQ== X-Received: by 2002:a2e:aaa4:0:b0:2d8:113c:d58 with SMTP id bj36-20020a2eaaa4000000b002d8113c0d58mr832621ljb.20.1712197401338; Wed, 03 Apr 2024 19:23:21 -0700 (PDT) Received: from rogue.localnet ([46.8.104.251]) by smtp.gmail.com with ESMTPSA id k11-20020a2ea26b000000b002d808b86073sm1300151ljm.78.2024.04.03.19.23.20 for <9front@9front.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 19:23:20 -0700 (PDT) From: an2qzavok@gmail.com X-Google-Original-From: an2qzavok2gmail.com@tete To: 9front@9front.org Date: Thu, 04 Apr 2024 05:23:18 +0300 Message-ID: <1811213.3VsfAaAtOV@rogue> In-Reply-To: <7833cb39-ccb1-4f04-89ac-aaab6f25b80e@howhill.com> References: <9a2ec537-c6a5-4c44-8306-d12ebee98446@howhill.com> <25847D39-F21B-463F-922E-E49E98CC6D85@gmail.com> <7833cb39-ccb1-4f04-89ac-aaab6f25b80e@howhill.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: managed extended JSON component-oriented proxy software Subject: Re: [9front] Musings on web browsers and office applications Reply-To: 9front@9front.org Precedence: bulk > That's intriguing. What are those edge cases? My memory of HTML standard is fading... Main issue is all the elements that have extra state associated with them. Sometimes data needs to be fetched from outside (img, link), fetching can be non-trivial and controled by client software (source) or user (audio, video). Sometimes data is provided by user (text input fields, radio buttons), or generated by scripts (canvas) Very often data needs to be processed before use (decoding videos, resizing images) iframe is nasty in particular because it's not just static data but another whole DOM instance. Another issue is various metadata, for example style properties. Those need to be derived from multiple sources (some of them external, i.e. linked css) and can be changed by scripts and need to be recomputed. And a real showstopper is dynamic/OOP nature of the DOM, where nodes have many methods depending on their type (around 12 of them) and can be created, destroyed and rearranged right under user's feet. It's hard to draw a line on where handling all of this belongs, fileserver or it's client. The more work we push on the client, the less useful server becomes, but doing things in server ruins all our hopes of having nice and clean file structure and doesn't make client's work any easier, only different kind of complicated. (Huh, I guess these are not really edge cases, these are meat and bones of HTML now. Sorry for the confusion.)