Re: CfC: Close ISSUE-82 profile-disambiguation by amicable resolution

On Thu, Apr 29, 2010 at 1:49 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 29.04.2010 10:34, Maciej Stachowiak wrote:
>>
>> On Apr 29, 2010, at 1:13 AM, Julian Reschke wrote:
>>
>>> On 29.04.2010 06:24, Maciej Stachowiak wrote:
>>>>
>>>> On Apr 21, 2010, at 12:24 AM, Julian Reschke wrote:
>>>>
>>>>>
>>>>>> On Apr 20, 2010, at 11:44 PM, Julian Reschke wrote:
>>>>>>
>>>>>>> On 21.04.2010 08:33, Anne van Kesteren wrote:
>>>>>>>>
>>>>>>>> Right, but DOM Level 2 HTML did include it.
>>>>>>>
>>>>>>> I do not disagree with the statement that's left, but now it really
>>>>>>> lacks context; it's a "Note:" without any text it refers to. Maybe
>>>>>>> one
>>>>>>> sentence needs to be added stating what you just said.
>>>>>>
>>>>>> If this isn't a blocker for ISSUE-82, perhaps that could be a separate
>>>>>> bug as well? I'm willing to file it, it does seem worth clarifying
>>>>>> that
>>>>>> the note is there because attribute was in previous specs.
>>>>>
>>>>> As much as I'd like to close ISSUE-82, this is really a problem caused
>>>>> by the suggested change. We really should fix it.
>>>>>
>>>>> So *if* we have consensus that the spec doesn't define the IDL
>>>>> attribute we consequently should also drop comments about it (yes, I
>>>>> just changed my mind on that).
>>>>
>>>> Julian, based on the more recent comments on this thread, do you still
>>>> think this needs to be changed? Do you object to closing ISSUE-82 at
>>>> this time? (This point seems at best tangential to the original issue,
>>>> so I'd rather not block the ISSUE-82 resolution on it, but it's up to
>>>> you.)
>>>
>>> In the meantime the spec has changed under us; it would have been nice
>>> to mention it in this thread:
>>>
>>> "Note: The profile IDL attribute on head elements (with the
>>> HTMLHeadElement interface) is intentionally omitted, and would
>>> therefore not be supported in conforming implementations. (It is
>>> mentioned here as it was defined in a previous version of the DOM
>>> specifcations.)"
>>>
>>> That's better, but still confusing. It sounds as if an extension spec
>>> would not be allowed to define it.
>>
>> It doesn't read that way to me, since it's a non-normative note. A
>> non-normative note could not possibly constrain what extension specs are
>> allowed to do.
>>
>>> I'd be in favor to fix this completely; otherwise we'll just have
>>> another bug, another issue, and another series of change proposals.
>>
>> Just to make sure we're perfectly clear on this: do you object to
>> closing ISSUE-82 at this time?
>
> Yes.
>
>> If you do object, do you have a specific suggestion for what could
>> address your objection?
>
> Removing
>
>  ", and would therefore not be supported in conforming implementations"
>
> would address my objection.

I support that too. I agree the cited text adds more confusion then it helps.

/ Jonas

Received on Thursday, 29 April 2010 08:54:44 UTC