Re: HTML Form attributes

On Thu, Oct 17, 2013 at 9:48 AM, Francesco Iovine <f.iovine@gmail.com>wrote:

> Hi Alex,
>
> what you said is correct, it's exactly the way the wiki is working at the
> moment: thank you for the clear explanation! :)
>
> What I'm doing is suggesting enhancements when I find hard, even if not
> impossible, insert content into the platform through this wiki, or when I
> find out document pages are messy 'cause of the wiki form editor. Before
> opening issues I talked first with Chris (in Zurich) and with Scott (in
> Amsterdam), to make sure I'm not (that) crazy :)
>
> So, from a contributor/user's point of view (and IMHO), applying to DOM
> Elements in HTML Element pages makes sense, but for HTML Attribute pages
> *does not* mainly because the label showed in the doc page is different:
> "DOM Interface" for Element pages, "Applies to" for Attribute pages. So I
> would expect links to HTML Elements here, instead let people insert them
> manually somewhere into the description.
>
> Let's consider your example, the "type" attribute page<http://docs.webplatform.org/wiki/html/attributes/type>
> :
>
> Applies to (the URL of the most general DOM interface it applies to, for
> purposes of listing all elements it applies to):
>
>    - This field should be set to [[dom/HTMLElement|HTMLElement]]
>    - Instead it makes much more sense to me to set it as
>    [[html/elements/input|InputElement]] AND [[html/elements/ol|OLElement]] so
>    the type attribute can be showed up both on HTML Elements pages and in DOM
>    Elements pages, thanks to inheritance.
>    - Anyway invalid links should not be allowed.
>
> Property applies to (when this is used in its DOM property form, which DOM
> interface does it apply to?):
>
>    - This field should be set to dom/HTMLInputElement
>    - Instead it is often set to dom/HTMLElement
>    - Anyway I would like the wiki to do this for me automatically, based
>    on the "Applies to" field :)
>
>
> Best, and thank you ;)
>


Yup, everything you've said makes total sense!

I think what it comes down to is balancing two solutions, neither of them
ideal:

*List HTML elements that an attribute applies to on each element*:

   - Pro: Makes *much* more sense to editors
   - Con: Requires a *lot* of manual work to set up. If there is a new
   attribute that is added that applies to many elements you'd need to visit a
   lot of pages. That is, it requires manual effort and is "brittle" in the
   engineering sense, since the data is not as "normalized" as it could be.
   I'd expect some hard-to-spot errors will pop up where someone left off one
   or two element types.

*Associate attributes to DOM interfaces*

   - Pro: Clean engineering wise, since the data is normalized nicely. Easy
   to apply attributes to many elements at once.
   - Con: *Much *harder to understand as an editor, and difficult to deal
   with in the editing workflow.


Ultimately, which approach we take will come down to where we balance out
on those pros and cons. At the beginning I made the call that the latter
approach is, on balance, better. However, it may very well be that the
former approach is actually better, especially now that we have a year of
experience with how annoying the editing workflow is.

Hope this makes sense!



