Re: Pedagogic validation

2009-09-10 15:49, Smylers skrev:
> You mention both 'polyglot' and 'pedagogic' in that post, suggesting
> they may be equivalent.

Strange impression I must have given, since my intention was the 
opposite. I discussed at length a few problems true polyglot documents 
have for newbies... OK, I guess one can never be clear enough.

> I think it's entirely reasonable for somebody to declare a labelled
> group of restrictions on HTML 5 style as being useful for teaching
> purposes.  It's also reasonable for somebody else to declare a
> _different_ set of restrictions also being useful for teaching purposes
> (and to label them differently).

For exactly this reason we who do teach this stuff need to discuss 
options and see where the might be a reasonable amount of agreement and 
what is the best way of solving our differences.

Simon Pieters idea about a report, rather than a profile is interesting. 
That, and a Greasemonkey script would be a very fascinating solution! 
(The latter to provide "green light".)

> But I'm not sure it's a good idea to have one particular subjective
> style choice endorsed as being "the pedagogic style" by W3C (or
> apparently endorsed, by being labelled as such as an option on a W3C
> validator).

Without having discussed this with my colleagues in OWEA, I think it 
might be a particular good fit for us to work on. We are expecting to 
get quite a good reach into the teaching community.

OWEA is still taking shape, though, so I can not promise anything.

http://www.w3.org/2005/Incubator/owea/

>> Is is quite long, so I will not paste all of its contents into this
>> mail.
>
> It's just as easy to read long e-mails as long webpages!  And when
> replying having the text already in an e-mail makes it easier to quote:

Pro's and con's to all choices indeed. If there ever will be a next time 
I'll provide the text in my email.

>    ... everyday problems I encounter as a teacher of markup languages, in
>    addition to what a normal validation would reveal:
>
>      * Students forgetting to quote attribute values, even though they
>        contain multiple words.<img alt=My dog>
>
> 'Normal validation' would catch the above, since dog isn't a valid
> attribute of<img>.

Yes, sloppy example. The principle still holds though:

1. The error message would be more informative.
2. It would catch mistakes like alt=My title

>      * Students messing up the balance of the quotation marks:
>      <img src="foo.jpg alt=My dog">
>
> 'Normal validation' also catches the above, complaining about the space
> in the path.

Ahh. The HTML5 validator actually is improved in this regard, Thank you 
Henri! The old validator would only complain about the missing alt 
attribute for the code above. (A feature I would like to see in a 
pedagogic validation profile, if it gets dropped from as a normal 
conformance criteria.)

BUT: The principle still applies since the code to check could have been:

<input name="foo" title="foo type=text" />

Which is valid today, now that type="text" is optional.

>      * Students messing up the DOM since they do not (yet) know all the
>        rules for when an element is implicitly closed by another elements
>        starting tag.
>
> With some students (particularly those not from technical backgrounds) I
> find the opposite: they can understand why you need to indicate where,
> say, a link both begins and ends, but also see, say,<li>  as meaning
> 'start the next bullet point in the list' -- and it's implicit in
> starting that one that you're no longer in the previous one.
>
> So it isn't a case of learning that</li>  'closes' a list item (whatever
> that means) and then that</li>  can be an implicit tag; it's simply that
> to do what they want to achieve</li>  doesn't crop up at all.
> Mentioning it can even provoke comments of the form "Stupid computer
> -- why can't it work out that if I've gone on to the next bullet point
> then I've finished with the previous one?!".  Not having to explain tags
> which don't do anything (and not having to type them -- those new to
> creating webpages are often slow typers) is a pedagogical advantage with
> such students.

The problem is not a list of li, tr, td or p. It is when some other 
element will close the previous one. <p> followed by <table> (MSIE 6 got 
that wrong as in Acid2...) would be the most common one, I suppose.

