Re: explaining my issue with one single attribute, and review of the three options.

On 25/09/2018 18:50, lisa.seeman wrote:
> people mess up the syntax around embedded values, for example  
> aui= easylang*:(**"this") "  i*s more complex then a simple and familiar 
> easylang=*"this "*

I agree with JF that the syntax he proposes is already familiar to 
developers.

It's worth exploring this though. Lisa, do you have data you can share 
that demonstrates the degree to which this form of syntax is error prone 
(perhaps using the CSS inline style attribute as a benchmark)?

It is also worth considering the impact of multiple attributes. 
Implementors and developers are increasingly concerned about 
performance, and the "weight" of the code is one aspect of this.


I strongly suggest we need input from implementors and authors before we 
choose a syntax.

Léonie.




> 
> All the best
> 
> Lisa Seeman
> 
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter 
> <https://twitter.com/SeemanLisa>
> 
> 
> 
> ---- On Tue, 25 Sep 2018 18:21:10 +0300 *John Foliot 
> <john.foliot@deque.com>* wrote ----
> 
>     Hi Lisa,
> 
>     While I am trying to understand your concern, I'm also struggling to
>     see how this is confusing. You proposed the following:
> 
>         <p aui= " simplification:critical
>         symbol:(https://blissorsomething.com/uri.html)"  
>           easylang="This is a long easy to understand description, it
>         could have 3 sentences. People are likely to have bugs by adding
>         quotes."   numberfree = "this is a a description which avoids
>         number. it could have four sentences and again people may add
>         quotes or brackets that would add bugs." > some text  about this
>         example </p>
> 
>     Candidly, I fail to see how that is materially different than this:
> 
>         <p aui="simplification:critical;
>         symbol:url(https://blissorsomething.com/uri.html); easylang:("This
>         is a long easy to understand description, it could have 3
>         sentences. People are likely to have bugs by adding quotes.");
>         numberfree:("This is a a description which avoids number. It
>         could have four sentences and again people may add quotes or
>         brackets that would add bugs.")" > some text  about this example
>         </p>
> 
>     In your example, you are using spaces to denote three different
>     "attributes", while in my example, each aspect of the paragraph is
>     separated by semi-colons, in a fashion *EXACTLY LIKE CSS NOTATION* -
>     in other words, a familiar pattern that most hand-authored
>     contributors will recognize and pick up (I assert) quite easily.
> 
>     Additionally, I am proposing colons while you are proposing equals
>     symbol, which frankly seems to be nothing more than personal
>     preference (with the exception that colons and semi-colons - as I
>     propose -  are used for compound attribute values already: /<p
>     style="color:red; font-weight: bold; font-family:"MS Comic Sans",
>     sans-serif;">/ - a pattern that authors have been using for almost
>     two decades now).
> 
>     Lisa, when you asked "Can I (we) spot the bugs?" my answer is
>     "Absolutely! You aren't using semi-colons to separate concepts, and
>     the lack of quotation marks makes it harder to parse what is prose
>     text, and what is "code"". I don't think either of these are
>     showstoppers, and once we get the pattern confirmed and "locked-in"
>     I don't see why a linting tool or other validator couldn't also pick
>     up these mistakes. And given that the authoring pattern is identical
>     to CSS in structure, there is absolutely no reason why you could not
>     also author the following to make it clearer for human parsing:
> 
>         <p aui="simplification:critical;
>                       symbol:url(https://blissorsomething.com/uri.html);
>                       easylang:("This is a long easy to understand
>         description, it could have 3 sentences. People are likely to
>         have bugs by adding quotes.");
>                       numberfree:("This is a a description which avoids
>         number. It could have four sentences and again people may add
>         quotes or brackets that would add bugs.")" > some text  about
>         this example </p>
> 
>     ...because of course browsers ignore extra white space.
>     Additionally, the addition of quotation marks *may or may-not* be a
>     problem, as currently there are NO PARSING RULES for either of the
>     proposed patterns (so I assert your concern may be premature). If we
>     look to inline CSS as a "hint", either of these are valid today:
> 
>         style="/font-family:"MS Comic Sans", sans-serif;"/
> 
>     or
> 
>         style="/font-family:MS Comic Sans, sans-serif;"/
> 
> 
>     (in other words, the quotation marks are optional - so we can
>     certainly look to adopt that 'rule' as well. As Google's Alex
>     Russell famously said, "This is code, we can do whatever we want")
> 
>     In my mind, what this is coming down to is the choice between using
>     = (equals symbol) versus : (colon) to separate term from value
>     (i.e., /term: value/, versus /term="value"/), and your desire to see
>     multiple attributes versus my concern that we've already got far too
>     many "accessibility attributes" thanks to the ever growing taxonomy
>     of ARIA attributes (48 and counting).
> 
>     As you may recall, back during the Sapporo TPAC (2015), a number of
>     accessibility folks were concerned then about the "ARIA all the
>     things" proposal that was coming forward, when the very first draft
>     of the COGA-attributes (back then, just more ARIA-attributes) was
>     proposed. Representatives from many larger-scale organizations
>     vocally object to that approach (which then saw us go from more
>     ARIA-attributes to COGA-* attributes, and then to AUI-* attributes).
>     The fundamental problem however remains: too many attributes,
>     irrespective of their prefix. At this point, you are now asking for
>     3 new attributes (without prefixes), which we may also find a
>     difficult ask to justify to Web Platforms WG (and WHAT WG as well -
>     sadly).
> 
>     In your other email, you spoke of experience and implementations.
>     Lisa, while I respect your years of dedication to the cause, I too
>     have been creating and teaching about accessible web sites for close
>     to two decades, in both "small shop" scenarios as well as at a major
>     education institution (Stanford University), one of the world's
>     largest banks (JP Morgan Chase), and via Deque consulting with
>     multiple Fortune 500 companies, and so I have what I believe to be
>     justifiable concerns about scaling. And while I agree that in the
>     early days, the application of personalization markup to the code
>     base will come from dedicated, hand-coding authors, if we desire to
>     see this grow beyond that to a more mainstream adoption, we MUST
>     be cognisant of how this will be taken up at scale. That may not be
>     a concern you share at this time, but as the AC Rep for Deque, it is
>     a concern that my employer will likely have as we move forward.
> 
>     JF
> 
> 
>     On Tue, Sep 25, 2018 at 8:50 AM lisa.seeman <lisa.seeman@zoho.com
>     <mailto:lisa.seeman@zoho.com>> wrote:
> 
> 
> 
>     -- 
>     *John Foliot* | Principal Accessibility Strategist
> 
>     Deque Systems - Accessibility for Good
> 
>     deque.com <http://deque.com/>
> 
> 
>         __
>         Hi Folks
> 
>         I wanted to explain my example from last night.
> 
>         I strongly do not believe we can rely on large authoring tools
>         to automatically generate the web code for authers to get it
>         right. some of our user cases are about small user groups (such
>         as symbol) who desperately need any content they can use. The
>         content being made for them may be small sites making content
>         specifically for these users. Therefor we have to allow authers
>         who are less experienced to manage this.
>         Also the only way to test for bugs is via running an extension
>         against different profiles and seeing if it works as expected.
>         in other words, bugs will often not be found. Therefor avoiding
>         author errors is critical for this be be of use.
> 
>         The micro syntax of Johns proposal will look like this:
> 
>         <p aui= " symbol:(https://blissorsomething.com/uri.html
>         <http://something.com/uri.html>)  easylang:(this is a long easy
>         to understand discripiton, it could have 3 sentences . people
>         are likely to have bugs by adding quotes.) numberfree:(this is a
>         a discripiton which aviod's number. it could have four sentences
>         and again people may add quotes or brackets that would add
>         bugs".)  simplification:critical"> some text  about this example
>         </p>
> 
> 
>         Can you spot the bugs?
> 
>         My counter proposal is to have easylang and numberfree as
>         separate attributes. That will reduce the chance of author
>         errors whilst keeping most of the advantages. It is a compromise
>         (although I prefer the aui- approach)
> 
> 
>         The above proposal would look like:
> 
>         <p aui= " simplification:critical
>         symbol:(https://blissorsomething.com/uri.html
>         <http://something.com/uri.html>)"    easylang="this is a long
>         easy to understand discripiton, it could have 3 sentences .
>         people are likely to have bugs by adding quotes."
> 
>         numberfree = "this is a a discripiton which aviods number. it
>         could have four sentences and again people may add quotes or
>         brackets that would add bugs." > some text  about this example </p>
> 
> 
> 
>         not perfect but less overloaded.
> 
> 
> 
>         All the best
> 
>         Lisa Seeman
> 
>         LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>         <https://twitter.com/SeemanLisa>
> 
> 
> 
> 

-- 
@LeonieWatson @tink@toot.cafe Carpe diem

Received on Wednesday, 26 September 2018 11:00:00 UTC