Fwd: several messages from Orion Adrian

> > HTML 4.0 has a lot of elements and attributes deprecated, eventually
> > removed entirely from the spec in XHTML 1.0 Strict.
> 
> Actually they were removed from HTML 4.0 strict. But that's irrelevant. It
> doesn't make user agents not support them -- you can still use all the
> deprecated features and they'll work regardless of your DOCTYPE.

Deprecated yes, obseleted no. At least it's my understanding you're
not supposed to be able to use them when you specify a DOCTYPE that
doesn't allow them. At a mimimum it's non-conforming right?

> > Under the CSS model, the addition of <B>, <I>, <U>, <FONT>, etc could
> > never be removed. It would still be in HTML 5.0, 6.0 and so on.
> 
> Not at all. You simply remove them from the new version of the spec and
> you're done. For instance, the way that 'display: marker' has been removed
> from CSS. It existed in CSS2, and no longer exists (it is permanently
> removed from CSS, not just moved to CSS3 like 'display: compact').

This response facinates me. Display: marker was never really
implemented so removing it wasn't that big a deal, but I'm referring
to things actually in browsers and in use in web pages. You say you
just remove them, but user agents cannot stop using them can they?
They must implement all properties that have had some level of use.
So, regardless, the set of properties that need to be supported grows,
does it not?

My understanding of this is that a browser must have one engine that
supports all properties that have ever been used significanty. That or
attempt to calculate what historical point in the spec the user was
targeting (defacto versioning, but harder).
 
> > What extra needed resources? I'm confounded by the scenario you've put
> > together. Are we saying that major changes will have to be maintained
> > for CSS 1.0 renderers? No. Once you finish getting it done, you package
> > up the renderer as a plugin and ship it with your product so that when a
> > resource specifies 1.0, it uses the 1.0 renderer.
> 
> What about bugs in the 1.0 renderer?

First it depends on what market share you have and how long it's been
since release of the renderer.

Given that web developers tend to work with what's out there more than
what the specs say, many products will be produced and many pages will
have been written with certain buggy behavior in mind and there may be
merrit in not fixing bugs or fixing bugs in such a way that pages that
relied on buggy behavior still work.
 
> Your suggestion does not make it easier. It makes it harder. We'd have to
> created more test suites. (Your "easier" was relative to testing
> methodologies, not relative to how versioning would help.)

I'm confounded by the mechanism the W3C has put together for browsers
to test against their specs. The necessity of such a mechanism should
have long been a flag that the design of CSS (or HTML) wasn't
sufficiently componetized. In the world of software validation, we
clamor for systems that garuntee output for a given set of inputs by
testing for edge cases.

CSS, however, doesn't work in that way. Every property has the
potential it seems to manipulate the output not only in its existence,
but also in its relationship to other properties. This to me has
always been the core flaw of CSS.

Rather than one set of tests per property (the set consisting of the
edge cases), the tests must be written as if all the properties were
inputs to one big function that must be tested. Now we have a
permutation of test cases. We must test every property value and how
it affects every other property value.

While interconnectedness facinates me in history, here it is just a bother.
 
> > Use whatever terminology you want. If I were to ask someone what version
> > HTML 3.2 was, I'd bet 99 out of a 100 times they'd say 3.2.
> 
> Just like if you ask people what version CSS 2.1 was, they'd say 2.1...

So at a minimum if there is no versioning, giving it numbers was
probably a bad idea given people's proclivity to ascribe numbers with
versions.
 
> That simply isn't how CSS works at the moment, and as I've described
> before, the change to a two-pass cascade is not a change the working group
> feels comfortable with requiring (mostly for perf and complexity reasons).

I can appreciate this statement as I would imagine it would be a major
change for the purpose of adding color-coding to columns. That doesn't
seem a big enough reason to do so. I'm not above understanding that
radical solution must only be attempted to deal with complex problems
that affect everyone or prevent progress on a larger scale.

> > Versioning doesn't break backwards compatability. It does break forward
> > compatability which I say is a good thing since forward compatability
> > was a pretty silly concept.
> 
> Forward compatibility is one of the main reasons for the success of the
> Web. Documents and stylesheets written for the new browsers still work in
> the old ones (albeit with reduced functionality). This is the main thing
> that has allowed the deployment of new technologies in a world where
> browser upgrades take years to propagate across the market.

After thinking about this some, I have to agree that forward
compatibility is key and is one of the major factors for the success
of the web.

This hasn't really happened though. Many features being developed now
and almost all of the non-trivial layout features are not forwards
compatible. They could have been, but they really aren't.

This is exacerbated by dual mode properties. If margin, border and
padding weren't using in layout calculations then setting browsers
that supported them wouldn't break pages that didn't support
non-static layout. It is this dual role problem that I see and I have
brought up in at least 3 or 4 messages recently and I feel it hasn't
been addressed. If I specify display: absolute; and use a margin to
move it to the proper location then there's a decent change that when
a browser comes across it and doesn't support position: absolute I'm
going to end up with a broken page, but no other mechanism has been
suggested to fully get around the need for margin in layout.
 
> I guess you'd have to pay $50,000 to join the W3C, then join the CSSWG
> and come to our meetings.

So what you're saying is that I have to pay $50,000 to help you with
the process you said you'ld love to hear ideas about. Yeah, not gonna
happen.
 
> CSS2 was released (in 1998) and has been in errata mode ever since. When
> the errata document reached epic sizes, we merged it into the CSS2
> document (it was getting hard to remember what was errataed). This caused
> a large number of new errata to be raised, and we've been dealing with
> those since.
> 
> What you seem to not realise is that "stable" does not mean "no work
> required". If anything, the work of maintaining a spec is more than the
> work of writing it in the first place.

No, I understand pretty well that "stable" means "work". What I
disagree with is the idea that the priority is always refinement over
invention and not some happy medium.

I don't recommend new specs because there's some product to push. I
recommend it because advances in understanding come more often from
invention than refinement. Refinement is good for making something
very good at what it does, but it very rarely opens up new
possibilities.

Refinement can also be very bad reducing your mental model to the
status quo and preventing you from getting away from it.

Refinement makes something practical (e.g. making polio vaccines cost
0.03 USD) and invention allows entirely new opportunities (e.g. cures
cancer).

Both are necessary and I wouldn't want all progress to stop on CSS 2.1
revision, but let's start thinking about new models from which to
work.

> > But then the only way to remove the -orion- part is to get it approved
> > by the W3C.
> 
> Yes. That's a feature, not a bug. We want to promote the use of
> interoperable, standardised properties.

I'll be dealing with this in a separate e-mail as it deserves its own
discussion.

> > 3) Allow for deprecation or the obseleting of grammar elements,
> > properties or values.
> 
> How would versioning do this?

By creating safe havens for old content. Web authors could reference
specific versions of a spec and know that even if later on those
elements were removed, their code would still work. This is the
primary functioning of versioning today. To produce concrete groupings
that allow for advancement by decoupling old work from new work.

-- 

Orion Adrian

Received on Wednesday, 13 July 2005 02:31:24 UTC