RE: CSS Charter (Apple's Wishlist)

Daniel Glazman wrote:

> David Hyatt wrote:
> > So Microsoft can propose cool new ideas like:
> > 
> >
> > 
> > ...and have them worked on because they happen to fall under the scope 
> > of the current charter?
> > 
> > However when Apple proposes something that happens to lie outside the 
> > scope of the current charter, your response is "No! We shouldn't do that!"
> > 
> > While I can understand that your engine is struggling to play catch-up 
> > after years of neglect on your company's part, that's no excuse for 
> > holding the rest of the Web back.  Some of us have largely completed 
> > CSS2.1 and would like to see CSS improve significantly in the coming years.
> > 
> > Finally, Silverlight implements many of these ideas and is being pushed 
> > for use on the Web.  I guess "cool" is ok when it's part of your 
> > company's proprietary technology stack.
> David, like it or not, Paul has a point : the CSS WG has not released a
> single REC in ten years...

And why is that Daniel? How many years did it take for Microsoft to come to the party? Now that all implementers are on board we have a chance of doing it correctly. At this point Microsoft is struggling to create a CSS2.1 standard compliant UA. They are getting close but indeed there are bugs.

The parsing or non-parsing of commented selectors has taken IE8 backwards and now is worst than IE5 or IE6 in some cases.

When IE8 stops selecting comments this page will not be a disaster (not mentioning support for true XML, IE9 perhaps).

Also the whole Meta X-UA-Compatible and version vectors are completely broken.

I was explicitly invited to join Tech Beta but I guess someone in Microsoft got wind of what was happening on the CSS Discuss list when IE8 was released for beta testing. Yes I an advocate for standalone UAs. So Microsoft desire to hold back CSS4 is I think something to do with IE8 wanting to become CSS21 complaint first since they realize there are holes in CSS2.1. I would truly like to help them with the holes (there are many) in the specs and with IE8 generally.

> Whatever is the interest of your proposals, zilch, low, high
> or fantastic, prioritizing our work is in itself a priority
> and we must push our existing CRs to REC. It's not only a question
> of standard, it's also a more complex question of IPR. And that's why we
> absolutely need the discussions on the charter we're going to have
> tomorrow.
> I hope you agree with that.
> </Daniel>

Please excuse my ignorance but what does IPR stand for? I know about Proposed Recommendation.

I have put up a test series of attribute selectors. This was not a hack sheet (as some may have assumed) but designed to understand how a CSS parser logically parses attribute selectors including the wild card selectors. I through logic divided these into two tests either matches or non matches.

But there was problem in my test about one particular wild card [alt*=val]. So the CSS WG spent what I believe is wasted time deciding from a logical perspective that [alt*=val] should not match. I will provide one of my random links.

Instead of deciding if the [alt*=val] should match without any 'preconceptions' (sometimes called a process of lateral thought) the CSS WG went for the logical approach. Why should the CSS WG dispute the logical parsing of CSS by a CSS parser? Remember who built these parser, they must follow logic. It was Gecko that is getting it wrong. All other UAs are getting it right. The whole tests series (including structural class) is correctly and logically parsed by Opera 9.5. Safari errs with a minor specificity detail but otherwise is correct. IE8 is correct in all test involving attributes apart from lack of support for negation. Apart from a much improved layout engine in Gecko 1.9 there is no extra support for CSS selectors from Gecko 1.8. A new AcidTest4 is now needed for Safari since it is leading the charge into the future, CSS4 perhaps. Go for David.

Apart from the issues about [alt|=""] and those concerning namespace, I see the selector module is close to being ready for CR. Background and color module is getting close to LC.

I did ask many months ago if the margin-left of and overflow box begins from it parents' padding left or content left.

Which implementation shows this correctly? IE8 and Gecko 1.7~1.9 agree one way where the margin-left begins from the Overflow box. Opera shows close but the second example has dropped. Safari however shows the margin-left from the container. Then there are differences in the original test.

And more testing

Which browser is showing correctly?

I didn't get a reply to my original questions. I can only assume that that's because know one knows the answer. How can anyone know the answer with all the holes in CSS2.1? This would indicate to me that CSS3 is has had greater progress made with it than CSS2.1. I now have worked out that an overflow box has its overflowed width calculated first and then both the margin right of the child elements and padding-right of the overflow box is deducted from the calculated width (or should I say clipped).

But there no mention in the spec that this is what a UA does.

Which UA handles these tests correctly?

I say Firefox 3.04 is close. And the next test cases.

This time Opera 9.5 come out on top.

Lastly I don't appreciate off-line messages like this (many months old):

> What about if I wanted to style two div differently. They don't have
> to be styling an element with a "lang" attribute. I could have this.
> <div class="some-content"></div> <div class="some-content special"></div>
> To style the former I could use
> span[class|="content"] {}

Or you could use .some-content:not(.special), which would be less
failure-prone anyway (e.g. wouldn't break if the order of the classes is

I'm not saying you can't find use cases for |=. But the one you suggest
is silly, I'm sorry. 


I have a used case for.

div.x, dix.y {} /* legacy style */
div[id="x"] {} /* x special style */
div[id="y"] {} /* y special style */
div[id*=""], div:not([id*=""]) {} /* progressive enhancement general style */

E[att*=val] is not silly. I believe that I can use it.

Please note that I am new here and sometimes what you all talk about goes right over my head but remember I  am using CSS (an author) and I am pushing CSS to it's limits in what I understand of it. If what I say is wrong tell me so. If what I say in unnecessary tell me so. If what I say you don't know the answer for then tell me you don't know the answer. If you wish to ignore my questions or if you believe that what I contribute to discussions is irrelevant, then why am I on this list in the first place? Is what Alan Clarke wrote about correct?


Received on Wednesday, 26 March 2008 07:32:02 UTC