validating a validator
Guy Macon
I am in the process of evaluating a commercial product that
claims to do the fundtions of an HTML Linter, Validator,
rudamentery SEO, tidy, and accessability checker.
I would like suggestions for URLs to test with it. I am looking
for well-written HTML to see if it flags bogus errors, and really
badly written HTML to see if it catches most errors. The results
will be posted here.
Any suggestions?
--
Guy Macon
<http://www.GuyMacon.com/>
Andy Dingley
> I would like suggestions for URLs to test with it.
As a wild guess, find the source code for OpenJade and see if there's
a test suite with it.
Hendrik Maryns
> I am in the process of evaluating a commercial product that
> claims to do the fundtions of an HTML Linter, Validator,
> rudamentery SEO, tidy, and accessability checker.
>
> I would like suggestions for URLs to test with it. I am looking
> for well-written HTML to see if it flags bogus errors, and really
> badly written HTML to see if it catches most errors. The results
> will be posted here.
I just finished freeing http://www.weltladen-tuebingen.de from frames
and generally hope that I made it validating, but it would be great if
you tested it so that I can check whether I did my work right ;-)
About bad websites: I don’t know, there’s so many of them. How about
http://www.microsoft.com/en/us/default.aspx? Total Validator gives me a
lot of errors and warnings there…
H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Incon
html is so forgiving that very few now days bother to validate. The
faster you get the page up the quicker you can market your product.
And I don't think the bigger sites are hand coding their html anymore
there are programs that do it for you. I don't care to hand code html
it is very tedious as you know.
Jan Krohn
> html is so forgiving that very few now days bother to validate. The
> faster you get the page up the quicker you can market your product.
> And I don't think the bigger sites are hand coding their html anymore
> there are programs that do it for you. I don't care to hand code html
> it is very tedious as you know.
HTML ist not so forgiving, but browsers are... And every single one of
them displays invalid HTML differently...
Incon
I stand corrected
Eric Biller
> HTML ist not so forgiving, but browsers are... And every single one of
> them displays invalid HTML differently...
Furthermore, even valid HTML will be displayed differently on different
browser.
greets
Eric
C A Upsdell
Or even on the SAME browser, e.g. because different users have different
fonts, preferred font sizes, browser window sizes, etc., etc., etc.
Jan Krohn
> Furthermore, even valid HTML will be displayed differently on different
> browser.
Very true and very annoying...
Ben C
> On Oct 8, 5:16 am, Guy Macon <http://www.GuyMacon.com/> wrote:
>> I am in the process of evaluating a commercial product that
>> claims to do the fundtions of an HTML Linter, Validator,
>> rudamentery SEO, tidy, and accessability checker.
>>
>> I would like suggestions for URLs to test with it. I am looking
>> for well-written HTML to see if it flags bogus errors, and really
>> badly written HTML to see if it catches most errors. The results
>> will be posted here.
>>
>> Any suggestions?
>>
>> --
>> Guy Macon
>> <http://www.GuyMacon.com/>
>
> html is so forgiving that very few now days bother to validate. The
> faster you get the page up the quicker you can market your product.
Which is the biggest reason to validate-- it helps you get the page up
quicker.
John Bokma
http://johnbokma.com/ most if not all pages should validate
--
John Bokma http://johnbokma.com/
AISE/AWW/SEO/web development forum: http://seo-expert-wiki.com/
Tonnie Lubbers
> On 8 Okt., 16:13, Eric Biller <Bilef...@gmx.net> wrote:
>> Furthermore, even valid HTML will be displayed differently on different
>> browser.
>
> Very true and very annoying...
Yes i agree.
We should force them all to use 1 and the same browser on the exact same
system and with the exact same fonts installed. If he or she even tries
to change it or is fiddeling in the preferences, his fingers should be
chopped of. Let that be a warning to all out there.
--
Webdesign: http://vision2form.nl/webontwerp/
Korte handleiding zoekmachine optimalisatie / gevonden worden:
http://vision2form.nl/webontwerp/gevonden-worden.html
Lifestyle - wonen reizen en genieten : http://vision4living.com
dorayme
Hendrik Maryns <gtw3...@sneakemail.com> wrote:
> Guy Macon schreef:
> > I am in the process of evaluating a commercial product that
> > claims to do the fundtions of an HTML Linter, Validator,
> > rudamentery SEO, tidy, and accessability checker.
> >
> > I would like suggestions for URLs to test with it. I am looking
> > for well-written HTML to see if it flags bogus errors, and really
> > badly written HTML to see if it catches most errors. The results
> > will be posted here.
>
> I just finished freeing http://www.weltladen-tuebingen.de from frames
> and generally hope that I made it validating, but it would be great if
> you tested it so that I can check whether I did my work right ;-)
Ah, a freeloader eh? Possibly getting the benefits of Albert's hard
sweat and tears for nothing!
See what you have now done Guy! I knew your offer to him was some sort
of trojan horse. I knew you would not quietly and objectively beaver
away at testing his product. And no, it turns out, you don't, you come
back to this newsgroup of opposition to everything Albert stands for,
this swirling biased hotbed to assist you to assess it.
And you expect that Albert should accept your assessment when it has
been dipped in this swirl?
<g>
--
dorayme
dorayme
John Bokma <jo...@castleamber.com> wrote:
> Guy Macon <http://www.GuyMacon.com/> wrote:
>
> > I am in the process of evaluating a commercial product that
> > claims to do the fundtions of an HTML Linter, Validator,
> > rudamentery SEO, tidy, and accessability checker.
> >
> > I would like suggestions for URLs to test with it. I am looking
> > for well-written HTML to see if it flags bogus errors, and really
> > badly written HTML to see if it catches most errors. The results
> > will be posted here.
> >
> > Any suggestions?
>
> http://johnbokma.com/ most if not all pages should validate
Look at
<http://jigsaw.w3.org/css-validator/>
re your css
--
dorayme
Stanimir Stamenkov
> I just finished freeing http://www.weltladen-tuebingen.de from frames
> and generally hope that I made it validating, but it would be great if
> you tested it so that I can check whether I did my work right ;-)
The content appears incorrectly labeled as English while I guess it
should be German:
<html lang="en">
...
should become:
<html lang="de">
...
--
Stanimir
Chris F.A. Johnson
> On Oct 8, 5:16 am, Guy Macon <http://www.GuyMacon.com/> wrote:
>> I am in the process of evaluating a commercial product that
>> claims to do the fundtions of an HTML Linter, Validator,
>> rudamentery SEO, tidy, and accessability checker.
>>
>> I would like suggestions for URLs to test with it. I am looking
>> for well-written HTML to see if it flags bogus errors, and really
>> badly written HTML to see if it catches most errors. The results
>> will be posted here.
>>
>> Any suggestions?
>
HTML is not forgining; browsers that interpret it are (too)
forgiving.
> The faster you get the page up the quicker you can market your
> product.
It doesn't take any longer to write valid HTML than it does to
write invalid HTML.
> And I don't think the bigger sites are hand coding their
> html anymore there are programs that do it for you.
All the more puzzling why they don't use valid HTML. If you only
have to do it once, what's keeping them from doing it properly?
> I don't care to hand code html it is very tedious as you know.
Hand coding HTML is simpler and faster than using any HTML
generator. And produces much better HTML.
--
Chris F.A. Johnson, webmaster <http://Woodbine-Gerrard.com>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
John Bokma
>> http://johnbokma.com/ most if not all pages should validate
>
> Look at
> <http://jigsaw.w3.org/css-validator/>
> re your css
Thanks, I just fixed the typo (oem instead of 0em). Will look soonish in
the (now) 62 warnings :-).
C A Upsdell
> We should force them all to use 1 and the same browser on the exact
same
> system and with the exact same fonts installed. If he or she even tries
> to change it or is fiddeling in the preferences, his fingers should be
> chopped of. Let that be a warning to all out there.
If the user has a laptop, something else could be cut off.
Guy Macon
My only responsibility is to give an honest and fair assessment
of the quality of the program, which I believe that I am well
qualified to do. It is to Albert's credit that he provided an
evaluation copy to me, knowing that I disagree with his naming
and marketing practices. The reason I made the offer is that
pretty much every criticism here is about his naming and marketing
practices -- nobody has examined the quality of the actual
program. I am making no assumptions about that.
Got a URL for me to test, dorayme? I envisioned you digging up
some sort of site designed to crash browsers or some such. :)
Hendrik Maryns
Thanks, I noted some other problems as well (make your viewport small).
I’ll be fixing them when I have time (as you might have understood,
this is pure voluntary work).
Cheers, H.
dk_sz
> and marketing practices. The reason I made the offer is that
I think people forget the program was created all back
in 1997... If I had been a developer of something could
check "HTML properness" I would probably also have
called it "HTML validator" :-)
--
best regards
Thomas Schulz :: Sitemap Generator
http://www.micro-sys.dk/products/sitemap-generator/
Jukka K. Korpela
> My only responsibility is to give an honest and fair assessment
> of the quality of the program, which I believe that I am well
> qualified to do.
Evaluating program quality is actually much harder than people think. Being
honest and fair is even more difficult, and all we can do, as humans, is to
make our best effort at that. Those that realize that honesty and fairness
is impossible usually make a better attempt at them.
> It is to Albert's credit that he provided an
> evaluation copy to me, knowing that I disagree with his naming
> and marketing practices.
Well, I don't think that such a marketing move deserves any special credits,
but it is surely more acceptable marketing than continued lies.
> The reason I made the offer is that
> pretty much every criticism here is about his naming and marketing
> practices -- nobody has examined the quality of the actual
> program.
In all fairness, the phoney "validator" _has_ been evaluated and comments
have been posted to Usenet. People just got tired of it, because none of the
fundamental flaws - like presenting outright false claims, wrong advice,
misleading statements, and irrelevant notes, ultimately reflecting nothing
but the software author's and vendor's personal likes and dislikes - were
addressed by the said author and vendor. He just makes his own rules and
then sells a "validator" that checks (or tries to check) whether such rules
are followed.
Followups randomized as usual. (Posting to three groups just calls for
trimming followups, in the rare cases where it makes sense to partipate.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
dorayme
Guy Macon <http://www.GuyMacon.com/> wrote:
> My only responsibility is to give an honest and fair assessment
> of the quality of the program, which I believe that I am well
> qualified to do.
....
> Got a URL for me to test, dorayme? I envisioned you digging up
> some sort of site designed to crash browsers or some such. :)
I did make a site that crashed my own browsers back in the days when
browsers and most else crashed more easily (at least on OS > X). It was
a framed site that generated a lot of frames afaicr... <g>
Surely, you can just go to any of the many crummy sites on the net and
approach it thus: would Albert's program give helpful clues that the
author would benefit from attending to directly.
But I have many misgivings about objectivity in this test of yours. I do
not question your motivations. I am much more worried about the very
fact that your criteria might well be from the point of view of would it
pick up stuff that you would find helpful. And what you might find
helpful might be very different indeed to what someone less capable
would find helpful.
I just have this indelible image of brave Albert clucking innocently
into the wolves den here...
--
dorayme
Guy Macon
dorayme wrote:
>
> Guy Macon <http://www.GuyMacon.com/> wrote:
>
>> My only responsibility is to give an honest and fair assessment
>> of the quality of the program, which I believe that I am well
>> qualified to do.
>
>....
>
>> Got a URL for me to test, dorayme? I envisioned you digging up
>> some sort of site designed to crash browsers or some such. :)
>
>I did make a site that crashed my own browsers back in the days when
>browsers and most else crashed more easily (at least on OS > X). It was
>a framed site that generated a lot of frames afaicr... <g>
>
>Surely, you can just go to any of the many crummy sites on the net and
>approach it thus: would Albert's program give helpful clues that the
>author would benefit from attending to directly.
>
>But I have many misgivings about objectivity in this test of yours. I do
>not question your motivations. I am much more worried about the very
>fact that your criteria might well be from the point of view of would it
>pick up stuff that you would find helpful. And what you might find
>helpful might be very different indeed to what someone less capable
>would find helpful.
Actually we already know that several less capable people have
found it to be helpful -- they have posted as much here. What
I will be looking for is whether the advice it gives leads them
in the right direction, as opposed to only seeming to be helpful.
I am curious as to how it will turn out, but I am swamped with
paying work until Friday. I can toss of a Usenet post or two
while the techicians set up the next test, but I want some
uninterupted time before I start testing software.
teebo
>>> them displays invalid HTML differently...
a good browser should alert the viewer with blinking red text
if the page viewed have faulty HTML/CSS/JS, and that the page viewed is
just a guesstimate of what the creator had in mind (and didn't write).
Ok, smaller html-errors could perhaps just have discreet normal info-text
on the statusline, but the more ugly errors should have blinking
yellow/red+warning icon and a beep!
>> Furthermore, even valid HTML will be displayed differently on different
>> browser.
> Or even on the SAME browser, e.g. because different users have different
> fonts, preferred font sizes, browser window sizes, etc., etc., etc.
but that is the GOOD thing about HTML. html is about describing
content not about how things looks. Different persons looking at the
web page have different taste, some like one font, some another, some have
a big 24" screen and some have a 4" PDA (while other perhaps blind
people don't look at the screen at all and just listen to it or use
braille-display).
It would have been nice if web browsers during install asked the user
what he likes, how he want tables, headings or previously visited links
to look like for example.
CSS on the other hand suggest how webpages are rendered on
screens/print/pronounced. A document stylesheet tells what things
in a certain web pages look different from the users own settings
(except for those marked as important by the user).
It is of course very important that all web browsers interpret
the css-code in the same standardized way, and that page writers
understand that they are not, and should not, describe everything
about how the page will look.
> I am in the process of evaluating a commercial product that
> claims to do the functions of an HTML Linter, Validator,
> rudamentery SEO, tidy, and accessability checker.
every web editor *should* have one built in, IMHO....
and refuse to save until the writer have fixed the page
(or if the author insist to save anyway, should insert a
text "this page is faulty and is not finished yet")
> I would like suggestions for URLs to test with it. I am looking
> for well-written HTML to see if it flags bogus errors, and really
Hmm.. that can be tricky to find good pages that have all
combinations of HTML's posibilities... I guess it is easier to
create these pages yourself than go hunt for them premade.
HTML isn't that big... just create a couple of page that use
every html code and lots of blocks in blocks. HTML isn't
that complex language and it isn't hard to do right....
Neither is CSS but with it you can create a page that follows
spec but still is verry unaccessable, and there isn't an exact line
where blue text on somewhat lighter blue is too similar blue.
I guess a HTML+CSS checker would say "I give a 10% error
on you bad colors here dude" :-)
But I don't think you have to worry about that the program
report bogus errors...
just push all pages on w3.org through it, they *should* be correct,
right? ;-)
> badly written HTML to see if it catches most errors.
badly pages is easier, just take some random pages from the web ;-)
hehehe...
since the tool you are evaluating is allso checking accessability
things, I wonder is it allso checking for bad javascripts?
Like when I go to http://slashdot.org/ my browser since some time
allways asks if I want to abort the script that is causing mozilla
to run slowly and may make the computer become unresponsive".
A commercial page checking tool could perhaps have that kind of
function too.
I wonder if there are some tool out there that gives a special
warning if the tested page is correct but do things that in some of
the browsers will make the page hard to use. it should ignore that
some browser might render margins and widths etc wrong so it looks "bad",
and only complain if some text will dissapear or drawn on top
of each other and that kind of things...
I wonder if is hard to create an universal web checker that tests
correctness of all web formats against spec
HTML/XHTML/CSS/GIF/JPG/PNG/SVG/JS
and some other common formats like SWF, PDF and ICO, and allso try to
see if a page is unuseable/unreadable due to bad css or javascript
and when you're at it check for spelling errors too....
Perhaps I should try some day (but I think I wait until they release
HTML5 and CSS3)
Guy Macon
teebo wrote:
>CSS on the other hand suggest how webpages are rendered on
>screens/print/pronounced. A document stylesheet tells what things
>in a certain web pages look different from the users own settings
>(except for those marked as important by the user).
>It is of course very important that all web browsers interpret
>the css-code in the same standardized way, and that page writers
>understand that they are not, and should not, describe everything
>about how the page will look.
The user marking CSS stylings as important does different things
in different browsers, especially browsers written before CSS2.
"In order to ensure that users can control styles, CSS2 changes
the semantics of the "!important" operator defined in CSS1. In
CSS1, authors always had final say over styles. In CSS2, if a
user's style sheet contains "!important", it takes precedence
over any applicable rule in an author's style sheet. This is
an important feature to users who require or must avoid certain
color combinations or contrasts, users who require large fonts,
etc." Source: [ http://www.w3.org/TR/WCAG10-CSS-TECHS/ ].
To make things worse, Internet Explorer 6 and do not handle
"!important" properly, while IE 7 does.
For more on Internet Explorer CSS support, see:
[ http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx ]
[ http://www.webcredible.co.uk/user-friendly-resources/css/internet-explorer-7.shtml ]
[ http://www.positioniseverything.net/explorer.html ]
[ http://www.positioniseverything.net/explorer.html ]
[ http://www.maratz.com/blog/archives/2005/06/16/essentials-of-css-hacking-for-internet-explorer/ ]
[ http://www.wipeout44.com/brain_food/css_ie_bug_fixes.asp ]
dorayme
> >>> HTML ist not so forgiving, but browsers are... And every single one of
> >>> them displays invalid HTML differently...
>
> a good browser should alert the viewer with blinking red text
> if the page viewed have faulty HTML/CSS/JS
No, this would be quite awful, it would not be appreciated by people
uninterested in technical requirements and it would make life
unnecessarily difficult for a lot of website makers who can only get by
with a rough accuracy, they probably should not be held back from
publishing before they have been been thoroughly vetted like a
thoroughbred horse for a formal race.
>
> >> Furthermore, even valid HTML will be displayed differently on different
> >> browser.
> > Or even on the SAME browser, e.g. because different users have different
> > fonts, preferred font sizes, browser window sizes, etc., etc., etc.
>
> but that is the GOOD thing about HTML.
"That" is not necessarily a good thing. But "it" might be a consequence
of a good thing.
> html is about describing
> content not about how things looks.
HTML is not really about describing anything. It is a way to mark up
linguistic and other objects. One central idea about this mark up is
that it is designed to allow these objects to appear according to their
natures, a picture should appear as a picture, a heading as a heading, a
paragraph as a paragraph and a list as a list.
>
> CSS on the other hand suggest how webpages are rendered on
> screens/print/pronounced.
Your "on the other hand" is premature because you have not even begun to
describe one of the hands. It suggests that HTML has nothing to do with
layout and this is demonstrably and thoroughly false.
--
dorayme
Adrienne Boswell
<dorayme...@optusnet.com.au> writing in news:doraymeRidThis-
CB2D9E.075...@news-vip.optusnet.com.au:
> HTML is not really about describing anything. It is a way to mark up
> linguistic and other objects. One central idea about this mark up is
> that it is designed to allow these objects to appear according to their
> natures, a picture should appear as a picture, a heading as a heading, a
> paragraph as a paragraph and a list as a list.
>
I would not say that HTML has anything to do with appearance, but as a
method of marking up text in a meaningful way. After all CSS can alter the
appearance of almost any element.
As we know, browsers' default presenation of some elements has lead to the
abuse of that element for appearance sake, eg. blockquote and table.
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
dorayme
Adrienne Boswell <arb...@yahoo.com> wrote:
> Gazing into my crystal ball I observed dorayme
> <dorayme...@optusnet.com.au> writing in news:doraymeRidThis-
> CB2D9E.075...@news-vip.optusnet.com.au:
>
> > HTML is not really about describing anything. It is a way to mark up
> > linguistic and other objects. One central idea about this mark up is
> > that it is designed to allow these objects to appear according to their
> > natures, a picture should appear as a picture, a heading as a heading, a
> > paragraph as a paragraph and a list as a list.
> >
>
> I would not say that HTML has anything to do with appearance, but as a
> method of marking up text in a meaningful way. After all CSS can alter the
> appearance of almost any element.
Your last sentence gives the game away, Adrienne. If CSS can alter the
appearance of an element, it must have an appearance to alter in the
first place. This appearance is everything to do with HTML, without it,
HTML would be more than useless.
--
dorayme
Jonathan N. Little
Well there this a basic "appearance" associated with types. Lists tend
to be small blocks of text in a vertical stack that has a linear
relationship. Paragraphs are blocks of text that support a basic
thought. Headings tend to be a line of text that announces a new topic,
which traditionally is larger and bolder with margins to separate it for
the supporting text. But I would argue that the purpose of HTML markup
to to identify the "purpose" or "function" of the text within the document.
Now because there are these traditional associated styles for such,
lures the uniformed to use elements for styling instead of structure of
a document. Prime examples are using H# element to enlarge or bold text,
DL to create hanging indent paragraphs... Appearance may have some thing
to do with HTML, but not everything. CSS has everything to do with
appearance, HTML has everything to do with structure.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
John Bokma
Please don't snip away attributions:
>>>> HTML ist not so forgiving, but browsers are... And every single one
>>>> of them displays invalid HTML differently...
>
> a good browser should alert the viewer with blinking red text
> if the page viewed have faulty HTML/CSS/JS, and that the page viewed
> is just a guesstimate of what the creator had in mind (and didn't
> write).
Netscape did that to some extend, if there was an error in the HTML it
showed a gray (default background color) page. Guess what... they
changed that soon.
Quite a number of XHTML pages on the internet are not even well-
formed...
> Ok, smaller html-errors could perhaps just have discreet
> normal info-text on the statusline, but the more ugly errors should
> have blinking yellow/red+warning icon and a beep!
And what would be the result of this? Wouldn't amaze me if such a page
would blink and beep for years before anybody contacts the webmaster.
>> Or even on the SAME browser, e.g. because different users have
>> different fonts, preferred font sizes, browser window sizes, etc.,
>> etc., etc.
>
> but that is the GOOD thing about HTML. html is about describing
> content not about how things looks.
HTML is a failure, because it's neither IMO. Maybe because the two are
very hard to separate to begin with.
> It would have been nice if web browsers during install asked the user
> what he likes, how he want tables, headings or previously visited
> links to look like for example.
Would work for some pages, but there are plenty of examples for which
this wouldn't work.
> It is of course very important that all web browsers interpret
> the css-code in the same standardized way, and that page writers
> understand that they are not, and should not, describe everything
> about how the page will look.
For some pages this is possible and certainly should be done, for others
possible not.
> every web editor *should* have one built in, IMHO....
> and refuse to save until the writer have fixed the page
> (or if the author insist to save anyway, should insert a
> text "this page is faulty and is not finished yet")
Stuff like that just doesn't work. That's why XHTML has become such a
failure (IMO).
[ snip ]
> I wonder if there are some tool out there that gives a special
> warning if the tested page is correct but do things that in some of
> the browsers will make the page hard to use. it should ignore that
> some browser might render margins and widths etc wrong so it looks
> "bad", and only complain if some text will dissapear or drawn on top
> of each other and that kind of things...
and solve the halting problem while you're at it :-)
> I wonder if is hard to create an universal web checker that tests
> correctness of all web formats against spec
> HTML/XHTML/CSS/GIF/JPG/PNG/SVG/JS
For a program language (JavaScript) you're trying to solve the halting
problem, so your answer is: no
> and some other common formats like SWF,
for SWF, see answer above (JS).
[..]
John Bokma
> Your last sentence gives the game away, Adrienne. If CSS can alter the
> appearance of an element, it must have an appearance to alter in the
> first place.
Because the browser has a default style sheet. What's the appearance (as
in: coming into sight / looks), of say, the h1 element on a browser that
reads aloud instead of presenting the HTML visually?
dorayme
John Bokma <jo...@castleamber.com> wrote:
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > Your last sentence gives the game away, Adrienne. If CSS can alter the
> > appearance of an element, it must have an appearance to alter in the
> > first place.
>
> Because the browser has a default style sheet. What's the appearance (as
> in: coming into sight / looks), of say, the h1 element on a browser that
> reads aloud instead of presenting the HTML visually?
"Appearance" in this discussion is merely to take the visual case, the
presentation in an aural case would attract similar remarks from me. An
HTML heading would be read with a characteristic pause in the voice
before and after the heading text was read, there might be other subtler
cues to let the hearer know it was a heading that was being read. There
is no point in an HTML heading if it is not bundled with some basic
appearance or presentation.
I would not particularly object to the particularly abstract idea that
HTML has nothing essentially to do with appearance as long as the folks
who are ever ready to say this agree that an HTML doc would be more than
useless without some el basic appearance.
That default style sheet you refer to is not some optional extra. (And,
btw, I am not at all sure that all browsers are provided with a
traditional CSS sheet. Maybe the el basic appearance is more
'hard-wired' into the coding but can be turned off by the presence of
user or author provided CSS sets of instructions).
It is all very well to talk about the semantics of HTML elements, to
talk about the semantic structure of a document, but when it comes down
a human being having to actually recognise this structure, appearance -
at least very basic appearance - is not some sort of afterthought for
aesthetic purposes, it is quite essential.
--
dorayme
dorayme
Identifying the purpose or function of text in a doc, to take your
example, is for a higher purpose. This higher purpose it to tell the
browser - not the human reader who never sees the mark up - to make the
text appear in a way that humans will see it as a paragraph. So when I
say HTML is everything to do with appearance, I mean this deeper thing.
If HTML elements are to be the slightest use when going to a party, they
must make sure the party will understand it. They ain't going to get to
dance by mere attendance. When they arrive, someone or something must
recognise them and fit them out with dance gear. That is appearances.
You can talk about meaning, semantics, function till the cows come home
Jonathan. But in the end, the coinage for human non geeks is
appearances. It is from appearances that meaning comes. It is not the
other way around.
> Now because there are these traditional associated styles for such,
> lures the uniformed to use elements for styling instead of structure of
> a document. Prime examples are using H# element to enlarge or bold text,
> DL to create hanging indent paragraphs... Appearance may have some thing
> to do with HTML, but not everything. CSS has everything to do with
> appearance, HTML has everything to do with structure.
In a curious way, I don't want to disagree with you, I would be happy to
say what you say. But I would not be happy to stop there as if this is
the whole story.
--
dorayme
Guy Macon
dorayme wrote:
>
> Adrienne Boswell <arb...@yahoo.com> wrote:
>
>> I would not say that HTML has anything to do with appearance, but as a
>> method of marking up text in a meaningful way. After all CSS can alter the
>> appearance of almost any element.
>
>Your last sentence gives the game away, Adrienne. If CSS can alter the
>appearance of an element, it must have an appearance to alter in the
>first place. This appearance is everything to do with HTML, without it,
>HTML would be more than useless.
So when I turn off my monitor and access a web page using sound
alone, HTML becomes more than useless? Doesn't seem like it to me.
Guy Macon
John Bokma wrote:
>
>teebo <n...@mail.no> wrote:
>
>> I wonder if is hard to create an universal web checker that tests
>> correctness of all web formats against spec
>> HTML/XHTML/CSS/GIF/JPG/PNG/SVG/JS
>
>For a program language (JavaScript) you're trying to solve the halting
>problem, so your answer is: no
>
>> and some other common formats like SWF,
>
>for SWF, see answer above (JS).
Leaving aside the question of whether the JS/SWF specifications
actually define a program that does not halt as being incorrect,
from a practical standpoint such a checker could be set to stop
and flag scripts that are still running after X minutes/hours/
days/years as being potentially non halting. To the average
person browsing the web "never halts" and takes "at least 3 days
(and possibly forever) to halt" are pretty much the same thing.
I would also point out that for the halting problem to be
not solvable requires an infinite amount of storage. For
a computer that has a 1TB hard drive, there are (cough)
only 2 to the 8,000,000,000,000th possible states. Once
the program runs through all of them without halting, we
know that it will never halt.
Then again, going through a mere 2 to the 128th possible
states would require a minimum of 30 gigawatt/hours and
(assuming a billion GHz clock) would take 10 to the 13th
years -- far longer than the current age of the universe,
so perhaps exhausting every state on a 1TB hard drive
isn't very practical way to determine whether a program
halts... <grin>
John Bokma
> In article <Xns9B3CAFAB56...@130.133.1.4>,
> John Bokma <jo...@castleamber.com> wrote:
>
>> dorayme <dorayme...@optusnet.com.au> wrote:
>>
>> > Your last sentence gives the game away, Adrienne. If CSS can alter
>> > the appearance of an element, it must have an appearance to alter
>> > in the first place.
>>
>> Because the browser has a default style sheet. What's the appearance
>> (as in: coming into sight / looks), of say, the h1 element on a
>> browser that reads aloud instead of presenting the HTML visually?
>
> "Appearance" in this discussion is merely to take the visual case, the
> presentation in an aural case would attract similar remarks from me.
> An HTML heading would be read with a characteristic pause in the voice
> before and after the heading text was read, there might be other
> subtler cues to let the hearer know it was a heading that was being
> read. There is no point in an HTML heading if it is not bundled with
> some basic appearance or presentation.
This presentation has nothing to do with the HTML elements themselves, but
is provided by a different layer (CSS, or defaults in the software).
[..]
> That default style sheet you refer to is not some optional extra.
Depends on what browser you're using. I use telnet ;-).
> (And, btw, I am not at all sure that all browsers are provided with a
> traditional CSS sheet. Maybe the el basic appearance is more
> 'hard-wired' into the coding but can be turned off by the presence of
> user or author provided CSS sets of instructions).
That's just an implementation detail, doesn't matter.
John Bokma
> isn't very practical way to determine whether a program
> halts... <grin>
In short, my point is a very valid one.
dorayme
Guy Macon <http://www.GuyMacon.com/> wrote:
I trust the triple space between your sentences is evidence of a
hesitation in your interpretation of my words? <g>
Short answer: "appearance" was just an example of a central medium.
Similar things would be said by me for sound and touch.
Longer answer: If you listen to the page somehow, how do you imagine the
meaning of it all comes to you? By magic?
Does it come somehow directly into your brain unmediated except via an
amp and speakers? No, of course it does not. It requires a browser or
something that reacts to the HTML tags. The brain of most folk - not on
this ng - do not react to these tags directly!
What do you think this reaction is? Something deep and meaningful? Do
you suppose that in some ghostly way the browser understands the meaning
and somehow conveys it into your mind in some mysterious language that
stands in some separate logical category to styling? It sure does not
convey it in the language of HTML because no one except a few of us
authors ever much see that language.
A browser does not understand much in the ordinary meaning of
understand. It is a machine to turn tagged text etc into appearances or
sounds in conjunction with other suitable things like monitors,
speakers, braille making machines or whatever. It conveys the
information embedded in the HTML doc in looks, appearances, in pauses
and soft and loud readings aloud and so on. This is the language of
appearances, of sound or of touch. The browser is something that is
programmed to make appearances and it is equipped with an el basic means
to do this. Without this means, a browser would be utterly unable to
convey the meaning to a human.
It is not for nothing or to stir up Bergamot (a sport I indulge in) that
I say that appearances are quite central to HTML. People are always
saying how HTML conveys the information and CSS conveys the
presentation. I don't like this one little bit because it conveys a
false impression.
Now and then you will get someone to say that there is a default
stylesheet that gets applied to make a basic appearance. Ask yourself
this question: what would you see or hear if there was not default sheet
or if there was not programming to give direct el basic styles in the
browser itself? You would see a useless mess. There is a core set of
appearances at the very heart of HTML, it is not something that is added
on or arbitrary.
I am not meaning to deny obvious things like that there is an abstract
independence of a heading from how it appears. For example, a machine or
robot could be programmed to count how many H1 headings there are on a
particular website. It counts them and gets it right. All this is quite
independent of the appearance. Fine (as Luigi would say). But this is
because this robot is interested in things that have nothing to do with
appearance. Human beings are not like this, so be careful before you
apply these abstractions to them.
--
dorayme
dorayme
John Bokma <jo...@castleamber.com> wrote:
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <Xns9B3CAFAB56...@130.133.1.4>,
> > John Bokma <jo...@castleamber.com> wrote:
> >
> >> dorayme <dorayme...@optusnet.com.au> wrote:
> >>
> >> > Your last sentence gives the game away, Adrienne. If CSS can alter
> >> > the appearance of an element, it must have an appearance to alter
> >> > in the first place.
> >>
> >> Because the browser has a default style sheet. What's the appearance
> >> (as in: coming into sight / looks), of say, the h1 element on a
> >> browser that reads aloud instead of presenting the HTML visually?
> >
> > "Appearance" in this discussion is merely to take the visual case, the
> > presentation in an aural case would attract similar remarks from me.
> > An HTML heading would be read with a characteristic pause in the voice
> > before and after the heading text was read, there might be other
> > subtler cues to let the hearer know it was a heading that was being
> > read. There is no point in an HTML heading if it is not bundled with
> > some basic appearance or presentation.
>
> This presentation has nothing to do with the HTML elements themselves, but
> is provided by a different layer (CSS, or defaults in the software).
Easy for you to say this because you say nothing at all about what the
HTML layer *does* have to do with! I say quite different things after
saying *a lot* about what HTML has to do with. Try to say much about
what HTML has to do with without bringing in stuff about appearances.
You will find that you might be able to do it if you have in mind robots
manipulating and counting things but not if you bring humans into the
picture.
--
dorayme
Ben C
>
>
>
> John Bokma wrote:
>>
>>teebo <n...@mail.no> wrote:
>>
>>> I wonder if is hard to create an universal web checker that tests
>>> correctness of all web formats against spec
>>> HTML/XHTML/CSS/GIF/JPG/PNG/SVG/JS
>>
>>For a program language (JavaScript) you're trying to solve the halting
>>problem, so your answer is: no
>>
>>> and some other common formats like SWF,
>>
>>for SWF, see answer above (JS).
>
> Leaving aside the question of whether the JS/SWF specifications
> actually define a program that does not halt as being incorrect,
> from a practical standpoint such a checker could be set to stop
> and flag scripts that are still running after X minutes/hours/
> days/years as being potentially non halting. To the average
> person browsing the web "never halts" and takes "at least 3 days
> (and possibly forever) to halt" are pretty much the same thing.
Most of them do pop up a dialogue after being stuck in script for a
while.
> I would also point out that for the halting problem to be
> not solvable requires an infinite amount of storage. For
> a computer that has a 1TB hard drive, there are (cough)
> only 2 to the 8,000,000,000,000th possible states. Once
> the program runs through all of them without halting, we
> know that it will never halt.
>
> Then again, going through a mere 2 to the 128th possible
> states would require a minimum of 30 gigawatt/hours and
> (assuming a billion GHz clock) would take 10 to the 13th
> years -- far longer than the current age of the universe,
> so perhaps exhausting every state on a 1TB hard drive
> isn't very practical way to determine whether a program
> halts... <grin>
This is an enjoyable enough herring, but I think all teebo probably
means is why not flag up syntax errors and uncaught exceptions. That
would be easy.
Ben C
> In article <Xns9B3CAFAB56...@130.133.1.4>,
> John Bokma <jo...@castleamber.com> wrote:
>
>> dorayme <dorayme...@optusnet.com.au> wrote:
> That default style sheet you refer to is not some optional extra. (And,
> btw, I am not at all sure that all browsers are provided with a
> traditional CSS sheet. Maybe the el basic appearance is more
> 'hard-wired' into the coding but can be turned off by the presence of
> user or author provided CSS sets of instructions).
Firefox certainly does have one, and you should be able to delete it and
watch everything become display: inline.
Most browsers don't bother to do list-items with all the funny
counter-increment properties and things (which they don't always fully
support), but apart from that it all comes from the default stylesheet.
> It is all very well to talk about the semantics of HTML elements, to
> talk about the semantic structure of a document, but when it comes down
> a human being having to actually recognise this structure, appearance -
> at least very basic appearance - is not some sort of afterthought for
> aesthetic purposes, it is quite essential.
I think so. There are two problems with trying to claim HTML has
fundamentally nothing to do with presentation:
1. It's not what happened historically. They stripped out and deprecated
a lot of things, but it's still basically the same language it was
before anyone used CSS. You can't make a dog just by cutting two of
the legs off an octopus and deprecating another two.
2. (And I think this is closer to your point) even if you did start out
trying to make a brand-new dog without trying to modify an octopus,
it's not clear that you could define "headings", "tables", etc. in
ways that are completely abstracted from presentation. The concepts
just don't make sense any other way. You could invent some new ones
but either they would be unintelligible or sneakily presentational
really ("I get it, a 'section' is basically a paragraph").
dorayme
Ben C <spam...@spam.eggs> wrote:
> On 2008-10-19, dorayme <dorayme...@optusnet.com.au> wrote:
> > In article <Xns9B3CAFAB56...@130.133.1.4>,
> > John Bokma <jo...@castleamber.com> wrote:
> >
> >> dorayme <dorayme...@optusnet.com.au> wrote:
> [...]
> > That default style sheet you refer to is not some optional extra. (And,
> > btw, I am not at all sure that all browsers are provided with a
> > traditional CSS sheet. Maybe the el basic appearance is more
> > 'hard-wired' into the coding but can be turned off by the presence of
> > user or author provided CSS sets of instructions).
>
> Firefox certainly does have one, and you should be able to delete it and
> watch everything become display: inline.
>
At least you can do this: In the web developer, disable all styles or do
it by hand somehow and substitute something along the lines of
* {display: inline; font-size: 100%; font-weight: normal; font-style:
normal; text-decoration: none;}
and maybe you can think of other things we should add to be in the
spirit of removing all presentational style. <g>
Not very handy to read at all then! Try, for example, the otherwise
excellent (with author's or even FF default stylesheet):
<http://www.cs.tut.fi/~jkorpela/forms/methods.html>
> > It is all very well to talk about the semantics of HTML elements, to
> > talk about the semantic structure of a document, but when it comes down
> > a human being having to actually recognise this structure, appearance -
> > at least very basic appearance - is not some sort of afterthought for
> > aesthetic purposes, it is quite essential.
>
> I think so. There are two problems with trying to claim HTML has
> fundamentally nothing to do with presentation:
>
> 1. It's not what happened historically. They stripped out and deprecated
> a lot of things, but it's still basically the same language it was
> before anyone used CSS. You can't make a dog just by cutting two of
> the legs off an octopus and deprecating another two.
> 2. (And I think this is closer to your point) even if you did start out
> trying to make a brand-new dog without trying to modify an octopus,
> it's not clear that you could define "headings", "tables", etc. in
> ways that are completely abstracted from presentation. The concepts
> just don't make sense any other way. You could invent some new ones
> but either they would be unintelligible or sneakily presentational
> really ("I get it, a 'section' is basically a paragraph").
Yes, I think this is right.
When a newcomer is introduced to the excellent idea of separating style
from content, and the useful idea of semantic markup first and styling
later, the actual practice of this teaching is quite clearly *very far*
from the fantasy of a pure and sharp distinction. One typically starts
with el basic styling. Right from the word go, the game seems to be up!
But the purists do have a line they can try:
"Ah, but that is just pedagogy. We can throw that crutch away later to
get a glimpse of the crystal pure distinction, HTML with no
presentational aspect."
I'd say to this, a bit like I said to another poster in this thread, go
ahead. Let's see you do it. Let's see you actually describe an HTML
document that would be of some real human use and consciously and
deliberately exclude all thought or reference or imagining of
appearances.
I might also say, why could you not do without the el basic style to
teach the distinction to a *really* bright student? If it is a mere
crutch to teaching, perhaps not all students need it? Is such a thing
possible. In the end, I do not believe in a pure distinction between
what is conveyed and how it is conveyed, not in some big general sense.
--
dorayme