HTML syntax quiz of the day

[Jukka K. Korpela]

This is a quiz, not a real question (i.e., I know the answers, most
people don't).

a) Is the following valid in HTML 4.01 Strict:

<table border border=1><tr><td>foo</table>

b) Why?

c) Does it matter?

d) What on earth made me think about it?

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Swifty]

On Wed, 29 Feb 2012 10:21:22 +0200, "Jukka K. Korpela"
<jkor...@cs.tut.fi> wrote:

>This is a quiz

I can't wait to see the responses, but you're not going to tempt me
into the trap! :-)

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[Jonathan N. Little]

Jukka K. Korpela wrote:
> This is a quiz, not a real question (i.e., I know the answers, most
> people don't).
>
> a) Is the following valid in HTML 4.01 Strict:
>
> <table border border=1><tr><td>foo</table>

For the fragment, yes.

>
> b) Why?

Because it doesn't break any rules for HTML 4.01 Strict ;-)

Closing tags on TD & TR are optional and attribute values do not need to
be quoted if they do not contain embedded spaces.

>
> c) Does it matter?

Not really. However I would say it is bad practice because it can get
difficult to read with later revisions and would not be valid if
"upgraded" to HTML5--if that ever goes anywhere...

>
> d) What on earth made me think about it?
>

I think you are better qualified to answer that one!

Maybe all the flame wars over validation. Although even though the above
is valid, I would not code that way myself for the reasons I have just
hinted. I rather not solely focus on just validation but on making the
markup clear and clean is best by using the optional closing tags,
quotes and such. It is analogous to using coding style in programing
with indented structure and proper commenting ... it make maintenance
down the road much easier.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Jukka K. Korpela]

2012-02-29 16:11, Jonathan N. Little wrote:

>> <table border border=1><tr><td>foo</table>

- -

> Closing tags on TD & TR are optional and attribute values do not need to
> be quoted if they do not contain embedded spaces.

Yes, but what about setting the same attribute twice? If I try
<table summary=foo summary=bar>
I get 'duplicate specification of attribute "SUMMARY"' from a validator.
Is my example equally invalid?

>> d) What on earth made me think about it?
>
> I think you are better qualified to answer that one!
>
> Maybe all the flame wars over validation.

Not really, but they _could_ have been the reason.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Jonathan N. Little]

Jukka K. Korpela wrote:
> 2012-02-29 16:11, Jonathan N. Little wrote:
>
>>> <table border border=1><tr><td>foo</table>
> - -
>> Closing tags on TD & TR are optional and attribute values do not need to
>> be quoted if they do not contain embedded spaces.
>
> Yes, but what about setting the same attribute twice? If I try
> <table summary=foo summary=bar>
> I get 'duplicate specification of attribute "SUMMARY"' from a validator.
> Is my example equally invalid?

But in that example both attribute instance have a value, in your
original example the first instance has in value so assume NULL
concatenated with 1 = 1. I would also assume this would work too
<table border border border border=1>

Strangely enough the validator will not allow an additional attribute
beyond the the two and only if one had no value and one does. Do all
below causes a duplicate attribute error in the validator...

<table border border>

<table border=1 border=2>

<table border border=1 border=2>

>
>>> d) What on earth made me think about it?
>>
>> I think you are better qualified to answer that one!
>>
>> Maybe all the flame wars over validation.
>
> Not really, but they _could_ have been the reason.
>

Ri-i-i-i-i-i-ight.

[Andreas Prilop]

On Wed, 29 Feb 2012, Jonathan N. Little wrote:

>>>> <table border border=1>
>

> the validator will not allow an additional attribute

So you can conclude that there is only one attribute in the above
and that the first "border" is not an attribute.

--
In memoriam Alan J. Flavell
http://www.alanflavell.org.uk/charset/

[David Stone]

In article <it7sk75djp9367tis...@4ax.com>,

Swifty <steve....@gmail.com> wrote:

> On Wed, 29 Feb 2012 10:21:22 +0200, "Jukka K. Korpela"
> <jkor...@cs.tut.fi> wrote:
>
> >This is a quiz
>
> I can't wait to see the responses, but you're not going to tempt me
> into the trap! :-)

[Python] Run away, run away! [/Python]

[Jonathan N. Little]

