>>>>> "Larry" == Larry Masinter <masinter@xxxxxxxxx> writes:
Larry> I think the discussion about “no JavaScript” in the Data
Larry> Tracker got side-tracked by bringing up IE6.
Larry> https://datatracker.ietf.org/doc/draft-hildebrand-html-rfc/
Larry> identifies requirements for Internet Drafts and RFCs, for
Larry> general access and long-term preservation.
Larry> It notes:
Larry> Any use of JavaScript in the HTML document will not
Larry> negatively impact the ability to read the document. Some
Larry> consumers of the RFC series routinely disable JavaScript for
Larry> security purposes.
Hi.
I understand the appeal of approaches like this.
It's desirable to support every browser, and desirable to support stable
interfaces, and desirable to support secure configurations.
However, it's also desirable to create a usable, responsive web site.
It's desirable to use current development techniques, to be able to use
modern off-the-shelf software, and to be able to minimize development
costs. We're in the business of writing standards, not implementing
them. Yes, there's a sense in which we should try and follow our
standards, doing things like supporting IPv6 and DNSsec for our
infrastructure services. However, for the most part, I disagree with
the proposition that the IETF should have significantly different
requirements for its web presence than any professional organization
trying to serv its users. In particular, infrastructure is a case where
we should generally trust the professionals we hire to do their jobs.
We should expect them to collect customer requirements from us, but we
should be careful not to overly constrain the methodology they use. We
need not and should not come to community consensus on software
development practices or the sorts of requirements about technology use
you're discussing here. In stead, I hope we come to community consensus
that we'll let the IAOC deal with that, and hopefully the IAOC will
delegate much of that to their contractors while overseeing the work
using reasonable industry standards.
With regard to the Javascript requirements you are proposing and related
similar requirements, I think there's a huge cost in terms of either
usability or development effort to what you're asking for. A web 2.0
website designed with a backend RESTful web service and with all the UI
in Javascript can be much more responsive. In many cases you won't need
to have a full page reload, you can save state more quickly, you can
more quickly update to reflect user input.
This sort of functionality is becoming what people expect in a quality
web application.
It kind of depends heavily on javascript.
In addition, it significantly influences how you design the app. It is
very difficult to design that sort of backended-by-webservice app in a
way that falls back to anything sane without javascript. You very
likely have to design the app twice, quite possibly in two different
languages with two different UI frameworks depending on what you are
doing.
Unlike the RFC series, the datatracker UI is online and does not produce
archival artifacts. It's not actually
important that today's datatracker UI work with tomorrow's browsers
provided that we are willing to continue maintaining the datatracker UI
so that by the time tomorrow's browsers are released, it works with
them. I'm not saying we shouldn't design for the future, simply that if
Javascript or AJAX were going away, we'd see it from enough of a
distance to react. It's certainly not important to me that the browser
pages (and associated resources like Javascript) produced by today's
datatracker function or look good with software 20 years from now.
Some aspects of the datatracker UI may have longer-term impacts. I'd
definitely like there to be stable URLs for ballots for documents as
well as for the datatracker information about the documents.
I think APIs including ATOM feeds about documents might want a stability
guarantee.
I definitely hope we forward migrate our data as we adapt our internal
schemas.
However, in my mind, that's a far cry from the sort of requirements
being discussed here.