If I code in strict XHTML will it validate in transitional doctype?

[system]

@noonnope

Where in the specs have you find it says so, the most important text on the page? You have a probable misuse as an argument for a wrong point. When I read the specs I understand that h1 has the biggest importance when it comes to h1-h6.

I think you completely missed what I was saying, as you are AGREEING with what I said while saying you aren’t…

Though again, your entire post I’m having a devil of a time trying to figure out what you are even saying since this latest one seems to contradict itself in every SENTENCE!

Seriously:

@noonnope

You have a probable misuse as an argument for a wrong point.

Can someone turn that into english? The Triple Negative and lack of an actual subject or explanation is losing me.

Though this one:

@noonnope

Specs talk about a basic way of PRESENTING TEXT to a USER

IF I’m reading it properly, (That’s a big IF) MISSES the point completely as the HTML spec is NOT about presentation apart from telling the user agent WHAT the element is, so the user agent may best present that content to the user within the capabilities of the device.

You seem to think I’m talking about it in terms of semantics for the developer, when I’m talking about it in terms of presenting semantic content to the USER AGENT, which then determines the best way to present it to the end user.

Which is WHY the HTML specification is filled to the brim with ambiguous wordings like “may”, “typically” and “often” – and is the cornerstone of semantics; Say what the element IS, not how it is going to appear; that way the user agent can craft that content the best way for the user regardless of media type.

In the case of headings, that makes the h1 the structural parent of all headings on the page, h2’s subsections of that h1, h3’s subsections of the parent h2, etc – this was done so user agents could in fact build a TREE, which many handhelds (like blazer powered ones) allow the user to navigate. You can look at this tree in the FF Web Developer Toolbar “Information > View Document Outline”

Which if people bothered using correctly would make a hefty part of the garbage in HTML 5 pointless… well, more pointless than it already is.

Bottom line MARKUP is to tell the user agent what things are, user agent presents it to the user according to the users preferences, capabilities of the target device, etc. CSS exists to craft that user agent presentation by targeting devices (hence the existence of media types).

Really sad part is the people who don’t grasp that are just making more work for themselves and vomiting up fat bloated garbage websites with CtC’s in excess of 10:1 when 90% of websites should never exceed 3:1 on the markup. Then they dive for stupid code tricks like whitespace stripping to make up for their piss poor coding habits.

[system]

@xhtmlcoder

Hence XHTML 1.0 Transitional.

AND STRICT… AND FRAMESET! – if you’re talking 1.0

MOST of the stuff people run their mouths about on XHTML is only true for 1.1+ and not 1.0

Since 1.1 and later are not intended for backwards compatibility on user agents while 1.0 is.

That difference being WHY 1.1 and later are effectively stillborn.

[system]

@deathshadow60

Bottom line MARKUP is to tell the user agent what things are, user agent presents it to the user according to the users preferences, capabilities of the target device, etc.

OK. How will a <p> be presented differently “according to the users preferences, capabilities of the target device, etc.”, apart from what the specs are saying:

The P element represents a paragraph. It cannot contain block-level elements (including P itself).
and apart from making changes in the default style sheet or apart from enforcing additional CSS rules.

When specs say it’s a block-level element, I assume it will be one even w/o an UA present, right? Unless you are a “are the trees cracking and screeching in the woods when there is no one to listen?” kind of guy

I think you may confusing specs with technical implementation: theory with filed reality. Specs DO convey a BASIC PRESENTATION. What UAs do with the info provided…

Off Topic:

The biggest text on page: you once gave an example with newspapers and headlines. Hence: “You have a probable misuse as an argument for a wrong point”. I should have provide a link to it, sorry. I get that the confusion may insinuate w/o a proper reference.

[system]

@noonnope

How do you call then an element having no content, either because it CANNOT or because it DOESN’T have one An “empty element”. So you’re contradicting your self in this paragraph.

HUH?!? Methinks your lack of understanding the nuances of english made you mis-read what I was saying. When they say “empty element” they are using it in context as a specific term, NOT the generic meaning of the text.

@noonnope

Until you provide an alternative name for those elements that CAN have content but DON’T have one.

There’s no reason for the specification to make that distinction – the only distinction it needs AND uses is elements that can have content, and elements that cannot have content. The term “empty elements” as used in the specification refers only to the latter. WHETHER there is content or not on ‘non-empty’ elements is irrelevant.

It’s the equivelent of asking if you CAN go to the bathroom, or if you MAY go to the bathroom.

@noonnope

Maybe be that some will not understand the difference very well, but still, both categories have the same description: “empty elements”, right?

