Go for it
I have occasionally displayed an interest in Go, the king of
deceptively-simple abstract grid-based board games. The problem,
of course, is that none of my family or friends plays, and Go
software is difficult to find—because it’s really difficult to
make.
A recent article I’ve been meaning to reference here suggests
that writing
Go programs may teach us how to make smarter software. The difficulty
of programming Go comes from the vast number of possible moves and
the difficulty in assessing whether a given position is superior or
inferior to another. Human players develop an intuition, but one could
describe intuition as a sophisticated pattern-matching process that
operates below the level of conscious thought. Pattern matching is one
of those areas where humans are very strong and computers are very
weak, so further research into Go may teach us ways to develop
computer intuition.
Of course, even the free, handicapped software I’ve played against
has been able to stomp me, so no complaints from me.
#
XHTML 2.0
Well, the first draft of XHTML 2.0 is out,
and the comments and speculation have begun. Of these, I’ll point to
Kevin Mark’s notes
and this article at XML.com because
I’ve read them.
My one thoughts: One of the points of XHTML 2.0 was to
abandon backward compatability in favor of improving the language; thus
lots of deprecated presentational elements are gone, as are elements like
img, embed, and applet whose functionality
are subsets of object. These are all positive steps, but I
wonder why the working group didn’t go farther. For example, they’ve
created new nestable section elements with associated
h (heading) elements (thus answering one of my old
complaints about HTML),
but they didn’t get rid of the old h1–h6 headings.
Why not? Since they’ve already decided not to be backward-compatible, why
bring forward old, less-capable ways of structuring documents? It’s not
as though the older versions of HTML
are going away, so there’s no need to make things easy for people to convert
documents to the new format—they can still use the old ones.
That being said, here are some other thoughts:
- Paragraphs can include lists, tables, block quotes, and other block-level
elements. This makes life a lot easier for people marking-up complex
documents, as it’s not uncommon to have block quotes in the middle of
paragraphs (the effect is more obvious with indented paragraphs).
q is gone, with quote replacing some of its
functionality. Unfortunately, quote does not have the effect of
adding quotation marks (although this could be done with style sheets).
I would like to see quote and block quote combined
into one element; the only difference between them logically is presentational.
With a sufficiently-sophisticated style sheet language, one can have quotations
appear in quotation marks or as block quotes depending on how many lines they
take up, as my English teachers recommended. (This is possible, as other markup
languages have done it; whether it’s practical is another matter.)line provides a structural way to do what most people
used br for, but br is still included. Why?hr is still included. Why?- We can probably dump
strong. If people want to
really emphasize something, they can nest ems.
- There’s no real difference between
acronym and abbr.
The distinction doesn’t even exist in other (non-English) languages,
and English speakers can’t all agree on what the distinction is supposed
to be. I say, dump acronym.
- We now have four types of list (ordered, unordered, definition, and
navigational). Are the differences between them enough to require four
different elements? I can easily imagine creating a generic
list
element which has a superset of their expressiveness, and allows authors
to choose the presentation with style sheets. (Actually, this would be difficult
for navigation lists as the draft describes their presentation.) Certainly,
the definition list has been abused by authors who want titled list items
that aren’t strictly definitions.
- The
style, script, and noscript
elements are still with us, but I think we can live without them, as we
can live without the events module. Style sheets and scripts should be
included by linking to the appropriate code, and the use of in-line
script elements really messes with the ability to
consider HTML documents
as declarative markup—especially if they include Javascript which writes
new code to the document. That means that the HTML
parser has to stop, run a Javascript script, back up and replace the
script element with the script’s output, and restart
the parsing. The DOM
provides clean methods for adding new elements and text to documents
and for assigning event handlers; thus, none of this needs to be in
HTML.
- There are good reasons to want to include style sheets and
scripts with the document, along with other useful data (eg,
RDF metadata).
I say, have a
data element which appears at the same level
as head and body. Documents can reference the
data by id:
<html namespace declarations>
<head>
<title>Hypothetical Example</title>
<link rel="stylesheet" type="text/css" href="#style"/>
<link rel="meta" href="#meta"/>
</head>
<data id="style" type="text/css">
body { font-family: "lucida grande" }
</data>
<data id="meta" type="application/rdf+xml">
<rdf:RDF>
<rdf:Description rdf:about="">
<dc:creator>Mr Apocryphal</dc:creator>
</rdf:Description>
</rdf:RDF>
</data>
<body>
document content
</body>
</html>
This could be used for lots of things, like providing arbitrary
XML data to scripts.
One could even imagine including images (encoded with Base64), although that’s
usually not a smart idea for other reasons. (Note that the contents of
data are parsed by the XML
parser, so <, >, and & would need to be escaped if they appeared, say,
in Javascript code.)
pre isn’t described as requiring xml:space="preserve",
despite the fact that it does in XHTML 1.1. Without it,
XML parsers will cheerfully
strip out all the whitespace which the pre is supposed to preserve.
In fact, pre itself may be unnecessary, as one can put
xml:space="preserve" into any element. In any case, I assume the
omission is an oversight.href can appear in most elements, allowing almost anything to
become a link. I’m still undecided about whether this is a smart idea or not
(certainly, it allows people to do stupid things, but so do most powerful
languages). Odd, though, that rel, rev, hreflang,
and other link-related attributes are not as widely applied.
Things are likely to change before the specification is finalized and
recommended. (What things specifically will change is more difficult to
predict.) None of my suggestions are likely to be considered, as the
working group does not read ZedneWeb, but hopefully I am not alone in
thinking these thoughts—particularly those I stole from others.
#