Styling a range of HTML Headers inside TD
Swifty
table cell.
The following works:
td h4,td h5,td h6 {margin-top:2px}
But is there a simpler way to define H4-H6 inside TD ?
I tried "td h4,h5,h6" but (from observation) that affects ALL h5,h6
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Andy Dingley
> I would like the HTML headers (H1-H6) to display differently inside a
> table cell.
>
> The following works:
>
> td h4,td h5,td h6 {margin-top:2px}
>
> But is there a simpler way to define H4-H6 inside TD ?
No. CSS is verbose. Simplicity was a goal for it, not avoiding
verbosity.
Use
td h4,
td h5,
td h6 {
...
}
Maybe even (for both kinds of cell) as much as:
td h4,
td h5,
td h6,
th h4,
th h5,
th h6 {
...
}
Swifty
> No. CSS is verbose. Simplicity was a goal for it, not avoiding
> verbosity.
I should get on well with it. I score highly on the "verbose" and
"simple" scales.
> Use
>
> td h4, td h5, td h6 { ... }
Curses. I was hoping for some sort of nesting/grouping control, such as
brackets. Still, 99% of my CSS/HTML is generated by CGI scripts, so it's
the program that can do the work.
Andy Dingley
> Still, 99% of my CSS/HTML is generated by CGI scripts, so it's
> the program that can do the work.
That's why CSS is the way it is. The assumption is that you're going
to be auto-generating, not hand-editing.
Jukka K. Korpela
> Maybe even (for both kinds of cell) as much as:
>
> td h4,
> td h5,
> td h6,
> th h4,
> th h5,
> th h6 {
> ...
> }
Or maybe simpler
table h4, table h5, table h6 {
... }
since any table cell is inevitably inside a table element and a table
element cannot contain anything but td and th elements wrapped in suitable
containers, in essence (caption elements must not contain headings, so
they're irrelevant here).
On the other hand, if anyone can present me a document where it makes sense,
logically and semantically, to use h4, h5, and h6 inside table cells, I'll
buy him a large beer. (I'm afraid I'd have to drink it myself, as the
Internet doesn't have a beer transport protocol yet, but so what.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Swifty
> On the other hand, if anyone can present me a document where it makes
> sense, logically and semantically, to use h4, h5, and h6 inside table
> cells, I'll buy him a large beer. (I'm afraid I'd have to drink it
> myself, as the Internet doesn't have a beer transport protocol yet, but
> so what.)
I'm not vying for the beer, but I thought some people might appreciate
an explanation of what I'm up to.
The webpage (mostly just one table) is the list of the user's "To Do"
list of tasks. They compose the entries (which are placed in the cells
of my table) themselves, and I allow them to us any HTML they wish. We
all work for the same company, and my trust has always been rewarded. In
effect, each cell may contain its own entire HTML document.
So, I have no idea what people will put in their cells. They may even
try to use <H7> for all I know. I styled the H1-H6 tags because the H1
inside the cells looked "wrong", as the cells themselves are subsidiary
to the H1 that I put at the top of the entire page. Having shrunk the H1
font size (and margins), I was obliged to do the same for the H2, and so on.
It's quite probable that I'll be the only person ever to use HTML in the
task data. So I designed it to look OK to me. Everyone else will just
have to use the heading tags that give the effect that they want. Or use
their own <STYLE> tags (shudder).
If I won the beer, Enjoy it, Jukka!
Roy A.
Ah, don't worry that much. Use html too present information, use xml
too deliver data. Use some other means to give us a chance to pick our
optioin (it is all there).
Roy A.
> I would like the HTML headers (H1-H6) to display differently inside a
> table cell.
>
> The following works:
>
> td h4,td h5,td h6 {margin-top:2px}
>
> But is there a simpler way to define H4-H6 inside TD ?
No. There is no simplere way. CSS don't know anything about HTML. It
dosn't know about the p-elment, it dosn't know about span or div. In
stead it treat all elements as inline (text) elements.
CSS don't know the name of any elements.
So, no. There is noe easy way. One document type could contain
headers, like h1, h2, h3, h4, h5, and h6, but one other document type
don't need to have any heading.
dorayme
"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:
> On the other hand, if anyone can present me a document where it makes sense,
> logically and semantically, to use h4, h5, and h6 inside table cells, I'll
> buy him a large beer. (I'm afraid I'd have to drink it myself, as the
> Internet doesn't have a beer transport protocol yet, but so what.)
To buy someone a beer requires only that you pay for it. You can send
the money to the person or you can send it to their local pub. I will
walk up later to find out the BSB and Account number of my local and
then we will take it from there...
--
dorayme
Jukka K. Korpela
> The webpage (mostly just one table) is the list of the user's "To Do"
> list of tasks. They compose the entries (which are placed in the cells
> of my table) themselves, and I allow them to us any HTML they wish.
That's rather risky, since people tend to use HTML markup rather absurdly. I
wonder what happens if they enter </body>, for example.
> We all work for the same company, and my trust has always been rewarded.
They might be trustworthy, but do they know HTML?
> So, I have no idea what people will put in their cells. They may even
> try to use <H7> for all I know. I styled the H1-H6 tags because the H1
> inside the cells looked "wrong",
Certainly they look odd, but the problem is in markup, not in styling.
But I think I see your point. The content of a cell is in this case
comparable to the content of a BLOCKQUOTE element. If you have block
quotation that happens to quote an H1 element, it's not really level 1
heading for your document. Rather, a BLOCKQUOTE should create its own
rendering environment, so to, and so should, perhaps, some table cells in
your case.
Nevertheless, I don't think it's logically or semantically sound to let
people enter whatever markup they like into something that you include in
your document. Even if we ignore cases like </body> or <html> or unclosed
<blink> (creating invalid markup of course, but nasty effects), they will
mess up the structure of _your_ document. Using embedding via <iframe> or
<object> would logically more sound, though objectionable in other ways.
> If I won the beer, Enjoy it, Jukka!
You didn't, but I will, as soon as I've finished the port I'm enjoying right
now. :-)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
> On 12 Nov, 10:30, Swifty <steve.j.sw...@gmail.com> wrote:
>> I would like the HTML headers (H1-H6) to display differently inside a
>> table cell.
>>
>> The following works:
>>
>> td h4,td h5,td h6 {margin-top:2px}
>>
>> But is there a simpler way to define H4-H6 inside TD ?
>
> No. There is no simplere way.
That much is correct for CSS2. Unfortunately so, I may add. A grouping
operator introduced by CSS3 definitely would come in handy.
> CSS don't know anything about HTML. It dosn't know about the p-elment, it
> dosn't know about span or div. In stead it treat all elements as inline
> (text) elements. CSS don't know the name of any elements.
This gibberish borders to nonsense, if that. CSS is a (formatting)
language. Like any other language, it does not know anything. *People* can
know. So the person writing the CSS code, knows what markup is supposed to
be formatted with that stylesheet. In doing so, they have to know and apply
the rules of the markup language. For example, if you are going to format
XHTML, you need to use lower-case element type names, while for formatting
HTML only, you can be lenient regarding letter case.
> So, no. There is noe easy way. One document type could contain headers,
Those are _headings_. Headers are elsewhere.
> like h1, h2, h3, h4, h5, and h6, but one other document type
> don't need to have any heading.
You appear to answer a completely different question than which was asked.
PointedEars
Jukka K. Korpela
> Roy A. wrote:
[...]
>> CSS don't know anything about HTML. It dosn't know about the
>> p-elment, it dosn't know about span or div. In stead it treat all
>> elements as inline (text) elements. CSS don't know the name of any
>> elements.
>
> This gibberish borders to nonsense, if that.
Welcome to Earth. What you see as "gibberish" is is how experts may speak
here.
> CSS is a (formatting) language. Like any other language, it does not know
> anything.
If you protest against metaphoric use of "know", which is quite widespread
in issues like this, how come you use the word "language" so metaphorically?
Think about writing a list of similarities between CSS, on one hand, and
languages proper (such as Swahili, Chinese, and Finnish) on the other. How
long a list could you produce while we wait? Or at all?
> So the person writing the CSS code, knows what
> markup is supposed to be formatted with that stylesheet.
He may, or he may not, and in any case that's irrelevant in our issue.
> In doing
> so, they have to know and apply the rules of the markup language.
Why?
Here's a stylesheet:
* { line-height: 1.3; }
What did I need to know about the rules of "the" markup language when I
wrote that? (The article "the" is in quotes, since a stylesheet, especially
like the one I gave as example, need not be limited to use for one
particular markup language.)
> For example, if you are going to format XHTML, you need to use
> lower-case element type names, while for formatting HTML only, you
> can be lenient regarding letter case.
That's a fairly trivial point, and the underlying principle is even more
trivial: an element name selector matches only elements with that name. So
when using such selectors, you need to consider which element names appear
in the document(s) to which your style sheet is to be applied.
>> So, no. There is noe easy way. One document type could contain
>> headers,
>
> Those are _headings_. Headers are elsewhere.
Everyone here knows what was meant when the element names h1 etc. were
mentioned. It's pointless to nitpick in such a case.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Roy A. wrote:
>>> CSS don't know anything about HTML. It dosn't know about the
>>> p-elment, it dosn't know about span or div. In stead it treat all
>>> elements as inline (text) elements. CSS don't know the name of any
>>> elements.
>> This gibberish borders to nonsense, if that.
>
> Welcome to Earth. What you see as "gibberish" is is how experts may speak
> here.
Certainly nobody I would consider a (if I may say so, fellow) expert in this
field would talk like that.
>> CSS is a (formatting) language. Like any other language, it does not
>> know anything.
>
> If you protest against metaphoric use of "know", which is quite widespread
> in issues like this, how come you use the word "language" so
> metaphorically?
I do not.
> Think about writing a list of similarities between CSS, on
> one hand, and languages proper (such as Swahili, Chinese, and Finnish) on
> the other. How long a list could you produce while we wait? Or at all?
I do not follow. Both natural languages and programming languages are
languages, and of course they do not know anything.
>> So the person writing the CSS code, knows what
>> markup is supposed to be formatted with that stylesheet.
>
> He may, or he may not, and in any case that's irrelevant in our issue.
It is not. Not knowing the markup language for which a stylesheet is
intended is a recipe for disaster.
>> In doing so, they have to know and apply the rules of the markup
>> language.
>
> Why?
>
> Here's a stylesheet:
>
> * { line-height: 1.3; }
>
> What did I need to know about the rules of "the" markup language when I
> wrote that? (The article "the" is in quotes, since a stylesheet,
> especially like the one I gave as example, need not be limited to use for
> one particular markup language.)
Fallacy: Proof by example.
>> For example, if you are going to format XHTML, you need to use
>> lower-case element type names, while for formatting HTML only, you
>> can be lenient regarding letter case.
>
> That's a fairly trivial point, and the underlying principle is even more
> trivial: an element name selector matches only elements with that name. So
> when using such selectors, you need to consider which element names appear
> in the document(s) to which your style sheet is to be applied.
It may be a trivial issue for the both of us. It is not so trivial a point
considering the amount of markup out there that claims to be XHTML and is
not.
>>> So, no. There is noe easy way. One document type could contain
>>> headers,
>> Those are _headings_. Headers are elsewhere.
>
> Everyone here knows what was meant when the element names h1 etc. were
> mentioned. It's pointless to nitpick in such a case.
This is not a guessing game. Headers are a different thing than headings.
In an (X)HTML document, what constitutes the content of the HEAD/head
element, or the META/meta elements that have an `http-equiv' attribute
specified, could reasonably be understood as headers. But so could the
HTTP headers served with (before) the document (as the document is part of
the corresponding HTTP response's message body).
Those who regard valid corrections as nitpicking might not have really
understood what they are talking about in the first place. Correctness,
which includes correct terminology and unambiguousness, is vital in order
to avoid misunderstandings and misconceptions, especially in a technical
field. You of all people should know this.
BTW, the proper way to reply is to trim the "(was: ...)" part from the
Subject header value.
PointedEars
Jukka K. Korpela
> Certainly nobody I would consider a (if I may say so, fellow) expert
> in this field would talk like that.
If you purport to be an expert on CSS, you should at least try to present
something that makes it credible, such as citing some sites or articles you
have authored. Signatures are a suitable tool for that.
> I do not follow.
I can see that.
> Both natural languages and programming languages are
> languages,
So you refuse to admit that your use of the word "language" was metaphorical
(as was the use of "know" that you criticized), which means that you are
seriously confused. It is common to use metaphors without realizing they are
metaphors; but if you don't see that they are metaphors after an
explanation, then you are deep stuck in the metaphor that obscures your
thinking.
If is noteworthy that you quoted this challenge, yet did not make any move
to address it, even with a single tentative example:
"Think about writing a list of similarities between CSS, on
one hand, and languages proper (such as Swahili, Chinese, and Finnish) on
the other. How long a list could you produce while we wait? Or at all?"
> and of course they do not know anything.
CSS "knows" things in much the same sense as it is a "language".
>> Here's a stylesheet:
>>
>> * { line-height: 1.3; }
>>
>> What did I need to know about the rules of "the" markup language
>> when I wrote that? (The article "the" is in quotes, since a
>> stylesheet, especially like the one I gave as example, need not be
>> limited to use for one particular markup language.)
>
> Fallacy: Proof by example.
That's a fairly amusing way to refuse to discuss on a rational basis. If you
claim something and an unrefutable counterexample is given, you shout
"Fallacy: Proof by example."
> It may be a trivial issue for the both of us. It is not so trivial a
> point considering the amount of markup out there that claims to be
> XHTML and is not.
That's yet another irrelevant point. You seem to write about everything else
than the topic of discussion.
> Those who regard valid corrections as nitpicking might not have really
> understood what they are talking about in the first place.
You seem to refuse to discuss the issue at hand and babble about something
completely different. Corrections are relevant if they actually correct some
misconceptions, and you just added to the confusion if there was one, e.g.
by calling meta tags headers.
You seem to have absolutely nothing to reply to the substantial content of
my message, even the parts you quoted. I'm pretty sure this won't prevent
you from posting yet another such reply.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Certainly nobody I would consider a (if I may say so, fellow) expert
>> in this field would talk like that.
>
> If you purport to be an expert on CSS, you should at least try to present
> something that makes it credible, such as citing some sites or articles
> you have authored. Signatures are a suitable tool for that.
As much as the anonymous group of people you are referring as "experts" to
have not had their being labelled an "expert" by you being supported by
evidence, I do not need to.
>> Both natural languages and programming languages are
>> languages,
>
> So you refuse to admit that your use of the word "language" was
> metaphorical
Yes, because it was not. Nothing more than "cigar" is a metaphor
for "cigar".
>> and of course they do not know anything.
>
> CSS "knows" things in much the same sense as it is a "language".
It is impossible to disprove a wording without using that wording in the
argument somewhere. And yes, CSS *is* a language (not a natural one of
course, but that is beside the point). Do you really need proof?
,-<http://www.w3.org/TR/CSS21/>
|
| This specification defines Cascading Style Sheets, level 2 revision 1
| (CSS 2.1). CSS 2.1 is a style sheet language [...]
>>> Here's a stylesheet:
>>>
>>> * { line-height: 1.3; }
>>>
>>> What did I need to know about the rules of "the" markup language
>>> when I wrote that? (The article "the" is in quotes, since a
>>> stylesheet, especially like the one I gave as example, need not be
>>> limited to use for one particular markup language.)
>>
>> Fallacy: Proof by example.
>
> That's a fairly amusing way to refuse to discuss on a rational basis. If
> you claim something and an unrefutable counterexample is given, you shout
> "Fallacy: Proof by example."
I assumed you would see the fallacy then by yourself. For the record, one
needs to know the markup language this is designed for in order to write
this stylesheet, because the `line-height' attribute has different meanings
depending on whether the element satisfies one of block-level, table-cell,
table-caption, or inline-block, or one of inline-level, with inline-level
replaced being a special case. That is presuming the stylesheet is
supposed to make sense, of course.
>> It may be a trivial issue for the both of us. It is not so trivial a
>> point considering the amount of markup out there that claims to be
>> XHTML and is not.
>
> That's yet another irrelevant point.
No, it is relevant. If one does not know the markup language the stylesheet
is designed for, the stylesheet might prove ineffective or
counter-effective.
> You seem to write about everything else than the topic of discussion.
If so, you too.
> [snipped pointless ranting]
Get a life.
PointedEars
Jukka K. Korpela
> And yes, CSS *is* a language (not a natural
> one of course, but that is beside the point).
You still don't understand the word "metaphor", do you? Nobody called
languages "human languages" before people started using the word "language"
metaphorically.
> I assumed you would see the fallacy then by yourself.
The "fallacy of example", your interesting "logical" invention? Hardly.
> one needs to know the markup language this is designed for in
> order to write this stylesheet,
Not at all.
> because the `line-height' attribute
> has different meanings depending on whether the element satisfies one
> of block-level, table-cell, table-caption, or inline-block, or one of
> inline-level, with inline-level replaced being a special case.
No, it has just the same meaning. You could learn this from CSS
specifications. But thanks for playing. At least you tried to make a
relevant and on-topic argument. It was just a completely false one.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
dorayme
Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Both natural languages and programming languages are
> languages, and of course they do not know anything.
Don't be so sure!
<http://dorayme.netweaver.com.au/letters/proudZ.html>
--
dorayme
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Both natural languages and programming languages are
>> languages, and of course they do not know anything.
>
> Don't be so sure!
>
> <http://dorayme.netweaver.com.au/letters/proudZ.html>
YMMD :)
\\// PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> one needs to know the markup language this is designed for in
>> order to write this stylesheet,
>
> Not at all.
>
>> because the `line-height' attribute
>> has different meanings depending on whether the element satisfies one
>> of block-level, table-cell, table-caption, or inline-block, or one of
>> inline-level, with inline-level replaced being a special case.
>
> No, it has just the same meaning. You could learn this from CSS
> specifications.
,-<http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height>
|
| [...]
| On a block-level, table-cell, table-caption or inline-block element whose
| content is composed of inline-level elements, 'line-height' specifies the
| /minimal/ height of line boxes within the element. The minimum height
| consists of a minimum height above the block's baseline and a minimum
| depth below it, exactly as if each line box starts with a zero-width
| inline box with the block's font and line height properties (what TEX
| calls a "strut").
|
| On an inline-level element, 'line-height' specifies the height that is
| used in the calculation of the line box height (except for inline replaced
| elements, where the height of the box is given by the 'height' property).
> But thanks for playing. At least you tried to make a
> relevant and on-topic argument. It was just a completely false one.
Mirror, mirror ...
PointedEars
Ben C
[...]
> For the record, one needs to know the markup language this is designed
> for in order to write this stylesheet, because the `line-height'
> attribute has different meanings depending on whether the element
> satisfies one of block-level, table-cell, table-caption, or
> inline-block, or one of inline-level, with inline-level replaced being
> a special case.
I don't follow. You're right that line-height does different things on
blocks and inlines, but whether something's block or inline in this
sense doesn't depend on the markup language.
Line-height specifies a minimum height for line boxes if set on an
element that's display: block. But the element that's display: block can
perfectly well be a SPAN-- which is "inline" in the HTML sense of the
word.
In other words, what matters is what value it has for the CSS display
property, and that doesn't depend on the markup language, except by way
of the UA default stylesheet (although don't get Korpela started on
that, he thinks UA default stylesheets are merely a figment of the
imagination).
Ben C
> Thomas 'PointedEars' Lahn wrote:
>
>> And yes, CSS *is* a language (not a natural
>> one of course, but that is beside the point).
>
> You still don't understand the word "metaphor", do you? Nobody called
> languages "human languages" before people started using the word "language"
> metaphorically.
Perhaps not, but that doesn't make "language" in the sense of computer
languages a metaphor.
By that criterion almost every word would be a metaphor.
Thomas 'PointedEars' Lahn
> On 2009-12-03, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> [...]
>> For the record, one needs to know the markup language this is designed
>> for in order to write this stylesheet, because the `line-height'
>> attribute has different meanings depending on whether the element
>> satisfies one of block-level, table-cell, table-caption, or
>> inline-block, or one of inline-level, with inline-level replaced being
>> a special case.
>
> I don't follow. You're right that line-height does different things on
> blocks and inlines, but whether something's block or inline in this
> sense doesn't depend on the markup language.
But it does. The initial value of the `display' property and several other
properties depends on the layout engine, and at least in the case of HTML
and XHTML its rendering behavior is (probably indirectly) derived from the
Document Type Definition. For example, `P' is considered a "block element"
per default in CSS because per HTML DTD it can contain elements that are
also produced by %block (are block-level elements themselves); as such, it
is required for general proper rendering that the initial value of its
`display' property is `block'.
> Line-height specifies a minimum height for line boxes if set on an
> element that's display: block. But the element that's display: block can
> perfectly well be a SPAN-- which is "inline" in the HTML sense of the
> word.
And you need to know the layout engine and the DTD to know that formatting
the SPAN element with `display: block' would be necessary in the first
place. You also need to know that a SPAN element is an inline-level element
because any selectors like `span div' are not supposed to work regardless of
what the SPAN's `display' property is, because DIV is a block element and
cannot be contained in a SPAN element. No, a stylesheet is not independent
of the markup language it is used for at all.
> In other words, what matters is what value it has for the CSS display
> property, and that doesn't depend on the markup language, except by way
> of the UA default stylesheet (although don't get Korpela started on
> that, he thinks UA default stylesheets are merely a figment of the
> imagination).
The default stylesheet (even if such a thing is only implemented virtually)
and the DTD are key points for a stylesheet that *works*.
PointedEars
Andy Dingley
> For example, `P' is considered a "block element"
> per default in CSS because per HTML DTD it can contain elements that are
> also produced by %block (are block-level elements themselves);
No, the DTD (both Strict & Transitional) for <p> is that the content
is %inline; You can't nest <p>
<!ELEMENT P - O (%inline;)* -- paragraph -->
> as such, it
> is required for general proper rendering that the initial value of its
> `display' property is `block'.
Although your assumption might reasonably be used as a proof by
induction for <div> (also assuming the axiom that <div> can contain
other boxes) it's inapplicable for <p>. If <p> "requires" to be
rendered with a box, it's to do with its external box, not its
internal contained elements.
Ben C
> Ben C wrote:
>
>> On 2009-12-03, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> [...]
>>> For the record, one needs to know the markup language this is designed
>>> for in order to write this stylesheet, because the `line-height'
>>> attribute has different meanings depending on whether the element
>>> satisfies one of block-level, table-cell, table-caption, or
>>> inline-block, or one of inline-level, with inline-level replaced being
>>> a special case.
>>
>> I don't follow. You're right that line-height does different things on
>> blocks and inlines, but whether something's block or inline in this
>> sense doesn't depend on the markup language.
>
> But it does. The initial value of the `display' property and several other
> properties depends on the layout engine, and at least in the case of HTML
> and XHTML its rendering behavior is (probably indirectly) derived from the
> Document Type Definition.
That doesn't sound right. The CSS specification defines an initial value
for each property, that has absolutely nothing to do with document
language.
Then browsers typically override the initial values for various element
types using a UA default stylesheet for HTML (and possibly a slightly
different one for XHTML).
> For example, `P' is considered a "block element" per default in CSS
> because per HTML DTD it can contain elements that are also produced by
> %block (are block-level elements themselves);
That's not even true-- a P _can't_ contain block-level elements (in the
HTML sense of "block-level").
In other words, you can't put a DIV inside a P-- it's invalid HTML...
> as such, it is required for general proper rendering that the initial
> value of its `display' property is `block'.
...but even if it wasn't, CSS wouldn't care.
The requirements that certain elements can only contain things from
%block and certain others only things from %inline etc. exist only in
HTML and NOT in CSS.
In CSS it's perfectly defined what happens if you nest something that is
display: block inside something that is display: inline, or even
something that is display: table-row inside something that is display:
inline-block. It's all valid and defined (by way of anonymous boxes).
>> Line-height specifies a minimum height for line boxes if set on an
>> element that's display: block. But the element that's display: block can
>> perfectly well be a SPAN-- which is "inline" in the HTML sense of the
>> word.
>
> And you need to know the layout engine and the DTD to know that formatting
> the SPAN element with `display: block' would be necessary in the first
> place.
Why? A SPAN is just display: block if some stylesheet somewhere sets it
to that.
> You also need to know that a SPAN element is an inline-level element
> because any selectors like `span div' are not supposed to work
> regardless of what the SPAN's `display' property is, because DIV is a
> block element and cannot be contained in a SPAN element. No, a
> stylesheet is not independent of the markup language it is used for at
> all.
"span div" works in principle in CSS, it just will never end up being
applied to a valid HTML document.
In fact, you can perfectly put a DIV inside a SPAN using DOM
(appendChild etc.). I believe that ought to work, and the span div
selector will then match it.
There's been some dispute about this before, but my view is that HTML
validity is not required of bits of documents constructed by DOM, but if
it is, I'd be interested to know where in which spec this is stated.
Jukka K. Korpela
> The initial value of the `display' property and several
> other properties depends on the layout engine,
No they do not. The initial values are defined in the CSS specifications.
You have misunderstood the concept "initial value".
> and at least in the
> case of HTML and XHTML its rendering behavior is (probably
> indirectly) derived from the Document Type Definition.
No it is not. DTDs describe (part of) syntax, nothing more. It does not
postulate or dictate any visual rendering, explicitly or implicitly.
> For example,
> `P' is considered a "block element" per default in CSS
No it isn't.
> because per
> HTML DTD it can contain elements that are also produced by %block
> (are block-level elements themselves);
You have misunderstood what DTDs are. You also fail to see that names of
auxiliary symbols like "%block" are just names; "%block" in HTML 4.01 spec
is just shorthand for
P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS
> No, a stylesheet is not independent of the markup language
> it is used for at all.
Since you have demonstrated fundamental mistakes in your understanding of
both CSS and markup, I don't think you can be qualified in matters of their
relationship to each other.
> The default stylesheet (even if such a thing is only implemented
> virtually) and the DTD are key points for a stylesheet that *works*.
The default stylesheets are browser-dependent and need not be documented,
and they may change without notice. This is somewhat unfortunate, but it's
just part of the old issue that _browser behavior_ is not prescribed and is
often hard to describe.
DTDs are just a technical way to describe syntax, and the great majority of
HTML authors (including you) cannot read DTDs correctly. They don't need to
do that either, since there are more digestible ways to describe the allowed
structure of markup.
What matters is the structure of documents that the style sheet will be used
for.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Thomas 'PointedEars' Lahn
> On 8 Dec, 16:02, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
>> For example, `P' is considered a "block element"
>> per default in CSS because per HTML DTD it can contain elements that are
>> also produced by %block (are block-level elements themselves);
>
> No, the DTD (both Strict & Transitional) for <p> is that the content
> is %inline; You can't nest <p>
>
> <!ELEMENT P - O (%inline;)* -- paragraph -->
Thanks, my bad example.
>> as such, it
>> is required for general proper rendering that the initial value of its
>> `display' property is `block'.
>
> Although your assumption might reasonably be used as a proof by
> induction for <div> (also assuming the axiom that <div> can contain
> other boxes) it's inapplicable for <p>. If <p> "requires" to be
> rendered with a box, it's to do with its external box, not its
> internal contained elements.
I stand corrected, but that does not invalidate my argument. See my reply
to "Ben C" for details.
PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> The initial value of the `display' property and several
>> other properties depends on the layout engine,
>
> No they do not. The initial values are defined in the CSS specifications.
> You have misunderstood the concept "initial value".
I have not. In several cases the initial value of a CSS property is
specified as "auto" in a way that leaves the effective display to the user
agent, or is specified explicitly as "depends on user agent". I am willing
to concede that 'display' was a bad example, though, as that does not apply
there.
>> and at least in the
>> case of HTML and XHTML its rendering behavior is (probably
>> indirectly) derived from the Document Type Definition.
>
> No it is not. DTDs describe (part of) syntax, nothing more. It does not
> postulate or dictate any visual rendering, explicitly or implicitly.
As a standalone entity, yes. However, I referred to HTML and XHTML here,
where the Specification prose defines at least implicitly how an element
should be rendered, and the DTD where it may occur. Other markup
specifications (like SVG, MathML, etc.) make similar provisions, and I
consider it a mistake to view a DTD as a standalone entity. It needs to be
understood in the context of the rest of the Specification instead. That is
probably, and IMHO most certainly, what UA vendors did when they defined
their default stylesheets or equivalents thereof.
>> For example, `P' is considered a "block element" per default in CSS
>
> No it isn't.
But it is. The example in parentheses is not normative of course
(and a coincidence, if you can believe that), but the definition is:
,-<http://www.w3.org/TR/CSS21/visuren.html#block-level>
|
| Block-level elements are those elements of the source document that are
| formatted visually as blocks (e.g., paragraphs). Several values of the
| 'display' property make an element block-level: 'block', 'list-item', and
| 'run-in' (part of the time; see run-in boxes), and 'table'.
A `P' element (which happens to stand for a paragraph in HTML) is formatted
visually as a block by default. The `display: block' in the UAs default
stylesheet would make sure of that (because the initial value is `display:
inline' instead.)
> [snip misunderstanding]
See my reply to "Ben C" for further possible re-evaluation of your
assessment.
PointedEars
Thomas 'PointedEars' Lahn
> On 2009-12-08, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Ben C wrote:
>>> On 2009-12-03, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>> [...]
>>>> For the record, one needs to know the markup language this is designed
>>>> for in order to write this stylesheet, because the `line-height'
>>>> attribute has different meanings depending on whether the element
>>>> satisfies one of block-level, table-cell, table-caption, or
>>>> inline-block, or one of inline-level, with inline-level replaced being
>>>> a special case.
>>>
>>> I don't follow. You're right that line-height does different things on
>>> blocks and inlines, but whether something's block or inline in this
>>> sense doesn't depend on the markup language.
>>
>> But it does. The initial value of the `display' property and several
>> other properties depends on the layout engine, and at least in the case
>> of HTML and XHTML its rendering behavior is (probably indirectly) derived
>> from the Document Type Definition.
>
> That doesn't sound right. The CSS specification defines an initial value
> for each property, that has absolutely nothing to do with document
> language.
But it has:
| Note that although the initial value of 'display' is 'inline', rules in
| the user agent's default style sheet may override this value. See the
| sample style sheet for HTML 4 in the appendix.
> Then browsers typically override the initial values for various element
> types using a UA default stylesheet for HTML (and possibly a slightly
> different one for XHTML).
Guess how they arrived at the value in the default style sheet, provided
there is such a thing in the respective UA.
>> For example, `P' is considered a "block element" per default in CSS
>> because per HTML DTD it can contain elements that are also produced by
>> %block (are block-level elements themselves);
>
> That's not even true-- a P _can't_ contain block-level elements (in the
> HTML sense of "block-level").
>
> In other words, you can't put a DIV inside a P-- it's invalid HTML...
Ah yes, bad example. You know what I mean, though (take DIV as a
replacement example).
>> as such, it is required for general proper rendering that the initial
>> value of its `display' property is `block'.
>
> ...but even if it wasn't, CSS wouldn't care.
Yes, "it" would. It changes the meaning of several properties. I had
already showed one example.
> The requirements that certain elements can only contain things from
> %block and certain others only things from %inline etc. exist only in
> HTML and NOT in CSS.
Of course not. They do have an impact on CSS, though, that cannot be
reasonably denied.
> In CSS it's perfectly defined what happens if you nest something that is
> display: block inside something that is display: inline, or even
> something that is display: table-row inside something that is display:
> inline-block. It's all valid and defined (by way of anonymous boxes).
However, you are ignoring here that invalid markup does not always end up in
the document tree as it was written, which has an impact on the effect that
a stylesheet has. BTDT.
Vice-versa, a non-trivial interoperable stylesheet must follow the rules for
element nesting that the markup language defines in order to be effective.
It must follow the case rules that a markup language defines (e.g., selector
`P' works in HTML, but not in XHTML). It must follow the attribute rules
that the markup language defines (e.g., the ID selector only works on
elements with an ID-type attribute). In short, it is not independent of the
markup language in which the document is written that is formatted, which
was debated by Jukka.
>>> Line-height specifies a minimum height for line boxes if set on an
>>> element that's display: block. But the element that's display: block can
>>> perfectly well be a SPAN-- which is "inline" in the HTML sense of the
>>> word.
>>
>> And you need to know the layout engine and the DTD to know that
>> formatting the SPAN element with `display: block' would be necessary in
>> the first place.
>
> Why? A SPAN is just display: block if some stylesheet somewhere sets it
> to that.
In order to know that *you* *need* to set `display: block' for a SPAN
element, you need to know that it is `display: inline' by default. (Else
you could omit the declaration and be fine.) "default" meaning not only its
initial value, but what the user agent (per its default stylesheet, which is
purely a specification mechanism that we take for granted here) makes of it.
And guess how it is decided how that default stylesheet should look like --
could it be by any chance that a markup language, perhaps HTML or XHTML, has
something to do with it?
>> You also need to know that a SPAN element is an inline-level element
>> because any selectors like `span div' are not supposed to work
>> regardless of what the SPAN's `display' property is, because DIV is a
>> block element and cannot be contained in a SPAN element. No, a
>> stylesheet is not independent of the markup language it is used for at
>> all.
>
> "span div" works in principle in CSS, it just will never end up being
> applied to a valid HTML document.
So we agree that it matters for the stylesheet whether the markup document
formatted with it is Valid or not. But validity is defined in terms of
syntax, which is defined for SGML/XML-based document types in DTDs.
In particular, if the HTML document is not Valid, there are user agents
where some wrong stylesheet selectors will be applied (e.h., MSHTML), and
there are user agents where they will not (e.g., Gecko), on the same
document. As a rule of thumb, such a selector does not belong into an
interoperable stylesheet.
Likewise, if the document is not Valid but its stylesheet is, it depends on
the user agent what the effect of a stylesheet will be. I had a case where
a stylesheet was Valid but the (generated) markup was not. As a result, the
formatting differed between MSHTML, which took the invalid markup for
granted, and Gecko, where error-correction took place which allowed
different selectors to match in each case.
Bottom line again: A stylesheet is _not_ independent of the document it
formats or of the markup language that this document is written in.
> In fact, you can perfectly put a DIV inside a SPAN using DOM
> (appendChild etc.). I believe that ought to work, and the span div
> selector will then match it.
Reasonable DOM implementations, especially XML-compliant ones, throw an
exception here. Others do not.
> There's been some dispute about this before, but my view is that HTML
> validity is not required of bits of documents constructed by DOM, but if
> it is, I'd be interested to know where in which spec this is stated.
W3C DOM Level 2 HTML makes provisions for XHTML, and I would be surprised if
the XML DOM Specification would not do so for XML.
PointedEars
Thomas 'PointedEars' Lahn
> Ben C wrote:
>> There's been some dispute about this before, but my view is that HTML
>> validity is not required of bits of documents constructed by DOM, but if
>> it is, I'd be interested to know where in which spec this is stated.
>
> W3C DOM Level 2 HTML makes provisions for XHTML,
To be found here:
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642>
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-882764350>
> and I would be surprised if the XML DOM Specification would not do so for
> XML.
Apparently, there is no explicit XML DOM Specification but W3C DOM Level 2+
Core applies for both HTML DOM and XML DOM. Here for Node::appendChild():
,-<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-184E7107>
|
| [...]
|
| Exceptions
|
| DOMException HIERARCHY_REQUEST_ERR: Raised if this node is of a type
| that does not allow children of the type of the newChild
| node, or if the node to append is one of this node's
| ancestors or this node itself, or if this node is of type
| Document and the DOM application attempts to append a
| second DocumentType or Element node.
(The first and third cases are relevant regarding validity.)
DOM Specifications for other markup languages (like the SVG DOM of the SVG
1.1 Specification [SVGDOM]) specify similar restrictions in order to ensure
that the resulting document tree (and therefore, its serialization) is
Valid.
But, AISB, it depends on the implementation to honor that.
X-Post & F'up2 comp.lang.javascript
PointedEars
___________
[SVGDOM] <http://www.w3.org/TR/SVG/svgdom.html>
Johannes Koch
> There's been some dispute about this before, but my view is that HTML
> validity is not required of bits of documents constructed by DOM, but if
> it is, I'd be interested to know where in which spec this is stated.
HTML 4.01 recommendation, section "18.2.4 Dynamic modification of
documents" (<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>):
HTML documents are constrained to conform to the HTML DTD both before
and after processing any SCRIPT elements.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Ben C
> Jukka K. Korpela wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> The initial value of the `display' property and several
>>> other properties depends on the layout engine,
>>
>> No they do not. The initial values are defined in the CSS specifications.
>> You have misunderstood the concept "initial value".
>
> I have not. In several cases the initial value of a CSS property is
> specified as "auto" in a way that leaves the effective display to the user
> agent, or is specified explicitly as "depends on user agent".
Name a few. In most cases I think of, the behaviour of auto is fairly
strictly defined.
line-height: auto leaves a little bit of latitude to the UA, but I can't
think of any others offhand.
Jukka K. Korpela
> On 2009-12-09, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Jukka K. Korpela wrote:
>>
>>> Thomas 'PointedEars' Lahn wrote:
>>>> The initial value of the `display' property and several
>>>> other properties depends on the layout engine,
>>>
>>> No they do not. The initial values are defined in the CSS
>>> specifications. You have misunderstood the concept "initial value".
>>
>> I have not. In several cases the initial value of a CSS property is
>> specified as "auto" in a way that leaves the effective display to
>> the user agent, or is specified explicitly as "depends on user
>> agent".
>
> Name a few. In most cases I think of, the behaviour of auto is fairly
> strictly defined.
I think we can mostly ignore what Thomas 'RedEars' Lahn writes, as he seems
to be in the process of admitting he's been completely lost but still just
apologizes his mistakes as if they were just isolated details. It's not easy
to admit you've been wrong, especially when you have been so convinced and
eager to share your views.
The quick index to properties at
http://www.w3.org/TR/CSS2/propidx.html
tells that the only basic properties (as opposite to shorthands) for which
the initial values "depends on user agent" are color, font-family, quotes,
and voice-family. The last one is best ignored. For the others, there is not
much variation in practice: the initial values are normally black, Times New
Roman, and "", though for font-family, some browser vendors have their own
preferences.
This has nothing to do with the initial value for the display property,
which is unambiguously inline.
And for every property, the CSS specification defines the initial value. For
three (or nominally four) properties, it defines the initial value as
depending on user agent, i.e. each user agent must provide a specific
initial value. This value does not depend on the element - it is by
definition the same for all elements.
> line-height: auto leaves a little bit of latitude to the UA, but I
> can't think of any others offhand.
line-height: auto is a syntax error; you meant line-height: normal, or
rather the fact that the initial value of line-height is normal. The initial
value _is_ normal, independently of browser. This must not be confused with
the fact that the meaning of this value is special, explicitly described as
giving browsers latitude in selecting the used value - and this applies
whether normal is used since line-height is not specified at all in
stylesheets or due to explicitly setting it to normal (perhaps in order to
prevent inheritance).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Ben C
[...]
>> line-height: auto leaves a little bit of latitude to the UA, but I
>> can't think of any others offhand.
>
> line-height: auto is a syntax error; you meant line-height: normal, or
> rather the fact that the initial value of line-height is normal.
Sorry, yes you are quite right.
> The initial value _is_ normal, independently of browser.
Indeed, although I thought Pointed Ears was arguing that properties
whose initial value was auto had UA-dependent implementations.
> This must not be confused with the fact that the meaning of this value
> is special, explicitly described as giving browsers latitude in
> selecting the used value - and this applies whether normal is used
> since line-height is not specified at all in stylesheets or due to
> explicitly setting it to normal (perhaps in order to prevent
> inheritance).
Yes.
Ben C
> Thomas 'PointedEars' Lahn wrote:
>
>> Ben C wrote:
>>> There's been some dispute about this before, but my view is that HTML
>>> validity is not required of bits of documents constructed by DOM, but if
>>> it is, I'd be interested to know where in which spec this is stated.
> Apparently, there is no explicit XML DOM Specification but W3C DOM Level 2+
> Core applies for both HTML DOM and XML DOM. Here for Node::appendChild():
>
> ,-<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-184E7107>
>|
>| [...]
>|
>| Exceptions
>|
>| DOMException HIERARCHY_REQUEST_ERR: Raised if this node is of a type
>| that does not allow children of the type of the newChild
>| node, or if the node to append is one of this node's
>| ancestors or this node itself, or if this node is of type
>| Document and the DOM application attempts to append a
>| second DocumentType or Element node.
>
> (The first and third cases are relevant regarding validity.)
>
> DOM Specifications for other markup languages (like the SVG DOM of the SVG
> 1.1 Specification [SVGDOM]) specify similar restrictions in order to ensure
> that the resulting document tree (and therefore, its serialization) is
> Valid.
>
> But, AISB, it depends on the implementation to honor that.
But isn't that just for things like trying to give a #text node
children? I didn't think it was supposed to enforce validity in the much
stricter HTML sense.
And I'm pretty sure you don't get a HIERARCHY_REQUEST_ERR in any of the
main browsers if you put a div inside a span with appendChild.
Ben C
> Ben C schrieb:
>> There's been some dispute about this before, but my view is that HTML
>> validity is not required of bits of documents constructed by DOM, but if
>> it is, I'd be interested to know where in which spec this is stated.
>
> HTML 4.01 recommendation, section "18.2.4 Dynamic modification of
> documents" (<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>):
>
> HTML documents are constrained to conform to the HTML DTD both before
> and after processing any SCRIPT elements.
But there's a bit of a nuance here. If the script writes to the document
with document.write, then, sure, whatever it writes has to conform to
the DTD.
But what if it just stuffs things in to the DOM tree with appendChild
and friends? There's no "generated CDATA" in that case to be
re-evaluated, and HTML was not used in the process.
Ben C
> Ben C wrote:
>
>> On 2009-12-08, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>> But it does. The initial value of the `display' property and several
>>> other properties depends on the layout engine, and at least in the case
>>> of HTML and XHTML its rendering behavior is (probably indirectly) derived
>>> from the Document Type Definition.
>>
>> That doesn't sound right. The CSS specification defines an initial value
>> for each property, that has absolutely nothing to do with document
>> language.
>
> But it has:
>
>| Note that although the initial value of 'display' is 'inline', rules in
>| the user agent's default style sheet may override this value. See the
>| sample style sheet for HTML 4 in the appendix.
>
>> Then browsers typically override the initial values for various element
>> types using a UA default stylesheet for HTML (and possibly a slightly
>> different one for XHTML).
>
> Guess how they arrived at the value in the default style sheet, provided
> there is such a thing in the respective UA.
Those aren't initial values though, in the technical sense, but what one
might call "default" values-- the UA has a default stylesheet for HTML
that sets things like display: block on P.
Initial values are per property and defined in the CSS spec. Not my
terminology, just that of the spec.
[...]
>>> as such, it is required for general proper rendering that the initial
>>> value of its `display' property is `block'.
>>
>> ...but even if it wasn't, CSS wouldn't care.
>
> Yes, "it" would. It changes the meaning of several properties. I had
> already showed one example.
Obviously a P needs to be display: block to look like a paragraph, if
that's what you're saying.
>> The requirements that certain elements can only contain things from
>> %block and certain others only things from %inline etc. exist only in
>> HTML and NOT in CSS.
>
> Of course not. They do have an impact on CSS, though, that cannot be
> reasonably denied.
Only indirectly.
>> In CSS it's perfectly defined what happens if you nest something that is
>> display: block inside something that is display: inline, or even
>> something that is display: table-row inside something that is display:
>> inline-block. It's all valid and defined (by way of anonymous boxes).
>
> However, you are ignoring here that invalid markup does not always end up in
> the document tree as it was written, which has an impact on the effect that
> a stylesheet has. BTDT.
I never ignore that. That's the reason why I advise people to validate
(even though many of the validity requirements of HTML seem to me
personally arcane and pointless).
> Vice-versa, a non-trivial interoperable stylesheet must follow the
> rules for element nesting that the markup language defines in order to
> be effective. It must follow the case rules that a markup language
> defines (e.g., selector `P' works in HTML, but not in XHTML). It must
> follow the attribute rules that the markup language defines (e.g., the
> ID selector only works on elements with an ID-type attribute). In
> short, it is not independent of the markup language in which the
> document is written that is formatted, which was debated by Jukka.
And even more trivially, it must use only the actual elements present in
the markup language. To be effective that is.
[...]
>> "span div" works in principle in CSS, it just will never end up being
>> applied to a valid HTML document.
>
> So we agree that it matters for the stylesheet whether the markup document
> formatted with it is Valid or not. But validity is defined in terms of
> syntax, which is defined for SGML/XML-based document types in DTDs.
Except of course many browsers will actually let through things like
divs inside spans (if not that, plenty of other invalid things, but I
think they do actually allow that), upon which span div will work as
expected.
[...]
> Likewise, if the document is not Valid but its stylesheet is, it depends on
> the user agent what the effect of a stylesheet will be. I had a case where
> a stylesheet was Valid but the (generated) markup was not. As a result, the
> formatting differed between MSHTML, which took the invalid markup for
> granted, and Gecko, where error-correction took place which allowed
> different selectors to match in each case.
Yup, reason #38413 to always validate.
> Bottom line again: A stylesheet is _not_ independent of the document it
> formats or of the markup language that this document is written in.
The effect of it is not, but its correctness as a stylesheet is. But the
effects of lots of things are dependent on a lot of other things, and
this can't be used an excuse to conflate the entire universe into a
single congealed concept.
Johannes Koch
> On 2009-12-09, Johannes Koch <ko...@w3development.de> wrote:
>> Ben C schrieb:
>>> There's been some dispute about this before, but my view is that HTML
>>> validity is not required of bits of documents constructed by DOM, but if
>>> it is, I'd be interested to know where in which spec this is stated.
>> HTML 4.01 recommendation, section "18.2.4 Dynamic modification of
>> documents" (<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>):
>>
>> HTML documents are constrained to conform to the HTML DTD both before
>> and after processing any SCRIPT elements.
>
> But there's a bit of a nuance here. If the script writes to the document
> with document.write, then, sure, whatever it writes has to conform to
> the DTD.
Why is this sure?
> But what if it just stuffs things in to the DOM tree with appendChild
> and friends? There's no "generated CDATA" in that case to be
> re-evaluated,
True
> and HTML was not used in the process.
Well, you to add/change the HTML (DOM), that the HTML user agent has to
deal with. So I think the quoted passage covers any modification by
scripting.
Andy Dingley
> But what if it just stuffs things in to the DOM tree with appendChild
> and friends?
DOMs (in the general sense) are expected to be analogous to a well-
formed document. The DOM methods will throw exceptions if they're used
in a way to break this well-formedness.
DOMs are _NOT_ required to represent valid or conformant documents,
according to a doctype or prose standard. The DOM methods may allow
you to create non-valid documents, even for a DOM that is already
associated with a doctype, and are not required to throw exceptions
for this (I'm not even aware that such exceptions are defined by the
DOM standard, although they might have been added since I last
looked).
The DOM _MAY_ support a mechanism to bind to a doctype or schema, and
to validate against that doctype. If the application wishes to
automatically check or maintain such validity though, it should use
these DOM methods to check and act accordingly, it shouldn't assume
that the DOM methods will do it for it.
Writing DOM specifications is a hard task, because the W3C are forced
to try and resolve the contradictory legacy positions of both HTML and
XML.
Ben C
> Ben C schrieb:
>> On 2009-12-09, Johannes Koch <ko...@w3development.de> wrote:
>>> Ben C schrieb:
>>>> There's been some dispute about this before, but my view is that HTML
>>>> validity is not required of bits of documents constructed by DOM, but if
>>>> it is, I'd be interested to know where in which spec this is stated.
>>> HTML 4.01 recommendation, section "18.2.4 Dynamic modification of
>>> documents" (<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>):
>>>
>>> HTML documents are constrained to conform to the HTML DTD both before
>>> and after processing any SCRIPT elements.
>>
>> But there's a bit of a nuance here. If the script writes to the document
>> with document.write, then, sure, whatever it writes has to conform to
>> the DTD.
>
> Why is this sure?
Because the spec you helpfully linked to said so :)
>> But what if it just stuffs things in to the DOM tree with appendChild
>> and friends? There's no "generated CDATA" in that case to be
>> re-evaluated,
>
> True
>
>> and HTML was not used in the process.
>
> Well, you to add/change the HTML (DOM), that the HTML user agent has to
> deal with. So I think the quoted passage covers any modification by
> scripting.
I think Andy Dingley is right: a tree built with appendChild has only
got to be well-formed, not valid according to any DTD. Certainly this is
what browsers did last time I checked.
Johannes Koch
> On 2009-12-10, Johannes Koch <ko...@w3development.de> wrote:
>> Ben C schrieb:
>>> On 2009-12-09, Johannes Koch <ko...@w3development.de> wrote:
>>>> Ben C schrieb:
>>>>> There's been some dispute about this before, but my view is that HTML
>>>>> validity is not required of bits of documents constructed by DOM, but if
>>>>> it is, I'd be interested to know where in which spec this is stated.
>>>> HTML 4.01 recommendation, section "18.2.4 Dynamic modification of
>>>> documents" (<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>):
>>>>
>>>> HTML documents are constrained to conform to the HTML DTD both before
>>>> and after processing any SCRIPT elements.
>>> But there's a bit of a nuance here. If the script writes to the document
>>> with document.write, then, sure, whatever it writes has to conform to
>>> the DTD.
>> Why is this sure?
>
> Because the spec you helpfully linked to said so :)
It says, that HTML documents to conform to the HTML DTD both before and
after processing _any_ SCRIPT elements. This is not restricted to
document.write().
>>> But what if it just stuffs things in to the DOM tree with appendChild
>>> and friends? There's no "generated CDATA" in that case to be
>>> re-evaluated,
>> True
>>
>>> and HTML was not used in the process.
>> Well, you to add/change the HTML (DOM), that the HTML user agent has to
>> deal with. So I think the quoted passage covers any modification by
>> scripting.
>
> I think Andy Dingley is right: a tree built with appendChild has only
> got to be well-formed, not valid according to any DTD.
That may be correct from a general DOM perspective.
> Certainly this is
> what browsers did last time I checked.
Browsers don't throw exceptions on invalid source code. Why should they
do so when creating invalid HTML by DOM manipulation? What is the
benefit of validity, if it only refers to the initial source code? Why
should it be conforming to have valid HTML source code and create all
kinds of stupid invalid things by DOM manipulation?
Ben C
> Ben C schrieb:
>> On 2009-12-10, Johannes Koch <ko...@w3development.de> wrote:
>>> Ben C schrieb:
>>>> On 2009-12-09, Johannes Koch <ko...@w3development.de> wrote:
>>>>> Ben C schrieb:
>>>>>> There's been some dispute about this before, but my view is that HTML
>>>>>> validity is not required of bits of documents constructed by DOM, but if
>>>>>> it is, I'd be interested to know where in which spec this is stated.
>>>>> HTML 4.01 recommendation, section "18.2.4 Dynamic modification of
>>>>> documents" (<http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>):
>>>>>
>>>>> HTML documents are constrained to conform to the HTML DTD both before
>>>>> and after processing any SCRIPT elements.
>>>> But there's a bit of a nuance here. If the script writes to the document
>>>> with document.write, then, sure, whatever it writes has to conform to
>>>> the DTD.
>>> Why is this sure?
>>
>> Because the spec you helpfully linked to said so :)
>
> It says, that HTML documents to conform to the HTML DTD both before and
> after processing _any_ SCRIPT elements. This is not restricted to
> document.write().
But one could argue that appendChild is not modifying an HTML document.
It's modifying a DOM tree (that happened to originate from an HTML
document perhaps, but that was a long time ago and we have forgotten
about it).
[...]
>> I think Andy Dingley is right: a tree built with appendChild has only
>> got to be well-formed, not valid according to any DTD.
>
> That may be correct from a general DOM perspective.
>
>> Certainly this is
>> what browsers did last time I checked.
>
> Browsers don't throw exceptions on invalid source code.
HTML doesn't have exceptions, so you wouldn't expect them to. The
mechanism there instead is that they do something undefined. But DOM
errors do result in exceptions, so if something's an error, you would
expect to get an exception.
> Why should they do so when creating invalid HTML by DOM manipulation?
> What is the benefit of validity, if it only refers to the initial
> source code?
For things other than normal browsers to be able to process the markup
and thus for it to make sense. That requirement doesn't exist of stuff
cobbled together with appendChild-- there is no markup in that case.
> Why should it be conforming to have valid HTML source code and create
> all kinds of stupid invalid things by DOM manipulation?
Stupid invalid things get a bit of a bad press, a bit like carbon
dioxide. What's actually wrong with a document structure that only
exists inside a browser that doesn't conform to HTML validity rules?
HTML validity is not necessary for proper rendering by a CSS user agent
or for Javascript.
The most pressing practical reason to validate is so that you avoid the
minefield of different browsers' undefined broken-HTML-patching-up
behaviour. But so long as they're not doing that, which they're not on
whatever you construct with appendChild, because they don't care, it
doesn't matter.
The more theoretical reasons for validity seem to me only to apply to
the marked-up document not to the rendered document.