font-size:0 DOES NOT kill white space bug in Saf/Chr

[deathshadow60]

using the above implies you plan on changing it's appearance later to display:block, visibility:visible or whatever.

So you've never seen a jumpto menu or written a media="print" CSS file then? It doesn't imply we EVER plan on showing it... in this stylesheet since we can have stylesheets target DEVICES using MEDIA types.

Like my normal print.css

.jumpto,
#mainMenu,
.borderTop,
.borderBottom { display:none; }

and no I don't set them to re-appear in the same stylesheet.

or in screen.css

hr,
.jumpto { display:none; }

I use horizontal rules for CSS off and print, they don't style well for screen so I hide them and set borders instead. .jumpto menus are only for CSS off or handheld, not screen... (well excepting opera's accesskeys menus, which work display:none or not!)

[noonnope]

yet you seem to have a purpose for all of the above, or at least for some use cases.

but this doesn't seem to be the case with the subject at hand.

[gary.turner]

White space is a presentational issue. Whether white space exists is a content and markup issue, and its collapse rules are defined in html for the nonce. White space presentation, or rendering, is defined by word-space and letter-space properties, and that's where the cure belongs. Font size is simply a multiplier, and setting it to zero affects the white space value.

Jiggering the document's markup formatting to remove certain white spaces will work as a non-robust solution. Its downfall lies in that changing the formatting breaks the solution. If something as simple as that causes breakage, formatting is not the solution.

Most of my work is about fixing html/css problems for developers and, more often, for maintainers. It would seem that most of the world's sites are coded by non-professionals (to judge by the markup), the formatting often makes the pages unreadable by the Mark I mod 0 human eye. Like Paul, my first step is often to run the source against a reformatting tool; usually Tidy. If someone's "fix" for a white space anomaly was a formatting hack, it's now broken. Or, maybe the maintainer had already broken the hack in his editing.

Noonnope, you seem to have only a tenuous grip on the functions of html markup and css rulesets. HTML does not define how an element shall be rendered. As Jason pointed out, html is for rendering in any and every kind of user agent. Only the stylesheet built into every browser defines the default presentation. To see how this works, go to wherever Firefox lives on your machine. In the res directory is a file named html.css. Rename that file (e.g. html.css.orig), and touch html.css. (For those using a legacy OS, create an empty file named html.css) Now open an html document, preferably one without its own stylesheet. Even a pure text browser like Lynx has its own rendering rules; lynx.cfg.

cheers,

gary

[noonnope]

Noonnope, you seem to have only a tenuous grip on the functions of html markup and css rulesets.

i assume you mean sophisticated, but didn't manage to find the right word your comments are "precious" as always

as for the rest, i'm sorry, but you are just grinding stone to hurt my ears.

really?

HTML does not define how an element shall be rendered[...] html is for rendering in any and every kind of user agent.

you're savy sounds like infatuation. and if you still believe that a bogus formating rule that breakes the layout is stronger than a sensible solution like removing that formating, you're just trolling.

removing whitespace between elements has absolutely nothing to do with html. it doesn't affect the html in any way. also, whitespace between elements has nothing to do with presentation.

so, if UAs don't know how to always handle your format, don't resort to css. css is not there to corect your format, but to offer a presentation. that is, in this case you suggest to use css to remove presentation for good, not to alter it, or to make it show later or whatever. correcting formating is your job, not css's. ponder about it tenuously griping the concept, please

[noonnope]

there are three wrongs:
- formating whitespace does not equal to whitespace used in presentation, default or otherwise
- using css to solve a bogus formating markup option is like using html to solve a presentation problem
- believing that removing format means altering the markup

adding elements, that's true manipulation of the markup.

adding format to your markup does not alter the markup, it's messing up with the DOM, by adding whitespace nodes.

these nodes have no business being there in the first place. there is no fourth layer: formating. only three: HTML, CSS, JS. and neither impose rules about formating.

so, your problem about removing whitespace OUTSIDE elements, and considering that whistespace manipulation OUTSIDE elements is about presentation and about markup manipulation, that is a complete false problem.

