Re: Conversion of HTML attributes to CSS2 properties

Chris Lilley wrote:
>David Perrell wrote:
>>
>> Frank Boumphrey vehemently wrote:
>>
>> >>"The UA may choose to honor presentational hints from other sources
than
>> >>style sheets, for example the FONT element or the "align" attribute in
>> >HTML.
>> >>If so, the non-CSS presentational hints must be translated to the
>> >>corresponding CSS rules with specificity equal to zero. The rules are
>> >>assumed to be at the start of the author style sheet and may be
overridden
>> >>by subsequent style sheet rules."
>> >
>> >What this gibberish basically means is that a user agent can choose to
>> >display styling type tags provided there is no conflicting CSS rule!!
>
>Sort of
>
>> Close. How about: "A user agent may display HTML element styling
attributes,
>> such as 'align', 'color', and 'face', provided there are no conflicting
CSS
>> rules in the author stylesheet." ?
>>
>> >The rest is semantics!!
>>
>> I believe that's semantically incorrect. The rest is *gobbledygook*.
>> Semantics is what remains when the gibberish and gobbledygook are
>> exclusively-ORed.
>
>I believe that is gobbledygook. The wording in the specification is a
>more precise formulation of whether such hints are to be processed and
>if so, how; in particular, what happens when there are partially
>conflicting CSS rules.

I grant that a logical XOR of gibberish and gobbledygook may sometimes
result in amphigory rather than semantics. In fact, applying the hypothesis
to the above paragraph indicates that a logical AND may be the correct
procedure.

For example, a semantical investigation into the precision of the
formulation might begin with an inquiry regarding the appropriateness of the
word 'hint', established meanings of which include "a slight indication or
intimation", "a brief or indirect suggestion", and "a statement conveying
information in an indirect fashion." I contend that the existence of this
word in context semantically gobbledygookylizes the entire paragraph.

>The wording makes sense when read in conjunction with the specificity
>and cascading algorithms.

I don't think so. "Specificity" has an established meaning outside the
context of the CSS spec, and, sensibly, the specificity algorithm assigns
specificity of one to an element type selector. Arbitrary devaluation of
element type specificity to zero simply because its declarations are
translations does not make sense except as a convenience.

>The advantage of precise wording is that
>impleentations can implement the same way and thus, hopefully, give more
>consistent results.

If the goal is implementations that implement the same way, "may choose"
would be replaced with "must". To do so, however, would demean "honor".

David Perrell

Received on Friday, 7 August 1998 12:39:16 UTC