definitely some thorny issues here
one of the reasons I'm interested in this is the prospect of using
the same technology that helps us present on little screens (whatever
it turns out to be) to help us present view of info on screens of
whatever size to people who want a simple presentation
from this viewpoint one would like the centrality/non centrality
markup to be semantic, not size driven, and one would like it to come
in as far upstream as possible
one would also like not the crude option of just tossing non central
stuff, but making it available if needed in progressive disclosure
(eg through a "more info" control
it could be that this philosophy is compatible enough with the ARIA
view to justify using their tags
though I still think that some uses of the ARIA tags by others would
not serve our other purpose of fitting on small screens
On Jun 16, 2009, at 7:16 PM, [email protected] wrote:
This seems promising, but I'm wondering whether we are getting to the
point where we have stepped over the threshold of burden we should
reasonably expect to put on static markup? Clearly we would want to
take the static world absolutely as far as we could, but it seems to
me that once we get to this point of issuing device-specific switches
in a newly coined markup namespace, we would want to start thinking
about notations to express this one level back, in the
"component tree" world?
If there is a physical tag that we would wish to suppress completely
on a particular device, it would seem better to set about making
rules to suppress them during rendering. This of course creates
issues of user agent detection and persistence, etc... it is always
a bit disconcerting for me to paste URLs to people from Google Maps
and find they contain junk like "&agent=opera" etc.... but this is
at least evidence that this approach is workable for someone :P
Cheers,
Antranig.
Quoting Clayton H Lewis <[email protected]>:
there's an approach that's been hiding in plain sight (from me,
anyway)
among the ARIA roles are "main" and "complementary"
they are intended to do what we want, marking the more and less
central content in a page
only one thing in a doc is supposed to be tagged "main", so that's
not very flexible
but lots of things can be tagged "complementary"
since roles are attributes that CSS can select on, it is easy to
style out anything tagged "complementary"
this very simple example page shows this:
<html>
<head>
<title>Role Styling Test</title>
<style type="text/css">
div[role="complementary"] {display:none}
</style>
</head>
<body>
<div role="complementary">
This is secondary text.
</div>
<div>
This is important text.
</div>
<div role="complementary">
This is secondary text.
</div>
<div>
This is secondary text not marked "complementary".
</div>
</body>
</html>
A drawback to using "complementary" in this way would be that if we
were dealing with content someone else had tagged for ARIA, say with
a screen reader in mind, they'd be using "complementary" differently,
that is, NOT to mean "don't show this on an iPhone". so we'd have to
mess with their tags. We can use RDFa to coin our own role tags that
no-one else would use, as in this example page:
<html>
<head>
<title>Role Styling Test</title>
<style type="text/css">
div[property="fe:complementary"] {display:none}
</style>
</head>
<body>
<div role="complementary">
This is secondary text marked with the ARIA "complementary" tag. It's
visible in this version.
</div>
<div>
This is important text.
</div>
<div>
There follows some text marked with our very own "fe:complementary"
property. It should be invisible.
<div property="fe:complementary">
This is secondary text marked "fe:complementary".
</div>
</body>
</html>
Clayton Lewis
Professor of Computer Science
Scientist in Residence, Coleman Institute for Cognitive Disabilities
University of Colorado
http://www.cs.colorado.edu/~clayton
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
Clayton Lewis
Professor of Computer Science
Scientist in Residence, Coleman Institute for Cognitive Disabilities
University of Colorado
http://www.cs.colorado.edu/~clayton
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