using css to remove whitespace introduced NOT by markup NOR by presentation, but by markup formating, that's the wrong use for what it supposed to be a tool to introduce presentation, not remove it.

yes, you do manipulate whitespace with css. but let's be clear, that's presentation whitespace, whether author's or user's. the whitespace we discuss it's not that. it's a rendering bug of the formating whitespace. a complet different type. forced in there by bogus formating rules.

yes, you maybe use hide elements with css. but if you never ever show them again, if they are not needed for a graceful degradation, they don't belong in the markup in the first place. you need to remove them. and so it is about formating whitespace. you need to remove it as you never have a need for it. don't use css as a palliative for what it should be a DOM modification.

[Stomme poes]

HTML does not define how an element shall be rendered[...] html is for rendering in any and every kind of user agent.

Rendering != "visual appearance", though usually graphical desktop browsers choose the appearance as they bring the content to the screen. However, a scraper bot also gets text rendered to it... without form or style.

adding format to your markup does not alter the markup, it's messing up with the DOM, by adding whitespace nodes.

these nodes have no business being there in the first place.

When first learning Javascript, this really pissed me off: some browsers would consider newlines the same way as markup whitespace, while others didn't (correctly I believe... look, IE doing something right!).

Whitespace between words, and between inline tags, has meaning. They should not be removed in order to achieve some particular visual setup.

Newlines, however, are usually something the developer (or client) does to ease reading, not because they want to change the meaning. Ideally the user agent should ignore these newlines because they are not content. But, browsers aren't ideal, so we hack for them.

I'd rather use CSS for the hacking because of the reasons mentioned above: I can't have my code break depending on whether someone ran the HTML through a newline-remover/code optimiser or not. I don't think it SHOULD be able to break my visual styles, but here it does, so in an imperfect situation, I'll choose CSS.
Similarly, while I'd like to remove whitespace so I can more easily find children of DOM nodes in Javascript, I instead add extra loops checking for nodeType ==3 or not because someone somewhere may add a newline, and that should NOT be able to affect the children I'm after... so I make my JS more robust.

[noonnope]

hmmm...

so you say: html is pure text. i agree.

so, why the tags then? since it's only text, there is no need for any tags notepad as a UA will do just fine.

only for semantic? but semantic alone, w/o any visual distinction, is only useful for "scaper bots". i thought those are not the primary targets. users are. and users need a consistent visual representation of the written web. which is why you use tags. to give a distinct meaning&visual representation for different part of your message.

there is an equal weight for semantic and visual representation there. you choose a semantic element because it's having also a default inherited presentation, by default. inherited from what old scribes learned it's best to pass on the written word, that you can mess now with using styles. lynx can't handle visual. guess what: that's the reason GUI UAs have been thought off. to overcome text-mode confusion.

semantic alone means s%*t. you talk to the user, not the seo. you talk about user styles, agent styles, author style like it has nothing to do with the markup. it has everything to do with it. yeah, you can change each and everyone of them. and i can try and make square U-turns

stop pretending web gave the written word a new meaning. web it's just a conveyer for the Gutenberg old way.

don't try and say: web has changed the way a written item looks and feel. web has brought one new thing alone: spreading speed. that's it. all the rest have been thought off and invented far long ago. and web obeys this system.

stop looking for hidden meanings when things are so simple. there is no wisdom in hotchpotch, only self-absorbance of a narrow-mind

[Stomme poes]

so, why the tags then? since it's only text, there is no need for any tags notepad as a UA will do just fine.

Please, please, use a screen reader. I dare you to experience it. Learn how to use it. Then navigate your favourite web pages. The ones built out of all tables or all divs will not delight you. The ones using headers, lists, and proper structure will speed up your use of the page immensely.

They are not scraper bots. Quit downplaying who semantics are for. They are for people, and occasionally for other programs since, why not?

you choose a semantic element because it's having also a default inherited presentation, by default.

No; if I did, why am I always changing the default presentation?