It is not being used as a description, but as a specific term; basically it’s not being used as a adjective/noun pairing, but as the ultra-rare adnoun combination referring specifically to elements that CANNOT have content, NOT whether it has content.

Admittedly, the specification is filled with VERY specific language that goes right over the heads of anyone not used to reading legalese.

Jur, lectură greşită dvs. de posturile mele şi mizerie complet confuze mesajele dumneavoastră sunt mă face să mă întreb dacă faci toate astea prin intermediul Google traduce.

[system]

@deathshadow60

Jur, lectură greşită dvs. de posturile mele şi mizerie complet confuze mesajele dumneavoastră sunt mă face să mă întreb dacă faci toate astea prin intermediul Google traduce.

Actually it’s a pretty good translation, you know! And manages to keep the “deathshadow60 language” style to it!

But no, I do make my own mistakes, I don’t blame Google Translate for it Actually, I believe, sometimes, it could be better at it than I am!

And I appreciate you making me improve, even though in a harsh manner. But hey, each man with his style, right? I need to also get the good part of the message, hidden there. It was harder to face at first, but you do make valid points. That doesn’t mean I agree with your style, though

But, to make it short, to make the argument gain more substance: I believe specs convey semantics & basic presentation.

Basic presentation means a theoretical default style, based on general attributes and description: inline level, block level, bigger importance etcetera.

Basic presentation != Specific presentation.

Specific presentation is something you find in the default style sheet, for example. A technical implementation.

So UAs, on their turn, convey semantics & specific presentation.

If specs were to omit the parts about inline level, block level, bigger importance, UAs would be left clueless as to where to start.

[system]

@noonnope

OK. How will a <p> be presented differently “according to the users preferences, capabilities of the target device, etc.”, apart from what the specs are saying: and apart from making changes in the default style sheet or apart from enforcing additional CSS rules.

It may be indented by a heading preceeding it as in many Lynx user stylesheets. Some user agents may pad the bottom only (blazer, bolt, teashark), others may apply margin all-around (most desktop browsers)… it may have text-indent or the equivalent applied to it instead of padding as is common on a number of book readers that have web capabilities.

@noonnope

When specs say it’s a block-level element, I assume it will be one even w/o an UA present, right? Unless you are a “are the trees cracking and screeching in the woods when there is no one to listen?” kind of guy

… and the moment you override the block-level behavior with CSS? Different presentation, same meaning because the meaning you want on one target like SCREEN might not be the one you want when CSS is not present or for other media types like HANDHELD.

Besides, block-level and inline-level in the markup is not so much about presentation as it is structure… You are structuring the document so the user agent or CSS can apply meaningful presentation depending on the needs of the user, desires of your design and the capabilities of the end user device.

@noonnope

I think you may confusing specs with technical implementation: theory with filed reality. Specs DO convey a BASIC PRESENTATION.

No, they don’t – at least NOT so far as HTML is concerned. Presentation is not even HTML’s JOB unless you want to run around using HTML 3.2 like it was 1997 with outdated nonsense garbage code like FONT, CENTER, TABLE for layout, etc…

Which admittedly is what the majority of people seem to be doing anyways and just slapping a modern doctype on their outdated bloated train-wreck code - hence all the people who still ‘require’ transitional… Would they like a baby bottle and a pacifier with that?

[system]

@deathshadow60

… and the moment you override the block-level behavior with CSS? Different presentation, same meaning because the meaning you want on one target like SCREEN might not be the one you want when CSS is not present or for other media types like HANDHELD.

ds60 false point!

What is CSS doing here? We are not taking it in consideration for this subject. Because CSS can bring confusion when used wrong. I thought we already agreed upon that.

[system]

@deathshadow60

Besides, block-level and inline-level in the markup is not so much about presentation as it is structure… You are structuring the document so the user agent […] can apply meaningful presentation depending on the needs of the user, desires of your design and the capabilities of the end user device.

So the markup it is a little about presentation, right ?! And yes, that “not so much” is the basic style I’m talking about, that specs are conveying.

@deathshadow60

No, they don’t – at least NOT so far as HTML is concerned. Presentation is not even HTML’s JOB unless you want to run around using HTML 3.2 like it was 1997 with outdated nonsense garbage code like FONT, CENTER, TABLE for layout, etc…

Now you again muddy the waters a little and mix the basic presentation concept with specific presentation style and technical implementation.

[system]

@deathshadow60

When they say “empty element” they are using it in context as a specific term, NOT the generic meaning of the text.

What context? Probably the one I was talking about first :

@noonnope

It’s all about the context. That way you know which “empty element” category the element fits in

---

So, I guess that you’re doing what you accuse me of:

@deathshadow60