>
> Francesco <https://twitter.com/franciov>
>
>
> On 17 October 2013 01:55, Alex Komoroske <komoroske@google.com> wrote:
>
>>
>>
>>
>> On Wed, Oct 16, 2013 at 3:22 PM, Francesco Iovine <f.iovine@gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> last Saturday at the Amsterdam Doc Sprint, Scott and I had the
>>> opportunity to talk a bit about how to improve the Wiki in HTML Elements
>>> and Attributes.
>>>
>>> In short, we have to delve deeper into "applies to" and "property
>>> applies to" fields, anyway we agreed on the following:
>>>
>>>    - each HTML attribute should be linked to one or more HTML elements
>>>    (not DOM Elements), and the User/Contributor should have the possibility to
>>>    specify which elements the attribute applies to
>>>    - each HTML elements should list automatically all the attributes
>>>    which can applies to it
>>>    - each HTML Element should inherit from a DOM Element
>>>
>>> This is just the first step, anyway it should solve most of the problems
>>> I encountered in working on the HTML5 Form Attributes pages.
>>>
>>
>> Glad to see folks thinking about these issues!
>>
>> Back in the day I remember that there was a reason to associated
>> attributes with DOM elements, not HTML elements. I'm struggling to remember
>> why it was--I think it's because DOM elements have an inheritance structure
>> that makes it easier to associated attributes to the highest common
>> ancestor, whereas HTML elements have no such structure and thus it would
>> take a lot of manual/brittle work to wire up attributes to the right
>> elements.
>>
>> As an example, the title attribute is allowed on many different HTML
>> elements; ideally you wouldn't have to enumerate them but figure out the
>> highest common DOM element ancestor and apply it that way.
>>
>> Does that make any sense, or am I talking crazy talk?
>>
>>>
>>> Cheers,
>>>
>>> Francesco <https://twitter.com/franciov>
>>>
>>>
>>> On 25 September 2013 22:57, Francesco Iovine <f.iovine@gmail.com> wrote:
>>>
>>>> Just to let you know the associated issues:
>>>>
>>>> http://project.webplatform.org/content/issues/65
>>>> http://project.webplatform.org/content/issues/67
>>>>
>>>> Cheers,
>>>>
>>>> Francesco <https://twitter.com/franciov>
>>>>
>>>>
>>>> On 11 September 2013 20:06, Francesco Iovine <f.iovine@gmail.com>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> at the last Doc Sprint in Zurich I started working on HTML Form
>>>>> attributes and found out that there seems to be a lack of consistency in
>>>>> WebPlatform's URL structure for HTML attribute pages.
>>>>>
>>>>> Here are some examples:
>>>>>
>>>>>    1. the "value" attribute has no general page html/attributes/value<http://docs.webplatform.org/wiki/html/attributes/value> and
>>>>>    has a page for each element it applies:
>>>>>    html/attributes/value_(input_elements<http://docs.webplatform.org/wiki/html/attributes/value_%28input_elements%29>
>>>>>    ), html/attributes/value_(textarea_element<http://docs.webplatform.org/wiki/html/attributes/value_%28textarea_element%29>
>>>>>    ), html/attributes/value_(button_element<http://docs.webplatform.org/wiki/html/attributes/value_%28button_element%29>
>>>>>    ), html/attributes/value_(HTMLProgressElement<http://docs.webplatform.org/wiki/html/attributes/value_%28HTMLProgressElement%29>
>>>>>    ), html/attributes/value_(param_element<http://docs.webplatform.org/wiki/html/attributes/value_%28param_element%29>
>>>>>    ), html/attributes/value_(li_element<http://docs.webplatform.org/wiki/html/attributes/value_%28li_element%29>).
>>>>>    Moreover, using the WP search tool there's no results matching the
>>>>>    query "value"<http://docs.webplatform.org/w/index.php?search=value>
>>>>>    .
>>>>>
>>>>>    2. the "type" attribute page for the HTML Input element has the
>>>>>    following (different) structure: html/elements/input/type<http://docs.webplatform.org/wiki/html/elements/input/type>.
>>>>>    It's located in the "elements" subtree and contains a list of the possible
>>>>>    values of the "type" attribute: each item of the list links to a page with
>>>>>    a URL structure like following: html/elements/input/type/button<http://docs.webplatform.org/wiki/html/elements/input/type/button>
>>>>>    , html/elements/input/type/checkbox<http://docs.webplatform.org/wiki/html/elements/input/type/checkbox>
>>>>>    , html/elements/input/type/color<http://docs.webplatform.org/wiki/html/elements/input/type/color>
>>>>>    , html/elements/input/type/date<http://docs.webplatform.org/wiki/html/elements/input/type/date>
>>>>>     etc.
>>>>>
>>>>>    3. the "type" attribute is defined also for other elements, but in
>>>>>    the "attributes" subtree: html/attributes/type_(button_element)<http://docs.webplatform.org/wiki/html/attributes/type_(button_element)>
>>>>>    , html/attributes/type_(param_element)<http://docs.webplatform.org/wiki/html/attributes/type_(param_element)>
>>>>>    , html/attributes/type_(script_element)<http://docs.webplatform.org/wiki/html/attributes/type_(script_element)>
>>>>>    , html/attributes/type_(select_element)<http://docs.webplatform.org/wiki/html/attributes/type_(select_element)>
>>>>>    , html/attributes/type_(textarea_element)<http://docs.webplatform.org/wiki/html/attributes/type_(textarea_element)>
>>>>>    , html/attributes/type_(ul,li,ol_elements)<http://docs.webplatform.org/wiki/html/attributes/type_(ul,li,ol_elements)>
>>>>>    , html/attributes/type_type_(a,_link,_embed)<http://docs.webplatform.org/wiki/html/attributes/type_type_(a,_link,_embed)>.
>>>>>    (For some of these elements the "type" attribute doesn't exist in W3C
>>>>>    specifications and should be deleted)
>>>>>
>>>>> Regarding the "type" attribute, together with Chris concluded that
>>>>> they should all be covered on the html/attributes/type<http://docs.webplatform.org/wiki/html/attributes/type> page,
>>>>> so I flagged every subpage of html/elements/input/type<http://docs.webplatform.org/wiki/html/elements/input/type> as
>>>>> Merge Candidates with the [[html/attributes/type]] page, moved all relevant
>>>>> information to the page html/attributes/type<http://docs.webplatform.org/wiki/html/attributes/type> and
>>>>> added examples.
>>>>>
>>>>> Now, I see 2 problems in the page html/attributes/type<http://docs.webplatform.org/wiki/html/attributes/type>
>>>>> :
>>>>>
>>>>> 1) the "Applies to" entry refers to N elements, but Media Wiki doesn't
>>>>> provide a way to let an attribute refer to more than 1 element (or at least
>>>>> I don't know how to do that)
>>>>>
>>>>> 2) there's no way to specify the compatibility related to a specific
>>>>> value of an input type (e.g. input type="date"). It was possible for
>>>>> html/elements/input/type<http://docs.webplatform.org/wiki/html/elements/input/type>
>>>>>  pages.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Francesco <https://twitter.com/franciov>
>>>>>
>>>>
>>>>
>>>
>>
>

Received on Friday, 18 October 2013 21:35:42 UTC