lynx can't handle visual.

Actually, it does... in a strange way. These forums, for example, are in tables... and Lynx does show that.
I'm on these forums about half the time using Lynx or Elinks. The problem is they don't show where quotes are or when quoted text ends : ( which is vBulletin's bad code I assume.

semantic alone means s%*t.

True. If there is no UA or user who understands their meaning, they have no meaning.

stop pretending web gave the written word a new meaning. web it's just a conveyer for the Gutenberg old way.

Not really: watching my husband struggle with a German client who wanted their newpaper ads (which were archived as PDFs) to be searchable on the web was quite eye-opening in how easy HTML is. In the PDFs, like print, there are no words, no letters even: everything is a glyph, with a size, and a placement on the page with page locators. Your closest "context" is that there is another glyph of x-size whose coordinates may be "close" to the spot your glyph is. Hubby ended up writing a Perl Module (postscript::textDecode) which looked for the largest glyphs, then went through several pages of rules looking for things that should match... luckily, in the PDFs, the person's name was the largest text but almost never the first text, so a lot could be eliminated by looking at glyph size.
Everything was coded with strange PostScript codes with Adobe proprietary glyph maps. You couldn't just "read" it, nor could the program. A lot like if you had large, relief words on a wall and you were blind: you could feel the shapes of the letters but it's not like you could just "read" them.

web has brought one new thing alone: spreading speed. that's it. all the rest have been thought off and invented far long ago. and web obeys this system.

The web has brought the world into the homes of the locked in and the visually impaired. Before, it was Audio Books and recordings of the news sent through the mail, or your family came to read to you. : ( This is huge. Absolutely huge.

[noonnope]

Please, please, use a screen reader. I dare you to experience it. Learn how to use it. Then navigate your favourite web pages. The ones built out of all tables or all divs will not delight you. The ones using headers, lists, and proper structure will speed up your use of the page immensely.

i would, but i'm afraid that by your own words, it wouldn't do me any good.

remember?

Rendering != "visual appearance"

now, that also means

Rendering != "aural representation"

since visually it has no importance, why would it aural?



let's get to basics and logic. we're talking words here. let's make a comparison. words vs. people.

words w/o tags. people w/o specifics.

words w/ tags. <h1>Big words</h1>. people w/ specifics. <height7">Tall people</height7">.

that means that, in order to convey semantics, you rely on visuals.


now, about why you change the default style. because you're advertising. you know, like flowers hopping to get visited by many bees. but changing default style also leads to confusion. it can also lead to error. you could convey the wrong meaning, like making h3 bigger than h1. would that make it semantically wrong? yes. why? you answer me but i have an idea: visuals!

as for aural. what if you start changing aural style the wrong way? it's like someone threatening your life while smiling. is that making you misunderstand the threat? are you smiling back? that's why default style has its place. conveying semantic.

[noonnope]

above is 7ft not 7".

I'd rather use CSS for the hacking because of the reasons mentioned above: I can't have my code break depending on whether someone ran the HTML through a newline-remover/code optimiser or not.

the problem with that is that you assume. you assume nobody would break your css solution. you assume nobody will trip or mess with it. you assume they will understand where the css hack for your inline-block bug starts and where it ends. you assume they will remember and have skills to make it work and provide good assimilation with complex css code.

i say you assume wrong. i say it's easier to remember and fix this whitespace bug in the markup formatting. messing or tripping with this solution it's far less likely to provoke future complex problems.

even more, that whitespace in the markup formatting has no use as far as the content is regarded. but you keep it there to indulge your code writing aesthetics. i say you're vain missy


one more thing, the most important one: changing formatting markup whitespace IT'S NOT THE SAME OR EVEN NEAR with changing markup. you are changing the WAY you place your markup in your file, not the ACTUAL markup used for content. that's the misunderstanding leading to this false problem in the first place.

why false? because you may:

• use formatting for your markup
• use some formatting for your markup
• use no formatting for your markup

and all these w/o degrading or improving your markup, but your in-file placement of your markup bits.

it has no ties to the actual content, apart from causing your content to break sometimes. that says that the one to be sacrificed is it: formatting, not html, nor css. sacrificing formatting has no "manipulate presentation in markup" meaning. it says "sacrifice visual placement of the markup in the file, w/o interfering at all with the markup and saving the css interference later on".

[noonnope]

Not really: watching my husband struggle with a German client who wanted their newpaper ads (which were archived as PDFs) to be searchable on the web was quite eye-opening in how easy HTML is. In the PDFs, like print, there are no words, no letters even: everything is a glyph, with a size, and a placement on the page with page locators. Your closest "context" is that there is another glyph of x-size whose coordinates may be "close" to the spot your glyph is. Hubby ended up writing a Perl Module (postscript::textDecode) which looked for the largest glyphs, then went through several pages of rules looking for things that should match... luckily, in the PDFs, the person's name was the largest text but almost never the first text, so a lot could be eliminated by looking at glyph size.
Everything was coded with strange PostScript codes with Adobe proprietary glyph maps. You couldn't just "read" it, nor could the program. A lot like if you had large, relief words on a wall and you were blind: you could feel the shapes of the letters but it's not like you could just "read" them.

nice. skilful hubby.

but i would've done something simpler. pdf2txt. like this one. a batch pdf2txt utility. there are many. i'm sure a redirect to pdf after would be easy. and the whole process faster.

[gary.turner]

This may meander a bit, as I'm replying to your comments in the order made.

i assume you mean sophisticated, but didn't manage to find the right word your comments are "precious" as always

I meant exactly what I wrote; tenuous, as weak, flimsy, lacking substance or consistency. Certainly more sophomoric than sophisticate.

as for the rest, i'm sorry, but you are just grinding stone to hurt my ears.

Would that it would, but you'd have to actually listen.

you're savy [sic] sounds like infatuation. and if you still believe that a bogus formating [sic] rule ...

You keep running on about a formatting rule, bogus or not. What rule is that? The only formatting rules are those we or our employers impose; usually to improve clarity and thus productivity.

... that breakes [sic] the layout is stronger than a sensible solution like removing that formating [sic], you're just trolling.

The problem isn't that your solution doesn't work, it does. The problem is that it depends on formatting which is highly susceptible to change. Since html is format agnostic, there is nothing to enforce that particular format, the maintainer is under no obligation not to naively screw it up while performing his job.

removing whitespace between elements has absolutely nothing to do with html. it doesn't affect the html in any way. also, whitespace between elements has nothing to do with presentation.

Ah, but in this case, it does. More in a bit.

so, if UAs don't know how to always handle your format, don't resort to css. css is not there to corect [sic] your format, but to offer a presentation. that is, in this case you suggest to use css to remove presentation for good, not to alter it, or to make it show later or whatever. correcting formating [sic] is your job, not css's. ponder about it tenuously griping [sic] the concept, please

The UA ignores the markup formatting. We are dealing with a white space within an inline string, i.e. CDATA. That, my friend, is a word space.

What do you mean, I should think about it with a flimsy gripe (on, with, about, ?) the idea? Sorry, makes no sense unless you meant I should think about it with a strong grip on the idea. But, that's not what you wrote.

there are three wrongs:
- formating whitespace does not equal to whitespace used in presentation, default or otherwise
- using css to solve a bogus formating [sic] markup option is like using html to solve a presentation problem
- believing that removing format means altering the markup ...

It has become, once again, abundantly clear that you have no understanding of the purpose or design of html. We are not dealing with a white space bug such as lived in IE<7. That did have somewhat to do with the white space, e.g. a line feed, between block level elements that should have been ignored, but wasn't.

We have been talking about a correct rendering of white space between inline elements. The reason the problem exists is because we have used css to cause block elements to act as inline. Why would you expect a different behavior than that of natural inline elements or inline character data?

adding elements, that's true manipulation of the markup.

What added element? The white space? That's not an added element; that's a part of the inline string. If you think otherwise, go back to the kiddie pool, you're not ready to swim in the deep end.

That's why it's reasonable and safe to eliminate spacing between natural inline elements. Its effect and purpose is obvious. That is not true of the same hack for natural block elements, since they only act as inline due to the css display property. It follows that a css solution is appropriate to a css induced issue

yes, you do manipulate whitespace with css. but let's be clear, that's presentation whitespace, whether author's or user's. the whitespace we discuss it's not that. it's a rendering bug of the formating [sic] whitespace. a complet [sic] different type. forced in there by bogus formating [sic] rules.

Again with the non-existent formatting rules. How many times must you be told before you understand; html ignores formatting. We are talking about white space that is content, as it appears within an inline string.


HTML is a declarative structural language. That means it describes the structure of a document. No more, no less. It is up to the UA to use its default style rules, the user's rules and/or the author's rules to render the document. Your statement regarding Lynx indicates your total lack of knowledge of that browser. It too has its built in default display rules. I repeat from an earlier post, look in lynx.cfg; hell, modify it to suit your own preferences. Notepad, otoh, doesn't grok html. It would make a crappy browser (it's not much of a text editor either). It's the structure, defined by html, that the UA uses to create the DOM. CSS and js then work against the DOM to do their things.

That the various graphic browsers all render stuff pretty much the same is the result of vendor cooperation or a desire not to be the odd looking one. The latter gets my vote. If you choose tags for their common presentation, you don't understand the medium.

Aural presentation works the same as for visual. There are built in defaults, and aural style sheets. For example, I might write:

<p>Noonnope is a <span lang="fr">soi-disant</span> html expert.</p>

An aural UA would default to a French pronunciation for the spanned phrase.

Aargh, that's enough

[noonnope]

We have been talking about a correct rendering of white space between inline elements.

see, that's why i said you are trolling.

we have been talking about formatting whitespace between <div>s. are <div>s inline? no. further more, we talk about the use of display: inline-block. will that make <div>s inline? no.

we were talking about a bogus formatting rule: use newline between the end tag and the start tag of two sibling <div>s. this false rule makes your presentation break. removing it has no ties to managing presentation in markup, since the whitespace we talk is not part of the content. or content whitespace. if you can't understand why it's bogus, i can't make it much clearer than it has been made already.

you? you chimed in your self absorbed unrelated opinion, w/o making any sense. you, for your self importance, started juggling and mixing up with basic concepts. i really don't know why you try and show me how to change agent style? is there a point? i don't see it? is it a bright idea? why? why do you keep reiterating obvious presentation and aural concepts? is this your way of closing your eyes and shutting down your ears to hear only your ideas when you don't get the gist of this thread?

as for the rest, i know enough about you as not to care about your opinion about me and i would not give you the satisfaction of resorting too to self sufficient language and approach.

one more thing you forgot

"cheers,

gary"

[gary.turner]

we have been talking about formatting whitespace between <div>s. are <div>s inline? no. further more, we talk about the use of display: inline-block. will that make <div>s inline? no.

All elements and character data are inline unless a style rule says differently. %block and %inline et al are entity tokens that are useful for describing structural characteristics. Did you ever try the default stylesheet experiment I suggested? I thought not. Once the stylesheet sets a div to {display: inline-block;}, it is inline externally, and acts like any other inline replaced element.

we were talking about a bogus formatting rule: use newline between the end tag and the start tag of two sibling <div>s. this false rule makes your presentation break. removing it has no ties to managing presentation in markup, since the whitespace we talk is not part of the content. if you can't understand why it's bogus, i can't make it much clearer than it has been made already.

Again, there is no such rule. It is common convention, and to depend on a particular formatting for a presentation fix is simply silly.

Moreover, once the div, li, or other elements are made inline of any sort, e.g. inline, inline-block, or inline-table, the white spaces between them become cdata, inter-word space.

My usual sign-off is meant as a friendly gesture. Note that again I don't use it

[noonnope]

<edited by spike>

on to the point.

Again, there is no such rule. It is common convention, and to depend on a particular formatting for a presentation fix is simply silly.

since there is no such rule, it's simply silly NOT to simply fix a particular whitespace nodes problem generated by a particular formatting (no way a presentation problem! presentation is when you target html CONTENT elements and whitespace, this one is FORMATTING whitespace), by removing that no-such-rule formatting (or preserving a certain formatting, or fixing in a few simple steps a formatting that breaks your page), but to depend on a convoluted css fix (that doesn't depend on whitespace declarations for a fix, if you were kind enough to read the latest css quiz), css solution that will be hard to maintain and to assimilate with a complex css code. by you or by your css solution recipient.