Andreas Prilop wrote:
> On Wed, 29 Feb 2012, Jonathan N. Little wrote:
>
>>>>> <table border border=1>
>>
>> the validator will not allow an additional attribute
>
> So you can conclude that there is only one attribute in the above
> and that the first "border" is not an attribute.
>

Not sure how it is interpreted since single word "checked" and
"selected" are valid attributes for HTML 4.01 strict in a form controls
such as:

<input type="checkbox" name="foo" value="bar" checked>

and element's name must be a single word with no spaces, e.g., BODY, H1,
IMG, etc. So if it is not the element name, or the attribute, nor the
attribute-value, then what?

[Andreas Prilop]

On Wed, 29 Feb 2012, Jonathan N. Little wrote:

>>>>>> <table border border=1>
>>

>> So you can conclude that there is only one attribute in the above
>> and that the first "border" is not an attribute.
>

> So if it is not the element name,

i.e. "table"

> or the attribute,

i.e. "border=1"

> nor the attribute-value,

So it must be a value. Find the attribute!

[Jonathan N. Little]

Maybe I should have said element-name, attribute-name, & attribute-value.

[Thomas Mlynarczyk]

Andreas Prilop schrieb:
[border]

> So it must be a value. Find the attribute!

frame="border". But this is really weird. Syntactically it's the same as
<input ... checked>, but while "checked" is a boolean attribute with an
implied "truish" value [1], "border" here seems to be the value with an
"implied" attribute name "frame".

Greetings,
Thomas


[1] I still fail to see why <input ... checked> becomes <input ...
checked="checked" /> in XHTML rather than the more logical <input ...
checked="true" /> (or some similar representation of a boolean value).

--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[Jukka K. Korpela]

2012-03-01 16:49, Thomas Mlynarczyk wrote:

> Andreas Prilop schrieb:
> [border]
>> So it must be a value. Find the attribute!
>
> frame="border".

Yes.

> But this is really weird. Syntactically it's the same as
> <input ... checked>, but while "checked" is a boolean attribute with an
> implied "truish" value [1], "border" here seems to be the value with an
> "implied" attribute name "frame".

The concept of "boolean" attributes, though being made "official" in
HTML5, is more confusing than any strange things that it is supposed to
clarify.

> [1] I still fail to see why <input ... checked> becomes <input ...
> checked="checked" /> in XHTML rather than the more logical <input ...
> checked="true" /> (or some similar representation of a boolean value).

The reason is that once "boolean" attributes had been introduced to
HTML, the way to incorporate them into the SGML framework was to define
an attribute that had the name as _value_. So "checked" had to be a
value. The attribute name could have been, say, state or status. But
some people decided to use the name checked. And then it was too late to
change this.

The reason for the quiz is that I have been playing with the idea of
writing a sort-of DTD for a sort-of HTML5:
http://www.cs.tut.fi/~jkorpela/html5-dtd.html
I was wondering how to allow both
border="1"
and just
border
as per HTML5 drafts. And the only way seems to be to allow the frame
attribute, along with the border attribute.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Thomas 'PointedEars' Lahn]

Thomas Mlynarczyk wrote:

> Andreas Prilop schrieb:
> [border]
>> So it must be a value. Find the attribute!
>
> frame="border". But this is really weird. Syntactically it's the same as
> <input ... checked>, but while "checked" is a boolean attribute with an
> implied "truish" value [1], "border" here seems to be the value with an
> "implied" attribute name "frame".

Ex falso quodlibet.

> [1] I still fail to see why <input ... checked> becomes <input ...
> checked="checked" /> in XHTML rather than the more logical <input ...
> checked="true" /> (or some similar representation of a boolean value).

Because XHTML is an application of XML, and either omitting the attribute
specification or specifying the attribute name as attribute value is the
*simplest* way of satisfying the constraints of an XML attribute
specification using a DTD. There is no boolean type in XML.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

[Thomas Mlynarczyk]

Thomas 'PointedEars' Lahn schrieb:
> Ex falso quodlibet.

You mean that <... checked> does not "expand" to <... checked="something
truish"> but rather to <... status="checked">, so checked is the value,
not the name of the attribute and it's the attribute name which is
omitted rather than the (implied) value?

