input element: checked attribute

[Neil Zanella]

Hello,

I would like to know why the W3C decided not to make the following
valid XHTML:

<input checked type="radio" name="foo" value="bar" />FooBar

forcing people to write the following to make the document comply:

<input checked="checke d" type="radio" name="foo" value="bar" />FooBar

It seems kind or redundant to have the "checked" explicitly written down,
doesn't it?

Regards,

Neil

[David Dorward]

Re: input element: checked attribute

Neil Zanella wrote:[color=blue]
> I would like to know why the W3C decided not to make the following
> valid XHTML:
>
> <input checked type="radio" name="foo" value="bar" />FooBar[/color]

Becuase XHTML is an XML application and XML does not allow it.

The only differences between HTML 4.01 and XHTML 1.0 are those enforced by
the move to XML.

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):

http://minutillo.com/steve/weblog/2003/5/30/microsoft-announces-ie-is-dead

[Matthias Gutfeldt]

Re: input element: checked attribute

Neil Zanella wrote:[color=blue]
> Hello,
>
> I would like to know why the W3C decided not to make the following
> valid XHTML:
>
> <input checked type="radio" name="foo" value="bar" />FooBar
>
> forcing people to write the following to make the document comply:
>
> <input checked="checke d" type="radio" name="foo" value="bar" />FooBar
>
> It seems kind or redundant to have the "checked" explicitly written down,
> doesn't it?[/color]

Yeah, it does seem redundant. But according to the W3C that's how it has
to be: "XML does not support attribute minimization. Attribute-value
pairs must be written in full. Attribute names such as compact and
checked cannot occur in elements without their value being specified."
<http://www.w3.org/TR/xhtml1/#h-4.5>

IMHO they should have changed the name of the attributes to something
that makes a bit more sense, e.g. <input type="text" status="checked " >
or <dl display="compac t">, something along those lines. But I suppose
they had valid reasons not to do that; you could probably check the
appropriate W3C mailing lists for the details if you're interested.


Matthias

[Jukka K. Korpela]

Re: input element: checked attribute

Matthias Gutfeldt <worte@gmx.at > wrote:
[color=blue]
> Yeah, it does seem redundant. But according to the W3C that's how
> it has to be: "XML does not support attribute minimization.[/color]

That's why XML has X, for eXtended (or was it eXtensible? who cares),
to hide the simple fact that it is a banal simplification of SGML. :-)
[color=blue]
> Attribute-value pairs must be written in full. Attribute names such
> as compact and checked cannot occur in elements without their value
> being specified." <http://www.w3.org/TR/xhtml1/#h-4.5>[/color]

It has often been pointed out that this is a misrepresentati on of
facts. By SGML rules, an attribute specification like CHECKED (in SGML,
we are allowed to use upper case whenever we like) is a shorthand
notation based on using the _value_ of an attribute alone. So it's
really the attribute name (and the delimiter, "=" in the reference
concrete syntax) that can be omitted, in certain situations.

I wonder which possibility is worse: people who wrote the XHTML
specification didn't know this, or they decided to lie about it. Let's
be reasonable and assume that it was a typo. Or a cow flew by.
[color=blue]
> IMHO they should have changed the name of the attributes to
> something that makes a bit more sense, e.g. <input type="text"
> status="checked " > or <dl display="compac t">,[/color]

I've asked myself that question recently, though as relating to the
_original_ decision to use attribute names like "checked" or "compact".
I can't see any other reason than thinking in terms of "Boolean
attributes", which is a non-SGML concept of course - but natural if you
are _really_ just defining a simplistic and presentation-oriented
markup system. (In HTML history, "checked" is a novelty, whereas
"compact", a presentational attribute if you ever saw one, is an old
one, and oddly left unimplemented, in most browsers.)
[color=blue]
> But I suppose they had valid reasons not to do that;[/color]

Hardly anything else than compliance with old browsers.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Neil Zanella]

Re: input element: checked attribute

David Dorward <dorward@yahoo. com> wrote in message news:<bdp291$ji 7$1$830fa795@ne ws.demon.co.uk> ...[color=blue]
> Neil Zanella wrote:[color=green]
> > I would like to know why the W3C decided not to make the following
> > valid XHTML:
> >
> > <input checked type="radio" name="foo" value="bar" />FooBar[/color]
>
> Becuase XHTML is an XML application and XML does not allow it.[/color]

You mean to tell me that XML requires all element attributes to have explicit
values in any XML application? Is this a deficiency in XML or in the power of
DTDs themselves? BOTH XHTML and HTML have the same line:

checked (checked) #IMPLIED -- for radio buttons and check boxes --

