Re: mix proposal

Hi All,

> Note the aui- option is still easier to parse and will probably have much
better performance. this is a big issue for implementations.


My concern is that it adds additional weight to the authoring process, with
a multitude of new attributes that authors will need to learn. This makes
the 'language' too verbose, a comment *I'm* hearing about ARIA today: that
there are too many attributes to remember there already. Additionally, I am
unsure about how the performance claim can be made, as we really don't have
a 'compare and contrast' example to prove that suspicion.

<opinion>
I continue to fall back to the mantra used during the HTML5 days: users
over authors, authors over implementer(s), implementer(s) over code-purity.
And so while I can be sympathetic to a point about implementations, if it's
too hard to author, none of the implementations will have much value, as
nobody will be authoring to them...
</opinion>


> Does the syntax work for you all (ie. space separated)?

While it "works", I do find it harder to parse. Personally, I like to see
clear(er) demarcations of concepts or ideas. Using Lisa's example, but with
the notation I suggested yesterday, I could write the same thing this way:

<p>Homes selling in the <span purpose="numberfree:('moderate price
range')">low $300,000's</span>.</p>


versus:

<p>Homes selling in the <span aui-clarificationType="easylang numberfree"
aui-clarification="moderate price range" >low $300,000's</span>.</p>



I personally find the second example more verbose, and harder to author,
but that's but one opinion <grin>.

*************

I also have a question: is the difference between "easy lang" and "numbers
free" that significantly different that we'd need to overload the example
with both concepts?

It kind of reminds me of the old debate (in older versions of HTML) over
the difference between <acronym> or <abbr>: yes, conceptually they may have
differences, but functionally for the end user what is required is an
'expansion' (or explanation) of the abbreviation or acronym, which is one
of the reasons why HTML5 deprecated <acronym> and only retained <abbr>.

I'm not rejecting the idea of using both, but I'd like to explore this a
bit more, as it strikes me that "numbers free" is but a type of "easy lang"
- but if I'm not understanding this please do help me to do so.

JF





On Tue, Sep 18, 2018 at 8:51 AM, Charles LaPierre <charlesl@benetech.org>
wrote:

> This does look interesting, and I like the idea if you don’t include the
> type easylang is assumed if that we think will be the most used option to
> cut down on amount needed to be authored.
> Does the syntax work for you all (ie. space separated)?
> Charles.
>
>
>
> On Sep 18, 2018, at 2:22 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:
>
> I am wondering about the following mix
>
> *1. A semi complex single attribute for context *  <button aui="submit
> critical symbol(http://uri.html) step(5)" > These are all content
> descriptors. This allows more then one context descriptors from fixed
> vocabularies and symbols. The con is it is slower to parse, slower to
> process and some more author error as the vocabularies are not separated. I
> am not sure if it works with things like css selectors.
>
> 2. Then we have a clarification  *v**alue pair for free text* for easy
> lang, litral etc. this could be like
>
> clarification="this costs less money" clarificationType="easylang
> numberfree"
>
> If you do not fill in clarificationType the default is easylang.
>
> Note the aui- option is still easier to parse and will probebly have much
> better performance. this is a big issue for implementations
>
> I suspect we should have tow option and go to web apps and people like
> James for their opinion.
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
>


-- 
*John Foliot* | Principal Accessibility Strategist

Deque Systems - Accessibility for Good

deque.com