I've seen several mentions that the is="" construct is now deprecated, which goes to show how early this process still is. We might really need the input from people on the inner circle if we go further with using webcomponents.
--
Don
On 6/27/2016 12:39 AM, Mark Giffin
wrote:
Michael,
On using the is= syntax to base your new element on an existing HTML element:
<ol is="simple-steps">
I am almost positive that you cannot put more than one value in the is="". I know a couple people who were on the web components committee, I can try to get a definitive answer. It's probably in the spec somewhere too.
Mark Giffin
Mark Giffin Consulting, Inc.
http://markgiffin.com/
On 6/26/2016 5:56 PM, Michael Priestley wrote:
I talked a bit more about it with Don, and this is where my thinking is right now, based on the descriptions of custom elements here:
https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks
- our two main alternatives are autonomous custom elements, which we could give custom element names to
- or customized built-in elements, which would retain the name of an existing HTML element plus the "is" attribute giving a custom element name
Example for autonomous custom elements:
<simple-steps>
<simple-step>...</simple-step>
</simple-steps>
Pros:
- they have easily understandable semantic names
- they look like XML, and can more closely mimic XML specializations
Cons:
- nothing will happen remotely resembling fallback processing (like rendering these as an ordered list) without a bunch of _javascript_
- for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks
Example for customized built-in elements
<ol is="simple-steps">
<li is="simple-step">...</li>
</ol>
Pros:
- they process automatically as list items
- they can be registered using _javascript_ as special nodes, for extra behavior, but you only need to identify the delta stuff
Cons:
- looks less like XML
Net
My clear preference is now for customized built-in elements, given the warnings of the spec against using autonomous custom elements when extending an existing element type.
But the open question for me is whether the "is" attribute can take multiple values. If it can, it could map really cleanly to specializations. Even the requirement for hyphenation in the element name could be a mirror for the "/" in the XML class attribute.
Otherwise we'd be looking again at limiting ourselves to one level of specialization, which may still be on the page anyway - nobody has said they want it yet.
So... does anyone have a contact on the Web Platform Working Group? I couldn't find a simple answer to my question anywhere, including here:
https://lists.w3.org/Archives/Public/public-webapps/
If no one else has a contact I'll poke around IBM.
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
--
Don R. Day
Founding Chair, OASIS DITA Technical Committee (current version: DITA 1.3)
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day
Founding Chair, OASIS DITA Technical Committee (current version: DITA 1.3)
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
Where is the knowledge we have lost in information?"
--T.S. Eliot
| Virus-free. www.avast.com |