>> [1] I still fail to see why <input ... checked> becomes <input ...
>> checked="checked" /> in XHTML rather than the more logical <input ...
>> checked="true" /> (or some similar representation of a boolean value).
>
> Because XHTML is an application of XML, and either omitting the attribute
> specification or specifying the attribute name as attribute value is the
> *simplest* way of satisfying the constraints of an XML attribute
> specification using a DTD.

And why could checked="yes" or checked="true" or checked="1" not satisfy
those constraints? checked="checked" is just ridiculously redundant.

There is no boolean type in XML.

But clearly there can be attributes with boolean semantics. XML itself
doesn't need to care, but the application using it. And for XHTML, the
semantics here are clearly boolean: is this checked or not?

Greetings,
Thomas

[Thomas Mlynarczyk]

Jukka K. Korpela schrieb:

> The concept of "boolean" attributes, though being made "official" in
> HTML5, is more confusing than any strange things that it is supposed to
> clarify.

What is the problem there? Things like `name="value"` can be specified,
I see no syntactic difference between `checked="true"` and `width="42"`.
If the latter can be specified, why not the former?

> The reason is that once "boolean" attributes had been introduced to
> HTML, the way to incorporate them into the SGML framework was to define
> an attribute that had the name as _value_. So "checked" had to be a
> value. The attribute name could have been, say, state or status. But
> some people decided to use the name checked. And then it was too late to
> change this.

Thank you for correcting my misconception. I had always thought
`checked` was meant as `checked="yes"`, not as `status="checked"`. But I
still cannot quite follow as to why it *had* to be done by defining the
attribute to have the name as value. After all, neither SGML not the
HTML parser need to know or care that the attribute is boolean, it just
needs to find out that element X has attribute Y with value Z (and that
this is allowed) and leave it to the rendering engine to figure out the
consequences.

Greetings,
Thomas

[Jukka K. Korpela]

2012-03-02 14:05, Thomas Mlynarczyk wrote:

> Jukka K. Korpela schrieb:
>
>> The concept of "boolean" attributes, though being made "official" in
>> HTML5, is more confusing than any strange things that it is supposed
>> to clarify.
>
> What is the problem there?

Originally, "boolean" attributes were introduced but formally defined as
if HTML were an SGML application, so formally e.g. ISMAP was declared as
an attribute with "ISMAP" as its only allowed value, so that ISMAP is
short for ISMAP="MAP". I don't think there is anything intuitively
Boolean about this.

> Things like `name="value"` can be specified,
> I see no syntactic difference between `checked="true"` and `width="42"`.
> If the latter can be specified, why not the former?

Yes, why not? The CHECKED attribute could have been defined with two
possible values, TRUE and FALSE. But it wasn't.

It gets more weird. HTML5 introduces some attributes with TRUE and FALSE
as enumerated values, but they are _not_ boolean attributes in HTML5
terminology! Moreover, an attribute like spellcheck has _three_ values,
TRUE, FALSE, and the empty string, but the empty string means the same
as TRUE, whereas the absence of the attribute means something else, a
third truth value so to say? Confused? It doesn't end here.

> Thank you for correcting my misconception. I had always thought
> `checked` was meant as `checked="yes"`, not as `status="checked"`.

It means checked="checked", because the attribute name was so defined.

> But I
> still cannot quite follow as to why it *had* to be done by defining the
> attribute to have the name as value. After all, neither SGML not the
> HTML parser need to know or care that the attribute is boolean, it just
> needs to find out that element X has attribute Y with value Z (and that
> this is allowed) and leave it to the rendering engine to figure out the
> consequences.

Surely it could have been checked="true" and checked="false", but then
you would not have been able to use just a keyword as an attribute. Or,
rather, you could, if no other enumerated attribute had those values,
but TRUE would not have the understandability of CHECKED.

HTML was never actually implemented as an SGML application (contrary to
what trolls may say), but we have to suffer from some of the
consequences, and some features of HTML are SGML-based without much
difficulty. If browsers has actually implemented HTML as defined, we
could write <input checkbox> instead of <input type="checkbox"> (and a
true validator accepts <input checkbox>, because it follows the SGML book).

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Thomas Mlynarczyk]

Jukka K. Korpela schrieb:

> [...] HTML5 introduces some attributes with TRUE and FALSE

