"Mark Lloyd" wrote
| BTW, I noticed you put quotation marks around "clock", but not around
"30".
|
That seems to be another poorly defined detail.
As far as I can tell, it's like CSS: Attributes don't
have to have quotes unless they contain spaces
or special characters. I guess I take the approach
of simplifying things for myself and trying not
to strain browsers, by using quotes for strings
and no quotes for numbers, as one usually
does in programming languages. That mitigates
ambiguity. Though I see a lot of code that quotes
everything. And I guess the browser can't really
reduce ambiguity if it's accepting "30" and 30 for
either string or numeric values. But it seems sloppy
to me. It requires the browser to assess the context.
I think a lot of this dates back to the early days
when people agreed, reasonably I thought, that
HTML should be forgiving and should be rendered
as well as possible, rather than punishing people
for imperfection. A spirit of the law kind of approach.
And it still seems to work that way. The FONT tag
works dependably, for instance, even though it
was phased out years ago, and even if a page is
explicitly marked as HTML5. FONT was "deprecated"
even in HTML4.
I wonder if the quote-mania approach might be
connected with the JSON trend and the general fad
of precision. JSON requires quotes around its INI-style
names, which makes no sense. The values seem to
be like programming: numbers get no quotes while
strings do get quotes.
At this w3schools page...
https://www.w3schools.com/htmL/html_attributes.asp
....they explain that quotes are never required, yet they
recommend always using quotes and say they always use
double quotes. But the source code on that very page
alternates between ' and "! (I didn't see any numeric
values in their code, so I don't know what they do with
those.)
I've noticed that Microsoft seems to always quote
both strings and numbers in HTML. On the other hand,
they'd use 6 lines of XML and a GUID on a price sticker
for a piece of fruit.... They're far more interested in
officiality than clarity.... Then they'd offer
certification in fruit price stickering. And we'd be here
debating things like whether "navel orange" has to
be specified as being printed in UTF-8 in the 3rd
line of XML on our price stickers.
