Re: Which default values need to be declared in Polyglot Markup?

On 25/04/2013 06:26, Leif Halvard Silli wrote:
> As part of the shift to more focus on the robustness principle, I
> wanna clarify why polyglot markup requires @type to be declared for
> script and style elements.

I can't see any justification for requiring that.

>
> Put very bluntly, the reason is that the Polyglot Markup spec does
> not rely on 'The default, which is used if the attribute is absent,
> is "text/javascript".'[1]  However, script and style are not the only
> elements that have a missing value/missing attribute default. So why
> do we not require explicit declaration for e.g. the following
> elements?
>
> * missing value default for @type on <input> is the Text state *
> missing value default for @kind of <track> is 'subtitles' * missing
> value default for @shape is the rectangle state * missing value
> default for @autocomplete of form is "off" * missing value default
> of @type of button is Submit Button state * (may be various @role
> and @aria-* values too?)
>
> Justification for asking defaults to be explicitly declared can be:
>
> * known (legacy) user agent/consumer issues

It is to be honest hard to believe that there are legacy issues that
if they were there would not also be important for HTML.

> * being explicit increases authors’ awareness of what they do *
> consequence - equal situations should be equally handled. (For
> instance for pedagogical reasons. And ass spec editor, I look for
> principles)

Making authors explicitly specify something if the same thing happens
whether it is specified or not seems pedagogically dubious

> * simplifying (e.g. to remember shape="rect" can be simpler than
> remembering both shape="rect" *and* the missing value default)

You are joking surely. Is there ever a page in existence that has used
shape=rect other than pages that have been through a dtd
normalisation step and had this entirely useless attribute added as a
result of that?

> A fourth justification could as well be format issues:
>
> * special XHML vs HTML requirements
>
> But in all the above examples (including for script/style) I doubt
> there are format issues. (The best example of a format issue would be
> the charset="UTF-8" of the <meta> element - and since it can only
> take a single value - UTF-8, it does remind a little about 'missing
> value default', too. As well, the I18N WG favors meta@charset over
> BOM partly for explicity reasons.)
>
> There are some cases when being explicit does not make sense: * when
> missing value default is "user-agent defined" (@preload), * when
> missing value default is the single method to set a state (e.g. auto
> state for @scope) In the auto state case, the only action Polyglot
> Markup’s editors *eventually* could take, would be to request that
> e.g. the value 'auto' is added to HTML5 proper, so that it in turn
> could be added to polyglot.
>
> So, in a summary, our options are: 1. keep requirements as is. If
> so, why? 2. require the relevant elements to align with script/style
> 3. require script/style to align with the relevant elements 4.
> replacing today’s *requirement* to add @type on script/style with a
> *recommendation* to add the missing value default for *all* elements
> that have a missing value default.
>
> Looking for principles and consequence as I am, I am inclined to rule
> out option 1. Can anyone explain why I should not go for option 4?

Adding requirements over and above what is required for HTML validity
and XHTML compatibility will just mean the spec is not used. What is
needed is a robust spec for a language that is well formed XML and valid
HTML, those two together already put more than enough requirements on
people, why make it harder by making them add useless attributes like shape?

>
> [1] http://www.w3.org/TR/html5/scripting-1.html#attr-script-type
>

David

Received on Thursday, 25 April 2013 08:24:43 UTC