Dan Williams wrote:
"obvious to everyone" - assuming that everyone understands
something the
same way is about the worst way to write a specification. You need to
explicitly state what that understanding is, otherwise it's not a
specification, it's a vague idea and everyone will have a different
understanding of that idea. And a different, potentially incompatible
implementation of.
I'm sure the Plasma and Unity developers behind the spec would have accepted
(and in fact would still accept!) clarifications added by those who think
the spec is too vague as is. If it's obvious to them, why should they be the
ones to spend the time to write more details?
Try understanding what the authors probably meant (putting yourselves in
their position), then writing it up, and sending the patch to the spec for
review to them.
Since one principle of the spec is to not set rendering details in stone
forever (which is very reasonable), that kind of clarifications should be
presented like, e.g., the suggested glyph shapes in the Unicode standard,
which are not normative. If they are written like that, I don't think the
spec authors will have any reason to reject them.
So just because something is in use, but hasn't been standardized
or
been through any kind of standardization discussion, it should
automatically be adopted as-is? I think not...
For a specification already in wide use (it had already been used by Plasma
for years and Unity for months when the changes were requested), you have to
weigh any proposed changes against the impact on the existing
implementations. Nitpicks on method names that are not user-visible are NOT
productive change requests. Changing those names breaks all the existing
implementations and does not bring the end user anything. It's as if you
proposed to fix the "Referer" typo in the HTTP standard, it is just not
practical.
Kevin Kofler