[Bug 14011] New: Allow custom elements

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14011

           Summary: Allow custom elements
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://tanalin.com/_experimentz/bugs/w3/html/custom-el
                    ements/
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LC1 HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mtanalin@yandex.ru
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


It would be nice to be able to use custom elements (elements with any custom
tag names) where otherwise SPAN elements with class would be used.

For example, instead of:

    <span class="lorem">LOREM</span>
    <span class="ipsum">IPSUM</span>

we could do this:

    <lorem>LOREM</lorem>
    <ipsum>IPSUM</ipsum>

This would simplify HTML-code while making it more elegant.

Browsers already support custom elements -- to the same extent as any other
HTML5 container-elements such as SECTION or ARTICLE.

To prevent future conflicts with new (currently even noninvented) structural
markup (which rendering or behavior may be different from just block-level or
inline element), we could use special CSS-like declarations that define
explicitly what elements should look/behave natively and what elements should
look/behave just as common containers (exactly like SPAN element).

Such declarations could contain selectors (tag names in simplest case), where
each selector is placed on its own line (one selector per line).

These declarations are intended _solely_ for future (currently nonexistent)
browsers that would support both using custom elements _and_ some new
(currently noninvented) structural markup.

For example:

<style type="text/elements">
/* elements.txt contains two selectors: DOLOR and AMET*/
@import "elements.txt";

@custom {
    LOREM
    IPSUM
}

@native {
    .example > LOREM
}
</style>

In the example, DOLOR and AMET (from external file) as well as LOREM and IPSUM
elements will look/behave by default exactly as SPAN element. But LOREM
elements that are direct children of an element with "example" class should
look/behave native way (according to actual HTML-spec and default browser
capabilities) -- as if LOREM was not declared as custom element.

More detailed syntax decription:

@import directive imports external file (like as in CSS) that contain list of
custom and native elements. This external file can contain @custom and @native
sections as well;

@custom section contains selectors specifying elements that should behave as
just _common container_ (exactly like SPAN element) even if in a future
HTML-version these elements will have some special styling (e.g., nonzero
margins or borders) and/or functionality (e.g., some special response to
clicking).

@native section contains selectors specifying elements that should behave way
they should according to current HTML-spec and current browser capabilities.
When needed, this allows to override some selectors from @custom section and
thus "reset" global "customness" of elements to make them behave natively in a
more local contexts. In the particular example, LOREM elements that are direct
children of element with "example" class should look/behave according to actual
HTML-spec and default browser capabilities.

Since these declarations are inside STYLE element with new type-attribute value
(type="text/elements"), such STYLE element is just ignored by current browsers
that do not support this mechanism.

Just in case, a common container has two kinds:

1. its default styling is exactly the same as for SPAN element;
2. it has no any special functionality/behavior -- exactly as SPAN element.

See also bug URL for demo page.

Thanks.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 2 September 2011 23:19:27 UTC