W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Lisbon F2F 2016-09-20 Part I: Joint Meeting with A11y Working Group [mediaqueries] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 21:27:25 -0500
Message-ID: <CADhPm3tmopTvSSn9aOC+CiUdwh=xbSmhZ6wK-eUZp_EJyfRY8Q@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Joint Meeting with A11y Working Group

CSS A11y Task Force/CSS AAM

  - A brief summary was given of the purpose of the task force and
      what it hopes to achieve.
  - The charter for the task force will be amended to state that
      publications will be made jointly.
  - Rossen had volunteered to help this effort and was looking for
      more CSSWG members to join.
      - Several members of both working groups volunteered to work
          on editorship and a best practices document/questionnaire
  - There were concerns about a separate task force ending up in a
      silo; but it was clarified that everyone in CSS WG will need
      to be aware of a11y tasks and the task force members are there
      to coordinate and lead the effort.
  - The task force will start out with technical discussions over
      github and ~monthly telecons to sort out issues that can't be
      resolved on github.

  - There are two places where CSS affects accessibility; when it
      effects structure like injecting generated content and when it
      makes the visual order dramatically different than the DOM
  - The task force will look to document the best practices for
      authoring and ensure that CSS specs are following those best

Media Queries for ARIA-details

  - There was a request to have a media query to say that the page
      should display additional descriptions. This will be worked
      in with the rest of the user-preference MQ work in L5.


  - Task force will need to deal with problems around navigation.
  - The document from APA listing the problems is here:
  - There was a desire to ensure that any changes to the a11y tree
      that are also not reflected in the keyboard focus order.

- The APA doesn't anticipate objecting to the Grid transition


Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda

  Rossen Atanassov - Microsoft
  Tab Atkins - Google
  L. David Baron - Mozilla
  Brian Birtles - Mozilla
  Bert Bos - W3C
  Rick Byers - Google
  Tantek Çelik - Mozilla
  Dave Cramer - Hachette
  Emil A Eklund - Google
  Behdad Esfahbod - Google
  Elika J Etemad - Invited Expert
  Daniel Glazman - Disruptive Innovations
  Jihye Hong - LG Electronics
  Dean Jackson - Apple
  Ian Kilpatrick - Google
  Pierre-Anthony Lemieux - supported by MovieLabs
  Vladimir Levantovsky - Monotype Imaging Inc.
  Chris Lilley - W3C
  Myles C. Maxfield - Apple
  Theresa O'Connor - Apple
  Simon Pieters - Opera
  Liam Quin - W3C
  Matt Rakow - Microsoft
  Manuel Rego - Igalia
  François Remy - Microsoft
  Florian Rivoal - Vivliostyle Inc.
  Andrey Rybka - Bloomberg
  Shintaro Sakahara - BPS
  Hiroshi Sakakibara - BPS
  Simon Sapin - Mozilla
  Geoffrey Sneddon - Invited Expert
  Alan Stearns - Adobe
  Shane Stephens - Google
  Surma - Google
  Lea Verou - Invited Expert
  Jet Villegas - Mozilla
  Mark Watson - Netflix
  Greg Whitworth - Microsoft
  Steve Zilles - Adobe

  Rachel Andrew - Invited Expert
  Dael Jackson - Invited Expert

Scribe: fantasai

Joint Meeting with A11y Working Group

  Janina: Idea was that we'd organize our work.
  Janina: Started to see same issue with multiple specs.
  Janina: Don't want to hold back CSS, but have some real issues wrt
  janina: Wanted to bring together APA and ARIA expertise.
  janina: Don't want to go off on our own and misinterpret the spec.
  janina: Together there are certain things we can do that would
          help, and ultimately solve issues we've identified.

  janina: For instance, had good success in ARIA WG with mappings.
  janina: a11y API mapping specification.
  janina: Worked through W3C process through REC, tested and
          implemented and implementable.
  janina: Test and validate your implementation of a11y.
  janina: Many things can be handled by CSS-a11y mapping, that's why
          ARIA is involved.
  janina: Until a week ago, a11y mappings were owned by ARIA... HTML
          mappings are their own story.
  janina: Furthermore, some access among our various members to the
          various platforms where we are mapping.
  janina: So if we're missing support on the OS side, have
          opportunity to do something there.
  janina: Whether that covers everything, expectation is probably

  janina: May need a Best Practices as well.
  janina: But after looking at various issues, group that goes to
          work on this can decide what gets handled
  janina: Another AAM, best practices, and maybe some tweaks to
  janina: talk about that it coordinated and cohesive manner.
  janina: Excited about this, overdue collaboration.

