Quote:
Originally Posted by davidfor
Well, maybe I should have stated it as: "It would be a damn good idea if you did this, but, if you have a good reason not to, then you don't absolutely have to do it".
|
That would have been a considerably closer restatement, yes. My issue with even that version is that it conveys the sense that the feature under discussion is a bonus, a nice value-add where losing it is no big deal. That’s not at all how I read 2119. I see their “should” in the same sense as “this is a very important thing, and we strongly urge you to do it, but if your specific situation is truly exceptional, we’ll grudgingly let you go with a stern warning.” It’s not quite the absolute “must,” but it’s extremely close to it.
Quote:
|
Originally Posted by davidfor
And it comes down to, what is a "valid reason". I have no real idea why Kobo decided not to do this, but, I assume they had what they considered were valid reasons. Whether I would agree is a separate matter.
|
Consider this datum: The key specifications put forth by W3C – HTML, XHTML, CSS, everything – get finalized as “Recommendations.” There is no higher level over there; that’s the top. So when they say compliance with a given rule is “recommended,” that’s considerably stronger than the take-it-or-leave-it advice of “it looks like rain, so I recommend bringing an umbrella.”
That’s the context of these documents. That’s the environment and the mindset for the people formulating them. No, it’s not an absolute “must” – but it’s considerably stronger than “get a note from Mom and we’ll let you slide.” When you (and others) water that down to “meh, it’s not absolutely required, so it’s technically optional,” you misrepresent the intent of the specs.
Programmers are extremely wary of absolutes. We tend to avoid them, even in our documentation, because we know it’s a big wide world out there with a lot of weird situations. On occasion, exceptions need to be made, and 2119-should allows for that. No reputable programmer of my acquaintance would even consider breaking a should-level rule unless there really is no other option.
Nothing about leaving monospace support out of a dedicated e-reader approaches that level.
See, I look at those should-not-must exceptions I’ve cited and think, “what if someone’s writing an EPUB reader for an old PalmPilot?” Well, different fonts probably wouldn’t be an option there. Such an app would have to undergo some brutal cutting to be feasible, and in that context… yeah, map everything to the one available system font and ignore embeds. Sucks to do it, but there you go. How about non-visual rendering engines, like voice or Braille? Hard to speak in monospace or serif, but even then, I’d look into using different voices or inflections before caving and saying that there’s no way to obey the rule.
Those are the sorts of “valid reasons in particular circumstances” that “should” means. Serious technical limitations… and those simply don’t exist in this case.