[rfc-i] Graceful degradation is key, was: Re: draft-hildebrand-html-rfc

Tim Bray tbray at textuality.com
Sat Jul 14 08:24:44 PDT 2012


OK, now that we've shredded all the counterfactual arguments, what's left
is grep. Yep, multi-word grep is broken on markup languages like XML and
HTML because of the invisible tags, which nroff output doesn't have. It's
also broken on nroff output, because of the artificial newlines, which *ML
needn't have. Single-word grep works fine, either way.

Straws are being clutched at.

-T
On Jul 14, 2012 8:13 AM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:

> On 14 Jul 2012, at 16:36 , Tim Bray wrote:
>
> > > So the difference between regular and italic text can't be
> semantically meaningful, because that difference isn't there on some
> character based terminals
>
> > I haven't seen anyone using a "character based terminal" in at least a
> decade. Anyone.
>
> I still hope to be able to log on to my Mac on my VT420 terminal some
> day... I haven't found the right getty configuration so far, though.
>
> The reason why _compatibility_ with text terminals is still necessary even
> though text terminals themselves are no longer in use, is that the command
> line largely behaves like a text based terminal. Removing the ability to
> comprehend an RFC fully through the command line interface means removing
> the ability to use command line tools like grep in many cases.
>
> The big jump is from formatted ASCII to a markup language based format (or
> even PDF or some such). Let's make that jump without going overboard can
> severing all ties to the past. A few years down the road when we've gained
> some experience with the new format, we can always drop compatibility if
> that seems like a good idea at that point.
>
> For what we're doing now, I think it would be enormously helpful to be
> able to generate RFCs in the old format from the new format without losing
> anything meaningful.
>
> If that means that some math guys still can't express themselves the way
> that comes natural to them in RFCs, I can live with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120714/6334c541/attachment.htm>


More information about the rfc-interest mailing list