[tei-council] whither HTML of Guidelines and @lang

Martin Holmes mholmes at uvic.ca
Fri Nov 23 11:44:38 EST 2012


On 12-11-23 07:19 AM, Hugh Cayless wrote:
> I was under the impression that quirks mode was triggered by the doctype
> (or lack thereof). Use of the HTML5 doctype puts browsers into standards
> mode afaik. For what it's worth, I ditched XHTML for my own work years
> ago, and would advise against using it without some compelling reason.

The compelling reason for me is the ability to fix or change things 
across a whole website using XSLT.

You're right about the triggering of quirks mode for modern browsers, 
but I suppose what I meant was: when you create HTML which doesn't 
adhere to the standard, there's no guidance for the browser on how to 
render it, and therefore it has to make a decision about how best to 
proceed. Browser makers take different decisions in these situations, 
and additionally, the nature of the the browser's parsing algorithms can 
cause the same set of decisions to be triggered in different orders, so 
that even if they're thinking along the same lines, the results may be 
different. If your HTML is valid, at least you know what browsers are 
_supposed_ to do with it, and you can file a bug report if you find one 
that doesn't do the right thing.

Cheers,
Martin

>
> Best,
> Hugh
>
> On Nov 23, 2012 8:31 AM, "Martin Holmes" <mholmes at uvic.ca
> <mailto:mholmes at uvic.ca>> wrote:
>
>     Hi there,
>
>     On 12-11-23 03:15 AM, Gabriel Bodard wrote:
>
>      > Why do we need to validate the HTML output of the Guidelines? HTML5
>      > doesn't even need to be well-formed XML (although it can be, and
>     I like
>      > it to be). As Sebastian was arguing earlier in the TEI-L thread on
>      > @lang, the HTML is just a delivery medium, not something we need to
>      > process or expect anyone else to re-use, right?
>
>     I think this is a very dangerous point of view. If your XHTML doesn't
>     validate, then browsers go into quirks mode, where they behave
>     differently from each other. Anyone who remembers dealing with the
>     miseries of different behaviour from different browsers should never
>     want to go anywhere near it again. Validate, I say. Always.
>
>     We've got by without @(xml:)lang for years, so implementing it for the
>     Guidelines specifically is not a high priority. I think it should be a
>     long-term goal to move towards XHTML5 (for which the W3C seems to have a
>     good functioning validator, so it's possible), but we should move slowly
>     and carefully.
>
>      > If we produce HTML5 to the best of our ability, and don't get it all
>      > right first time, what breaks?
>
>     Personally, I use the Jenkins builds of the Glines in preference to the
>     official release, so if they're broken for extended periods of time it's
>     annoying. It's also hard to implement changes to the Glines in response
>     to tickets when you can't see good working builds.
>
>     Cheers,
>     Martin
>
>     --
>     Martin Holmes
>     mholmes at uvic.ca <mailto:mholmes at uvic.ca>
>     UVic Humanities Computing and Media Centre
>     --
>     tei-council mailing list
>     tei-council at lists.village.Virginia.EDU
>     <mailto:tei-council at lists.village.Virginia.EDU>
>     http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>     PLEASE NOTE: postings to this list are publicly archived
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


More information about the tei-council mailing list