keep it simple ... gary

[spikeZ]

Lets keep this away from sarcastic poking and mudslinging. We have a pretty good discussion going on and I would like to keep it that way.

[Paul O'B]

It's ok to argue your points as strongly as you like but keep please keep the discussions civil otherwise it ruins an interesting thread.

[Stomme poes]

since visually it has no importance, why would it aural?

We're not talking aural. If you actually bothered using one you would know the difference. But you refuse. The tags tell the user WHAT the content is. The tags allow Navigation By Type. You can't just cover your ears and say "lalala" as loud as possible and then claim that semantics don't mean anything to human beings, because that's at the least incredibly insulting to those who rely on AT to access information on the web.

Get a screen reader (there are free ones like NVDA for Windows, Orca for Gnome/Linux, VoiceOver for Mac...).
Go to a page using bad markup and try to navigate it.
Go to a page using good markup and try to navigate it.

(Aural stylesheets are usually ignored... I'm not talking about those (and I don't bother writing them for that reason).)

offtopic

but i would've done something simpler. pdf2txt. like this one. a batch pdf2txt utility. there are many. i'm sure a redirect to pdf after would be easy. and the whole process faster.

How do you find the name of the person then? There's nothing to work on.

The PDFs were messages sent to the newspaper with news of (birth, death, memorial, wedding, whatever). The styles on the PDF were mostly that the person listed was the largest text. You lose that if you convert PDF to text because all that meta-data is gone. So he needed to use that font-size and other info to "guess" what the person's name was (he needed to extract the name).
However later he did find something that did try to keep some of the metadata called pdf2html. That might have worked, but it was not known or possibly not available at the time.