in the input element's attribute list:

$ vim +/checked http://www.w3.org/TR/html401/strict.dtd
$ vim +/checked http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

Regards,

Neil

[Neil Zanella]

Re: input element: checked attribute

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message news:<Xns93AA96 AC06EF8jkorpela cstutfi@193.229 .0.31>...[color=blue]
> Matthias Gutfeldt <worte@gmx.at > wrote:
>[color=green]
> > Yeah, it does seem redundant. But according to the W3C that's how
> > it has to be: "XML does not support attribute minimization.[/color]
>
> That's why XML has X, for eXtended (or was it eXtensible? who cares),
> to hide the simple fact that it is a banal simplification of SGML. :-)
>[color=green]
> > Attribute-value pairs must be written in full. Attribute names such
> > as compact and checked cannot occur in elements without their value
> > being specified." <http://www.w3.org/TR/xhtml1/#h-4.5>[/color]
>
> It has often been pointed out that this is a misrepresentati on of
> facts. By SGML rules, an attribute specification like CHECKED (in SGML,
> we are allowed to use upper case whenever we like) is a shorthand
> notation based on using the _value_ of an attribute alone. So it's
> really the attribute name (and the delimiter, "=" in the reference
> concrete syntax) that can be omitted, in certain situations.
>
> I wonder which possibility is worse: people who wrote the XHTML
> specification didn't know this, or they decided to lie about it. Let's
> be reasonable and assume that it was a typo. Or a cow flew by.
>[color=green]
> > IMHO they should have changed the name of the attributes to
> > something that makes a bit more sense, e.g. <input type="text"
> > status="checked " > or <dl display="compac t">,[/color]
>
> I've asked myself that question recently, though as relating to the
> _original_ decision to use attribute names like "checked" or "compact".
> I can't see any other reason than thinking in terms of "Boolean
> attributes", which is a non-SGML concept of course - but natural if you
> are _really_ just defining a simplistic and presentation-oriented
> markup system.[/color]

If they were boolean attributes then they would have two values, but
they
are single-valued attributes. Their presence is associated with one
value
and their absense with the other boolean value if you really want to
think
of it that way. But absense of values makes me think of relational
databases
where some entries can be NULL. In this case it's like having
something which
can be either true or null, but not false. Basically what we are
seeing is
nonstandard representation of facts. A duality between something that
is
either true or false and something that is either present or absent.
In either case we have two things, but it's late, and I'm just going
on about nothing I suppose.

Anyhow, the options in the spec would better have been checked="yes"
and checked="false" or something like that, with checked being
#IMPLIED and
"false" being the default, as follows:

<!ATTLIST input ...
checked (true|false) #IMPLIED "false"
.... >

instead of

<!ATTLIST input ...
checked (checked) #IMPLIED
.... >

But then again there's the problem that for checkboxes one always has
to be checked, so having a default of false is not good. Perhaps the
W3C group just did what was right after all (except for there is
nothing wrong with SGML style attribute minimization from what
I can see: it's just the W3C group really wanted to simplify
things for the parser to come up with a smaller grammar).

Regards,

Neil
[color=blue]
> (In HTML history, "checked" is a novelty, whereas
> "compact", a presentational attribute if you ever saw one, is an old
> one, and oddly left unimplemented, in most browsers.)
>[color=green]
> > But I suppose they had valid reasons not to do that;[/color]
>
> Hardly anything else than compliance with old browsers.[/color]

[Jukka K. Korpela]

Re: input element: checked attribute

nzanella@cs.mun .ca (Neil Zanella) wrote:
[color=blue]
> If they were boolean attributes then they would have two values,
> but they
> are single-valued attributes. Their presence is associated with one
> value
> and their absense with the other boolean value if you really want
> to think
> of it that way.[/color]

That's what the W3C specs mean by "Boolean attributes". BTW, please fix
your newsreader: it generates odd variation in line length and
apparently forces you to quote too much.

Their meaning for "Boolean" is 'present or absent'. They really call
them "Boolean".
[color=blue]
> Anyhow, the options in the spec would better have been
> checked="yes" and checked="false"[/color]

Well, they were not that _consistent_ in making them Boolean.
[color=blue]
> <!ATTLIST input ...
> checked (true|false) #IMPLIED "false"
> ... >[/color]

Cui bono? Then checked="true" would fail on browsers that never heard
of this novelty.
[color=blue]
> But then again there's the problem that for checkboxes one always
> has to be checked,[/color]

No there isn't. You're confusing them with radio buttons, and you're
confusing semantics with syntax,
[color=blue]
> it's just the W3C group really wanted to simplify
> things for the parser to come up with a smaller grammar).[/color]

