- From: Chris Lilley <chris@w3.org>
- Date: Tue, 8 Oct 2002 20:21:33 +0200
- To: www-style@w3.org, Stuart Ballard <sballard@netreach.com>
- CC: Ian Hickson <ian@hixie.ch>, Rijk van Geijtenbeek <rijk@iname.com>
On Tuesday, October 8, 2002, 6:37:51 PM, Stuart wrote: SB> Chris Lilley wrote: >> On Tuesday, October 8, 2002, 5:28:07 PM, Stuart wrote: >> SB> May I suggest including language that allows other XML vocabularies to >> SB> explicitly designate attributes as presentational if they want to? >> >> >> Such as, for example, languages that are themselves presentational? >> That would be a lot better than merely looking at HTML and deciding >> that all XML has no presentational attributes. >> >> Rather than talk about 'transitional phases' and so forth, i suggest: >> >> a) distinguishing between presentational and non-presentational XML >> grammars. For example, MathML has two grammars, one of each type. >> >> b) stating that non-presentational grammars should not have, or add, >> presentational attributes. SB> Unfortunately, as you point out later, this doesn't fit with several SB> already-existing XML vocabularies. I'm not sure that I do - which ones were you thinking of that were a) in XML b) were not presentational c) had presentational attributes? >> c) stating that presentational attributes should have the exact same >> name, syntax, and semantics as the corresponding property. They then >> become zero-specificity "default styling" which is readily "restyled" >> by any CSS selector. this is, for example, the case in CSS. SB> I'm not sure that all attributes in classic HTML can be shoehorned into SB> this rule. Are you? Since classic HTML is not XML, whatever it does or does not do is not relevant to this part of the discussion. But, I would assert (since you ask) that classic HTML does none of the three things that I suggested: - it does not clearly distinguish between presentational and non presentational, claims to be one and is pretty much exclusively focused on the other. - the 'grown, not designed' attributes and elements atre mainly distinguished by not being the same as the corresponding properties in name, or allowed syntax, or presentational effect; neither one to one nor by a simple mapping. Further, it is experience with the messy failure to do these things that motivates my list. I was thinking primarily of XSL and of SVG when writing the list; MathML does some of it and fails some of it. >> While being more realistic and less antagonistic to other W3C >> specifications, this approach also - by encouraging use of stylistic >> attributes, rather than the style attribute, for presentational >> grammars - encourages restylability. Currently, lots of tools that >> construct content incrementally spit out xml elements with style >> attributes on each element. Due to the high specificity of the style >> attribute, this makes later restyling hard in CSS2 and impossible in >> CSS 2.1 SB> I agree with this reasoning, but I'm not going to go into it because SB> it's a tangent from the issue at hand. I see them as closely related; the effect of what one spec does on what another spec does, or on what implementations do, cannot be ignored. SB> I hope that the W3C eventually agrees with this and comes up with SB> a solution, though :) Yes. Working on it. >> Presentation attributes are not just a legacy issue. SB> Point. >> SB> Thus, I'd suggest treating XHTML Transitional as >> SB> HTML, >> >> No!! Its XML, uses the XML Object Model, etc. Don't muddy things >> further by treating some XML as HTML. SB> I meant "in the same way as the proposal currently treats HTML", not SB> "pretend that it *is* HTML". Ah - okay. >> SB> For other XML languages where the document type or schema >> >> or namespace (for namespace qualified attributes) SB> Point. >> This is where I really wish that the presentation attributes in XSL >> (and in SVG) had been defined in their own namespace. I still think >> that would have been a better solution. SB> I agree, but since they're not, we need a solution for those existing SB> specs. To be clear - I proposed this, but it was not accepted. I was just noting in passing that it would have made the 'unknown XML grammar' case more tractable; attributes that are namespace qualified are easier to deal with than anonymous attributes in the element partition, that might or might not be the same as similarly named attributes in a different element partition. SB> And, of course, for XHTML Transitional, which falls into the same SB> category (some presentational and some semantic attributes). SB> I think my language (with your specific proposed additions, such as the SB> namespace issue) could cover MathML, XSL-FO and SVG perfectly well. Probably. I would need to see it all as one piece of text rather than a series of diffs to be sure, but I agree its likely that it would. SB> In SB> fact, the treatment of classic HTML (and what I proposed for XHTML SB> Transitional) is really just part of the same thing, except that the use SB> of CSS with HTML is so ubiquitous that it makes sense for the CSS SB> authors to explictly list the presentational attributes for that language. Perhaps. SB> The only difference is that now the treatment of presentational SB> attributes is no longer just a legacy issue, but since the proposed SB> language never mentioned "legacy" at all, the bulk of it still stands. Point taken. -- Chris mailto:chris@w3.org
Received on Tuesday, 8 October 2002 14:22:00 UTC