[noonnope]

But you refuse. The tags tell the user WHAT the content is. The tags allow Navigation By Type.

agreed. "The tags show the user WHAT the content is. The tags alow Navigation By Type (visually)."

i see no difference you are ignoring something

Off Topic:

about the mood here. i'm new here at SP but i see the truth in this post:

Hi, [...]

Off Topic:


My only concern is always the same: the mood in the CSS/XHTML forums isn't particularly friendly, and most people posting in those forums aren't fun (pickiness, semantic purity and all the things you have to face before you can actually get an answer ). But it's been like that for a long, long time.

[Stomme poes]

agreed. "The tags show the user WHAT the content is. The tags alow Navigation By Type (visually)."

Uh, if you're blind, how do you navigate by tags visually?

Did you miss something?

Yes, sighted and partially sighted people can and do also use screen readers, but it's still not why semantics are important on a page.

[noonnope]

you are really keen on confusion.

for sighted people: "The tags show the user WHAT the content is."

for visually impaired people: "The tags tell the user WHAT the content is."

the same thing. if tag Rendering != "visual appearance" then tag Rendering != "aural representation".

simple. aural representation relies also on a default speaking style like the visual representation relies on a default visual style. the same rules apply for both visual and aural. you seem to think it doesn't. for same reasons.



