CSS2 + errata

Is there an (un)official version of the CSS2 Spec that includes the
changes from the Errata (
http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html ) ?

Re: CSS2 + errata

Also sprach Simon Hill:

 > Is there an (un)official version of the CSS2 Spec that includes the
 > changes from the Errata (
 > http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html ) ?

Good question. The CSS WG is in the process of preparing a version
with errata folded in, rather than having to colsult an external
source. Also, we're considering cutting some features that are not
widely implemented. We plan to send out a document for review shortly.

Cheers.

-h&kon
              Håkon Wium Lie                          cto °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome

Re: a:hover and a:active and named anchors

Coises wrote:
> I'm going to guess that what that principle means (I don't recall the
> original statement, if I ever heard it) is that the determination of which
> *elements* may be matched by a given a selector cannot depend on the CSS
> properties of (any) elements.
> 
> This does not apply to pseudo-classes and pseudo-elements, though.  For
> example, in CSS2, the ":first-line" pseudo-element can apply only to a
> block-level element; but whether an element is block-level or inline-level
> is dependent on the "display" property.

Pseudo-elements are a case of where a property ('display') on another element 
(the block) causes a new element (in this case, pseudo-element) to be generated. 
This then causes the new element to find which rules match it.

The CSS model is applied on a per-element basis, in document order, like this:

For each element:
    1. Find all rules matching the element or pseudo-element.
    2. Apply all the relevant properties.
    3. If this has created any new elements or pseudo-elements, add them to the
       list of elements to process.

Step 2 cannot affect step 1 of the same element or pseudo-element.

Note that 'display' doesn't actually change which rules match '::first-line' -- 
the same rules match, it's just a matter of whether the styling system does 
anything with those rules or not (i.e. whether the first-line exists or not.)

Revised "mobile profile 1.0"

The Candidate Recommendation of the "CSS mobile profile 1.0"[1] has
been updated. The changes are small, but hopefully avoid some
incompatibilities:

  - Alternative style sheets are now a "should" instead of a "must"
  - The '>' combinator (child selector) is now required
  - System fonts may be ignored

In addition, we included the "exit criteria" that define when the spec
can be considered successful. They were already mentioned in the test
suite[3], so they are not new, but now they are easier to find.

For those who want to see the exact differences, I've created a diff
file[2]. (It's created by a tool that is not very smart about HTML,
though...)

[1] http://www.w3.org/TR/2002/CR-css-mobile-20020725
[2] http://www.w3.org/Style/css2-updates/CR-css-mobile-20020725-diff
[3] http://www.w3.org/Style/CSS/Test/#css-mobile

Bert
--

-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert <at> w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Re: a:hover and a:active and named anchors

On 8/1/02 2:09 AM, "Ian Hickson" <ian <at> hixie.ch> wrote:

> 
> Coises wrote:
>> There is precedent for this in an existing  CSS3 working draft; see:
>>      http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-input
>> (the "user-input" property determines whether an element can take
>> the :active state).  An analogous infinite loop is noted and disallowed.
> 
> That property will not appear in the final version of this spec.

Actually, this spec is being replaced by a CSS3 module: basic user interface
- which will hopefully be published any day now, and has dropped the
"user-*" properties due to lengthy reconsideration.

> It was an 
> error.

Not an error, perhaps just ill-conceived.

It is technically possible to have a property which affects a pseudo-class,
you just have to disallow (e.g. Ignore) setting that property in a selector
which contains that pseudo-class.  However even _that_ is limited in that if
you have two such situations, they could trigger each other.  And even then
it is possible, by disallowing setting both properties in both
pseudo-classes.

Needless to say this would add significant unnecessary complication to both
the authoring model and processing model, and therefore the group decided a

height as percentage and inheritance

In the following example a p has a height of 4in;
the div inside that has height: 50% and the div
inside that has a height: inherit. In reading the
spec I assume that the inner div should inherit
the computed value (not percentage). This is the
behaviour Mozilla uses. But IE6.0 (Win32) and Opera6.0
seem to ignore height: inherit and use height: auto
instead.

Comments?
- Jacob

<html>
<head>
<style type="text/css">
div { overflow: hidden; border: solid thin black; padding: 0.5em }
div.one { height: 50% }
div.two { height: inherit}
</style>
</head>
<body>
<p style="font-style: italic">
Below is a <b>&lt;p&gt;</b> with a height of 4in. Inside it has
a <b>&lt;div&gt;</b> with height 50%; inside is another <b>&lt;div&gt;</b>
with height set to inherit.
</p>
<div class="one">
a
<div class="two">

Re: height as percentage and inheritance

Hello ex1),

On Saturday, August 3, 2002 you wrote:

> In the following example a p has a height of 4in; the div inside
> that has height: 50% and the div inside that has a height: inherit.

The 'P' stuff isn't in your code example. And that is a good thing, as
P can't contain DIV.

> In reading the spec I assume that the inner div should inherit the
> computed value (not percentage). This is the behaviour Mozilla uses.
> But IE6.0 (Win32) and Opera6.0 seem to ignore height: inherit and
> use height: auto instead.

Support for 'inherit' can be called 'shaky' at best in Opera 6.
Mozilla's behavior is correct.

Greetings,
 Rijk                            mailto:rijk <at> iname.com

Mot du Jour:
Make it as simple as possible, but no simpler.

<none>

Interaction of border-color and the inset and outset border styles

I just noticed an interesting issue in rendering inset and outset
borders of a given color. There are three basic ways of doing this:

1) Lighten the top and left borders from the specified color
2) Darken the bottom and right borders from the specified color
3) Both

As far as I can tell Mozilla does #3 (as does Opera 6.04, though the
latter changes the color a lot less) while IE6/Windows does #2.  As a
result, using the same border-color for an outset border on a dark
background will make it either nearly-invisible in IE or near-white in
Mozilla or Opera.

Is this something that should remain completely
implementation-dependent?  Or would it be worth standardizing this
behavior somehow?

Boris
--

-- 
Ninety-Ninety Rule of Project Schedules:

The first ninety percent of the task takes ninety
percent of the time, and the last ten percent takes the
other ninety percent.

Re: CSS2 + errata

On Thu, 2002-08-01 at 15:17, Simon Hill wrote:
> Is there an (un)official version of the CSS2 Spec that includes the
> changes from the Errata (
> http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html ) ?
> 
> 

Bump. :P