CSS AAM/CSS A11y Task Force

  janina: Wrt draft of ?, Michael and I did some work on it
  <MichaelC> -> https://github.com/w3c/aria/tree/master/css-aam CSS
             AAM stub (will migrate to a new repo soon)
  <MichaelC> -> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features
             CSS AAM Potential Features
  janina: APA approved it, but it's a starting point.
  janina: Will have a TF, chairs will appoint facilitators.
  janina: Expecting group will meet on some regular schedule, a lot
          of async communication, some telecons, etc. usual range of
          tools for communication.
  janina: That's organizational perspective we've put forward.
  janina: Also had a document prepared for us, making argument for
          why we though TF was really necessary.
  janina: Prepared by one of our members who suddenly and
          unexpectedly is no longer part of W3C.
  janina: Didn't get that email til yesterday...
  janina: Was hoping she'd give us a quick overview of the issues.
  janina: Asked Rich to give an overview.

  richardschwerdtfeger: OK, so, how this started is we had found
                        some issues where CSS was injecting content,
                        and we didn't have mappings across the
                        browsers for that.
  richardschwerdtfeger: We'd also found issues with Flexbox, working
                        through that.
  richardschwerdtfeger: Have been working with HTML and SVG, and all
                        those languages have mapping specs.
  richardschwerdtfeger: Able to make issues, make sure what you put
                        in gets mapped.
  richardschwerdtfeger: Talked with Rossen about how to go about
  richardschwerdtfeger: Wanted to make sure a11y issues are
                        addressed early on, because CSS critical to
  richardschwerdtfeger: So platform was created.
  richardschwerdtfeger: Don't need mappings for everything, but
                        those things that are critical.
  richardschwerdtfeger: TF is members of a11y and CSS, addressing
                        a11y issues.
  richardschwerdtfeger: Make sure that content and presentation is
                        addressed by WG as a team.
  richardschwerdtfeger: We haven't agreed on TF work state, next
                        step is how do we populate a group that will
                        work on these issues together.
  richardschwerdtfeger: Was just told by joanie diggs (????) who
                        would like to be an editor, but need more
                        than that. Need members of CSSWG.
  Rossen: I think that's a great summary.
  Rossen: I've been communicating what we've talked about with the
          CSSWG, we have few telecon time slots to talk about going
          forward, how to proceed in terms of participating in TF
          and what TF is actually going to do.

  Rossen: Quick summary for benefit of everyone, of what mapping
          spec is.
  Rossen: They are fairly different from most specs we do in CSS.
  richardschwerdtfeger: What people often don't think about when
                        creating Web content is that they're
                        contributing to a software application.
  richardschwerdtfeger: Every OS has a11y services that communicate
                        necessary info to assistive technology, e.g.
                        text on screen, role is, how it relates to
                        other content, where the keyboard focus is,
  <joanie> Example mapping spec:
  richardschwerdtfeger: That info is mapped to platform API
  richardschwerdtfeger: On every single OS
  richardschwerdtfeger: So write once, accessible on all platforms
  richardschwerdtfeger: as long as you write accessible code.
  richardschwerdtfeger: In CSS, when you do things like inject
                        content, want to make sure it maps to those
  richardschwerdtfeger: For HTML ARIA try to make mappings for that
  richardschwerdtfeger: We do ...????.
  richardschwerdtfeger: Would do same thing here.
  richardschwerdtfeger: You end up behaving just like accessible
                        software app on that platform.

  Florian: Since CSS doesn't exist in a vacuum but exists on top of
  Florian: Mappings we define here, just need to have difference
           from HTML mapping, right?
  richardschwerdtfeger: Yeah for example with content injection in
  richardschwerdtfeger: Doesn't show up in DOM, there's an OM that
                        shows up.

  astearns: Before going into details, ChrisL on the queue.
  ChrisL: Gone through work statement, in general it's fine.
  ChrisL: One thing that is different from our charter, our charter
          says that documents will be co-published
  ChrisL: Whereas work statement here is that one group will
          publish. Sort of uncomfortable.
  janina: Don't think we meant that, did we ?
  ChrisL: Willing to change?
  janina: Yes.
  ACTION Janina fix charter to co-publish

  Rossen: I'll try to give quick summary of work that was identified
          for the TF.
  Rossen: Problem statement here is that CSS affects the a11y layer
          in 2 major ways.
  Rossen: First one is when we end up affecting structure like
          injecting generated content, or in case of table fixup,
          more elements that are mapped.
  Rossen: Second part that we've been having a11y related issues
          have been when there's visual changes that are drastically
          different from DOM order, such as flex-order property.
  <Rossen> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features
  Rossen: So in order to get things going, Cynthia Shelly who was
          Microsoft representative for APA and other a11y groups
          created a quick outline of all of the modules that might
          have a11y issues.
  Rossen: As you can see, breakages the work that will be covered,
          related to reading/navigation order.
  Rossen: Flexbox, grid and positioning are called out explicitly.
  Rossen: There is generated content and ...
  Rossen: Documents of existing features that are implemented
  Rossen: e.g. Generated content
  Rossen: Which is supposed to be accessible, but isn't implemented
          as such.
  Rossen: Did some work in Edge recently to address some of these
          issues. Can attest that this type of work is not all that
          hard to do, and improves a11y layer a lot.
  Rossen: Don't want to list all the specs out loud but this is set
          of work that has been identified.
  Rossen: Kickstart discussion
  Rossen: I have volunteered myself
  Rossen: to join the TF and help the work forward
  Rossen: Would be very happy to have other CSS members.

  astearns: Two questions. One is question of editorship -- who is
            tasked with putting all the info into the document?
  astearns: Then further question of just participating in the TF,
            not necessarily writing specs.
  astearns: Are you also volunteering yourself as an editor?
  astearns: Anyone else from CSS interested in the TF for
  astearns: I am definitely interested.
  astearns: Francois & Greg from Microsoft.
  dauwhe: I'm interested.
  jcraig: Me too.
  iank: Participation wrt Houdini.

  astearns: Editing?
  MichielBijl: I'm interested, from APA.
  fantasai: I'm willing to help out.
  fantasai: I think one thing that I should be working on is the
            Best Practices document.

  astearns: Was at chairs breakfast this morning, talking about wide
            review especially by groups like APA.
  astearns: One thing that helped me in my writing is not just
            having a Best Practices document, with criteria.
  astearns: But having a list of questions, like the security
  astearns: Short questionnaire so as people stat writing specs,
            they have something to refer to.
  astearns: Maybe some of the work in best practices can be done as
            a short questionnaire on accessibility gotchas that
            editors can refer to.
  Rossen: I think fantasai was referring to ... we committed last
          TPAC to write best practices for authors of CSS.
  Rossen: This is something that will go a long way, I think there
          will be value of having reference directly from CSSWG.
  Rossen: Can hold this as formal recommended practices from our POV.
  MattKing: I'm willing to collaborate on best practices, so that we
            refer to each others' documents
  MattKing: ARIA authoring practices guide
  <MichielBijl> -> http://w3c.github.io/aria-practices/
  <fantasai> http://fantasai.inkedblade.net/style/talks/best-practices/#title

  MichaelC: We were focused on a11y mapping specification.
  MichaelC: Not sure that best practices belong in ARIA best
  Matt: Want to make sure documents are coordinated.
  MichaelC: What I do with TFs is to set up an ? in formal W3C
            infrastructure for participation.
  MichaelC: Will have to talk about ML, anyone object?
  ChrisL: Certainly not objecting. In this WG we're trying to move
          away from MLs to GitHub.
  ChrisL: Would encourage TF to work on that.
  MichaelC: Put in link to ? would move it new github repo.
  MichaelC: Do you want me not to set up an ML?
  ChrisL: No, go ahead, useful for some stuff.
  MichaelC: Didn't want to do without permission.

  jcraig: Rossen mentioned pseudo-elements mapping to a11y layer.
  jcraig: Generated content mapped in majority of browsers... Chrome
          and Safari at least... Possibly Firefox. [Joanie responded
  jcraig: The issue that Michael just brought up that's interesting
          is, a separate github repo...
  jcraig: I have reservations about accessibility TFs within WGs.
  jcraig: It ends up getting groups of people siloed, so a11y people
          on one side and CSS people not in the TF don't learn about
          the a11y side.
  jcraig: My general approach is that this type of work should
          happen in the main group.
  jcraig: I feel that works a little bit better.
  <fantasai> +1
  astearns: I share your concerns.
  jcraig: Separate github repo ..
  astearns: I think github repo for deliverables is ok.
  astearns: My expectation for TF is that it's a coordination
  astearns: CSS folks in TF wouldn't be only ones doing work, would
            be the ones outlining the work and drawing in each
            editor as specs need mapping, adjustment, review, etc.
  astearns: On CSS side, people not directly on TF, don't assume
            that you have no a11y work that is going to be assigned
            to you!
  astearns: Just TF people will be ones coordinating.

  MichaelC: Core stuff about how CSS maps into a11y
  MichaelC: Often times a piece of that work will start in that
            spec, and then needs to move xyz place.
  MichaelC: I think coordination role of TF makes that easy to do.
  MichaelC: TF can set up preferences for access to repo to everyone
            or just editors or whatever.

  MichaelC: Also want to know if people involved prefer or oppose
  Rossen: I'm in favor of starting with light telecon requirements.
  fantasai: Maybe monthly?
  Rossen: Yeah, something like that. Otherwise work on github issues

  MichaelC: Also what level of checking goes through WG?
  MichaelC: e.g. sometimes TF will go to parent WG for each thing.
  fantasai: Probably we'll do both.
  fantasai: If an issue is a bug fix, then it just gets written.
  fantasai: If it's a design issue, it will go back to the WG for
  fantasai: (to make sure people are paying attention)
  fantasai: issue-by-issue basis.
  janina: I imagine it's going to come up regularly to consult with
          the APA.

  <jcraig> +1 for most (all?) discussions happening on GitHub rather
           than conf calls, as conf calls are imprecise, and
           inaccessible in both senses of the word.
  <tantek> also +1 technical discussions on GitHub rather than
           mailing lists.
  <MichielBijl> +1

  janina: In APA we regularly go over a spec, assign someone to read
          about a new spec and report to the csswg.
  Rossen: What I was saying is, let's start with the TF as an
  Rossen: We often have technical discussions, imagine those that
          require design change and will have to do with larger
  MichaelC: We'll need to pull in... make sure we have expertise
            from both sides for the border.
  astearns: At minimum I'd like to see notification, this is what's
            been discussed, here's the minutes.
  astearns: In most cases don't need extra step of "did we do OK?"

  jcraig: Regarding what's discussed, minutes.
  jcraig: I have a lot of trouble following minutes.
  fantasai: Have you tried following CSSWG minutes?
  jcraig: Those are different.
  jcraig: But in general, easier to follow discussions on github.
  jcraig: More accessible in all ways.
  jcraig: Can have full, precise discussion at any time.
  jcraig: So prefer to have discussion in text on the Web, most
  MichalC: That said, when disagreements, often easier to sort out
           in telecons.
  astearns: In CSSWG, as we discuss things on the phone or in F2F
            meetings, as opinion coalesces, people update github
            issues to say what we discussed, what we decided, where
            are the minutes.
  astearns: Think that's a good practice going forward.
  jcraig: Important to summarize, not just link to minutes.
  [discussion of what to discuss]

Media Queries for ARIA-details

  janina: Trying to avoid using the word, cuz lots of controversy
          over attribute, but trying to get beyond that because
  [jokes about longdesc]
  janina: Trying to get beyond that, firstly because we don't like
          doing things that are opposed by browser makers
  janina: Secondly have more general requirements from dpub.
  janina: Issue is, we want to make it possible for someone who
          isn't using AT to be aware of e.g. simplified description
          or braille alternative.
  <jcraig> AT == "assistive technology"
  janina: We have ways to do this for people who use assistive
  janina: What we're looking for is for people who don't use AT to
          get at that additional information, alternative
  janina: Want them to know that ARIA-details is available.
  janina: Idea was to make extensions/plugins to experiment.
  janina: The short-term ask is, can we have an MQ that all it does
          it says that this element has an extended description.
  janina: Also looking at extended MQs.

  Elliott: what is the aria thing you're talking about?
  Elliott: What computes an aria...
  Elliott: You wanted an MQ on ARIA-details, what computes
  dbaron: I'm also a little confused that you're asking for an MQ
          that's asking about the state of an element.
  dbaron: MQs are about the presentation context, not about
          qualities of a particular element.
  dbaron: Were you maybe wanting a selector?
  <tantek> maybe even a pseudo-class?
  jcraig: I think that what we were discussing is related to new
          aria property that is a string of text that isn't
          displayed anywhere.
  jcraig: More or less the same as details and summary in HTML.
  jcraig: I believe what janina is asking for is a media feature
          that allows you to detect when the user wants to see
          additional details.
  jcraig: If that's the case, then the design, the CSS should be
          able to display additional text.
  janina: Close but not quite.

  richardschwerdtfeger: What digipub wants to do is to show extended
                        descriptions for drawings on the page.
  richardschwerdtfeger: This could be alternative formats, could be
                        a whole variety of things.
  richardschwerdtfeger: Problem with digital publish is that by
                        default, publishers don't want this
                        information rendered on the screen.
  richardschwerdtfeger: But need ability to know that it's there.
  richardschwerdtfeger: They want to put the content in the pages,
                        and they want to be able for the user able
                        to activate a setting in the browser, that
                        would tell the book for example, to expose
                        this detailed information with drawings.
  richardschwerdtfeger: What they're asking for is the ability write
                        a custom media query.
  richardschwerdtfeger: Maybe through a plugin in the browser.
  richardschwerdtfeger: So that they could turn on a feature that
                        activates CSS to expose that information on
                        the page.
  richardschwerdtfeger: No opinion in interface.
  richardschwerdtfeger: Details attribute in ARIA simply says that
                        that extended description is associated with
                        this other thing
  richardschwerdtfeger: But publishers want to not impact the normal
                        visibility of the page, because they want to
                        preserve the intent of the publisher.
  richardschwerdtfeger: But for people who need the extended info,
                        want to be able to turn that on.
  richardschwerdtfeger: MQs are generally about OS/device
  richardschwerdtfeger: But this is about preferences.
  astearns: A user preference.

  Florian: co-editor, Media Queries
  Florian: dpub was still thinking about this idea yesterday.
  Florian: If it's just about the details element, then seems too
           specialized for MQ.
  Florian: But if it's a general "if there's extended descriptions
           in the page, user wants to see them"
  Florian: This is going into new area of user preferences.
  Florian: Related to preferences for inverted colors, high
           contrast, etc.
  Florian: We're exploring this category.
  Florian: Seems to fall into this category, but for e.g. invert
           colors, might be thing wishes to see OR might be thing
           user wishes to see but might have been forced by browser.
  Florian: Wrt details, browser can't do it for you, page has to do
           it itself.
  Florian: Need to explore more, but given what we've discussed
  Florian: Makes sense to me.

  Florian: Another thing is custom media queries.
  Florian: We've also discussed custom MQs, based on whatever JS
           wants to compute.
  Florian: I'm not sure how this would work out in this case
  Florian: Because in the case of custom MQs, this is the JS in the
           document talking to CSS in the document view MQ
  Florian: But for this case, you want the plugin to talk to the
           page via browser.
  Florian: It doesn't seem to really be custom, seems to be standard.

  rich: Also talked about "I would like to render different content
        based on my preference"
  rich: Management systems, working on today, have ability to store
        personal info about the user.
  rich: I would say that we quite know exactly what those are going
        to look like.
  rich: This is why extending MQ is a better solution, experiment
        and figure out what we really need.
  Florian: If it's about prototyping, then yes makes sense for
  Florian: We had custom MQs in Level4, but are deferring to L5
           because less stable than other stuff in L4 currently.
  Florian: At the moment it's unclear whether will go into MQ or
           Houdini spec in the future
  Florian: But definitely on the radar.
  Florian: Tab and I will be working on it, will either go into a
           Houdini doc or MQ L5 which we will be starting soon
           because we're wrapping up L4 nowish.

  jcraig: ... Toggles value of a media feature, tells web page it's
          ok to expose this info
  jcraig: Mentioned working on custom MQs, similar to data-*
          attributes in HTML. Allowed to do anything you want, no
          consistency across websites.
  jcraig: Is there an affordance here for a standard taxonomy?
  jcraig: We'd be discussing something like
  jcraig: If there's a list of standard taxonomies, where would that
  Florian: From my understanding this would be about prototyping in
           a limited context where people have agreed on common
  Florian: Once it's no longer experimental, no longer needs to be a
           custom MQ, can be a standard MQ.
  Florian: No need for prefixing.
  Florian: ...
  Florian: Room for experimentation if it's boolean, expresses ...
  Florian: But once no longer prototyping, should be a standard MQ,
           not a custom one.


  astearns: Move on to navigation?
  [discussion of whether to discuss navigation issue]
  <MichaelC> -> https://www.w3.org/WAI/APA/wiki/Category:CSS_Navigation
             Specs APA thinks are related to the CSS navigation
             issue (there are more, still need to tag them)

  rich: There are times in Flexbox where order is important to user
        of AT
  rich: What we had was, Flexbox was changing things visibly on the
        screen but it wasn't reflected in how it maps to the a11y
        services layer.
  rich: You're looking at things in a sequence.
  rich: That was first part of the problem.
  rich: Second part was that the keyboard navigation didn't quite
        follow the visual order on the screen
  rich: So someone who is blind and is trying to navigate, didn't
        make sense.
  rich: There needs to be a discussion on how that can be corrected.
        At the mapping layers, and also how keyboard navigation is
  rich: We had proposed a way to deal with keyboard navigation when
        necessary, but much more work that needs to go on in the TF.
  rich: When do we change the order? Should we change the keyboard
        order when Flexbox vies display on the screen? Etc. That
        needs to be discussed.


  astearns: Last item.
  astearns: Grid.
  <MichaelC> -> https://www.w3.org/WAI/APA/wiki/CSS_Grid_Layout_Module_Level_1
             APA notes on Grid

  fantasai: We're planning to transition grid to CR.
  fantasai: I emailed you at start of year. I think that's going to
            happen this week.
  fantasai: Wanted to check with you if there's any objections to
            this transition.
  rich: Wasn't involved in that discussion, and have sense where
        grid is mapped correctly.
  rich: Structural information in CSS, needs to be mapped into a11y
        tree with rows/columns.
  rich: More capability to do that in ARIA 1.1
  rich: Haven't looked at Grid, things need to be looked at in terms
        of accessibility tree.

  Matt: Want to make a statement.
  Matt: So, Rich just said that with grid, when affecting structure,
        needs to be mapped to a11y services layer.
  Matt: Want to make statement that we should not make any changes
        to the a11y tree that are also not reflected in the keyboard
        focus order.
  Matt: That's very important, that order of a11y tree matches
        keyboard order.
  Matt: That's really important for combination of touch and
        keyboard. Do not separate these two orders.
  janina: I think maybe we need TF to makes this a priority.
  janina: Since you're going to CR, not blocking, happy to be on a
          path to a solution.
  janina: More tools to offer, prioritizing is important.
  astearns: Grid is important.
  jcraig: Navigation index?
  <tantek> jcraig: nav-index was dropped long ago
  janina: Best summary is Cynthia's document.

  Rossen: Back to grid question for minutes, what I heard from APA
          there is no current objection to proceeding to CR, will
          work through issues in TF.
  Rossen: If any changes come up, we will take...
  janina: This is a chair expressing her opinion.
  MichaelC: Wanted to say that we have a wiki page for every spec
            that we look at, and our notes on grid are that we did,
            three months ago, plan to work on this in the TF. So
            don't think we were expecting to object to a transition.

  Florian: Don't know if you're aware of it, there is in CSS4 UI
           nav-up/down/left/right properties for spatial navigation.
  Florian: The ordered variant of the same, nav-next/nav-prev, are
           not specced.
  Florian: If you would like them to exist, let us know. If you
           think they'd be terrible let us know as well.
  Florian: There is something along these lines in CSS3 UI.
  jcraig: Tantek just posted that they died a long time ago.
  tantek: We took nav-index out completely years ago.
  tantek: Based on feedback from a11y and other feedback.
  jcraig: up/down is still there?
  tantek: Yes, in multiple implementations, referenced from TV specs.
  ?: I like that for SVG a lot.

  astearns: OK, out of time, thanks.
  janina: thanks CSS
  astearns: CSS will be on break for the next 20 minutes
  <MichielBijl> Thanks all!
  janina: APA in our room at 11!
Received on Wednesday, 16 November 2016 02:28:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:05 UTC