> as enumerated values, but they are _not_ boolean attributes in HTML5
> terminology! Moreover, an attribute like spellcheck has _three_ values,
> TRUE, FALSE, and the empty string, but the empty string means the same
> as TRUE, whereas the absence of the attribute means something else, a
> third truth value so to say? Confused? It doesn't end here.

Is there any rationale for this weirdness?

> It means checked="checked", because the attribute name was so defined.

Okay. I was just a bit confused about which of the two occurrences of
the character sequence `checked` corresponds to the one in <input ...
checked>. But I guess that is a bit pointless in this case. Not so,
however, with <table border> vs. <table frame="border">.

> Surely it could have been checked="true" and checked="false", but then
> you would not have been able to use just a keyword as an attribute. Or,
> rather, you could, if no other enumerated attribute had those values,
> but TRUE would not have the understandability of CHECKED.

Ah, so SGML does not allow to define `foo` as a shortcut notation for
`foo="bar"` but it allows `bar` to be specified as the "naked" value of
an "anonymous" attribute, so to speak?

[Jukka K. Korpela]

2012-03-02 16:25, Thomas Mlynarczyk wrote:> Jukka K. Korpela schrieb:
>
>> [...] HTML5 introduces some attributes with TRUE and FALSE as
>> enumerated values, but they are _not_ boolean attributes in HTML5
>> terminology! Moreover, an attribute like spellcheck has _three_
>> values, TRUE, FALSE, and the empty string, but the empty string means
>> the same as TRUE, whereas the absence of the attribute means something
>> else, a third truth value so to say? Confused? It doesn't end here.
>
> Is there any rationale for this weirdness?

Probably. Some of the "new" attributes, like contenteditable, have been
taken from existing browser practice and documentation, preserving
compatibility. This means copying their oddities, too. But the term
"boolean"... beats me

> Ah, so SGML does not allow to define `foo` as a shortcut notation for
> `foo="bar"` but it allows `bar` to be specified as the "naked" value of
> an "anonymous" attribute, so to speak?

Right.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Thomas 'PointedEars' Lahn]

Thomas Mlynarczyk wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Ex falso quodlibet.
>
> You mean that <... checked> does not "expand" to <... checked="something
> truish"> but rather to <... status="checked">, so checked is the value,
> not the name of the attribute and it's the attribute name which is
> omitted rather than the (implied) value?

No, that is what Andreas Prilop implied in
<news:Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de> and
<news:Pine.LNX.4.64.12...@zen.rrzn.uni-hannover.de>, and I
think he is mistaken. Based on that assumption, your argument based on his
argument can be conclusive in itself, but it can also be fallacious in
context ("ex falso quodlibet" is Latin for the fact that you can conclude
anything from a false premise).

I mean the exact opposite of his implication, that is: if anything, `border'
is the *name* of an attribute in both instances here, _not_ a value. So
there would be no point in looking for a suitable attribute name for a given
attribute value as it is the other way around. AFAIK, #IMPLIED in a DTD
means that the *value* of an attribute is implied, not the name [1].
Therefore, I think the current W3C Validator's behavior which results in
`<table border border=1>' (in context) as being Valid HTML 4.01 is at least
suboptimal.

