Re: A possible presentational hints proposal for CSS 2.1

Ian Hickson wrote:
> (Speaking purely for myself and not for the working group:)
> 
> On Tue, 8 Oct 2002, Stuart Ballard wrote:
> 
>>Why not enumerate the "standard" presentational attributes, and then say 
>>that additionally, all attributes not defined in the relevant 
>>specifications are presentational?
> 
> 
> I think the proposed way is less open to arguments. I could be wrong.

No big deal to me. The only reasoning I can give is that the proposal 
sounds a little bit like "All attributes are non-presentational, except 
in HTML where all attributes are presentational, except these ones". An 
exception to an exception. Which is a little confusing.

> HTML has, I believe, buun end of lined.

I was including XHTML with HTML here, which (actually by the end of 
writing my original message I'd already realized) wasn't supposed to be 
the case.

>>May I suggest including language that allows other XML vocabularies to 
>>explicitly designate attributes as presentational if they want to?
> 
> 
> That rather defeats the point, doesn't it?

Depends what the point is, I suppose. Is it to discourage the creation 
of future languages with presentational attributes, or is it to 
discourage the use of presentational attributes in languages that 
already have them?

Is being able to express existing practice a part of the point, or not?

> If someone can give a very specific example, then I guess we could
> consider it, but I am not aware of any such problem, and I am very wary
> of adding loopholes without very good reason.

Well, there's always SVG and presentational-MathML - I assume that 
(since they're presentational languages) they have presentational 
attributes.

> We wanted to make all of HTML use the new system, only the legacy of
> text/html resulted in the compromise proposal. There is no legacy XHTML to
> speak of (in practice text/html doesn't count as XHTML), so the problem
> doesn't occur there.

Are you essentially writing XHTML Transitional out of existence? IOW, 
are you assuming that *any* XHTML document served as text/xml should be 
XHTML Strict?

If so, I applaud the idea, but I'd like to see it actually enshrined 
somewhere that XHTML Transitional (served as text/xml) is explicitly 
*NOT* a W3C recommendation.

If not, then the need for compromise has nothing to do with text/html, 
but rather to do with versions of HTML that include presentational 
attributes, and that includes XHTML Transitional. The same negative 
effects that happen with HTML Classic also happen with XHTML 
Transitional. And therefore the compromise should apply to it as well.

> Your wording specifically said that some of the behaviour was up to the
> UA; that, in my opinion, is very bad.

I allowed the UA to act differently depending on whether it understood 
the XML vocabulary or not. That's going to happen whether it's 
explicitly allowed by the spec or not: A UA that doesn't understand 
MathML, or SVG, clearly isn't going to render the same way as one that 
does. I just allow that already-existing difference to extend into the 
realm of CSS a little way.

I also allow the UA to use its own initiative to determine the version 
of HTML in use. Again, that's going to happen whether we like it or not 
, for example: Mozilla has a quirks mode setting that it uses to 
completely ignore (aspects of) the spec if it determines that the author 
wasn't expecting standards compliance. Should the spec include a 
description of how and when the UA should trigger quirks mode, or is it 
legitimately UA-dependent?

  It also introduces dependencies on
> XHTML, which the working group has tried very hard to avoid, on the
> request of the HTML WG, which said it doesn't want to be treated
> specially.

Rather, I'd say, it extends the rules in general so that any XML 
vocabulary can be treated specially, and then identifies the way in 
which XHTML in particular should be treated. I'd assume the objection is 
to "breaking the rules" for XHTML, rather than with saying exactly *how* 
the rules are applied to XHTML. For example, does XHTML not also still 
have access to the "." class selector? Presumably it's not doing 
anything that's specific to XHTML here, just XHTML applies a general 
rule in a specific way that's useful to it.

Stuart.


-- 
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/

Received on Tuesday, 8 October 2002 15:31:16 UTC