- From: Jim Jewett <jimjjewett@gmail.com>
- Date: Sun, 22 Feb 2009 21:21:17 -0500
- To: HTML WG Public List <public-html@w3.org>
On Jan 28, 2009, Maciej Stachowiak wrote:
> On Jan 27, 2009, at 9:05 PM, Michael(tm) Smith wrote:
>> A "tool" could be something as simple as a plug-in for Vim or
>> Emacs that enables context-sensitive editing of HTML documents,
> This is the kind of tool that would need to know how to parse an
> HTML document.
Maybe, maybe not.
A full-blown parser will correct
<b><i>text</b></i>
for me, but I would prefer to at least be warned about the error.
In particular, if I am viewing source as part of a debugging process,
I do *not* want ithat automatically cleaned up, because whatever
caused that mis-nesting is at least suspicious for also causing
whatever problem I haven't yet tracked down.
> Personally, I think there are constituencies that find "that ugly tag
> soup stuff" and "that evil scripting stuff" aesthetically and
> ideologically distasteful, and therefore wish to have some sort of
> standards document purged of such unclean influences, no matter how
> nonsensical and useless the resulting document may be.
I have a fair idea of what a simple .png should look like.
I do not have the same understanding of other graphics formats,
despite (at least for some of them) having read the standards. Why?
Because the standards were so much longer, and it wasn't clear where
to start. To implement the whole standard, sure, just plunge in and
come up next year. But to understand it? Or to explain what a
"simple" example should look like? I couldn't easily do it.
Static documents may not be the most interesting parts of the web, but
they are a good and useful subset.
-jJ
Received on Monday, 23 February 2009 02:21:57 UTC