In article <QdCdnW7i7taF0gDUnZ2dnUVZ_onin
...@mozilla.org>,
Robert O'Callahan <rob
...@ocallahan.org> wrote:
> On 19/2/09 11:16 PM, Henri Sivonen wrote:
> > Non-rhetorical question: If one works on style system or layout code,
> > does it make more sense to read CSS 2.1 or to read the latest Editor's
> > Draft of the relevant CSS3 spec?
> It depends. CSS 2.1 will tell you what authors are likely to be relying on.
Is it good to deduce that information from a spec? Wouldn't something
like Opera MAMA work better for that purpose?
> The difference is that CSS3 drafts are more likely to change, and be
> changeable, than CSS2.1. That matters to browser implementors and authors.
But the CSS WG is free to change only those aspects of CSS3 that
implementations have not yet converged on. If there's a feature that
implementations have converged on, shouldn't that part be equally stable
in CSS 2.1 and CSS3? It seems to me that if the CSS WG were to change a
part of CSS that has been interoperably implemented, it would be going
astray.
Personally, I think the direction of publishing things like "CSS
Beijing" (as a concept; not necessarily expressed exactly like 'Beijing'
was) for authors while making the "CSS3" perma-drafts available to
implementors and early adopters is more useful than getting CSS 2.1 to
REC at the expense of editorial attention to the same areas in the CSS3
drafts.
Ten years ago, the bar for a REC was way too low, but now the bar for a
REC is so high that any monolithic spec concerning an area of the
platform where innovation still happens is obsolete by the time it gets
to REC. The specs need to be roughly as live as implementations. If the
bar of pushing a spec to REC in far higher than the bar for pushing a
browser to a release, the specs either never get to REC or are obsolete
when they do (at least in the sense of being incomplete accounts of
their subject matter; I don't think CSS 2.1 will be incorrect for the
things it does describe).
Splitting stuff out of HTML5 in order to make it get to REC fast would
mean that the part that got to REC would already be obsolete in the
sense that it wouldn't accurately capture the new action in the
development of the platform even if it were accurate for the older parts.
However, splitting adds overhead in many ways including the technical
overhead of maintaining cross-references, the bureaucratic overhead
around licensing and chartering, the overhead of communication between
editors, etc. This is why I think it's useful to maintain fine-grained
stability annotations within a larger document than to split a document
solely for the reason of being able to use per-document stability
designations.
HTML5 does have mostly independent parts that could be offloaded to
different editors if editors were available. In particular, pure API
features such as Web Socket and SQL storage are minimally intertwined
with the rest of the spec. Still, the traditional W3C and IETF
dependency rules are very impractical, and I think it would be more
useful to adjust the rules than to try to make specs fit to the rules.
For example, XHR was a split out of HTML5 and is mostly independent,
except for the serialization and parsing algorithms and the concept of
origin. Redefining these concepts solely for the purpose of making XHR
proceed to REC without normative references to documents with a lesser
status would not be a good idea, because reuse of code should match the
inter-spec references. The concept of origin, for example, permeates the
entire browser, so it is exactly as stable or unstable regardless of
what aspect pretends about its stability.
> > If the purpose of "publishing" is to send signals to people other than
> > browser implementors, to whom and why?
> To let authors know what is stable and to raise their expections that it
> actually works in browsers.
> We could use annotations in a monolithic document for these things, but
> I think it's fair to say that a separate document makes the point better.
If the purpose is to communicate to authors, why does the document at
http://people.mozilla.com/~sayrer/2009/02/15/html5.html include the HTML5 parsing algorithm? Shouldn't authors be shown
something like the "Writing" section instead?
I think it would be useful to publish summaries of stable areas of the
open Web platform for authors from time to time. However, if the purpose
is to communicate to an audience the Web authors, I think taking a spec
with implementation algorithms and hitting backspace on parts of it is
not a very good method of communication. Summaries in the style of the
HTML5 differences from HTML 4 document could be much more effective.
Further, there is a political problem with publishing summaries of
platform stability to authors--at least from a W3C WG: If a feature is
implemented in Firefox, Safari, Opera, Chrome and IE, it is pretty
uncontroversial to summarize it as something that authors can use. If it
is only implemented in one of them, is pretty uncontroversial to
summarize it is something that authors can't safely use. However, coming
up with vendor-neutral criteria for documenting the cases in between is
harder.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