you've challenged the visual use of the tags but implied tags alone have an aural use. it's a contradiction in the way you treat the same Navigation By Type: either visual, as in identifying the elements by scouting the page or aural.



you don't seem to get one thing: there is no egg or chicken conundrum here. tags are natural descendants of the written system, Gutenberg and before. that means that <h1> is based on the visual representation of the biggest heading text found in a written document, or book.



saying that <h1> has semantics, but that semantics has nothing to do with the visual representation, is denying the history of human writings.

you, like gary, have a logic fault here. you seem to think that the way browsers modularize their system: keeping agent styles at large, in order to help you customize your experience, that this way changes the way written documents are perceived in the web world.

saying that all tags are text is like saying all java interface elements are objects. simply stating that you can alter the default style doesn't change the fact that this is a feature not an innovation. when altering the default style you still need to consider it further when designing yours.



no, UAs are pieces of software that have no say in the way humans used or will use the written words. their internal rules, their construction and logic is only serving the technology that is the underlying factor.

for the end user the book or the ancient written artifact or the web page have the same system. and it does. you seem to look for wrong hidden meanings where there is none. web semantics, which i believe is what you're trying to expose, were borned after and based on the existing "hard" written system and follow the old rules by every bit.

the problem here is the lack of vision. saying that html tags are used for semantics not for a visual meaning and that some style comes along later to do some rather unnecessary work otherwise, is nullifying the core html concept: text markup. if it's about text, then it's about a presentation of that text: visual or aural. having no presentation, default or otherwise, means html could be demoted to just t = text.

