w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-127: Simplify characterization of link types - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2011-03-04 to 2011-03-11.
4 answers have been received.
Jump to results for question:
- Objections to define link types to have the same semantics independent of the element on which they appear
- Objections to optimize the spec's editorial style for legibility.
1. Objections to define link types to have the same semantics independent of the element on which they appear
We have a Change Proposal to define link types to have the same semantics independent of the element on which they appear. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to define link types to have the same semantics independent of the element on which they appear |
|---|---|
| Ian Hickson | * Fundamentally, the change here is editorial, and should be left up to editorial discretion. The suggested change is to a non-normative table, and despite claims to the contrary in the change proposal, the change will do nothing to actually affect how future link relations are designed. * There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both. * The proposal claims to simplify the spec by removing a degree of freedom, but even if the section it proposed to change was normative, in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element), which would be a net increase in useless degrees of freedom, not a net decrease. * The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not. * A disallowed link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence. |
| Aryeh Gregor | I object to allowing people to waste the Working Group's time with issues that are purely aesthetic. Discussing whether a particular example is misleading, or what exact normative reference we should use for something, at least makes some theoretical difference to someone. But there is no credible claim anywhere in this Change Proposal that the proposed change, by itself, will make any difference to anyone or anything now or in the future. There are a few places that look like they might argue for some benefit to adopting the change, but they don't stand up to scrutiny: 1) "The semantics of a link relation should not vary too much depending on where it appears." But as the Change Proposal itself points out, the semantics of all existing link relations in the spec do not vary at all depending on where they appear, either before or after this change. Thus this is not an argument in favor of the change. 2) "to encourage consistent semantics across elements". How will this result from the change? Is the proposer arguing that after adopting the change, the editor will be less likely to introduce new link types with inconsistent semantics across elements? (As I read the proposal, it doesn't prevent the editor from introducing such relations later if he likes.) No evidence or reasoning is presented to support this point, so it should be disregarded. 3) "to simplify the spec", "Removal of an unused degree of freedom in defining link relations". These are purely aesthetic benefits, whose merits are entirely debatable, and are in fact debated by the editor. We should not allow Change Proposals to be based on entirely subjective aesthetic judgments, only on quantifiable technical arguments. Even if we were to permit aesthetic arguments, however, there is no actual argument presented for why this simplification or removal of freedom is a good thing. We are asked to accept this as self-evident, but it's actually contested, so arguments must be presented in favor for it to be considered. 4) "consistency with link relations in other contexts." No explanation is given for why the change would increase consistency with link relations in other contexts. HTTP and Atom are mentioned, but no explanation is given of how link relations are treated by HTTP or Atom, or what relevance the proposed change has. Since the proposed change would (by the proposer's own admission) have no impact on how any of the link relations in HTML function, and is merely a change to how the existing functionality is presented, it's hard to imagine how it could improve consistency with anything. Fortunately, we are not tasked with using our imagination here, and should again reject this point for failing to present supporting evidence. I could not find any other purported benefits of the change. Thus in summary, there are five claimed benefits, and none of them have any supporting arguments at all. It's not just that the supporting arguments are weak, they aren't present. The absence of any arguments in favor of the change means that we maintain the status quo. I encourage the chairs to make it clear that Change Proposals will not be adopted if they merely assert that some way of phrasing or presenting things is clearer or simpler or easier to read, even if they invoke trivial arguments such as "shorter things are easier to read". Such changes are not going to bring any benefit that comes close to outweighing the effort expended in processing them, and will unduly delay progress along the Recommendation track. No other W3C Working Group that I'm aware of will even consider such objections -- thus the term "editorial issue". Editorial issues should only be subject to oversight if there's an argument that they could meaningfully mislead or harm readers of the spec. |
| Julian Reschke | |
| Theresa O'Connor | There are existing HTML rel values that have different behavior on <link> versus <a>. This degree of freedom is actually needed for several defined link relations, namely those that impact the loading of external resources when used on <link> but not on <a>. So this Change Proposal is incorrect when it claims otherwise. The Change Proposal claims that distinguishing between rel values on <link> and on <a> conflicts with the goal of convergence with HTTP and Atom link relations. This goal does not (yet) have consensus in the Working Group, and is part of ISSUE-27. In only one of the potential resolutions to ISSUE-27 (adopting the IANA registry) does the current spec's table even potentially become a problem. Should ISSUE-27 go that way, we could always revisit this at that time. But, if ISSUE-27 is resolved in favor of *any of its other Change Proposals*, the change proposed here would result in wasted editor time that could have been more constructively spent elsewhere. |
2. Objections to optimize the spec's editorial style for legibility.
We have a Change Proposal to optimize the spec's editorial style for legibility. If you have strong objections to adopting this Change Proposal specifically with respect to the figure element, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to optimize the spec's editorial style for legibility. |
|---|---|
| Ian Hickson | |
| Aryeh Gregor | |
| Julian Reschke | I object to the Counter Proposal for the reasons given in the Change Proposal. See also my comments in http://lists.w3.org/Archives/Public/public-html/2011Mar/0139.html and http://lists.w3.org/Archives/Public/public-html/2011Mar/0242.html. |
| Theresa O'Connor |
More details on responses
- Ian Hickson: last responded on 4, March 2011 at 20:53 (UTC)
- Aryeh Gregor: last responded on 6, March 2011 at 01:51 (UTC)
- Julian Reschke: last responded on 10, March 2011 at 16:55 (UTC)
- Theresa O'Connor: last responded on 11, March 2011 at 22:53 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project