I might be wrong about this, in which case I would appreciate *references*
to/*quotes* from the SGML standard from more SGML-savvy contributors to back
up their opinion, which so far are missing from this thread.

As for `checked', that is an attribute *name* of a boolean attribute (of
INPUT/`input' elements) [2], that is (AFAIK), an attribute that has the
property of only being able to be not specified or specified. In HTML 4.01,
a boolean attribute does not require a value to be specified; but if you
specify one, the value has to be the same as the attribute name for the
document to be Valid. AFAIK, this follows from HTML 4.01 being an
application of SGML [3].

>>> [1] I still fail to see why <input ... checked> becomes <input ...
>>> checked="checked" /> in XHTML rather than the more logical <input ...
>>> checked="true" /> (or some similar representation of a boolean value).
>>
>> Because XHTML is an application of XML, and either omitting the attribute
>> specification or specifying the attribute name as attribute value is the
>> *simplest* way of satisfying the constraints of an XML attribute
>> specification using a DTD.
>
> And why could checked="yes" or checked="true" or checked="1" not satisfy
> those constraints? checked="checked" is just ridiculously redundant.

See below.

> There is no boolean type in XML.

That is what *I* wrote.

> But clearly there can be attributes with boolean semantics. XML itself
> doesn't need to care, but the application using it. And for XHTML, the
> semantics here are clearly boolean: is this checked or not?

As there is no boolean *data type* in SGML or XML [4], additional
*semantics* in an XML application require additional support from a markup
parser (a showcase of this problem are the current HTML5 parsers, because
HTML5 as specified in the Working Draft is not driven by *formalized* syntax
rules). You can define a boolean data type in an XML application (that is,
a data type that has only members that are the equivalent of either "true"
or "false"), so that *syntax* constraints can be satisfied and validated
against, but that requires the declaration of that data type in an XML
Schema or at least an XML document using an XML Schema Definition where the
`xs:boolean' type is defined for the respective attribute. There is no such
requirement for XHTML, and XHTML 1.0 being defined as "a reformulation of
HTML 4 in XML 1.0" [5], it would have been not a good idea by the W3C if
they had placed such one on XHTML documents.


PointedEars
___________
[1] <http://www.w3.org/TR/1999/REC-html401-19991224/intro/sgmltut.html#didx-
IMPLIED_attribute_value>
[2] <http://www.w3.org/TR/1999/REC-
html401-19991224/interact/forms.html#adef-checked>
[3] <http://www.w3.org/TR/1999/REC-
html401-19991224/appendix/notes.html#sgml-boolean>
[4] <http://www.w3.org/TR/2008/REC-xml-20081126/>
[5] <http://www.w3.org/TR/2002/REC-xhtml1-20020801/>
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas Mlynarczyk]

Thomas 'PointedEars' Lahn schrieb:

[ <table border border=1> ]

> I mean the exact opposite of his implication, that is: if anything, `border'
> is the *name* of an attribute in both instances here, _not_ a value. So
> there would be no point in looking for a suitable attribute name for a given
> attribute value as it is the other way around. AFAIK, #IMPLIED in a DTD
> means that the *value* of an attribute is implied, not the name [1].
> Therefore, I think the current W3C Validator's behavior which results in
> `<table border border=1>' (in context) as being Valid HTML 4.01 is at least
> suboptimal.

Well, the HTML 4.01 spec suggests that the first occurrence of `border`
here is not the name, but the value -- in this case of the frame attribute:

> The value "border" in the start tag of the TABLE element should
> be interpreted as the value of the frame attribute. [1]

And

border %Pixels; #IMPLIED

refers only to the second occurrence, the first being a kind of shortcut
for `frame="border"`.

>> There is no boolean type in XML.
>
> That is what *I* wrote.

Yes, I know. I accidentally deleted the quote marker -- only noticed it
after it was posted.

Greetings,
Thomas

[1]
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-border-TABLE>

[Thomas 'PointedEars' Lahn]

Thomas Mlynarczyk wrote:

> Thomas 'PointedEars' Lahn schrieb:
> [ <table border border=1> ]
>> I mean the exact opposite of his implication, that is: if anything,
>> `border' is the *name* of an attribute in both instances here, _not_ a
>> value. So there would be no point in looking for a suitable attribute
>> name for a given attribute value as it is the other way around. AFAIK,
>> #IMPLIED in a DTD means that the *value* of an attribute is implied, not
>> the name [1]. Therefore, I think the current W3C Validator's behavior
>> which results in `<table border border=1>' (in context) as being Valid
>> HTML 4.01 is at least suboptimal.
>
> Well, the HTML 4.01 spec suggests that the first occurrence of `border`
> here is not the name, but the value -- in this case of the frame
> attribute:
>
> | The value "border" in the start tag of the TABLE element should
> | be interpreted as the value of the frame attribute. [1]

Thank you for the hint, that settles it for me. So, in fact, what we can
know for sure at this point is that this particular parsing behavior for
this particular HTML element is strongly recommended (SHOULD) by the *HTML
4.01 Specification*, and is *therefore* observed by the W3C Validator. It
is not necessarily a requirement by the SGML standard. That makes a lot
more sense to me than the far-fetched alternative suggested elsewhere in
this thread.

BTW, it is recommended to use another leading character (`|' is common) to
mark third-party quotes, so that they are not easily confused with
quotations from the thread. I have modified your text as quoted here
accordingly.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14