- From: Mike Schinkel <w3c-lists@mikeschinkel.com>
- Date: Sat, 28 Apr 2007 01:25:31 -0400
- To: public-html@w3.org
Dannii wrote:
> If there was some context where specific indents were required for
> correct semantic meaning, couldn't the <pre> tag be used for that?
But <pre> is preformatted; it's not applicable at all, unless I
misunderstand.
> If there is no semantic meaning, CSS should definitely be used. I
> cannot see how <indent> would be useful.
Why should it "definitely be used?" There is a given ideology that
argues that CSS should be used, but I am questioning that ideology. I
think there is benefit to having non-semantic markup when the existing
semantic markup does not address the needs. Sure, add additional
semantic elements, I'm all for that, but include a catch-all for those
things that have yet to be addressed.
I also think knowing CSS should not be required for marking up a
document in a manner that is possible using word processor, or that was
possible when using a typewriter in the pre-computer era. Why? Because
the average non-technical user will learn HTML because it empowers them
to publish, but the average non-technical user won't go to the extra
effort to learn the abstractions of CSS, nor will the average user type
<div style="margin-left:1em;"> when <blockquote> will suffice.
Alexander Graf wrote:
> There are currently more than enough possibilities to indent elements
> via CSS and
> I honestly don't see the need to add properties or elements to HTML
> which do
> the same.
There are a large number of people who know HTML but don't know CSS.
Similarly, there will be a large segment of the people that will learn
HTML but will never learn CSS.
>
> As it is, web developers will have to learn (a little bit of) CSS
> anyway, to produce
> even just slightly good looking websites.
There are many people who need to publish content who are not web
developers.
> - give people a bit of semantical and a bit of presentational control
> in HTML
> and let them figure out the more advanced presentational styles in CSS,
> confusing them even more (what property takes precedence, etc...)
Indentation is not an "advanced" need.
> - or drop the support for presentational stuff altogether. People who
> use tables
> and don't care for the semantics in HTML (teachers who want to put
> timetables
> online, ... as Anne pointed out) can *still* use <blockquote> to
> indent text and
> those who care for a structured document will be able to use
> <blockquote> in
> its semantically correct meaning and style indented text with CSS.
Why leave the only options learning advanced content or publish using
incorrect semantics?
Benjamin Hawkes-Lewis wrote:
>
>> The meaning may well be: this is how my boss/teacher wants it to look.
> Purely presentational effects are what styling languages are for. CSS
> may not beautiful, but I don't think it's the job of this WG to fix that.
Learning CSS in order to be able to publish is far too high a bar for
the average non-technical person to be required to achieve (because most
simply won't.)
>
> If it's not a purely presentational effect, then we should be
> encouraging people to think about what they are writing - just as they
> do when composing print documents.
Is the goal of the HTMLWG to define rules and educate, or is it to
empower? I'd say the latter.
> As for bosses and teachers, they have (I believe) a moral duty, and in
> many countries a increasingly strong legal obligation, to think about
> how they can maximize accessibility as well as gratifying their own
> aesthetic whimsy. Not reducing employees or students to mindless
> automata might also be a good idea, but as far as HTML goes that's
> optional. ;)
Moral obligation is great, but the majority won't know matter how much
you would like it to be so.
>
> Web communication tools like HTML should require authors to be
> specific /enough/ to communicate effectively with their audience.
> Otherwise, such tools are not fit for purpose.
People use HTML every day to effectively /communicate./ You are instead
asking them to perfectly classify that which they communicate, and that
is simply unrealistic. If HTML were a clean slate, maybe, but even then
we would have to have enough vision to foresee all potential unforeseen
consequences (an oxymoron, for sure!)
And prohibition has been proven time and again not to work; we should
empower people to use semantic HTML whenever possible but also provide a
relief valve for when we did not foresee their needs.
> <indent> is hopelessly vague IMHO.
It was proposed as vague on purpose.
>
>> <strong> and <em> are aliases for <b> and <i>. Always have been.
>
> HTML is not defined by broken WYSIWYG tools: <strong> and <em> have
> never been aliases of <b> and <i>, though obviously within Western
> languages they are intricately related.
We can argue pedantically all day long about them not being aliases, but
in practice they almost always are used in that manner.
>
> I also recognize there is a desire for a crude presentational subset
> of HTML defined for use by systems like Blogger. But note that while
> Blogger thinks <i> and <b> are indispensable, the developers didn't
> feel any need to provide some form of indentation mechanism.
And your point is?
>
> In so far as I believe semantic markup significantly contributes to:
> 1) a just (equal access) society, 2) furthering human knowledge, and
> 3) liberating human beings from the tedium of repetitive formatting, I
> feel impelled to encourage its adoption. But I think the list is
> stronger for including people with differing ethical perspectives. :)
>
Those with ideologies are so often focused on the absolute application
of their ideologies that they don't realize they are doing more harm and
good in their lack of pragmatism. As I've been stating, I agree with
your goals but I think your rigidity regarding the methods by which
those goals will be reached will result in a worse situation as opposed
to a better one.
>
> Great, so we already handle callouts in the proposed WHATWG draft. :)
And the default presentation is?
>
> <figure><img src="sunflowers.jpg" alt="Sunflowers"><legend>Sunflowers
> are especially beautiful in Summer. By <cite>Joe
> Bloggs.</cite></legend></figure>
>
That's all well and good, but the reality is most people don't and won't
go to the trouble to markup content at that level as it is complex and
time consuming and most people are already far too pressed for time. One
thing HTML should strive is for it to be as easy as possible to mark
things up in addition to providing complex markup when the author is
willing to go to that level.
> My guess is you'd end up gibberish like:
>
> <indent left="3em" right="3em"
> style="font-size:70%;margin-top:1em;margin-bottom:1em;">Something that
> should have been a quotation, in text that is too tiny for you to
> read.</indent>
>
That argument is a straw-man. Most indentation needs that I was trying
to address are simple, and what you present is absolutely no different
than what we could have today:
<blockquote left="3em" right="3em"
style="font-size:70%;margin-top:1em;margin-bottom:1em;">Something that
should have been a quotation, in text that is too tiny for you to
read.</blockquote>
<div left="3em" right="3em"
style="font-size:70%;margin-top:1em;margin-bottom:1em;">Something that
should have been a quotation, in text that is too tiny for you to
read.</div>
<p left="3em" right="3em"
style="font-size:70%;margin-top:1em;margin-bottom:1em;">Something that
should have been a quotation, in text that is too tiny for you to read.</p>
Besides, all of these require inline CSS which is what I'm arguing
shouldn't be required for something as basic as an indent.
Murray Maloney wrote:
>
> The way I parse his statement is: It is better (read safer) to ignore
> <indent> than
> it is to trust that a <blockquote> is in fact a quote.
>
You got my meaning bang-on.
>
> I am convinced of my opinion because I have worked with markup for
> over 30 years.
> I am familiar with what people will and won't do -- and education is
> no remedy.
> People who need semantic markup will use it. People who don't will not.
> Path of least resistance and all that.
>
Agreed!
Shane Thacker wrote:
>
> In my experience, novice users tend to use what is available to them
> for presentation, not semantic meaning. (I'm including people who have
> been using HTML for a while, but haven't had any particular reason to
> learn more about it.) Unless you completely rid the browser world of
> the presentational aspects of HTML markup (as opposed to CSS
> definitions), such as a double line-break for <p>, it will continue to
> be used for presentation purposes. That doesn't seem realistic, and as
> a result I'm sure we can expect to see <p>'s that aren't paragraphs,
> <blockquote>'s that aren't blockquotes, and <em>'s that aren't really
> meant to be emphasized, for a long time.
>
Well said. Let me emphasize that, for the foreseeable future there will
be orders of magnitude more 'novices' than there will be learned HTML
coders because of the explosion of social media.
> That being said, I don't really support the idea of the <indent> tag.
That's a shame given your eloquently-stated understanding of the situation.
> and blockquotes...well, blockquotes are interesting.
Ah, you are making my point...
>
> Is that a problem with HTML and CSS? No, that was a problem with the
> editor. It should have had a blockquote button that used <blockquote>
> and an indent button that used <div> with styling.
But finding fault doesn't help the situation. Finding something that
empowers people to do a better job, even if its not exactly how we would
*like* them to do it, is.
>
> Anyway, I think the aim of this process shouldn't be to add extra
> top-level presentational elements to muddy the waters further. It may
> have already been mentioned in this thread, and if so I apologize, but
> why not use something we already have used: attributes? <indent> might
> add an extra element, but <p align="indent">, or however would be best
> to say it, simply adds a presentational suggestion to <p>, a concept
> that has been in HTML for a long time.
I argued for an <indent> because it is such an incredibly common element
used when writing, yet there is no element to correctly semantically
support indentation while there is one to incorrect support
indentation. <indent> is less complex. more likely to be used IMO, and
less likely to be mistyped than <p align="indent">, and further I would
argue that indent should ideally be set off vertically slightly more
than one <p> to the next in its default formatting.
>
> We could, of course, use inline CSS styling using the style attribute,
> but in my experience novice users get concepts like align="some visual
> location" better than style="some presentation logic that affects
> visual location".
I would definitely agree with that.
>
> That being said, anyone here used Textile, or BBCode for blog markup
> or forum posts? I haven't bothered to look and see what kind of HTML
> is being generated, but I would assume that is different for different
> engines.
Yes I use it a lot, and I abhor it because it does not offer nearly the
control of HTML and because each implementation has its quirks thus
making one never sure how things are going to turn out when moving from
implementation to implementation.
Dão Gottwald wrote:
>
> The implementations of Textile and the like that I saw (or even
> created) produced clean HTML.
>
> I personally hate BBCode with a passion. However, the produced HTML
> usually lacks <blockquote> or contains it where appropriate. Some use
> mostly presentational markup, i.e. <table> and/or <div> for [quote]
> and [code] (vBulletin, WoltLab Burning Board, Invasion Power Board).
> Others use <blockquote> for [quote] but don't misuse it for [code]
> (phpBB, PunBB).
>
Uh, are you sure you've checked vBulletin? vBulletin is *widely* used
and has a BBCode for [INDENT]. Know what it translates too? Take a
guess.....
Benjamin Hawkes-Lewis wrote:
>> I think the very fact that no tools except text editors are available
>> in all environments where HTML is applicable argues strongly that
>> HTML should be designed with a strong leaning towards
>> hand-authorability.
> That's not true. When you're faced with a WYSIWYG editor on a blog or
> CMS, you haven't got a text editor available to you. When you're using a
> symbolic editor, you might have a text editor available but not have the
> ability to use it:
>
True, but that's a spurious point. Just because some content management
systems have to lack of foresight to allow people to edit the HTML
doesn't mean that equally capable tools are available in all
environments. Your points here are just verbal slight-of-hand.
>
> And even if text editors were available everywhere, it wouldn't follow
> that they'd be the most widely chosen or the most fit for purpose. So I
> don't think that's a strong argument.
Again, you are making a spurious point. I didn't say they were the most
widely chose or the most fit for purpose just that they are the least
common denominator and that they are supremely easy to implement in all
environments. Higher level tools are many orders of magnitude more
complex, not for the least because there is no generally agreed upon
exact user interface that behaves the same during editing (because it is
really hard to exactly model in a WYSIWYG UI what can be modeled
declaratively in HTML.) The best I've seen to date has been Windows
Live Writer and I still spend more than 1/2 my time in HTML view...
>
>>>> But I do have anecdotal evidence that the languages that have been
>>>> easy to hand code have gained more rapid adoption. RSS vs RDF,
>>>> HTML vs SGML, Visual Basic vs. C++, Python vs. Perl, for example.
>>> I think the problem with this is that what may hold true for developers
>>> programming does not necessarily hold true for ordinary people writing
>>> web content. My experience of recommending text editor authoring over
>>> WYSIWYG to everyone who asks on the basis that WYSIWYG tools are
>>> fundamentally broken suggests that ordinary newbies generally prefer
>>> WYSIWYG and consider text editor authoring to be scary "programming".
>> You are looking at today, not 10 or 15 years out. Many of those
>> people who view it to be scary will be retired, and many of the kids
>> who cut their teeth on computers will be using HTML.
>
> a) HTML-next is supposed to be finalized in 2010, not 2022. ;)
Exactly my point. HTML 4.01 was finalized 24 December 1999 and HTML-next
is not supposed to be finalized until 11 years later. Add 11 years to
2010 and your are one year away from 2022...
>
> b) Retired people will want to author HTML too.
But, because of death, there will be less and less of them. :)
Besides, I'm not at all arguing against WYSIWYG, I'm arguing *for* the
requirement that HTML be able to reasonably be created with a text
editor. I'd further argue that if we get the latter it will be easier
for people to build the former.
>
> c) I see no reason to believe people will accommodate themselves to text
> editors, but not to semantic markup.
I don't understand "accommodate themselves to text editors." Do you
mean "learn?"
If so, your point is tangential. I'm not arguing against semantic
markup. I'm arguing for an escape valve when no existing semantic
markup is exactly right.
>
> d) That's plenty of time for the development of editors that are neither
> text editors nor WYSIWYG. In 1992, the web was in its infancy and most
> people were still using textmode word processors like WordPerfect 5.1
> for DOS.
Ha. Respectfully, now you are really dreaming. If that were true, we'd
all be programming visually instead of using text today some 25+ years
since the dawn of the IBM PC. I predict that 25 years from now we'll
still be using text. Why? Because it is completely expressive in ways
that more structured interfaces will frankly never allow.
>
>> But fundamentally, tools constantly change as vendors get bought or
>> morph, new products constantly emerge, and we never get to a
>> "perfect" tool.
>
> Nor a perfect markup language.
Agreed, but again a straw-man. Text allows us to improvise in ways
that "guided" tools do not.
>
>> A language as fundamental as HTML shouldn't be designed that it
>> *requires* a tool beyond a text editor. Tools should be viewed as
>> beneficial but not a requirement.
>
> A language as fundamental as HTML shouldn't require a text editor
> either. A text editor is not a baseline any more than a text browser is.
If a text editor is not a baseline, what is? And remember, a rose is
still a rose by any other name.
>
>> Over time, the number of people willing to be hamstrung my a
>> requirement for tools will be less and less.
>
> What makes you think that?
>
Are you arguing that people will be willing to be hamstrung?
>> Tools will be beneficial, but they add a layer of complexity on top
>> of text that should be able to be peeled away because I doubt anyone
>> will ever be able to build a WYSIWYG tool
>> that will be available in all environments and will meet the needs of
>> all users.
>
> Neither WYSIWYG editors nor text editors meet the needs of all users.HTML
Geez. I never said they did. But your argument for an HTML that is too
complex for hand-coding necessarily omits one segment of users.
>
>>> This remains true of many web professionals and people commissioning
>>> small retail websites. I doubt it's an accurate characterization of the
>>> "common" authors of social media.
>> I don't follow who you are referring to.
>
> I thought by "'common' authors" and "social media" you meant bloggers,
> forum posters, and user-generated content producers.
I see. But I've lost the original context of what "remains true" so I
can't really comment...
>
>>> Web accessibility issues are a novelty
>>> to most of the ordinary people I speak too. They don't know what screen
>>> readers are, for instance; some express surprise that blind people can
>>> use the web at all.
>> Exactly. Until you people actually experience the need, most will
>> never even consider it.
>
> Actually, the ordinary people I meet don't have to experience the need
> themselves, only to be made aware that other people have such needs.
>
And their being aware means...?
>
>> You don't get it!. You don't have the ability to make that choice
>> for them; they will make their own choices no matter what you think.
>> If you want to make things better you need to accommodate the fact
>> people will do what is easiest, accessibility be damned. Make the
>> easiest thing the most accessible thing and accessibility wins a
>> lot. Make the easiest thing less bad and accessibility wins a
>> little. That's what I'm proposing.
>
> How would <indent> make "[m]ake the easiest thing the most accessible
> thing"?
It doesn't. In that case it "Makes the easiest thing less bad and
accessibility wins a little." IOW, it minimizes the incorrect use of
<BLOCKQUOTE>
>>> that mass accessibility is reconcilable with widespread authorship
>>> and a
>>> sine qua non of mass authorship.
>> Can you provide any support for this belief?
> 100% accessibility is an ideal not a target, but I certainly believe
>
> Give people the tools and patterns to create accessible content, and
> it's no longer rocket science.
That's a good and idealistic goal, but unsupported by any evidence that
it will actually happen.
>>> Semantic markup that common authors aren't going to use doesn't
>>> particularly interest me (I recognize TEI and MathML have their
>>> places in specialist circles, but we're talking HTML here.)
>> What semantic markup are you referring to here?
>
> /Anything/ which will be ignored by most authors in favour of catch-all
> presentational equivalents.
>
You are making the assumption that people will ignore things like
<summary> if they are given the option to use both <summary> and
<indent>. I doubt that would be the case.as both are equally minimal in
complexity.
>> But you still want to control things, and I'm saying it's better to
>> loosen the reigns and empower people. Given the constraints but no so
>> much that they suffocate.
>
> Equal access is part of empowering people.
Again, a banal platitude without evidence of likelihood; not a pragmatic
solution.
>>> And that's how HTML was designed. By contrast, Flash was designed
>>> for animations.
>> Although I'll give you Flash, I'm pretty sure HTML was designed for
>> both.
>
> The web was certainly intended for hypermedia as much as hypertext:
>
> http://www.benjaminhawkeslewis.com/www/history/text-only-www
>
> But /HyperText/ Markup Language wasn't designed for animations.
I'm not proposing animations. I'm basic proposing document markup.
>> Two websites from professional bloggers do not make a statistically
>> accurate point. I could easily find two counterexamples, but it would
>> prove nothing.
> Actually Glenn Reynolds is supposed to be a professional law professor.
>
> Anyway, it still shows that /some/ ordinary authors do use some semantic
> markup,
I would hardly call a lawyer that knows HTML *ordinary*. At least when
compared to all the lawyers I've dealt with in my (recent) past.
> and I could easily accumulate examples to show that /many/
> ordinary authors do so.
Further banal platitudes. We can compare your semantically-savvy
authors to my semantically-challenged authors all day, but it's not a
good use of time.
> At which point the truly difficult and
> interesting question becomes, why do some ordinary authors do so, and
> some not? Is it because of the different tools they use, for instance?
I'd argue with a high level of certainty that it is their own personal
value systems as value systems seem to be why so many people have so
many intractable disagreements. Some people value semantic markup,
others do not, and there is a continuum separating the two. Our debate
here is because you have a value system that differs from mine: "Pure
Semantics Only vs. Pragmatic acknowledgment of both Semantics and
Presentation"
>>>> A wiki is a perfect example of the kind of problem that occurs!
>>>> Look at Mediawiki's syntax; it's so complex now as to be overwhelming.
>>> At least in the case of Wikipedia, that's largely because there's more
>>> than one way to do any one thing. That's another reason not to
>>> introduce
>>> <indent>.
>> Not really. Are there multiple ways to do bold? Underline?
>> Italics? And the big one: tables?
>
> Yes indeed:
>
> http://en.wikipedia.org/wiki/Help:Table
>
> But I was more thinking about:
>
> http://en.wikipedia.org/wiki/Wikipedia:Citing_sources
Heh. Wikipedia is a walled garden. If we had pedantic editors who
would ponce on and correct every bit of semantically-poor HTML published
then maybe we could be pedantic about HTML. But we don't have those
pedantic editors and thus being pedantic about HTML will only result in
a lot of badly semantic HTML.
>> Better to simplify basic HTML and have only one markup language for
>> people to learn rather than tens or hundreds of obscure ones.
>
> Perhaps we need a formal separation between HTML for streams of text
> (e.g. comments, articles) and other uses of HTML (forms, image maps
> etc.). Or a way of specifying particular subsets for input and textarea.
>
Now there's a discussion I'd be interested in participating in!
>>> But perhaps the way to combat individual web user powerlessness against
>>> companies is to begin to organize corporate action. I've been thinking
>>> recently that many inaccessible sites remain inaccessible because the
>>> people experiencing the problems don't have the technical skills to
>>> identify and articulate problems and solutions, and wondering if
>>> creating a bugzilla where reports could be refined before being mailed
>>> to webmaster would help. Even a template email where users report what
>>> OS, browser, and assistive technology they are using and how what
>>> happens differs from their expectations, and which provides links to
>>> WAI
>>> and other resources, would help.
>> Good idea, but who would implement?
>
> Possibly me, if I can find the time.
Hehe! Good luck! But you're too busy commenting on this list! ;-) ;-) ;-)
>> Bringing up a suggestion I made on another forum, things would be a
>> lot better if IE would display a green icon for valid HTML and a red
>> one for invalid HTML so validity would finally become "visible."
>
> A happy face and an unhappy face would be more accessible (something
> like one tenth of American males can't easily distinguish red and
> green). I put this suggestion on the MS bug tracker before they shut
> that down.
>
> The HTML Validator extension for Firefox shows how this can be done:
>
> http://users.skynet.be/mgueury/mozilla/
>
> Björn Höhrmann actually started work on a toolbar equivalent for IE a
> long time ago:
>
> http://ieqabar.sourceforge.net/
I'd agree with happy face vs. sad; it accomplishes the same. OTOH, I met
with Chris Wilson in Redmond last week and he told me under no
circumstances would IE ever do such a thing. And he gave many
reasonable reasons so I eventually gave up so as to keep him from
kicking me out of his office before I got a chance to tell him about
Toolicious. :-)
>> People learn from view source. People often discover how to fix
>> broken links with view source.
>
> Technical people, but I suspect not ordinary folk.
What's wrong with ensuring that the subset of people who directly or
indirectly influence the rest of are empowered?
>> People discover ids (for URL fragments) with view source.
> Judging by the tools we're making, we both recognize how broken /that/
> non-interface is.
>
Okay, I'll agree with that one. :-)
>> View source is one of the many powerful reasons why the web has been
>> such a success. Just because most people won't use it doesn't mean it
>> should be dismissed.
>
> I didn't dismiss it. I said it's irrelevant to most people ("common
> authors").
Most people read Wikipedia whereas few people edit it. But if they
didn't cater to the editors, they would have had nothing for the readers
to read.
>>> I think <indent> would be detrimental to source view. I find semantic
>>> elements buried in presentational soup extremely difficult to read. It
>>> gives me headaches trying to untangle the stuff.
>> Here's where you and I disagree.
>
> Really? Is your head some sort of mirror universe version of mine,
> such that when you spot semantic markup like <blockquote> you feel the
> need to find an aspirin while <center> fills you with inner peace?
Well that certainly is a wonderful use of the petitio principii.
.
>>>>> 1. HTML is about what you mean (content/semantics), not what you
>>>>> see (presentation).
>>>>>
>>>> If that is actually completely true, then we should eliminate ALL
>>>> default presentational behavior from ALL elements (p, h1..hn,
>>>> table/tr/td, ol/ul/li, etc.)
>>>
>>> That's a non sequitur.
>> Is it really? You said "HTML is about what you mean
>> (content/semantics), not what you see (presentation)" If it is not
>> about what you see, why shouldn't we remove ALL default
>> presentational behavior?
>> Honestly, I asked the question to trap you. It is not a non sequitur
>> because if your assertion is false, i.e. that presentation should not
>> be part of HTML then your arguments against presentation do not
>> hold. You can't have it both ways.
>
> Basically presentation is a function of user agents plus stylesheets.
> User agents can do what they like in terms of default rendering.
> The use of W3C providing default stylesheets would be so that
> designers can build on them, expanding the elements of a design that
> they care about without having to zero down than build again from
> scratch.
But you are not addressing the dichotomy of how "HTML can be about
(content/semantics) and not (presentation)" and the fact it has
presentational elements like <b>, <i>, <table> etc. As such your
statement cannot be true; wanting it to be true is not sufficient.
>> The problem is you can't get common semantic ones for every use-case,
>> so you need catch-alls for those that don't fit. Over time we can
>> identify
>> new common use-cases and there will be less and less need for
>> catch-alls, but the need will still be there. It's why we database
>> developers put a "Notes" field in most entity records to give users a
>> place to put stuff that doesn't fit elsewhere.
>
> I think HTML already has the equivalent of "Notes" in the form of div,
> span, and class. Possibly RDF roles might make such extension
> mechanisms a bit more machine-learnable, but we'll see.
But <div> suffers from the fact that people must first learn CSS to use
for indentation, and they must then type a lot more to use CSS, which is
why they use <blockquote>, which brings us full circle.
>
> The use of class in this way proved important to how new elements were
> developed for the HTML5 draft:
>
> http://code.google.com/webstats/2005-12/classes.html
That's really interesting. Thanks for that link.
By hacking the URL I found something interesting, a link to the WHATWG
element "small":
http://whatwg.org/specs/web-apps/current-work/#the-small
Isn't "small" presentational?
>> But expecting tools to solve these problems is a Faustian bargain as
>> you can't depend on the tools to be available. That's why raw HTML
>> needs to be designed to address the problem.
> I think we need both.
I 100% agree with that statement. But I think some of what you argue
for is to deemphasize the value of being able to hand edit raw HTML.
>> The HTML Validator extension for Firefox shows how this can be done:
>>
>> http://users.skynet.be/mgueury/mozilla/
>>
>> Björn Höhrmann actually started work on a toolbar equivalent for IE a
>> long time ago:
>>
>> http://ieqabar.sourceforge.net/
>
> I've just discovered iCab actually has this happy/sad face feature
> built in:
>
> http://www.icab.de/smile.html
>
Very interesting! Sadly, it only runs on Mac. :-(
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
Received on Saturday, 28 April 2007 05:26:03 UTC