Re: New web site

The ship has done more than sail, it has strapped a pair of jet thrusters
on each side and is wizzing off into the sunset. At this point, it is
fairly common to have sites using javascript to essentially implement a
whole different markup language of their own choice and then translate that
to a presentation markup.

When I look at the DOM representation that is actually in the browser, a
widget will often be wrapped in five or six <div> elements for obscure
purposes.

The problem is that when people are building tools to edit Web sites, they
are looking to achieve a particular look and feel and rather than that
happening through CSS becoming richer, it happened by drinking from the
poisoned chalice of active code.

Interacting with Web designers, I find myself talking a completely
different language because I am thinking in terms of HTML+CSS and they are
thinking in terms of a stack three layers deep on top of those, its way
past bootstrap now, I hear them talking about django on sploid-F, furzed on
giblig 6 and so on (ok, I made those up but you get the point).


I would wish it were otherwise but it isn't and just as I have to accept
what our baby became, maybe some folk lower in the stack need to accept
that the world has adopted an approach to networking that doesn't meet our
expectations either.


On Wed, May 27, 2026 at 10:42 AM Thomas Howe <[email protected]> wrote:

> +1
>
> I agree that in 2026, it’s unreasonable to expect that JavaScript isn’t a
> normal and expected part of the web experience.  More so, we have  strong
> controls over what we serve, and were there a security issue, there might
> be more concrete and specific reasons than the existence of JavaScript.
>
> In the words of JFK, a ship is safe in the harbor, but that’s not what
> ships are made for.  I appreciate the sentiment, but the JavaScript ship
> has sailed.
>
> =====================
> Thomas Howe <http://www.lightandelectric.com>
> +1 (508) 364-9972
>
> Sent via Superhuman <https://sprh.mn/[email protected]>
>
>
> On Sun, May 24, 2026 at 3:29 AM, Jay Daley <[email protected]>
> wrote:
>
>> Hi Stephen
>>
>> On 24 May 2026, at 12:50, Stephen Farrell <[email protected]>
>> wrote:
>>
>> On 24/05/2026 01:42, Nicolas Giard wrote:
>>
>> You can report any accessibility issues, and we'll do our best to fix
>> them, but the issue must stem from actual accessibility reasons / usability
>> concerns for people with severely constrained resources, not just because
>> "I don't like JavaScript".
>>
>> Where is the policy that underlies that "must" above documented?
>>
>> Apologies, the "must" part should have been worded better - a better way
>> of putting it is that full use of this particular site requires Javascript
>> and we won’t be trying to replicate all the JS features with non-JS
>> features even if tickets are added asking for that.
>>
>> If you’re asking where is the policy that says we don’t have to provide
>> strict JS/non-JS feature equivalence, then there isn’t one, but at the same
>> time there isn’t one that says we have to do that. Support for non-JS has
>> been discussed at open Tools meetings a number of times, the most recent
>> being the open meeting at IETF 124 Montreal and the clear community
>> feedback in those meetings has been that JS is a normal and intrinsic part
>> of the web experience and trying to make all of our sites fully support
>> non-JS is not reasonable.
>>
>> If you’re asking why we have JS only features then it’s because JS is a
>> vastly more capable tool than plain HTML/CSS and it therefore enables
>> things that cannot be done otherwise and with a better user experience.
>> That doesn’t mean we’re incautious about the use of it, explained below.
>>
>> And "I don't like JS" is not at all the issue, it's about attack surface.
>>
>> I think that’s oversimplifying a complicated landscape. The IETF sites do
>> not serve adverts, they control all of their JS and they do not serve any
>> JS that talks to a third party service. The IETF Privacy Statement is clear
>> on that. To be clear, I am not saying that running JS does not increase the
>> attack surface, just noting that our use of JS is intentionally very tight
>> and aimed at minimising the attack surface that JS introduces.
>>
>> cheers
>> Jay
>>
>> Thanks,
>> S.
>>
>> --
>> Jay Daley
>> IETF Executive Director
>> [email protected]
>>
>