W3C home > Mailing lists > Public > www-style@w3.org > April 2005

Re: Style confirmation descriptors

From: Barry <wassercrats@hotmail.com>
Date: Fri, 8 Apr 2005 14:05:05 -0400
Message-ID: <BAY102-DAV13EFB8C53C2B302DFC8247B93F0@phx.gbl>
To: "Mikko Rantalainen" <mikko.rantalainen@peda.net>, <www-style@w3.org>

Mikko Rantalainen wrote:
> Okay. The problem with this feature is that you *have to* define how 
> 'direction' and 'find' work. It may be a rough description, but you must 
> have some idea how it *could* be implemented as a computer program.

I'm a bit of a programmer, so I could go as deep into that as necessary, but 
I was relying on others to fill in the blanks. "Direction" defines the 
direction in which the "loc" area will be scanned in search of the things 
described in "find." More than one scan would be performed in the specified 
direction if the loc area is larger than the content described in find's 
descriptors. For example, if the direction is lr or rl, scans would start at 
the top and the last scan would be at the bottom. Details on how to match 
something described in "find" depends on what descriptors are allowed. The 
debate on that could go on forever, so I won't get into that unless there 
seems to be serious interest in this.

> Also, you have to figure out how you encode those "descriptors" in CSS 
> terms if you want to inlude those descriptions in the CSS file.

Once it's decided what kind of content (colors, borders, etc.) should be 
allowed in "find" I could offer an opinion on how to write it up in CSS, but 
I don't know what lower-level limitations there are. I don't know about DTDs 
or even how to read some of the specifications, and I won't learn it unless, 
maybe, there's serious interest. Most of you seem to know about this stuff, 
but I'm just a guy with an idea. At least I'm not asking how to fix my 

> is this kind of feature needed at all because all you could find is that 
> UA failed to style the page as you intended? That doesn't provide even 
> close enough information to fix the problem with some other CSS rules.

I know, like sound stuff, but I think it would help for things like 
detecting whether there's a margin where should be. You wouldn't even have 
to know if it's a margin. In my example, I allow "red" to be used as a 
descriptor. It could be a red anything. Sometimes that's a good enough 
description. Often, you would have a choice of descriptors that would do the 
job. Selecting the right descriptors and the right location and size of the 
area to be scanned could probably fix most CSS cross-browser problems 
without the need for hacks or conditional comments. At least the problems I 
tend to have.

> If, on the other hand, all you want is to ignore some ruleset because UA 
> fails to correctly implement it, @require-all (see recent discussion) or 
> similar feature would work for that purpose and would be *much* easier to 
> implement in UA.

Maybe not if you consider the extra testing that would need to be done, and 
the standards that would need to be created to determine whether a feature 
should be considered working. And you have to rely on the browser 
developer's honesty. Plus whatever other issues you're all talking about. 
I'm not following that discussion very closely. 
Received on Friday, 8 April 2005 18:05:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:17 UTC