presentation and semantic have equal weight. if you get it wrong about semantic you may provide the wrong presentation: visual or aural. if you get it wrong about presentation, you may convey the wrong semantic: h3 bigger text than h1, calm tone describing violent threat.

how easy HTML is

keep some of the metadata called pdf2html

i believe xml is the correct answer to that problem.

[xhtmlcoder]

Off Topic:

The DTD is the specification that describes the semantics to be ascribed to the markup.

I think there has been some confusion with the language being used; since without the DTD its pretty much 'text' within angled brackets.

The second concept is regarding the user-agent having a "default style sheet", which typically includes the presentation.

[noonnope]

actually, it's pretty simple.

html was born to put text from paper to screen and to link it. the text should look like the one on paper: headings, paragraphs, lists, figures.

hence, putting html tags around your text means presentation. at first, it was only visual. nowadays, it's also about aural.

the semantics, Navigate By Type, DTDs, stylesheet, inline, character data, interface etcetera are details of the technology used to make it possible.


these technological details are not changing in any way the initial facts:


html was born to put text from paper to screen and to link it. the text should look like the one on paper: headings, paragraphs, lists, figures.

hence, putting html tags around your text means presentation. at first, it was only visual. nowadays, it's also about aural.


it's really that simple. don't get lost in the details

don't mistakenly take implementation details, modularization (default style or such) as new ways to read into this. you are still addressing a human. you are still following the same old rules.

semantics and presentation go hand in hand. html tags were created looking at the presentational features of the different text parts. you use those still.

using html you have however presentation flexibility at low cost (lower than the hard print) and superior spreading speed.

and this may confuse some people.



and finally: looking at the two solutions for our problem. changing formatting vs. changing css.

changing formatting has no ties to the html, css, js, flash, w3c, microsoft, rednecks, Athena. it's all about a choice in slapping around you code bits in a file. it has no ties to the CONTENT or the CONTENT WHITESPACE.

changing css it's the first mistake. you're writing code to fix first rather than to present.

re-formatting may break your intended page result. it's an easy fix. easy to understand, easy to apply.

re-writing/adding to css may break your intended page result. it's not an easy fix. it's not easy to understand, not easy to conserve and and not easy to blend with simple or complex css. also, it may have unexpected results, as it has not been tested extensively. future mods in css may prove it has unwanted results. this means further research, further errors, more time losing for debug.

[Stomme poes]

the same thing. if tag Rendering != "visual appearance" then tag Rendering != "aural representation".

Ah, I finally understand what you mean. However isn't that the point of semantic tags? To tell the user /user-agent what the content in the tag represents?

I'm saying it matters WHAT tag you wrap around some content, regardless of how one styles it visually (this includes whatever styles are left to the browser).

you've challenged the visual use of the tags but implied tags alone have an aural use. it's a contradiction in the way you treat the same Navigation By Type: either visual, as in identifying the elements by scouting the page or aural

