Re: CSS3 and Selectors

On 9/9/02 6:19 PM, "Ian Hickson" <ian@hixie.ch> wrote:

> 
> On Mon, 9 Sep 2002, Adam van den Hoven wrote:
>>> 
>>> If an image is missing, then it will be replaced by the alt
>>> text. If the image is not missing
>> 
>> No, it creates a box of some size [...]
> 
> Oh, right, IE still does that doesn't it.
> 
> Sorry, it's been so long since I've used IE that I'd forgotten there are
> still browsers our there which get this wrong. Mozilla, Lynx and Links,
> the three browsers I use regularly, get this right.

Perhaps in your opinion.

This particular default presentation is informatively noted at best, and
unspecified at worst.

e.g. there is nothing wrong with this in a user agent default style sheet:

img { display:inline-block }

To more fully specify this, we need pseudo-classes that allow you to select
replaced elements that are
 (a) in the state of attempting to load (but have not received anything to
display)
 (b) have failed to load their replaced content.


> Anyway, if you include the text in the span, you don't need to include the
> text in the alt="" attribute, in fact doing so is rather confusing if you
> have images disabled, as it will be as if the text was there twice.

True.

>> What I meant was that I think something LIKE XPath would make for a very
>> nice CSS selector. That is, I want to apply CSS properties to "All the
>> input tags that are children of a fieldset whose legend has an input
>> element whose type attribute is 'checkbox' and whose checkeded attribute
>> is 'checked'" or in other words:
>> 
>> fieldset[legend/input[@type='checkbox' and @checked='checked']]/input{
>> background-color:grey; color:dark-grey;}
> 
> Ah yes. My proposal from several years ago would say this in CSS as
> follows:
> 
>  fieldset:has(> legend input[type=checkbox][checked=checked]) > input {
>    background-color: grey; color: dark-grey;
>  }

Yikes and double yikes.

> We'll see if CSS ever gets something like this.

Indeed.

>> The reason I made the comment (which I should not have, it wasn't at all
>> useful) was that one could always refer to the text of an element with
>> XPath using a/text() so using XPaths for selectors would automatically
>> accomplish what I'm talking about.
> 
> I'm not sure that it would be any better than the 'content' mechanism.

Agreed.

Tantek

Received on Monday, 9 September 2002 22:15:59 UTC