WYSIWYG... NOT!

Once upon a time, in the early days of the Commercial Internet - in mid-1999, to be precise - I tried using a couple of WYSIWYG HTML editors and became totally disenchanted with them when each editor totally mucked up practically any coding done outside of the WYSIWYG interface.

Today, I tried using KompoZer to add styles to a short, hand-written XHTML 1.0 strict standard page. It promptly broke my page; wouldn't render at all in Firefox 21.0 on Linux. It took an hour or so of repeatedly overlooking the bug to discover that KompoZer had changed this...

<script src="js/sked.js" type="text/javascript"></script>

to this...

<script type="text/javascript" src="js/sked.js" />

in addition to hosing my human-readable indenting and such.

I had actually looked into the script tag a bit when writing the XHTML page, and the use of start and end tags seemed to actually be correct in this instance. The twelve-year-old “HTML & XHTML The Definitive Guide, 4^th Edition” states on p. 434, “End tag: </script>; never omitted”. So I went with that and didn't think more about it.

After this problem cropped up, I found that page 514 of the same book indicates that any XHTML element with no content like <p></p> may be written like <p />, so KompoZer's change, while not necessary, should be ok. However, I also found "guidelines" from the W3C "for authors who wish their XHTML documents to render on existing HTML user agents" that indicates not to do that for “an empty instance of an element whose content model is not EMPTY”. <script>'s content model isn't EMPTY. So for compatibility, should you use a single <script ... /> tag? Fugetaboutit!

For other things, WYSIWYG editors are fine. But if a web content editor is going to make any unnecessary changes at all to anything I've written, then it's not for me.

Anybody out there in cyberspaceland know if Dreamweaver does this sort of nonsense?

Getting VectorLinux To Recognize PCMCIA Cards

Having successfully used VectorLinux 6 Light on an antique HP Pavilion laptop of unknown provenance and needing a new OS for my circa 1999 Compaq Presario laptop, I naturally turned to VectorLinux 7 Light. Unfortunately, VL 7 Light didn't recognize either of my wired or wireless PCMCIA adapter cards; didn't even power them up. In trying a VectorLinux 6 Light Live distro on the same machine, however, both worked with no problems.

My intention was to read through the previous postings on networking at the VectorLinux forum and then to post a question on the subject there if a solution wasn't unearthed. No solution was found, and I was preparing to post a question when an idea came to mind: Compare VL 6 Light Live and VL 7 Light to determine what the heck was different!

I skimmed back through various forum posts I had considered relevant and noted what info was requested in response to the various questions. This included outputs from dmesg, ifconfig -a, lsmod, lspci, lspcmcia, pccardctl info, cat /etc/rc.d/rc.pcmcia, and modinfo xxxxxxx (where xxxxxxx is the name of the driver appropriate for a particular card one was trying to get working). I saved copies of each of the outputs from each distro and then proceeded to compare them.

The problem turned out to be one of ACPI enablement. As shown in the attached picture, VL 7 Light judged my laptop unworthy and thus disabled ACPI support. On the other hand, VL 6 Light Live was more accepting and Ethernet via a PCMCIA card, requiring ACPI, worked fine.

From there, solving the problem involved figuring out how to “require” acpi=force as indicated on the line highlighted in yellow in the right-hand window in the picture above. After a bit of research and testing, I found that PCMCIA cards were properly recognized after adding acpi=force to each of the 'append' statements in /etc/lilo.conf, then issuing the command '/sbin/lilo -v' to commit the changes to the LILO bootloader, and finally rebooting*. Yea!

If you're using GRUB instead of LILO, the following ought to do it (but I haven't tested it...): add acpi=force to the 'GRUB_CMDLINE_LINUX' statement(s) in /etc/default/grub, then issue the command 'update-grub' to commit the changes to the GRUB bootloader, and finally reboot*.

And the moral of this story? I'll leave that for you to decide. :)

* Of course, all of this needs to be done from root.