Re: Splitting up the spec

On Sat, Nov 22, 2008 at 9:39 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
>
> Jonas Sicking wrote:
>> There is always going to be things in any given specification that some
>> people don't need.
>
> Agreed; but if the spec is long, then you don't want many people for whom
> the majority of the spec is unneeded.  Or, at the very least, you want to
> make it as clear as possible which parts they can ignore, even before
> they start reading.
>
>> if I don't care about CSS I won't care about <style>,
>> <div>, <span>, rel=stylesheet, or style="...".
>
> To me, that case is a good argument for the split.
>
> The Markup Semantics spec should define them, so that you can look
> them up for reference, if you find them elsewhere.  You probably won't
> use them, but the definitions are short enough that they won't be a problem.

I'm not following. Should we have those tags defined in the 'language
spec'? If so, why? Given that not all users need it why not split them
out into a separate spec?

> On the other hand, if the spec included all of CSS inline under the definition
> of the <style> element ... that would not be so good.

Agreed. We need to find the right level of separation. If we use too
little separation we'll end up with all of W3C in one huge spec. If we
use too much separation we end up with one spec per HTML element.

My point is that I think many people have been arguing for too much
separation. IMHO we should keep things together that heavily influence
each other and that need to be designed together. This makes both
writing the spec easier as well as reviewing the spec. I think
separating based on use case is going to result in way too small
specs.

> Please look at http://www.w3.org/TR/REC-html40/present/styles.html
> How much of that still seems like it should really be in HTML itself?
>
> To me, it looks like large portions really ought to have been left for CSS
> to define.  For example, Content-Style-Type appears in that document,
> and one other in my entire cache.  ... That HTML section provides
> (normative?) information about how to write a CSS style, but you still
> need to go to the CSS spec anyhow to get a list of valid property values.

IMHO all the parts about elements and attributes need to be in the
HTML spec. Content-Style-Type definitely needs to be in the HTML spec,
otherwise you have no idea how to interpret the text inside the
<style> element. I.e. you couldn't let CSS define that since you
couldn't know that it's CSS that you're trying to interpret. Or you
could rely on content sniffing I guess, but that seems suboptimal to
me.

Section 14.6 looks to me like the only part that doesn't belong in the
HTML spec, as it is not specific to HTML at all. Section 14.4.2 also
looks misplaced, but it doesn't contain any normative text as far as I
can tell. There is more in section 14.4 that would have been better
defined in the CSS spec, i.e. the CSS spec could have defined cascade
and what happens if several stylesheets are linked to from a single
page, and then the HTML spec could have defined how to do multiple
links.

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"?

Another, and I think more important point is this. How much harm has
the stylesheets part of HTML4 caused? How much harm would it have
caused linking to stylesheets had been left largely undefined by the
HTML WG and deferred while various groups decided who should handle
it? While in the meantime implementations had gone ahead and done what
they thought was right. I personally think that would have caused a
whole lot more harm.

The reason HTML content and browsers today is such a mess isn't that
the HTML4 spec is too bloated. It's that it left too many things too
poorly defined. That is what gave us incredibly complex tag soup
parsing and a way, way too complicated scripting model.

I actually find it quite humorous how many people are complaining
about error-handling being so complicated in HTML5. While it is a bit
of a mess, it is a tiny fraction of the complexities involved with
implementing a HTML renderer with script support.

And in most cases these complexities are due to specs leaving various
things undefined. In the remaining cases it is due to bugs in early
releases of browsers. The way to fix these things is to ensure that
everything is very precisely defined and have lots of tests in the
official test suite. If you are concerned that browsers and HTML is
too complex, then splitting up the spec is the entirely wrong thing to
do.

> At the time, these parts seemed unavoidably entwined -- they needed
> to give examples, after all.  But with the passage of time ... maybe
> just referring to CSS wouldn't have been such a burden after all.

I can't see anything in there that mentions CSS features that is
normative. Though I admit I could have missed such a place as I didn't
spend much time looking. All the examples look non-normative though.

/ Jonas

Received on Monday, 24 November 2008 09:57:01 UTC