W3C home > Mailing lists > Public > public-qa-dev@w3.org > September 2004

Re: Remaining HTML fragments in check

From: Terje Bless <link@pobox.com>
Date: Mon, 6 Sep 2004 13:27:30 +0200
To: public-qa-dev@w3.org
Message-ID: <r02010300-1035-BD8B67C7FFF711D8878C0030657B83E8@[]>

Hash: SHA1

Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

>Looking at v1.337 of `check` it seems that there is still lots of
>inline HTML/XHTML code in it, for example in parse_content_type(),
>authenticate(), doctype_spiel(), etc. aswell as XML/RDF/N3 code in their
>corresponding report_x() routines.

The report_foo() subs are not that important. They don't need to be easily
modifiable, they can be externally restyled (CSS or XSL), and they don't need
l10n. They may get moved out at some point but it's not a priority.

>Should I assume that this is just because no one got around to move this
>code to proper templates or are there other reasons that make it difficult
>or even impossible to move them from `check` to some other place?

A bit of both. They're still there because it's difficult to externalize them,
but it's not impossible by any means so you might say it's an issue of round

>How much of this inline code should/must/will/... be in our upcoming 0.7.0

Right now it looks like most of the remaining inline code will still be there
for 0.7. One way of dealing with it is to just dump it to a template to get it
out of the way, but my intent has been to leave this off for when we have a
decent l10n framework in place to do it right.

But then, priorities for 0.7 have been changed on me; I'd initially planned to
have the l10n stuff in place for 0.7, but now it looks like it's 0.8 at the

I'd need to go look into the current state of gettext() and friends in Perl
— which was fairly immature but workable last I looked into this — and how
well they mesh with our needs before I could estimate it's impact.

>And what should those among us who want less inline code in `check` do to
>help moving it?

Well, pestering me about it is one way. :-)

You've reminded me that authenticate(), for one, can just as well be nuked
right away. Likely several of the others can as well, with no impact on any
l10n framework we may or may not get to in the near future.

It'll be a bit crufty, but not excessively so.

I'll think a bit about how you can more directly contribute to nuking the
remainder of it.

- -- 
>For all I know they probably have a standard for
>which direction to put the thread on a bolt.

That would be ISO 261:1973.         -- John Cowan

Version: PGP SDK 3.0.3

Received on Monday, 6 September 2004 11:27:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:54:46 UTC