What is the philosophy/policy/spirit of appearances?
Nobody has claimed this yet.
- Dominant language
- CSS
- Stars
- 34
- Forks
- 28
- Avg merge
- 27m
- Merged PRs (30d)
- 1
Description
We've been touching on some bigger picture questions about `appearance`s in #108 #112 #111 and a couple other issues. It would be awesome to articulate some principles, processes and guidelines around them. Currently they're not really documented in this spec and they've been added on in a pretty ad-hoc way.
Here are some things I've been thinking about, numbered so they can be commented on separately:
1. `appearance`s are client hints. It should be totally fine for clients to ignore any or all of them. The only repercussion should be a loss of convenience for the enumerator or control for the form developer. (This isn't quite true at the moment but I'd like to propose it as policy moving forward)
1. Because clients can choose to pay attention to them or not, it's not a big deal to add more.
1. Given that we have a variety of different client types and users with significant challenges to overcome, `appearance`s can be a powerful way to add value to the ecosystem with limited effort.
1. To ensure some coordination across clients, new appearances should be proposed here with a clear description of what they are intended to do, what a client that ignores them should do and a proposed name or two.
1. Once approved by lazy consensus, appearances should be added to this spec even if only a couple of clients actually do anything with them.
1. Unlike in the W3C spec, appearances can be combined in a space-separated list. This is generally implemented just in specific contexts and allows for a limited number of combinations. See #111.
The W3C spec does make it clear that arbitrary, client-specific appearances can be added [here](https://www.w3.org/community/xformsusers/wiki/XForms_2.0#attrs-appearance) so I don't think any of this is revolutionary. I like some of the wording used [here](https://www.w3.org/MarkUp/Forms/wiki/Metadata_Appearance) (about metadata appearances, but same idea).
What else? What other "provocative" thoughts do we have?? 😄
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the appearance discussions in issues #108, #112, and #111, along with the linked W3C appearance references. Done means agreeing on principles, proposal and approval processes, and combination rules, then documenting the result in this spec.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100