- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 24 Nov 2008 17:21:10 -0500
- To: Asbjørn Ulsberg <list@asbjorn.ulsberg.no>
- CC: Jim Jewett <jimjjewett@gmail.com>, HTML WG <public-html@w3.org>
Asbjørn Ulsberg wrote: >> That approach makes it impossible to actually use the "markup spec" >> for even writing an authoring tool. What exactly is the point of this >> "markup spec", again? > > I believe there is a very valid use-case for an as pure "markup spec" as > possible, and that is: Authors. As people keep saying (including the ones advocating splitting things up), authors should be reading authoring guides, not specifications. > Being able to reference the markup > elements and attributes without the interference of DOM and scripting > definitions is a huge plus-side of the HTML4 specification. I've always seen it as a downside, as an author, that I have to go to two separate places to get information about the one thing I want, and then try to synthesize it... But then again, I've always seen it as a downside, as an author, that I have to read either the HTML4 spec or the DOM2 HTML spec at all, what with the cryptic DTD mess, the complexity and interconnectedness of DOM2 HTML, etc. > While HTML5 successfully tries to specify a heck of a lot more than > HTML4 in terms of how HTML actually works, I have to agree with Jim and > Toby in that the HTML5 specification would be better Better for what target audience of the specification itself? Authors aren't it. >> Informative circular references are even worse than normative ones, >> since they're more likely to become stale... > > True, and I agree that circular references should be kept at an absolute > minimum or best of all; avoided completetly. There is a way to avoid > them: Write the specifications in layers or levels, where the reference > and dependencies only one way (up or down, depending on your perspective). This works well when defining new things. It's _very_ hard to do when specifying existing things that don't have the benefit of splitting up nicely like that. > If we could think of "HTML5: Markup and Document Object Model" as "level > 1" in this stack of specifications, "level 2" could be "HTML5: > Processing", "level 3" could be "HTML5: Scripting", "level 4" could be > "HTML5: Interfaces and plugins", etc. Level 4 would reference level 3 > which would reference level 2 which would reference level 1, but never > the other way around. I'd love it if you could actually draw such lines, but given the existing behavior, you can't. Parsing has normative dependencies on scripting and vice versa, for example, in a UA that supports scripting. This can be done if the "lower" specs provide abundant integration points for the "higher" specs to hook into, but this enormously increases complexity. > I'd like to see level 1 be as bird's eye view and HTML author-friendly > as possible, without heavy scripting references or intricate parsing > algorithms. Again, there is no need for the normative specification to be author-friendly. In my opinion. -Boris
Received on Monday, 24 November 2008 22:31:08 UTC