Re: several messages from Orion Adrian

On Sat, 2 Jul 2005, Orion Adrian wrote:
> 
> Due to the excessive length of this, I'm going to cut it down a bit
> and deal with major issues.

Ditto.


> > JS versioning has been more explicit but again has been an annoyance 
> > more than anything, requiring implementations to have multiple code 
> > paths and making it harder to debug implementations.
> 
> 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.


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


> What is the mechanism to remove bad design decisions from the language 
> in CSS?

We remove them. Done. Where's the problem?


> > > So you kind of maintain them like they're maintained now, but you 
> > > concentrate on moving forward.
> > 
> > And where would the extra resources come from? Browser vendors are 
> > completely swamped with bug fixing _today_, in the one-version world. 
> > There is *no way* that multiple versions as you describe could 
> > possibly be implemented -- we just do not have the resources for it.
> 
> 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?


> > > > It may be "easier" but it isn't "easy".
> > >
> > > Did I say easy?
> > 
> > If you didn't mean "easy" then I fail to see your point. We don't have 
> > the resources to create the test suites _today_, in the one-version 
> > world, and you are suggesting a world needing more test suites.
> 
> Is not easier a good thing even if it's not easy? I don't understand how 
> you can say, if your suggestion only improves my life a little, it's not 
> worth it. It must make my life easy. Easier isn't a good thing?

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


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


> > CSS1 will not be updated, no. Implementors only refer to CSS2 at this 
> > point, so there is no need to update CSS1 (which is a subset of CSS2).
> 
> Why not? What if I bring up an issues with CSS 1? What would I be told? 
> That the current version is 2 or that's it's fixed in 2?

Yes.


> > Incidentally, both the layout and the structure can change 
> > dynamically. The structure can change through DOM calls, the layout 
> > through those and even simpler things like:
> > 
> >    td:hover { display: table-row; }
> 
> How about this? Prevent reassignment of display in in pseudo-element or 
> pseudoclass. Doesn't the ability cause problems anyway with things like 
> ::first-line { display: none }?

What properties apply to an element or pseudo-element depends on things 
like the 'display' property and the pseudo-element itself. So no, you 
can't prevent assignment of 'display' in pseudo-class cases. 


> As I see it, :column() only makes sense on display: table-* so it has to 
> cover the presentational case and not the semantic case. Once the 
> display: change is removed, the threat seems to be gone and now it's 
> possible to check to see what column you're in since you know the 
> display classes of all your parents before hand.

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


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


> > > Has anyone thought of maybe finding a better process.
> > 
> > Certainly one has thought about it. One has not found any good 
> > solutions.
> > 
> > If you have any ideas, I'm sure we'd love to hear them.
> 
> Sure. Where can I get detailed information on the processes currently in 
> use and can I have time to do interviews to see how the individuals 
> using the current processes actually use them.

I guess you'd have to pay $50,000 to join the W3C, then join the CSSWG 
and come to our meetings.


> > > Actually I'm of the mind that the specs have to move forward even at 
> > > the cost of the current ones.
> > 
> > IMHO new specs are irrelevant if old specs are not well implemented.
> 
> Once a spec is released, is there a reason it doesn't move into the 
> errata portion of maintenance? Shouldn't corrective work be done on the 
> new version so that the version being commented on can be stable?

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.


> > > What about non-working groups? I'm free to develop my own XML 
> > > grammar, but I'm not free to develop my own styling properties.
> > 
> > Yes, you are, so long as you use a vendor prefix, e.g.
> > 
> >    -orion-layout: rect(0,0,100%,100%);
> > 
> > ...or whatever. Mozilla, Opera, Apple, Microsoft, YesLogic, and OMA 
> > have all done this already. It is even semi-legitimised by the spec.
> 
> 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.


> Bert wrote:
> > You (Karl) can read the minutes of the last CSS face-to-face 
> > meeting[1], where we tried to lists all the reasons why people asked 
> > for versioning information and found that they fall into two 
> > categories:
> > 
> >   1) To be sure that the style sheet works on a particular browser.
> > 
> >   2) To be sure that the style sheet conforms to a some policy, e.g.,
> >      company policy or school assignment.
> 
> 3) Allow for deprecation or the obseleting of grammar elements, 
> properties or values.

How would versioning do this?

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

Received on Tuesday, 12 July 2005 01:03:38 UTC