From ian at hixie.ch Fri Apr 1 01:57:03 2005 From: ian at hixie.ch (Ian Hickson) Date: Fri, 1 Apr 2005 09:57:03 +0000 (UTC) Subject: [whatwg]

to

in In-Reply-To: <424CD1C4.4090607@myrealbox.com> References: <424BCBBE.2040308@cam.ac.uk> <424CAB13.1040709@myrealbox.com> <424CD1C4.4090607@myrealbox.com> Message-ID: On Thu, 31 Mar 2005, dolphinling wrote: > > |
> |
F
2.2. F > |
G
2.3. G > |
H
2.4. H > |
(part of section started by H) > |
...
(part of section started by H) > > If one were to explicitly include section tags around H here, where > would they go? It can't start before the
, because then it would > include F and G, but it can't start inside the
because then it > would break nesting. Oh, sure. You can't (always) use section elements to indicate the sectioning of legacy headers. Is it a requirement that you should be able to? What's the use case? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mpt at myrealbox.com Fri Apr 1 02:17:44 2005 From: mpt at myrealbox.com (Matthew Thomas) Date: Fri, 01 Apr 2005 22:17:44 +1200 Subject: [whatwg]
to
in In-Reply-To: References: <424BCBBE.2040308@cam.ac.uk> <424BEBFF.1080302@myrealbox.com> <424C177E.5030508@myrealbox.com> Message-ID: <424D1FC7.4000705@myrealbox.com> Ian Hickson wrote: >... > Note that the difference between and <h1> is not that <title> > is expected to include author information or whatever. You personally may not expect it, but that is the inevitable and unsurprising effect of it being used as "a context-free label to be used to describe the page elsewhere", in the absence of simply-specified and -supported markup for author, publisher, parent, and so on. > The example I gave earlier, of a Wikipedia page, shows the difference > I meant: > > <title>Main Page - Wikipedia, the Free Encyclopedia > ... >
Main Page
That example shows what I was talking about: being used to contain non-title data -- the publisher in this case -- separated by arbitrary (and therefore difficult-to-parse) punctuation from the title itself. > Another example: > > <title>Introduction to the mating rituals of bees > ... >
Introduction
And that's an unrealistic example, because it's treating two definitions of the word "Introduction" as if they were the same. (As a heading by itself, "Introduction" means an introductory section; but "Introduction to X" means a basic presentation of X.) As you collect more realistic examples, you'll find that they follow the pattern I described. > The point is that the has to stand alone and represent the > document when taken out of context, whereas the <h1> is the header of > a document _in the context of the page_, i.e. when people already know > what the basic subject area is. > > Thus the <title> is not in any sense the parent of the <h1> or other > headers. Not in Web pages designed to work with HTML 4 browsers, no. But if you're requiring new browsers to present some rel= values, you could take advantage of that to let <title> really be a title. > > It is a bad idea for the meaning of an element to be markedly > > different from the meaning of its name. That is likely to cause > > confusion, non-conformance, and disrespect for the spec in general. > > While I agree with this in general, and while I am aware of a huge > number of cases where the HTML language faito follow ls this design > principle, I don't see its relevance in this particular case. The relevance is that it is exactly what you were planning to do with <title>. > > Authors have been encouraged to misuse <title> so far for a > > different reason: the lack of a well-defined standard for presenting > > the other information they want shown in document summaries. So a > > better idea would be to explicitly define a very limited number of > > rel= attributes (as you already plan to do) to contain the non-title > > data that authors most often put in <title> -- mainly author and > > publisher -- and perhaps allow the rel= attribute to be placed in > > elements other than <link> and <a>. > > While this sounds like a good idea in principle, I don't see how it > affects my point (in terms of the examples above). The point is that you can do that to avoid entrenching a mismatch between the meaning of the <title> element and the meaning of its name. -- Matthew Thomas http://mpt.net.nz/ From ian at hixie.ch Fri Apr 1 02:58:12 2005 From: ian at hixie.ch (Ian Hickson) Date: Fri, 1 Apr 2005 10:58:12 +0000 (UTC) Subject: [whatwg] <h1> to <h6> in <body> In-Reply-To: <424D1FC7.4000705@myrealbox.com> References: <Pine.LNX.4.61.0503302359150.25644@dhalsim.dreamhost.com> <424BCBBE.2040308@cam.ac.uk> <Pine.LNX.4.61.0503311009300.25644@dhalsim.dreamhost.com> <424BEBFF.1080302@myrealbox.com> <Pine.LNX.4.61.0503311228200.25644@dhalsim.dreamhost.com> <424C177E.5030508@myrealbox.com> <Pine.LNX.4.61.0503311540350.13120@dhalsim.dreamhost.com> <424D1FC7.4000705@myrealbox.com> Message-ID: <Pine.LNX.4.61.0504011028380.32456@dhalsim.dreamhost.com> On Fri, 1 Apr 2005, Matthew Thomas wrote: > > > Another example: > > > > <title>Introduction to the mating rituals of bees > > ... > >
Introduction
> > And that's an unrealistic example, because it's treating two definitions > of the word "Introduction" as if they were the same. (As a heading by > itself, "Introduction" means an introductory section; but "Introduction > to X" means a basic presentation of X.) Sorry, that was a bad example indeed. I should have written: Introduction to The Mating Rituals of Bees ...
Introduction
...(as in, the site is "The Mating Rituals of Bees"). Another related example: Dances used during bee mating rituals ...
The Dances
The point is the is doing a completely different job than the <h1>. Their jobs are related, naturally, but they one cannot be replaced by the other. > As you collect more realistic examples, you'll find that they follow the > pattern I described. While I agree that many real-world examples include author and publisher metadata in their titles, I do not agree that this is the be all and end all of differences between <h1> and <title>. > > Thus the <title> is not in any sense the parent of the <h1> or other > > headers. > > Not in Web pages designed to work with HTML 4 browsers, no. But if > you're requiring new browsers to present some rel= values, you could > take advantage of that to let <title> really be a title. <title> _is_ a title. I don't understand what is wrong with the situation as it stands now. Why would we want to change the semantics of <title> between HTML4 and HTML5? How is what I describe <title> to be, not a title? Also, note that the backwards-compatibility thing is very relevant here. People aren't going to stop using <title> to include information that is important out-of-context simply because in newer UAs you might be lucky and have the UA generate that information for you. Legacy UAs still need that infotmation in the <title>. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mpt at myrealbox.com Sat Apr 2 02:34:17 2005 From: mpt at myrealbox.com (Matthew Thomas) Date: Sat, 02 Apr 2005 22:34:17 +1200 Subject: [whatwg] <h1> to <h6> in <body> In-Reply-To: <Pine.LNX.4.61.0504011028380.32456@dhalsim.dreamhost.com> References: <Pine.LNX.4.61.0503302359150.25644@dhalsim.dreamhost.com> <424BCBBE.2040308@cam.ac.uk> <Pine.LNX.4.61.0503311009300.25644@dhalsim.dreamhost.com> <424BEBFF.1080302@myrealbox.com> <Pine.LNX.4.61.0503311228200.25644@dhalsim.dreamhost.com> <424C177E.5030508@myrealbox.com> <Pine.LNX.4.61.0503311540350.13120@dhalsim.dreamhost.com> <424D1FC7.4000705@myrealbox.com> <Pine.LNX.4.61.0504011028380.32456@dhalsim.dreamhost.com> Message-ID: <424E7529.1050802@myrealbox.com> Ian Hickson wrote: >... > Sorry, that was a bad example indeed. I should have written: > > <title>Introduction to The Mating Rituals of Bees > ... >
Introduction
> > ....(as in, the site is "The Mating Rituals of Bees"). > > Another related example: > > Dances used during bee mating rituals > ... >
The Dances
This requires that the site be small enough for humans to bother assembling the in every page (rather than it being assembled by a CMS that doesn't know whether to use "to" or "used during" or "in" or whatever else), and that the author's carefulness and boredom thresholds are such that they will adapt the necessary context in the <title> for every page. That's highly implausible. Much more likely is what I described: the name of the site/subsite (which I too-loosely referred to as the "publisher"), either before or after the title of the page (and a parser can't tell which, making the document less useful), separated by some arbitrary punctuation (and a parser might well get that wrong if there's other punctuation in the components, making the document less useful again). > The point is the <title> is doing a completely different job than the > <h1>. Their jobs are related, naturally, but they one cannot be > replaced by the other. I wasn't suggesting they should be. >... > While I agree that many real-world examples include author and > publisher metadata in their titles, I do not agree that this is the be > all and end all of differences between <h1> and <title>. Good, that's a start. >... > > Not in Web pages designed to work with HTML 4 browsers, no. But if > > you're requiring new browsers to present some rel= values, you could > > take advantage of that to let <title> really be a title. > > <title> _is_ a title. I don't understand what is wrong with the > situation as it stands now. Why would we want to change the semantics > of <title> between HTML4 and HTML5? Because one day, I'd like search engines to be able to show me the title of a page in the same consistent position in a search result, and the name of the site (if available) in the same consistent position in a search result, and the name of the author (if available) in the same consistent position in a search result. They can't do that as long as <title> contains a subset of those components randomly chosen, randomly ordered, and randomly formatted. For that to happen, it would help slightly if the HTML specification stopped SHOULD-ing the current <title> behavior. It would help more if the HTML specification contained clear, straightforward markup for author and site name (and encouraged UAs to present this information when the document is taken out of context). > How is what I describe <title> to be, not a title? It's not not a title. (Awkward answer for an awkward question.) But what you describe <title> to be is only a subset of titles. > Also, note that the backwards-compatibility thing is very relevant > here. People aren't going to stop using <title> to include information > that is important out-of-context simply because in newer UAs you might > be lucky and have the UA generate that information for you. > Legacy UAs still need that infotmation in the <title>. Sure, it'll take a few years. I can wait. -- Matthew Thomas http://mpt.net.nz/ From ian at hixie.ch Sat Apr 2 02:52:42 2005 From: ian at hixie.ch (Ian Hickson) Date: Sat, 2 Apr 2005 10:52:42 +0000 (UTC) Subject: [whatwg] <h1> to <h6> in <body> In-Reply-To: <424E7529.1050802@myrealbox.com> References: <Pine.LNX.4.61.0503302359150.25644@dhalsim.dreamhost.com> <424BCBBE.2040308@cam.ac.uk> <Pine.LNX.4.61.0503311009300.25644@dhalsim.dreamhost.com> <424BEBFF.1080302@myrealbox.com> <Pine.LNX.4.61.0503311228200.25644@dhalsim.dreamhost.com> <424C177E.5030508@myrealbox.com> <Pine.LNX.4.61.0503311540350.13120@dhalsim.dreamhost.com> <424D1FC7.4000705@myrealbox.com> <Pine.LNX.4.61.0504011028380.32456@dhalsim.dreamhost.com> <424E7529.1050802@myrealbox.com> Message-ID: <Pine.LNX.4.61.0504021046080.26585@dhalsim.dreamhost.com> On Sat, 2 Apr 2005, Matthew Thomas wrote: > > > > [titles should include more context than h1s] > > This requires that the site be small enough for humans to bother > assembling the <title> in every page (rather than it being assembled by > a CMS that doesn't know whether to use "to" or "used during" or "in" or > whatever else), and that the author's carefulness and boredom > thresholds are such that they will adapt the necessary context in the > <title> for every page. That's highly implausible. Actually it happens all the time. Certainly it is as plausible as the fact that authors are going to be writing, say, valid markup. > I'd like search engines to be able to show me the title of a page in the > same consistent position in a search result, and the name of the site > (if available) in the same consistent position in a search result, and > the name of the author (if available) in the same consistent position in > a search result. > > For that to happen, it would help slightly if the HTML specification > stopped SHOULD-ing the current <title> behavior. It would help more if > the HTML specification contained clear, straightforward markup for > author and site name (and encouraged UAs to present this information > when the document is taken out of context). There are several options here, some of the easiest would be: <title site="" publisher="" author="">Page Title Page Title - <site></site> - <author></author> (<publisher></publisher>) ...or if people want to also provide links: Page Title I've noted your request and these options. Am I right in assuming that this request does not affect the headers discussion? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mattraymond at earthlink.net Mon Apr 4 07:11:05 2005 From: mattraymond at earthlink.net (Matthew Raymond) Date: Mon, 04 Apr 2005 10:11:05 -0400 Subject: [whatwg]
to
in In-Reply-To: References: Message-ID: <42514AF9.9040606@earthlink.net> Okay, here's my two cents on the heading/section issue... The element
can be used in HTML4 multiple times. Therefore, it is not by default the title of a document. The most natural thing to assume is that is the title of the document, regardless of how people might abuse it. At best, you could say that when there is only one <h1> element, it might be the title. Even that is not a certainty. There are already <meta> values for much of the stuff that people abusively put in the <title> element. For example, "author" metadata is pretty much a standard already: | <meta name="author" content="Space Dog"> Therefore, why not just standardize it and deprecate the use of such values in <title> while giving <title> more specific semantics? Something like this: | <meta name="author" content="Ian Hickson"> | <meta name="sitename" content="WHATWG"> | <meta name="publisher" content="Hixie Industries"> The <link> element can be used for the stuff that requires a URL or hyperlink of some kind. As for sections, in my opinion there are two types of sections. The first is what we have now, an implied section system that is difficult to define but essentially goes from the beginning of one heading to the beginning of the next. The second type of section is one defined by markup such as <section>. This type should be the only type that can be styled and affect rendering. Generally, implied sections should begin at the beginning of a <h#> element and end at either the end of the document or at the beginning of another <h#> element. Allowing exceptions makes describing implied sections much more complicated. If developers need flexibility with regard to this, we can use language that says developers should start and end sections in such a manner rather than must. Importance (given by the number of the <h#> element) determines styling, and it implies structure, but the level of importance should not create missing sections within the document outline. If the importance level of a heading implies a missing parent section, the outline tree should first be constructed as if the implied nodes existed, then the children of missing sections should be collapsed into the position of their parents. That said, this is how I would process the sample markup: <body> <p>...</p> <unnamed section> <h1>A</h1> 1 A (importance level 1) <h2>B</h2> 1.1 B (importance level 2) <h3>C</h3> 1.1.1 C (importance level 3) <h2>D</h2> 1.2 D (importance level 2) <h3>E</h3> 1.2.1 E (importance level 3) <p>...</p> E <ol> E <li> E <h3>F</h3> 1.2.2 F (importance level 3) </li> F <li> F <h3>G</h3> 1.2.3 G (importance level 3) </li> G <li> G <h3>H</h3> 1.2.4 H (importance level 3) </li> H </ol> H <p>...</p> H <h4>I</h4> 1.2.4.1 I (importance level 4) <h2>J</h2> 1.3 J (importance level 2) <div> J <p>...</p> J <h2>K</h2> 1.4 K (importance level 2) <p>...</p> K </div> K <p>...</p> K <h3>L</h3> 1.4.1 L (importance level 3) <h2>M</h2> 1.5 M (importance level 2) <h4>N</h4> 1.5.1 N (importance level 4) <h3>O</h3> 1.5.2 O (importance level 3) <h1>P</h1> 2 P (importance level 1) <h1>Q</h1> 3 Q (importance level 1) <h2>R</h2> 3.1 R (importance level 2) </body> This would be the outline: Document | +-- <unnamed section> | +-- 1 A | | | +-- 1.1 B | | | | | +-- 1.1.1 C | | | +-- 1.2 D | | | | | +-- 1.2.1 E | | | | | +-- 1.2.2 F | | | | | +-- 1.2.3 G | | | | | +-- 1.2.4 H | | | | | +-- 1.2.4.1 I | | | +-- 1.3 J | | | +-- 1.4 K | | | | | +-- 1.4.1 L | | | +-- 1.5 M | | | +-- 1.5.1 N | | | +-- 1.5.2 O | +-- 2 P | +-- 3 Q | +-- 3.1 R From ian at hixie.ch Mon Apr 4 07:24:57 2005 From: ian at hixie.ch (Ian Hickson) Date: Mon, 4 Apr 2005 14:24:57 +0000 (UTC) Subject: [whatwg] <h1> to <h6> in <body> In-Reply-To: <42514AF9.9040606@earthlink.net> References: <Pine.LNX.4.61.0503302359150.25644@dhalsim.dreamhost.com> <42514AF9.9040606@earthlink.net> Message-ID: <Pine.LNX.4.61.0504041420020.27693@dhalsim.dreamhost.com> On Mon, 4 Apr 2005, Matthew Raymond wrote: > > That said, this is how I would process the sample markup: > > <body> > <p>...</p> <unnamed section> > <h1>A</h1> 1 A (importance level 1) I agree with most of what you said but the problem I have with the above is that it means almost every document will have an anonymous section at the top, and I don't think that makes sense. Even in the case of: <body> <h1>...</h1> ...there's an anonymous section, because you have a whitespace text node before the element. That doesn't really work for me. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mattraymond at earthlink.net Mon Apr 4 21:25:40 2005 From: mattraymond at earthlink.net (Matthew Raymond) Date: Tue, 05 Apr 2005 00:25:40 -0400 Subject: [whatwg] <h1> to <h6> in <body> In-Reply-To: <Pine.LNX.4.61.0504041420020.27693@dhalsim.dreamhost.com> References: <Pine.LNX.4.61.0503302359150.25644@dhalsim.dreamhost.com> <42514AF9.9040606@earthlink.net> <Pine.LNX.4.61.0504041420020.27693@dhalsim.dreamhost.com> Message-ID: <42521344.2060304@earthlink.net> Ian Hickson wrote: > On Mon, 4 Apr 2005, Matthew Raymond wrote: > >> That said, this is how I would process the sample markup: >> >> <body> >> <p>...</p> <unnamed section> >> <h1>A</h1> 1 A (importance level 1) > > > I agree with most of what you said but the problem I have with the above > is that it means almost every document will have an anonymous section at > the top, and I don't think that makes sense. If "<p>...</p>" were instead a list of hyperlinks to different sections of the document, should that list be part of the first section? If the paragraph inside the <p> element starts with "I'd like to thank such-and-such for sticking by me while I wrote this...", is that part of the first section? The way I see it, if a heading starts a section, it should always be the start of a section. To do otherwise breaks consistency and may introduce semantics that are not backwards compatible in some situations. Better to use something like "[Top of the document]" that denotes that describes the position of the content without naming it, and also identifies that there is content before the first heading. | <body> | <p>...</p> | <Top> (importance level 1) | <h1>A</h1> | 1 A (importance level 1) > Even in the case of: > > <body> > <h1>...</h1> > > ...there's an anonymous section, because you have a whitespace text node > before the element. That doesn't really work for me. Why do outline generators need to worry about text nodes at the beginning that contain only whitespace? You're talking about content that won't be rendered, so for all intents and purposes, the heading is the first item in the <body>. Such whitespace can simply be ignored by outliners. However, if you are suggesting that such unrendered whitespace be associated with the first section, I have no problem with that. ;) From fora at annevankesteren.nl Tue Apr 5 01:36:55 2005 From: fora at annevankesteren.nl (Anne van Kesteren) Date: Tue, 05 Apr 2005 10:36:55 +0200 Subject: [whatwg] [html5] tags, elements and generated DOM Message-ID: <42524E27.6060006@annevankesteren.nl> I was wondering if HTML5 (WA1, at the moment) is going to define which tags are optional and which elements are implied. (This is of course only for text/html documents.) For example, what is the resulting DOM of this document: <title>Foo ... and this: Foo ..? Are both part of the implied HEAD element or is the SCRIPT element in the first example perhaps part of the BODY element? I believe both are possible. Is there a BODY element in this document (or, is there always a body element?): ... or this: Bar Is HTML5 going to list which start- and endtags are optional and how the resulting DOM tree should look like in situations were there are multiple options? -- Anne van Kesteren From lachlan.hunt at lachy.id.au Tue Apr 5 03:20:54 2005 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 05 Apr 2005 20:20:54 +1000 Subject: [whatwg] [html5] tags, elements and generated DOM In-Reply-To: <42524E27.6060006@annevankesteren.nl> References: <42524E27.6060006@annevankesteren.nl> Message-ID: <42526686.6050001@lachy.id.au> Anne van Kesteren wrote: > I was wondering if HTML5 (WA1, at the moment) is going to define which > tags are optional and which elements are implied. (This is of course > only for text/html documents.) > > For example, what is the resulting DOM of this document: > > Foo > For this, there is no implied body, as there is no element to imply it. SGML rules apply here, as they are expressed in the DTD, and I don't think HTML 5 should change them. The resulting DOM will be the same as that for an HTML 4 document, which is: html | +-head | +-title +-script > > Foo Same as above, with the title and script elements swapped. > ..? Are both part of the implied HEAD element Yes. > or is the SCRIPT element in the first example perhaps part of the BODY element? No. > I believe both are possible. Both are possible, but since script is allowed within the content of the head element, its presence does not imply and . End tags are implied after encountering content which is not allowed within the element. > Is there a BODY element in this document (or, is there always a body > element?): > > > > ... or this: > > Bar No, there is no implied body element in either of those fragments. Run all of your examples through the validator, with the the Show Parse Tree option selected and see for yourself. The rules for an HTML 5 document will be the same as HTML 4. http://validator.w3.org/fragment-upload -- Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox From fora at annevankesteren.nl Tue Apr 5 03:37:27 2005 From: fora at annevankesteren.nl (Anne van Kesteren) Date: Tue, 05 Apr 2005 12:37:27 +0200 Subject: [whatwg] [html5] tags, elements and generated DOM In-Reply-To: <42526686.6050001@lachy.id.au> References: <42524E27.6060006@annevankesteren.nl> <42526686.6050001@lachy.id.au> Message-ID: <42526A67.9030907@annevankesteren.nl> Lachlan Hunt wrote: > No, there is no implied body element in either of those fragments. I appreciate your comments but I was wondering if you have taken into account what existing user agents do. Since that, not some out-of-date-not-followed SGML standard, should be standardized in my humble opinion. That also means that: body{background:lime}> ... generates: HTML HEAD STYLE #text BODY ... whether you like it or not. Same for the other cases. I do not think it makes sense to say all current UAs are non-compliant as many pages may rely on the kind of DOM they generate. -- Anne van Kesteren From ian at hixie.ch Tue Apr 5 04:12:58 2005 From: ian at hixie.ch (Ian Hickson) Date: Tue, 5 Apr 2005 11:12:58 +0000 (UTC) Subject: [whatwg]
to
in In-Reply-To: <42521344.2060304@earthlink.net> References: <42514AF9.9040606@earthlink.net> <42521344.2060304@earthlink.net> Message-ID: On Tue, 5 Apr 2005, Matthew Raymond wrote: > > > > > > That said, this is how I would process the sample markup: > > > > > > > > >
...
> > >
A
1 A (importance level 1) > > > > I agree with most of what you said but the problem I have with the > > above is that it means almost every document will have an anonymous > > section at the top, and I don't think that makes sense. > > If "
...
" were instead a list of hyperlinks to different > sections of the document, should that list be part of the first section? > If the paragraph inside the
element starts with "I'd like to thank > such-and-such for sticking by me while I wrote this...", is that part of > the first section? If you maintain (as I do) that the first
is the document's title -- the same as the element but without the requirement that it be phrased so that it can be quoted out of context -- then yes. The first section is the <body>, the <body> is the document's content, and the spec currently says: # The first heading in a sectioning element gives the header for that # section. The content at the top of the <body> is part of the <body>, and thus it is associated with the <body>'s heading. Why would you _not_ want the navigation links, or the byline, or the dedication, etc, to be associated with the document's first section? It seems correct to me. > The way I see it, if a heading starts a section, it should always be the > start of a section. To do otherwise breaks consistency and may introduce > semantics that are not backwards compatible in some situations. Do you have any examples? As far as I can tell we always want the first heading of a section (assuming it isn't preceeded by any subsections) to be the heading of the section. > Better to use something like "[Top of the document]" that denotes that > describes the position of the content without naming it, and also > identifies that there is content before the first heading. But this will be happening all over the place. <body> <p>Fox Publications Presents:</p> <h1>The Big Newspaper</h1> <article> <h2>Flood in town</h3> <section> <h2>Geography</h2> ... </section> </article> The first <p> is clearly part of the same section as the first <h1>. The whitespace node before the two <h2> elements are similarly obviously part of their <section>, and the <h2>s clearly don't start a separate section that is independent of the <article> and <section> elements. > > Even in the case of: > > > > <body> > > <h1>...</h1> > > > > ...there's an anonymous section, because you have a whitespace text > > node before the element. That doesn't really work for me. > > Why do outline generators need to worry about text nodes at the > beginning that contain only whitespace? Because the spec is defined in terms of nodes, and introducing special rules for nodes that only contain space characters is a recipe for confusion and lack of interoperability (I'm talking from experience here). > You're talking about content that won't be rendered, so for all intents > and purposes, the heading is the first item in the <body>. It might well be rendered (e.g. due to 'whitespace: pre'). > Such whitespace can simply be ignored by outliners. However, if you are > suggesting that such unrendered whitespace be associated with the first > section, I have no problem with that. ;) I am suggesting that, and by extension, I'm suggesting that the first node (whatever it is) be associated with te first section, and that that be associated with the first heading. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 5 04:17:04 2005 From: ian at hixie.ch (Ian Hickson) Date: Tue, 5 Apr 2005 11:17:04 +0000 (UTC) Subject: [whatwg] [html5] tags, elements and generated DOM In-Reply-To: <42524E27.6060006@annevankesteren.nl> References: <42524E27.6060006@annevankesteren.nl> Message-ID: <Pine.LNX.4.61.0504051113310.20461@dhalsim.dreamhost.com> On Tue, 5 Apr 2005, Anne van Kesteren wrote: > > I was wondering if HTML5 (WA1, at the moment) is going to define which > tags are optional and which elements are implied. (This is of course > only for text/html documents.) Yes. > For example, what is the resulting DOM of this document: > > <title>Foo > > > ... and this: > > > Foo > > ..? If I am not mistaken: > Are both part of the implied HEAD element or is the SCRIPT element in > the first example perhaps part of the BODY element? I believe both are > possible. This is not ambiguous in SGML, which defines this in detail. > Is there a BODY element in this document (or, is there always a body > element?): > > > > ... or this: > > Bar In HTML4 those are invalid ( can't be empty). The will always e implied, though. (For backwards compatibility with legacy parsers, the probably won't be.) > Is HTML5 going to list which start- and endtags are optional and how the > resulting DOM tree should look like in situations were there are > multiple options? In HTML4 there are never multiple options, but the answer to your question is yes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 5 05:38:42 2005 From: ian at hixie.ch (Ian Hickson) Date: Tue, 5 Apr 2005 12:38:42 +0000 (UTC) Subject: [whatwg] Web Forms 2.0 Feedback In-Reply-To: <20050324234336.7855.qmail@web50908.mail.yahoo.com> References: <20050324234336.7855.qmail@web50908.mail.yahoo.com> Message-ID: On Thu, 24 Mar 2005, Csaba Gabor wrote: > > > > [simulating img clicks] > > What was your use case for wanting the event handler to trigger? > > 1. I had asked for the ability to simulate a REAL click complete with > simulated coordinates. Ah! You can do that by simply creating an event using the createEvent() method and then dispatching it into the DOM via dispatchEvent(). That will work for any event. > 2. Repetition model. > The Draft has a huge amount of space devoted to this, > but I haven't been able to think of a single compelling > argument for it. Most of the control enhancements such > as validation are conveniences, after all, but what they > have going for them is that they are very compact. This > repetition model is huge and messy and there are simple > javascript programming methods that allow you to do the > same thing. This developer's opinion is that I would > far rather roll my own and not even have the possibility > of using this construct. Yeah, several people have said that. We're thinking about removing it. On the other hand, several people have said that it is a godsend and that they are so happy it is there because they are fed up of rolling their own. At the moment it's about equally matched, in fact. The model is pretty simple and relatively easy to implement, so I'm leaning towards keeping it. > B) But I can't twist my mind about all this stuff with > allowing/not allowing block level contents inside DIVs > unless it's an odd numbered Tuesday of the month. Could > the document maybe provide some argument for this? This is just allowing you to do:

...which would otherwise be illegal (it is illegal in HTML4). Currently you have to do:

> It states: > > The children of a form element must be block-level elements, unless one > of the ancestors of the form element is an element other than div whose > content model includes both block- and inline-level content, in which > case either block-level or inline-level content is allowed (but not > both). input elements of type hidden may be placed anywhere (both in > inline contexts and block contexts). > > But isn't the ancestor of every form (in an html document) > a body element (which is not a div element)? And I'm pretty > sure I've put both inline and block content into body elements. only accepts block-level content in HTML4 Strict. > So now I can only have block or inline elements in my forms, but not > both (like I've gotten accustomed to doing)? What happened to backwards > compatibility and why should spec developers even be concerned about > this one? I just don't get it. In HTML4 Strict you can only have block-level content in
elements. This is simply relaxing this to allow inline-level content as well in certain cases where that makes semantic sense. > To my mind, a FORM element is a convenient way of saying, "unless > otherwise noted, every control within me will be submitted when I am > submitted." As such, why should it have any interest in the bock/inline > types of its descendents? I agree with you. The way it is defined in WF2 effectively makes transparent to all this, letting the ancestors and descendants figure it out between themselves. > I have two points that are not explicitly adressed: > A) There is mentioned a maximum length of about 1K for this > data type (in the RFC 2397). Couldn't this be extended? This will be extended in the Web Apps spec. > B) Security: Shouldn't it be mentioned that if the > the destination window gets a page like this, it should be > run in the context of the submitter? In general it is best to leave security concerns of this nature out of the normative definitions of the spec, in case new problems arise that were not considered during the development of the spec. However, the concern you raise has indeed been considered and is what UAs implement, I believe. > 5) When I first read the replace attribute of a form I thought good, > that is a useful innovation. Why destroy the document just to > repopulate a small section of it? So section 8 of form submission tells > me I should go see the section on: seeding a form with initial values to > find out how this is done. For a non XML person like me, that is scary > stuff there. Trying to figure out how ultra long strings with seemingly > random digits might be applicable to me (What I'm saying is, the HTML > person is going to be scratching his head upon reading it). Yeah, I expect we will need tutorials to make this understandable. The problem is the processing model as to be detailed, so the spec can't really be both simple for authors and implementors, and the latter take priority generally. :-) > And then my eyes alight on section > 6.2.4, 3rd paragraph, about image controls. > It says: > For image controls, instead of using the name given by the name attribute, the field's name is > checked against two names, the first being the value of the name attribute with the string .x > appended to it, and the second being the same but with .y appended instead. Thus image controls > are handled as if they were two controls. > > So, how does this make sense in a form seeding sense? It's a minor detail to do with keeping track of the controls being filled -- the above does not say that image inputs can be seeded. > Also, in step 4 of form submission, it is mentioned that: > Image buttons, during this step, are handled as if they were two controls, one with the > control's name with .x appended, whose value is the x coordinate selected by the user, and the > other with the control's name with .y appended, whose value is the y coordinate selected by the > user. The indices of these two virtual controls are handled separately and could, depending on > the values of other controls, end up with different values. > > I would say that these coordinates are not selected, but rather clicked They could be selected via some other means, UAs are not required to need a mouse for htis. > and shouldn't it be mentioned that they are relative to the control itself > (as opposed to the window or some other object). That is unchanged from, and therefore covered in, the HTML4 spec. > But more importantly, how could this .x and .y wind up with different > values (I assume you don't mean from each other) depending on the values > of other controls. I must say, I was sitting on the edge of my seat > with excitement upon seeing the 'For example' just below this, which > turned out not to give it away. It's an edge case. Say you have: ...then the image will generate an "i.x" and an "i.y" but not there are two "i.x"s and only one "i.y". This is just taking care of that. > 6) One thing I didn't think of before, but that replace attribute > reminded me... > Wouldn't it make sense to specify a way for a form or output contol, > IF IT REQUESTED, to be updated from the server on a continuing basis > (push technology years ago, if I remember right). I know it's late > in the game for this, but perhaps you will hear me out. This will be covered by the "remote events" part of the Web Apps spec: http://whatwg.org/specs/web-apps/current-work/#server-sent > 7. Finally, a curiosity question. SELECT elements are lacking > in this spec. Now, back in the summer it was pointed out to me > (Ian) that Hierachical menus will be available in Web Apps 1.0 > What I don't understand is why they are not part of this spec. > Isn't this their natural resting place? s can be nested in Web Forms 2. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 5 05:44:33 2005 From: ian at hixie.ch (Ian Hickson) Date: Tue, 5 Apr 2005 12:44:33 +0000 (UTC) Subject: [whatwg] WhatWG spec addition? Message-ID: UJS Contact US wrote: > > I gave the specs a quick scan - specifically for one element which I have an > interest in... that of the standard "select tag"... > > I believe this list selector should be updated to provide columnar data > formatting and enable properties that include: Greenbar (alternating colors > - odd rows/even rows)... This can be done using CSS and W3C Selector's :nth-child() pseudo-class. As a presentational detail, it should be out of scope of Web Forms. > ...header row, header column. > > I have a very rough "whitepaper" on my website showing an example... Please > take a look - it is a short read. > > http://www.aujsproduction.com/samples/wishlist/revampedselector.asp I agree that something like this is probably needed. We'll be looking at things like this in the Web Apps draft. > I will take a closer look at the entire doc to see what else I might be able > to "suggest". I look forward to it. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 5 06:45:19 2005 From: ian at hixie.ch (Ian Hickson) Date: Tue, 5 Apr 2005 13:45:19 +0000 (UTC) Subject: [whatwg] [WF2] The element In-Reply-To: <42495D8C.1080007@earthlink.net> References: <420A34FD.5040705@earthlink.net> <423ED662.2070805@earthlink.net> <42495D8C.1080007@earthlink.net> Message-ID: To summarise my position: solves some problems, and introduces others. Just like , it is not perfect. Since I do not consider the problems that it solves to be serious problems, and since I do not consider the problems it introduces to be any less important than the ones it sets out to solve, I do not see the advantage of introducing it. On Tue, 29 Mar 2005, Matthew Raymond wrote: > > > > If it uses scripting, isn't needed. > > Not true. See the jscalendar example. In that situation, it's far and > away easier to use (formerly ) than it is to > modify the script, especially if the author knows little or nothing > about Javascript and is simply using someone else's work. I wouldn't expect people to try to go from jscalendar to jscalendar + icomplex. I would expect them to go from jscalendar1 to jscalendar2, the second of which provides for WF2 UAs. > > > Can you explain exactly why it's so difficult to create server-side > > > scripts to deal with this issue? > > > > It's not, particularly; certainly no harder than supporting multiple > > date formats. The problem is mostly that it involves having multiple > > codepaths, which means more likelihood of errors (authors frequently > > only test in their UA), as well as opportunities for vulnerabilities > > (e.g. if the script doesn't expect to receive both date arguments at > > once). > > Nonsense. Here's the pseudocode: > > | if (exists(WF2_date_string)) { > | date1 = WF2_date_string; > | } else { > | date1 = select_year + "-" + select_month + "-" + select_day; > | } Sure. I've also seen code like: if (exists(WF2_date_string)) date1 = WF2_date_string; if (exists(select_year)) date1 = select_year + "-" + select_month + "-" + select_day; // later in the script if (exists(select_year)) date1 = select_year + "-" + select_month + "-" + select_day; if (exists(WF2_date_string)) date1 = WF2_date_string; > Then you just validate "date1" as if it where coming from a WF2 client. > This is the kind of problem they give programmers at a job interview for > people fresh out of college. Many Web developers are self-employed, or employed by people who hired them based on the fact that the demo Web page they were shown has a cool bit and funky use of . Sure, the professionals won't do this kind of mistake. > > > > It doesn't solve the problem of the default (simplest authoring) > > > > being zero fallback for legacy UAs. > > > > > > The simplest thing to author would be to use , so I don't see > > > your point. > > > > My point is it would be possible (and therefore, by Murphy's law, > > common) for authors to do: > > > > [ ] > > Exactly how would that work? In WF2-compliant HTML, nothing in the page > would show up after the element. Are you saying it's a > problem because XHTML parsers allow the more compact form even when a > closing tag is required? Eh? In XML, and are equivalent. > > > The problem here was that supporting