Re: Fwd: several messages from Orion Adrian

On Tue, 12 Jul 2005, Orion Adrian wrote:
> > > 
> > > 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?

You can use features that are obsolete -- heck you can use features that 
never made it into any spec at all, like <marquee> or <embed>, both of 
which are used on millions of pages world wide -- and they will work.

Your document will be non-conforming, of course. But we're talking about 
implementation requirements, not document conformance requirements. My 
point is that versioning in HTML doesn't help implementors because they 
still have to implement obsolete features since documents depend on them.


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

Yes. Just like with HTML (which you said was versioned). Just like with 
codecs, for that matter. A video player can't just stop supporting old 
video codecs, otherwise old video data will stop playing.


> My understanding of this is that a browser must have one engine that 
> supports all properties that have ever been used significanty.

Yes. And my point is that doing this is orders of magnitude easier than 
maintaining multiple engines that each support their own set of 
properties.


> > > 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.

Only to the extent that if you have a high market share and have not 
released a browser for a long time, you could decide to give up on being 
compliant to the previous version of the spec and just arrogantly assume 
that people will use you as the de facto standard instead of the spec.

Believe me, as far as the other UA implementors are concerned, that is 
highly anti-social behaviour.


> 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.

And then you result in quirks mode, which has no specification and which 
is therefore a nighmare to work with.

It seems unlikely to me that you are advocating a world where quirks mode 
scenarios are the by-design endgoal, but it sure sounds like you are.


> > 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.

That works well for simple systems, but is completely impractical for 
real-world complex systems like the Web, operating systems, graphical 
renderers, interactive multimodal user interfaces, etc.

I would be very interested in seeing a (formal) proposal for a system that 
could be tested as you describe while still providing medium to high 
quality typesetting on multiple platforms, media, devices, and user 
modalities, while still being very fast to render, while still allowing 
for user overrides, while still catering for highly interactive 
applications, and while still being simple enough to author that it could 
get the formidable level of uptake seen by HTML, JS, and CSS.


> 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.

If you believe this, please raise such issues when the relevant documents 
are in Last Call (or earlier), by concretely pointing to specific features 
that are not forward compatible. It is certainly the intent of the WG to 
specify new features in such a way that they are forward-compatible.


> > 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'd love to hear ideas about. Yeah, not gonna 
> happen.

Well you're the one who said you thought it was broken; I don't have a 
problem with it... (And note that I didn't make up the W3C membership fees 
nor the confidentiality rules, so it's not my fault.)


> > 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.

It is a happy medium. The changes we are making to CSS (even the changes 
we discussed today at our teleconference, for instance) are changes I 
would consider important changes for ensuring interoperability. If they 
weren't, I would agree with you.


> > > 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.

CSS achieves this without versioning. Implementations continue supporting 
old features even after they are obsoleted. For example, the CSS2 System 
Colours have been deprecated (in CSS3) and will probably be obsoleted 
altogether (in CSS4) yet implementations will always support them.

HTML has the same thing. HTML has no feature-wise versioning (it only has 
interpretation-wise versioning, and even that isn't officially in the 
specs), yet it has deprecated then obsoleted some features (e.g. <font>), 
without authors having to worry about their old documents failing 
(implementations will continue to support <font> for decades to come).

This is all possible without having to ship multiple rendering engines, 
with all the bloat, testing cost, implementation cost, maintenance cost, 
and documentation cost that that would imply.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 13 July 2005 02:56:09 UTC