W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2013

Re: Dropping nav-* properties?

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 13 Jun 2013 08:14:11 +0800
Message-ID: <CACQ=j+c=4rsrEyrsH8Yz9nQzOPh46zFiYbKzKBCsf_0yBdPVxA@mail.gmail.com>
To: Henrik Andersson <henke@henke37.cjb.net>
Cc: "Vickers, Mark" <Mark_Vickers@cable.comcast.com>, Giuseppe Pascale <giuseppep@opera.com>, "www-style@w3.org" <www-style@w3.org>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
On Thu, Jun 13, 2013 at 5:22 AM, Henrik Andersson <henke@henke37.cjb.net>wrote:

> Vickers, Mark skriver:
> > Giuseppe,
> >
> > We do, of course, absolutely require up, down, left right keys in TV and
> set-top box Web applications to support TV remotes. Regarding these
> specific CSS APIs:
> >
> > - What do the nav-* properties bring that cannot be done in other ways
> (HTML, JavaScript, DOM Event APIs, etc.)?
> >
> CSS can reposition elements on the viewport. It would be very
> inconvenient to attempt to mark the navigation data elsewhere, since it
> would at minimum have to ask where css put the content.

I don't believe this is relevant, or at least, CSS doesn't do anything the
Author hasn't asked for it to do. If an Author uses nav-* properties, then
that Author would be rather silly to use, say, CSS transforms or animations
to start repositioning content without updating the nav-* properties. Yes?

> It also risks making things complicated if media queries were employed
> to select different layouts depending on uhm, media conditions.

Obviously an Author that chooses to use MQs and resulting different layouts
would need to be prepared to dynamically set nav-* properties via CSSOM

> TL;DR: Navigation depends on visual layout. CSS controls visual layout.

Authors control CSS.
Received on Thursday, 13 June 2013 00:14:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:16 UTC