Benefit of using the -vendor- prefix

> [Original Message]
> From: Michael Day <mikeday@yeslogic.com>
> Subject: RE: [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)
>
> > Just because you think "A4" is obvious does not mean that others will
> > think so, or that it will turn out to be the best solution.  "A4" is
> > certainly an obvious choice to consider, but for the reasons I have
> > already given, I don't think that it is the best choice.
>
> It is not that *I* think that it is obvious, it is that A4 paper is
> commonly referred to as such by the wider user community. It is marketed
> and sold as being "A4 paper" and printers and photocopiers offer "A4"  
> paper trays and folders are sold as "A4 folders" for holding A4 paper and
> so on and so on. The ISO acronym never comes up outside of forums devoted
> to standardisation such as this one.
>
> Allowing the ISO prefix is fine and consistent. But *requiring* it is
> unnecessary, redundant, pedantic and confusing for ordinary users.

Just as the distinction between the "center" and "middle"
keywords for the 'text-align' and 'vertical-align' properties
is confusing.  Either the author will have access to the documentation
or he will using an authoring tool that hides that detail from him.
Assuming that he is writing his own CSS by hand how would he know
without consulting documentation that he needs to know to use:

@page {size: keyword;}

instead of:

:root {pagesize: keyword;}
or
:root {size: keyword;}
or
:root {height: 11in; width: 8.5in; display: page}

or any of the other ways that could be used to specify a page size?
It is only self evident once you are aware of it.  Once he is aware of
it, he might be bemused, but I doubt that he will be confused. (At least
not if the documentation is any good.)  Furthermore,  in this case
not using the prefix will just leave users confused because they will
have to remember when they can avoid using the prefix and some
will forget and wonder why

@page {size:b4}

isn't working as expected.


> > Had you followed the recommendation in this case it would have been:
> > 
> > @page {size: -yeslogic-a4 }
>
> One look at this monstrosity makes it pretty obvious why we did not
> implement it this way. Not to mention that identifiers cannot begin with a
> hyphen-minus in CSS 2, the highest level of CSS that is currently a W3C
> Recommendation (and has not been deprecated). Only the Working Draft of
> CSS 2 Revision 1 allows this syntax.

So does the working draft of CSS 3 Syntax, and it is in use by both Opera
and Mozilla, so I truly do hope your product's CSS tokenizer is prepared
to encounter such identifiers even if it doesn't use them itself.
You're the one who used yeslogic-a4 in your example, the only thing I did
to it was add the recommended - to the front.  If the length is
objectionable
then a simple -yl- or -y- as Tantek suggested should do.

> If we were implementing a new property that was likely to conflict with an
> existing or future property from another vendor, then we would need to
> qualify it appropriately to avoid conflicts. But as I said before,
> qualifying "A4" in this manner is ridiculous.
>
> Similarly with the extension in the usage of the portrait and landscape 
> keywords:
>
> @page { size: A4 landscape }
>
> It would be difficult to keep a straight face while documenting this:
>
> @page { size: -yeslogic-A4 -yeslogic-landscape }

Actually the landscape and portrait keywords are in CSS2, so there is
no need to prefix them as you aren't using them to mean anything different
than what they already meant.

> > (Note the extra - in front.)  Yes, the recommendation does put an extra
> > burden on those who seek to extend the standards beyond the current
> > recommendations, but I can't fault the reasoning behind it.
>
> Standardisation follows implementation, not the other way around.

Ideally they are complementary, and in this case the W3C has
provided a recommended way to experiment with implementation
so as to leave them free to handle standardization without having
to worry that they are conflicting with existing implementations.

While in this case "a4"  is not likely to cause problems, what if
the IEEE PWG had chosen to use instead of the keywords
"na_govt-letter" and "na_govt-legal" for the former US government
paper standards the keywords "na_us-letter" and "na_us-legal"?
In the context of that standard, that would be just as reasonable
as the leywords that thet IEEE PWG did choose to use.
 In the post you quoted earlier, you said Yes Logic was using
"us-letter" and "us-legal" for the 8.5"x11" and 8.5"x14" sizes that
the IEEE PWG standard identifies as "na_legal" and "na_letter".
In this case your use of the "obvious" choice could have caused
real problems beyond your just having to support a few extra
 keywords, as others could have chosen to extend their UA
to use those keywords as "na_us-letter" and "na_us-legal".
That's the main benefit of using the -vendor- prefix:
to protect your own product in case the standard or another
product that extends the standard ends up doing something
different than what you think is the "obvious" choice.

Received on Saturday, 24 January 2004 01:28:08 UTC