No, they actually played under the constraints of making the world safe
for XML and of not breaking old code or old browsers.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Jukka K. Korpela]

Re: input element: checked attribute

Terje Bless <link+news@pobo x.com> wrote:
[color=blue]
> - - the whole SHORTTAG issue stems
> from wanting to make HTML (SGML) less verbose and saving some
> typing[0].[/color]

Surely. But my question was why the attribute names were selected the
way they were.

The apparent history is that early browsers supported keyword-only
attributes like CHECKED or CENTER. There was hardly much thinking in
SGML terms then, though HTML had partly been inspired by some simple
SGML based markup systems (and a rather random choice of simple tags
was chosen from them). Later, retrofitting HTML into SGML in theory,
something had to be done. CENTER was made into a value of ALIGN, with
an enumeration of values, so that <h1 center> is shorthand for
<h1 align=center>. These days few people realize this, and even fewer
remember the browsers where it actually worked.

But the obvious choice had been something like making CHECKED the value
of an attribute like STATUS with an enumeration of values like
UNCHECKED, CHECKED or maybe just CHECKED. This would fit into the idea
of using CHECKED alone. But maybe they though that authors would fail
to understand the principle that the attribute _name_ can be omitted in
certain cases. Or maybe they (the people who did the retrofitting)
failed to understand or remember the principle.

As regards to why SHORTTAG features were officially removed in XML and
XHTML, the obvious answer is that the real complexity of this SGML
feature was understood up to the point that they shouted "oh no!",
without thinking further to consider why the designers of SGML had
still included it. I don't think the decision will be taken back, no
matter what you could explain. But it's quite possible that SGML will
be reinvented some day, in a simplified but not brutally simplified
form.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Terje Bless]

Re: input element: checked attribute

In article <Xns93C060C33C4 11jkorpelacstut fi@193.229.0.31 >,
Jukka K. Korpela <jkorpela@cs.tu t.fi> wrote:
[color=blue]
>Terje Bless <link+news@pobo x.com> wrote:
>[color=green]
>> - - the whole SHORTTAG issue stems
>> from wanting to make HTML (SGML) less verbose and saving some
>> typing[0].[/color]
>
>Surely. But my question was why the attribute names were selected the
>way they were.[/color]

Ah, sorry. Through my tinted glasses I misread your message.

[color=blue]
>But the obvious choice had been something like making CHECKED the value
>of an attribute like STATUS with an enumeration of values like
>UNCHECKED, CHECKED or maybe just CHECKED. This would fit into the idea
>of using CHECKED alone. But maybe they though that authors would fail
>to understand the principle that the attribute _name_ can be omitted in
>certain cases. Or maybe they (the people who did the retrofitting)
>failed to understand or remember the principle.[/color]

IIRC this ("checked") was the specific example used in the messages I
referred to, so it is likely that this was a result of SGML awareness
having snuck in, but only partially (which explains "align").

[color=blue]
>As regards to why SHORTTAG features were officially removed in XML and
>XHTML, the obvious answer is that the real complexity of this SGML
>feature was understood up to the point that they shouted "oh no!",
>without thinking further to consider why the designers of SGML had
>still included it.[/color]

Well, as mentioned, the timing of this as compared with the publication
of "Annex K"[0] makes me think that they simply failed to take into
account, or chose to ignore, the finer granularity offered by K.3.5
("Markup minimization features") of WebSGML when that particular
decision was made. Either that or the bulk of those involved failed to
notice the SGML Declaration for XML through all those furiously waving
hands.

[color=blue]
>I don't think the decision will be taken back, no matter what you
>could explain.[/color]

I would settle for a reasoned "WONTFIX", but I'm still hoping it may be
treated as an erratum. It would certainly make _my_ life much easier
and would break very very few actual implementations (w3m is the only
candidate I can think of that may actually implement these features).

[color=blue]
>But it's quite possible that SGML will be reinvented some day, in a
>simplified but not brutally simplified form.[/color]

YM "XML 2.0", no? As best I can tell the XML world is busily
reinventing SGML ass end first. By XML 3.0 they'll have achieved
feature parity and removed most of the most egrarious misfeatures. By
XML 4.0 we may begin to see something genuinely new...

[ Not really, but it sure feels that way some times. :-( ]






[0] - ISO/IEC JTC1/SC34 N0029; ISO 8879 TC2
<http://www.y12.doe.gov/sgml/sc34/document/0029.htm>

--
T.E.R.J.E. - Technician Engineered for Repair and Justified Exploration
B.L.E.S.S. - Biomechanical Lifeform Engineered for Scientific Sabotage