W3C home > Mailing lists > Public > public-html@w3.org > June 2012

Re: ISSUE-200: legend-placement - Chairs Solicit Alternate Proposals or Counter-Proposals

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Sat, 30 Jun 2012 14:26:29 +0400
To: Edward O'Connor <eoconnor@apple.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-Id: <2176281341051989@web17f.yandex.ru>
30.06.2012, 03:59, "Edward O'Connor" <eoconnor@apple.com>:
> Marat wrote, in response to my ISSUE-200 CP[1]:
>>>  The <fieldset> and <legend> author conformance criteria present in
>>>  the specification help authors to correctly use these elements and
>>>  should not be loosened.
>>  "Helping" and "correctness" are unconstructive abstractions.
> Reworded.

> The <fieldset> and <legend> author conformance criteria present 
> in the specification enable authors to use these elements in an 
> interoperable manner and should not be loosened.

As I've said in my proposal [A] and illustrated with usecases [B], wrapping legend in DIV do work quite interoperably across all major browsers.

[A] http://www.w3.org/wiki/User:Mtanalin/legend-placement
[B] http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/

>>>  No use cases have been provided to justify changing the status quo.
>>  Not. Multiple usecases _have been_ provided in both original bug 12834
>>  [1] and proposal [2]. See:
>>  http://tanalin.com/_experimentz/bugs/w3/html/wrap-legend/
> As the editor explained in [2], these test cases are not use cases. I
> have not changed my proposal based on this feedback.

If I would think the editor is right, then I would not raise the issue.

To prevent further endless unhelpful debates on this, I have replaced "testcase" word to "usecase" on that page. Voila. Now they all are usecases. ;-)

Make a point of usecases #2 and #6. In particular, usecase #6 has nothing to do with CSS at all and by nature cannot be addressed with CSS (semantics cannot be addressed with presentation).

>>>  Change proposal for LEGEND element suggests we mint a new <ilegend>
>>>  element, identical in semantics to <legend> but free from <legend>'s
>>>  compatibility constraints. Having multiple elements with identical
>>>  semantics balloons the size of HTML's vocabulary and should be
>>>  avoided unless there are compelling reasons for each element.
>>  Such "ballooning" is not a significant issue at all. There _are_
>>  compelling reason: existing LEGEND element is not styleable as it's
>>  needed by real-world web development.
> Styling deficiencies are not a good reason to add an element to HTML—but
> they *are* good input into how we can improve CSS to better handle the
> sorts of effects you'd like to achieve. Any deficiencies in the
> styleability of <legend> should be taken up with the CSS Working Group.
> I have not changed my proposal based on this feedback.

Fantasai said this is not a CSS problem. Ignoring this and continuing to say that this is CSS problem is just pointless dead-end road detached from reality.

>>>  For instance, when designing <figure>, we minted <figcaption> (instead
>>>  of reusing <summary> or <legend> within <figure>) due to the legacy
>>>  parsing behavior of <summary> and the legacy rendering behavior of
>>>  <legend>. But this was to enable the various use cases addressed by
>>>  <figure>.
>>  "various use cases" is an unconstructive abstraction.
> I don't see why a change proposal about <legend> would need to restate
> the use cases that gave rise to <figure>. The public-html and whatwg
> mailing list archives are public and searchable. I have not changed my
> proposal based on this feedback.

It's your right to say abstractions. Less specifics means less persuasiveness.


> 1. http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-200
> 2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=12834#c25
Received on Saturday, 30 June 2012 10:27:01 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:53 UTC