Uh, NO. I don't rely on CSS to tell someone what the h1 of a page is. I rely on the <h1> tags to tell users that. No contradiction, however yeah I'd say most sighted users with a graphical browser and CSS enabled don't notice semantic markup at all... they don't know the difference between <h1>BIG HEADING</h1> and <p><strong><font size=20px>BIG HEADING</font></strong></p>. But there are users who DO rely on semantic tags (tags which correctly describe the content), and screen reader users are some of them.

So yeah, sure, if I was a lazy developer and only wrote for sighted users with graphical browsers and CSS, I wouldn't have to worry if the main header text was in an h1 or a p. I don't believe you are arguing that <p> here is a good thing to use but it sure sounds like it from your arguments.

that means that <h1> is based on the visual representation of the biggest heading text found in a written document, or book.

You are saying that because traditionally the heading text of [some document] was large and bold, that this is why in HTML documents we wrap <h1> tags around the header text? Yes. Not because it is large and bold, but because it IS header text. That lots of people (and browsers) choose to make it look large and bold has nothing to do with the reason why TBL (or whoever it was) decided that heading text should be wrapped with heading-text tags.

<h1> does not mean "first large and bold". It means "heading text, first level". Regardless if one of my browsers shows it as small and green (which is visual representation).

Here's the "aural" you keep talking about but don't listen to:

on page load
"Page has five headers, two tables and fifteen links." (you wouldn't get this semantic information if you built everything out of p's)
I hit "h", the quick key that takes me to the first heading tag of the page.
"Header level one."
I hit "h" again.
"Header level two." Oh, this must be a subheading of the main header I was just on. It must be related information.

This is not "aural styling". It's semantics. It explains what the information inside IS.

[deathshadow60]

actually, it's pretty simple.

[B]html was born to put text from paper to screen and to link it. the text should look like the one on paper: headings, paragraphs, lists, figures.

NO, IT WASN'T!

HTML was invented to be able to present content in a device independent manner -- be it print, screen, teletype, aural, whatever.

Given the plethora of device dot pitches, device resolutions, etc that were present when TBL took SGML and did something useful with it, your statement is pure nonsense. From 22x21 9 color plaintext on a VIC-20 to 64x16 monochrome on a TRASH-80 to 80x25 16 color DOS/CPM... to 320x200 4 color CGA to 1152x864 on a monochrome NeXT workstation (like the one TBL was using when he made HTML) to 800x600 16 color IBM 8514. Even from daisy wheel to 9pin line-printer to 1200dpi typesetting - The idea was to make it so none of that mattered and have the content fluidly adjust on the fly to whatever the target was. Identical appearance across devices was impractical at best, impossible at worst. As such the point was NOT to make it appear "the same on screen as on paper" -- but to custom craft it to appear different but acceptable on both.

The entire POINT of HTML was to say WHAT things were, and let the user agent best determine how to show that meaning. This even includes the B and I tags when it comes to devices that don't have the equivalents to font-weight or font-style. (which is why B and I are in fact semantic tags that mean bold and italic but NOT font-weight:bold or font-style:italic!) It wasn't until the browser wars with proprietary tags like FONT (which was later accepted into 3.2 but started out proprietary) that the mere notion of presentational markup came into being.

That you apparently don't grasp that is likely why you're the only one defending your viewpoint on this here... You do not seem to grasp the point of semantics OR separation of presentation from content.

Hell, TBL's original prototype browser even had something much akin to stylesheets -- though his would be best compared to user.css today or the stylesheets used in some browsers like firefox, to customize the browser's behavior for each device it could be run on since the default appearance for one media type might have absolutely nothing to do with the default appearance on another -- even if they are both being used to convey the same meaning.

See the old daisy wheel styling of _underscores_ before and after to indicate bold and ~tilde~ before and after to indicate italic... Today that would be done with :before and :after on devices that don't support font-weight or font-style. (and some teletype devices actually support this!)