" results in various parse errors.]
2006-06-12 22:16 zcorpan the following snippet is conforming html5 according to the
current draft (ignoring that Ps must have text, and that
contents of Q and BLOCKQUOTE must be quoted from other
sources):
2006-06-12 22:16 Cerbera/Ben hi
2006-06-12 22:16 zcorpan hello
2006-06-12 22:17 Cerbera/Ben I see
2006-06-12 22:17 Cerbera/Ben
inside the
is indirectly inside the first? 2006-06-12 22:24 zcorpan yes 2006-06-12 22:24 Cerbera/Ben but
cannot contain "block-level elements"? 2006-06-12 22:24 zcorpan it doesn't 2006-06-12 22:25 Cerbera/Ben it does, a couple of nesting layers down 2006-06-12 22:25 zcorpan yeah, but the rules only apply to the children, not to descendants 2006-06-12 22:25 Cerbera/Ben ah, ok 2006-06-12 22:28 zcorpan at least in this case, there are rules where the content model puts restrictions on descendants aswell, such as must not contain interactive elements as descendants 2006-06-12 22:29 zcorpan like 2006-06-12 22:30 Cerbera/Ben I see] 2006-06-12 22:30 Cerbera/Ben are these highly specific nesting rules going to make HTML5 more complicated to implement than HTML4? 2006-06-12 22:31 zcorpan nesting rules don't apply to implementors, only to authors 2006-06-12 22:31 zcorpan parsing rules apply to implementors (but not to authors) 2006-06-12 22:32 Cerbera/Ben nesting rules to apply to implementors, it determines some aspects rendering 2006-06-12 22:32 Cerbera/Ben such as where borders go for your first example 2006-06-12 22:32 zcorpan unless you're implementing a conformance checker, of course :) 2006-06-12 22:32 zcorpan CSS covers that 2006-06-12 22:33 zcorpan the parsing section tells what the DOM should look like, and then CSS takes over for rendering rules 2006-06-12 22:34 Cerbera/Ben but the way nesting works effects how the DOM will look. I don't understand how the nesting rules can be seperate from parsing 2006-06-12 22:35 zcorpan they are separate. for instance the content model for HEAD requires a TITLE, but UAs don't insert a TITLE element if it is missing 2006-06-12 22:36 zcorpan UA conformance requirements and document conformance requirements are separate 2006-06-12 22:36 Cerbera/Ben yes, I understand that 2006-06-12 22:36 Cerbera/Ben but both have to handle nesting correctly, surely? 2006-06-12 22:37 Cerbera/Ben for example, they have to know that
tags are implied while parsing 2006-06-12 23:03 Cerbera/Ben themeans exactly that, and not think it should be2006-06-12 22:38 zcorpan yeah, the parsing section says how UAs should parse it 2006-06-12 22:38 Cerbera/Ben and the parsing include how to handle nesting? 2006-06-12 22:39 zcorpan well it includes how to tokenise and build a tree from a stream of unicode characters, which results in a DOM, and the DOM mostly contains nested elements 2006-06-12 22:41 Cerbera/Ben I see 2006-06-12 22:42 zcorpan but the parsing section doesn't talk about "this element can contain these elements", because when you parse you don't see elements but start tags, end tags, comment tokens, etc. 2006-06-12 22:43 Cerbera/Ben so if an author nests elements incorrectly, what does the parser do? 2006-06-12 22:44 zcorpan it builds a well-formed DOM based on the algorithms in the parsing section 2006-06-12 22:44 Cerbera/Ben I see 2006-06-12 22:46 zcorpan any input document that starts with a correct doctype has unambigous parsing rules 2006-06-12 22:46 zcorpan although a UA may either abort parsing on a parse error or recover according to the rules in the parsing section 2006-06-12 22:47 Cerbera/Ben I see 2006-06-12 22:48 Cerbera/Ben so the DOM for incorrectly nested elements is made according to the parsing rules? 2006-06-12 22:49 zcorpan yes 2006-06-12 22:51 zcorpan i think the new "strictly inline" and "structured inline" concepts and elements being either block-level or structured inline is a bit complicated and i think many devs will have issues understanding them (given that most have issues understanding the simpler content model rules in html4) 2006-06-12 22:51 zcorpan devs -> authors 2006-06-12 22:51 Cerbera/Ben yeah 2006-06-12 22:52 Cerbera/Ben are all types of nesting allowed in HTML4 also allowed in HTML5? 2006-06-12 22:52 Cerbera/Ben if so, they don't need to change what they do already? 2006-06-12 22:53 zcorpan yes, i think so, but HTML5 is a bit looser in some areas 2006-06-12 22:53 Cerbera/Ben that shouldn't cause devs any problems, then 2006-06-12 22:54 Cerbera/Ben they might not make the most of HTML5's capabilities, but they make more errors than they used to 2006-06-12 22:55 zcorpan why would they make more errors? 2006-06-12 22:55 Cerbera/Ben oh, I missed a word! 2006-06-12 22:55 Cerbera/Ben *they won't make more errors 2006-06-12 22:55 zcorpan oh right 2006-06-12 22:56 zcorpan the idea with struct-inline is basically that you can use lists and tables in paragraphs 2006-06-12 22:57 Cerbera/Ben yeah 2006-06-12 22:57 Cerbera/Ben I'm not sure that's a good idea 2006-06-12 22:58 Cerbera/Ben a printed paragraph is just a block of text with no other structures in it 2006-06-12 22:59 Cerbera/Ben when a list is used, it is a different type of structure since it is a block which contains several items of text 2006-06-12 22:59 Cerbera/Ben I'm not sure it makes sense to put rich structures inside paragraphs 2006-06-12 23:00 zcorpan surely, a paragraph can contain * lists, * tables, * and quotes without having to be split up in different blocks? (;)) 2006-06-12 23:01 Cerbera/Ben hmm, I guess so 2006-06-12 23:01 Cerbera/Ben it seems rather clumsy, though 2006-06-12 23:02 zcorpan it sort of doesn't apply to text/html anyway, becauseafter the wouldn't be implied? 2006-06-12 23:04 zcorpan
foo is equivalent to
foo 2006-06-12 23:05 Cerbera/Ben but if you had: p { margin-top: 2em; } this would no be applied to "foo"? 2006-06-12 23:05 zcorpan no, "foo" is just a text node 2006-06-12 23:05 Cerbera/Ben oh, I see 2006-06-12 23:07 Cerbera/Ben well, nice talking with you 2006-06-12 23:07 Cerbera/Ben I have to go now