[efh] website

[Drake Wilson]

Quoth Sebastian Bisbal <sebabisbal at gmail.com>, on 2007-05-10 20:23:40 -0500:
> www.actlab.utexas.edu/~sebabisbal

Content-wise, it looks very good:

  - The organization and visual design are quite reasonable, and not
    overly cluttered.  The stylistic differences between the regions
    of the site give a nice background visual cue about the current
    location, which works well.  The URLs are also sane, which is
    good.

  - This is actually a very good example of graceful degradation,
    especially WRT Adobe Flash; if I view the site without Flash, I
    can still see the rest of the site just fine, even though I can't
    see the fancy animation.  If I view the site with no graphics at
    all, I can still read the text just fine, even though things that
    actually _require_ images or video (such as the persistence of
    vision experiment) obviously won't work well.

  - It may be a little bit confusing for those who can't see the
    animations but who click on the "animation 1" and "animation 2"
    links anyway; I'd suggest adding some text before the animation
    itself to indicate that it's supposed to be there, rather than it
    just looking like a broken link that goes back to the home page.

  - I'm not a big fan of embedding video with audio directly (as
    opposed to offering it for download), but that's a debatable
    issue, and I think the course requires it in this case, so.  :-)

Technically, you have some issues---or, more likely, whatever
authoring tool you're using has some issues:

  - You have an XHTML 1.0 Transitional document type which is being
    sent as text/html (rather than application/xhtml+xml) by the Web
    server, which is kind of okay.  Then you have a meta tag declaring
    the type to be text/html, which is a little odder.  The
    theoretical proper MIME type for XHTML is application/xhtml+xml.

    Clobbering the meta tag may be advantageous for cleanliness; then
    again, it might not, because it also declares the character set,
    and the HTTP headers declare no character set.  Changing the meta
    tag to declare the type as application/xhtml+xml forms an
    inconsistency between the meta tag and the HTTP header, and I
    don't know how well browsers like IE will handle it.

  - Even XHTML 1.0 Transitional does not define a "height" attribute
    for the <table/> element.  Nor does it define the existence of
    the <embed/> element.  The latter may be a justifiable kludge in
    this case; the former I would probably strip out.

  - You're using <th/> tags for table cells, seemingly for the sole
    purpose of making them bold.  This is nonsense.  The table-based
    layout is probably a justifiable kludge in the absence of
    widespread support for XSL-FO and XSLT, but using <th/> (which is
    supposed to be for Table Header cells only---thus "th") is a bit
    much.  Use a style="font-weight: bold" attribute on the <table/>
    if you must, but those <th/> should at least be <td/>.

  - You're using an XHTML document type, but you're putting all your
    inline CSS inside an XML comment (<!-- ... -->).  This is
    nonsense.  A proper XML parser will drop the comment entirely,
    whereas you're expecting it to be parsed as stylesheet
    information.  I would recommend external CSS files instead, if
    you're actually trying to avoid the problem of older browsers
    displaying the stylesheets as text.

    <rant flamage="yes" length="long" detail="high" ignore="if-desired">

      While I realize not everyone can be expected to know these
      things, this is the kind of thing that makes good browsers
      nearly impossible to write.  What's the point of having
      well-defined rules for XML files if the sheer amount of garbage
      markup on the Web will force you to _not_ parse it as
      well-defined XML regardless?

      And then what happens when people actually want to write
      well-defined XML that will be parsed in a deterministic way, and
      _there is no way to do it_ because every crap Web authoring tool
      pollutes the format space so much?  The whole _point_ of
      _defining_ SGML and XML rules is to get _away_ from the tag-soup
      parsing the plagued the early Web, and now what?  All their hard
      work is a total waste:

        + Someone writes a tool that spits out markup that is expected
          to be parsed in a way that violates the rules.  They parse
          it as tag soup and hey, it looks okay.  Then they slap an
          XML document type on it, completely ignoring the actual
          validity of it.

        + If a _single_ sufficiently popular browser (case in point,
          usually Internet Explorer) displays these sites as the
          author intended---but _not_ as the author actually _wrote_
          in the markup, due to use of the aforementioned losing
          tool---then users will expect these sites to work properly,
          because they don't know any better.  And they shouldn't _have_
          to know better---this is the job of the technical people.

        + Now, any browser that actually follows the specification
          will be treated by users as broken, because it doesn't
          display their favorite sites, because a gazillion authors
          have used this garbage markup without knowing any better.
          This means that all browsers have to implement the kludge,
          thus violating the spec.

        + Now anyone who generates markup and expects it to be parsed
          according to the spec can no longer expect that, because
          they have to anticipate this stupid special case.

        + Now the markup space is polluted.  You basically cannot
          _ever_ get back deterministic parsing now, because you're
          locked into backwards compatibility all around.  The
          components of (a) one authoring tool that doesn't follow the
          spec and (b) any single sufficiently popular browser
          pandering to the whims of authors and users who are
          completely ignorant of the dynamics of the format space
          (which _will_ happen, because that is what will get them
          money and popularity) proceed to combine and morph into a
          giant robot, the Malformotron, which then defecates
          irreversibly all over the format space.

        + Eventually, people are forced to define a new format as a
          result of the pollution of the old one.  (Golly, isn't that
          what we already did?  Do we have to do it again now?)
          People start generating crap that claims to be the new
          format, and the cycle begins anew.

      This is one of the reasons that even though I'm opposed to
      restrictive copyrights and patents, I'm not nearly so opposed to
      restrictive trademarks...

    </rant>

    Fortunately this isn't a fatal problem in this particular case,
    because a browser that ignores the CSS-in-comment (as per XML
    specifications) will still render the text in a readable fashion,
    so your graceful degradation saves you here.

  (Most of this would actually be solved most simply by having no
   DOCTYPE declaration whatsoever, and leaving the MIME type as
   text/html.  Now, that's not ideal, because that means "tag soup,
   free-for-all", but at least it's tag soup that _knows_ it's tag
   soup.  Currently what you have is tag soup that pretends to be
   XHTML and falls on its face.)

  (The ideal way, of course, would be to fix all the markup to be
   nice and clean, but good luck getting both that _and_ browser
   compatibility; see rant above for why...)

> Sebastian

   ---> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://home.actlab.utexas.edu/pipermail/efh/attachments/20070510/e4d7f3a4/attachment.pgp