>    All elements should be explicit
>
>    This would mean that:
>
>      * Root-element (html), head and body tags should not be optional
>        (grade 5).
>
> With beginners I find that to be unnecessary boilerplate, which only
> frustrates them because it gets in the way of the 'fun' part, by being
> more typing (for which there isn't apparently any purpose, other than
> computers being tedious) and a potential source of errors (typing it
> incorrectly actually makes documents wrong).

I find that it is very much easier for my students to comprehend the 
document structure when it is explicit. It also makes discussions about 
putting scripts in head OR in body easier, now that that subject has 
been revitalized.

And html + head + body is only 39 characters to type.

Besides, you need <html> for lang!

>      * Void elements must have a trailing slash. (grade 3)
>
> Beginners without an XML background don't consider<bam/>  to be
> equivalent to<bam></bam>  anyway, so even those with a penchant for
> 'matching' all their tags aren't helped by this.  Whereas those who are
> happy to accept that 'the<img>  command' puts an image in the document
> at that point just find the slash one more thing they have to remember.
> And if their documents work without it, teaching them to include it is
> just wasting time (especially if one of them spots that it isn't needed
> and asks what it's for).

Once again, my experience is that this is not a problem. Three sentences 
is all it takes: "In XHTML this is required, since we must explicitly 
close all elements. In HTML it does not actually do anything. But to us 
it serves as a reminder that this element is void and self closes." My 
students are not bright, but this they get!

>    All non-shortened attributes must have their values quoted. (grade 5)
>
>    As I've said above, this is a very common error. In the worst case
>    scenario it might lead to very unexpected results.
>
> Beginners seem to be particularly bad at typing quote marks, possibly
> because how to do so varies so much between countries (and between
> PC/Apple).  Generally I find the more quote marks they try to type the
> greater the chance they'll mess up (and it slows down their typing a
> lot), so it's safer if they just need them where needed.
>
> Since most attributes don't need them -- especially in HTML5, where the
> rules have been considerably simplified -- it's relatively easy the
> first time somebody wants to have a multiword attribute to say it needs
> to be quoted.

Once again my experience - and the experience of every other colleague 
but you - that I've discussed this with, is the opposite. The habit of 
quoting everything is not a problem, and it reduces errors.

If they would start writing some true XML file later on the power of 
good habits is even more rewarding. (I teach a course on XML as well.)

>  Indeed anybody with a Unix shell background is already
> very familiar with the idea that quotes are needed when spaces or
> certain punctuation characters are involved.

That is NOT a description of the average student!

>    Look at this example, where the value attribute is supposed to contain
>    the words "Login name":
>
>    <input type=text value=Login name name=login>
>
> That's something the sudent will spot straight away when the look at the
> page and see the wrong text in the button.  A validator isn't going to
> make that more obvious.

I very much appreciate you going through my examples. I see that I chose 
them somewhat in a haste. My mind was on the actual explaining this 
stuff side of things.

This code is a better example:

<input type=text title=Login name name=login>

Students will not always catch the title, since they quite early on 
learn to use the tab key (at least in my classes!)

> Also, the above already fails validation because of the duplicate name
> attribute.  (With different text it would fail with an unknown
> attribute.)

Not in the W3C version of the validator, but I suppose that it's not on 
the most recent code.

>> The idea is to have options in the validator that can be of use in  a
>> teaching situation.
>
> I think that's a great idea.
>
> And where I point out specific places in which I'd want different rules
> from yours when teaching HTML, I'm not trying to persuade you that mine
> are in any way 'better' or that you should change your mind on this
> matter.

It has been my major occupation for 8 years to teach this stuff. 
Sometimes my mind does change, though, so please keep trying!

> Merely that it's entirely possible to reasonably have different ideas on
> subjective things like this, so no one ruleset should be able to claim
> rights to being the best for pedagogical reasons.

As I said above, I will ponder Simon P's idea about a report that I can 
put a script on top of. That might be a solution to both our desires.

It might even make it possible to include a lower case criteria for tags 
and attributes, which is easier on MY eyes when I have to wade through 
250 pages at the end of each spring...


-- 
Lars Gunther
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

Received on Friday, 11 September 2009 15:07:39 UTC