W3C home > Mailing lists > Public > public-html@w3.org > May 2012

Re: Issue 31c: Meta generator

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Fri, 18 May 2012 21:56:14 +0200
Message-ID: <4FB6A95E.40806@disruptive-innovations.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
CC: public-html@w3.org
Le 18/05/12 21:33, Leif Halvard Silli a écrit :

> Daniel Glazman, Fri, 18 May 2012 20:58:56 +0200:
>> Le 18/05/12 20:43, John Foliot a écrit :
>
>> Not worth a "public warning", and too great power given to chairs w/o
>> control, IMHO.
>
> As a more helpful thing talk about: What are your insights, as a
> WYSIWYG HTML generator vendor,  with regard to the meta generator
> exception?
>
> Because BlueGriffon inserts a meta generator, and it only gives the
> author two options: Empty or non-empty @alt. But if BlueGriffon works
> with some HTML were the @alt already is lacking, then it does nothing
> about it AFAICT. Which in turn means that the page will still get a
> ‘valid’ stamp from the validator.

I have always found, and I said and wrote it multiple times, that the
rules for handling emptyness of @alt in html5 are totally crazy from
a user's point of view. In particular, the rule to keep an empty alt for
icons (section 4.8.1.1.4) seems to such an exception that most people
will fail observing that rule. Please note a validator will never
be able to validate that correctly since it's based on the notion
of "icon". What's an icon and how can a markup validator check that?

To focus back on the meta generator exception, I just do not understand
it. The meta generator was never meant to give useful information. It
has always been almost only a way for editing tool authors to insert an
advertisement for their tool in the documents created by users.
In that sense, basing any kind of rule on the presence of such a meta
tag seems to me a pretty serious conceptual error.

Is that an answer to the question asked?

</Daniel>
Received on Friday, 18 May 2012 19:56:40 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:52 UTC