- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 24 Nov 2008 14:07:48 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Jim Jewett <jimjjewett@gmail.com>, HTML WG <public-html@w3.org>
Julian Reschke wrote: > Jonas Sicking wrote: >> ... >> So lets put it the other way around. Say that the CSS 1 spec would >> have looked the way it does, but it also defined the rel and name >> attributes for the <link> tag, and how they are used to link >> alternate, preferred and persistent stylesheets to HTML. Don't you >> think that someone would have said "That stuff doesn't belong in the >> CSS spec, that is HTML specific, CSS doesn't define how a specific >> markup language should link to CSS"? >> ... > > Good point. > > Funny enough, that's exactly what we have in the situation of XML and > XSLT (where the PI is described in a separate document). Yup, that is one way of doing it. Have separate specs to cover the integration points between other specs. However the strategy tends to balloon the number of specs. For example there are a number of things that needs to be defined in the integration-point between the PI and XSLT. The PI spec is generic spec for linking XML resources to stylesheets, but there are some special things that need to be defined when that stylesheet is an XSLT stylesheet. This is currently undefined and does result in browser behavior actually being vastly different in how they process XSLT stylesheets. For example, do scripts in the source document execute? And more importantly, how is the output from the XSLT treated? I.e. is the output tree displayed directly, or is it serialized and reparsed as the new page. Turns out all other browsers than gecko based ones serialize and reparse, and pages depend on that, those pages do not work in firefox. Sure, you can come up with a spec that defines the integration between the PI spec and the XSLT spec. And you can argue that the problem with undefined behavior right now isn't because the PI spec is missing information or that the XSLT spec is missing information, but rather that no-one wrote the spec about integrating the two. However the more you split up specs the more this exact thing occurs. There will be more undefined integration spots. Sure, you can patch it by adding more specs that define the integration spots, but then you also end up with integration points between the integration specs and the other specs. As shown above this is not a theoretical problem but does actually happen and does cause problems. So like I said in a recent mail. Splitting up the spec is certainly doable. And it does have advantages. But it does also have some very serious disadvantages. Some these disadvantages are a major reason that the web is as complex as it is today. Is that a cost that we are willing to take? / Jonas
Received on Monday, 24 November 2008 22:10:56 UTC