I think you completely missed what I was saying, as you are AGREEING with what I said while saying you aren’t…

---

But you still haven’t provided a name for “elements that have no content right now, but they could have one”. Or do you always refer to them as such: “elements that have no content right now, but they could have one” ?

I prefer the shorter version: empty elements, and let the context clear the air the next person, if necessary.

[system]

@noonnope

But you still haven’t provided a name for “elements that have no content right now, but they could have one”. Or do you always refer to them as such: “elements that have no content right now, but they could have one” ?

You’re thinking does or does not, when the specification means can and cannot.

Let me try to word that using your grammar techniques…

Does or doesn’t does not matter in the specification – it’s all about what it can and cannot do.

CAN it have content or CAN’T it – that’s all the spec cares about. Does or does not has no effect on how the element is handled – so there is no reason for the specification to HAVE a term for “an element that can have content but doesn’t”

A element lacking content is NOT what they mean by an empty element… If it was they wouldn’t have the keyword “empty” in the DTD in the first place! They wouldn’t have to explain that they are referring to the DTD in section 4.3, etc, etc…

<p></p> is not by the W3C specifications what they mean by an empty element… because P is not BY DEFINITION always empty, even when in the markup it has no content. BR is by definition ALWAYS empty - hence the rule in the DTD.

[system]

Yes, I get that about specs. No, i never said I expected to be said in the specs: “And for those elements that can have content, but at one point or another don’t have one, we have this name for them: …”

I was asking you, how do you call those elements not having content, though their definition in the specs is not “empty element”.

<p></p> is not what specs mean by an empty element. But how do you call it? You.

And a possible moot point: an element lacking content IT IS what they mean by an empty element. Their further explanation justifies why they chose to make it so: empty, w/o permitting content on it.

[system]

@noonnope

I was asking you, how do you call those elements not having content, though their definition in the specs is not “empty element”.

<p></p> is not what specs mean by an empty element. But how do you call it? You.

Ah, ok. That version of the question I can follow.

Oddly enough I wouldn’t call it anything special… That’s just a paragraph. There is nothing ‘special’ about it just because it doesn’t have any content, so I wouldn’t refer to it in the first place or give it any special treatment just because it’s empty; There’s no reason to!

As a rule I wouldn’t HAVE empty paragraphs in a document in the first place since that would likely be using a semantic tag as a spacer – basically doing a job that should be done in the CSS as padding or margin… or even a line-break tag’s job (though I hesitate to use those)

THOUGH if I was using the element as a presentational hook, I may refer to it as a “sandbag”… though typically I use DIV or SPAN for those since I don’t want the sandbag to have a semantic meaning. (not that the meaning would matter with no content inside it)

IF I were to refer to it, I’d call it by the tag name, “empty paragraph”… as in “what the **** do you have the empty paragraph in there for?”

[xhtmlcoder]

Probably P with ‘empty content’ is the nearest phrase. In the above case it is actually an ‘empty P’ element. But obviously with regards to ‘empty content’ NOT to be confused with the keyword “EMPTY”.

[zcorpan]

In HTML5 the elements that can’t have content in text/html are called “void” elements.

[Stomme_poes]

Zcorpan it’s the same as the old EMPTY? why the name change?

[system]

@xhtmlcoder

Probably “P with no content” alias “empty paragraph” alias “empty html <p> element” alias “empty element”.

[xhtmlcoder]

Well looking at one of the HTML5 Drafts:

@http://dev.w3.org/html5/html-author/

An empty element is any element that does not contain any content within it. In general, an empty element is just one with a start tag immediately followed by its associated end tag. In both HTML and XHTML syntaxes, this can be represented in the same way.

[…]

Some elements, however, are forbidden from containing any content at all. These are known as void elements. In HTML, the above syntax cannot be used for void elements. For such elements, the end tag must be omitted because the element is automatically closed by the parser. Such elements include, among others, br, hr, link and meta

So it looks like they are trying to clear any ambiguity with the word itself.

[Stomme_poes]

Probably “P with no content” alias “empty paragraph” alias “empty html <p> element” alias “empty element”.

Nah, that would make people think you meant
EMPTY
like

<!ELEMENT BR - O [b]EMPTY[/b]                 -- forced line break -->
<!ATTLIST BR
  %coreattrs;                          -- id, class, style, title --
  >

[zcorpan]

@Stomme_poes

Zcorpan it’s the same as the old EMPTY? why the name change?

To avoid discussions like the one in this thread…

[system]

A good thing. The void idea, not the discussion
I know I’ll be using this word for the “old EMPTY” from now on

So, having that in mind, the discussion wasn’t a bad one, right? An least one good thing came out of it.