Re: CSS aims

On Jan 23, 2014 8:02 PM, "Karl Dubost" <karl@la-grange.net> wrote:
>
>
> Le 24 janv. 2014 à 04:18, Brian Kardell <bkardell@gmail.com> a écrit :
> > One of us is clearly talking past the other.
>
> fwiw I don't really understand what you are saying either. I understand
better Simon. So I think maybe there is a lack of shared definitions. Not
the same culture when looking at the Web, not the same past, etc.

I agree.  I would be happy if anyone who understands me would help me and
vice versa. :)
I'm honestly, genuinely confused by how difficult this has turned out to
understand one another and desperate to resolve that.

>
> Maybe you should start what you think are the terms you are using such as
presentations, meaning, document, structure, etc. and how you articulate
them together.
>

This is the very question at hand.  I've asked quite directly whether there
was a simple canonical definition we felt we could point to in order to
illustrate - as well as specific examples of a comparatively simple problem
where it isn't exactly clear - certainly not universally understood and
applied.  Lets use your comments on those below as a start...

> Le 24 janv. 2014 à 02:57, Brian Kardell <bkardell@gmail.com> a écrit :
> > If you were creating an interface that includes, say, a list of folks I
know who are online, you might just have a list (<ul> or <li>).  Simple
enough.
>
> If we are talking about meaning. "ul" is not representing a simple list.
It goes a bit deeper than that. It is a keyword that surround a piece of
text and says that what's inside is a number of items or things in no
particular order (we could imagine a grocery shopping list). It's not often
used as is, but let say it matters. We are talking about both meaning and
structure here.
>
Are you implying that this is a misuse of an unordered list??? Wow i hope
not.  This seems to me a clear cut case of "yes that's
semantically correct and clearly structural".  That is why i used it.  If
you disagree with that I'm very confused and it would be super helpful to
understand why.

> > Now let's say you want to add an icon to the left of that - is that
style or structure?
>
> Style. The way you decide to visualize, render the list is clearly style,
it doesn't change the concept of a list.

I agree, and this is why i build on this simple example - specifically
because we have a box generated from css answer to that question already
(::before), with relationship to DOM but isn't quite DOM itself answer for
that case.

Now it becomes muddier if you start to put numbers in front of each items,
because there is a specific tool for this, the "ol" keyword. It is where we
start using the style to convey semantics to a document. A semantics parser
using the knowledge of html would not be able to understand that the intent
was this number of items or names are subsequent to each other.
>
I'm not sure if that example is better or worse than mine because i can't
build on it to get to the next step, and it seems easier to rationalize
that its not affecting the real semantic qualities of the list (merely the
presentational ones), but you hit it on the head with the word you use
"muddier".  There isn't always blindingly clear distinction.  Does it
matter?  I think not so much as some would purpose.  We've gotten adept at
working with the things we have, how radically should CSS aim to alter
that?  There are proposals/stated aims that would potential alter this
pretty radically if i understand them.  I am concerned by this.

> Someone could also argue because of the way the model of the document is
defined. The structure at the level of the DOM is always an ordered list,
but has nothing to do with the semantics/meaning of the text, it has to
with the semantics/meaning of the model and the parsers. The way we decided
to compute things.
>
> > With CSS, if you had data in an attribute or something you could use
::before to pick an attribute value and display a particular 'kind' of
image (online/offline).   Still, seems reasonably simple and fairly clear
cut.
>
>
> Well, you are mixing visual representation (style) and information
(meaning). First of all, you are making the choice of your visual language
is clear enough that this icon really means what it means to everyone. The
typical realization is all these icons in our UIs with the text equivalents
underneath. Then second is the assumption of visual language.
>
In my example the icon is, at this point purely a visual adornment - it
contains, meta information in the structure because it is logical to do so
so that it can be styled independently any number of ways - maybe the
foreground color changes, maybe the font weight...maybe an icon. It is a
visual thing...

> Stop using your eyes, close them, and use a vocal browser. Now how do you
convey that meaning of offline/online to the user?

CSS aural stylesheets?  Isn't that the point?  They can be localized too!

There are many things which have to be done so the thing is meaningful. It
requires a "message" both at the system and communicated to the human to
inform that there is a change of state.

I haven't even gotten into dynamism - I'm still talking old school page
here!  Still, in this trivially example my answer holds up and I think it
seems clearly presentation (yes, aural is presentation too).

>
> The fact to associate that to a change in a visual UI is the end of the
chain, not the start, and it represents only one channel of communications
through a visual language.
>
I think it sounds, like...we agree to this point?

...... However .....
You snipped out where i build tiny bits on these two, i consider clear cut,
examples to show where, as you said - it gets muddy and get to the
illustration of "does it matter?"

If i wanted to interact with that icon somehow - say rich informational
popup - does that change -its- quality in terms of requiring it to be be
structure vs presentation?  Some might say no - you should be able to use
:hover for example with a friend (idref) selector to describe this. But
what about if i wanted it  to be click/state driven?  There are proposals
in CSS for this too.  At what point does/should it cross the line and
become structurally necessary?

Now imagine that we hit this line and introduce an element (likely today
this would be a div or span (maybe a link or button) with class or meta
info and maybe some text content which is really only there so that we can
provide a simple element we can physically interact with in today's DOM.
OK, seems fine to me.  clearly you'd hang your icon styles off this new
element.  It's a somewhat arbitrary line, but we know it and we're pretty
adept at it.

Two weeks later, we decide maybe that functionality isn't necessary and so
we remove the listeners. The element now no longer necessarily serves some
self evident purpose on its own.  We already said if it wasn't for that we
wouldn't have added it. So now, even in this -very- simple example, we have
an example where some would argue that this is tag abuse: an unnecessary
element which serves no purpose but to hang a style off of.

I am trying to show that at _some level_ this becomes impossibly arbitrary
and maybe even wrong.  In fact, we've illustrated that there is potential
utility to current practice in helping to decouple: having this extra
element of structure actually enables more possible variants of script and
CSS without touching the HTML and it is mostly benign to the semantics.

I won't go so far as to say that this is always the case or that we can't
do better on some measures because i absolutely think we could - I'm just
saying that I'm not -as- worried about the fact that I need this extra
element in the markup as some.  I don't think it is necessary - in fact -
I'm saying it may be harmful to strive for über separation that create
significant "visual structures" via CSS.  If it is necessary to adorn
things via CSS it should consciously  recognize that the DOM is important
for many purposes and HTML is the language of serialization for the DOM.

Anything beyond seems to me new magic that requires explanation of its
existing natural relationship with DOM.

NOT to keep bringing up Regions, but Regions both explains and strides this
line pretty nicely in the sense that you can simply say "this elements
visual representation flows into that one and then that one."  This is
actually the quality about it that some don't like.  It isn't "pure".  I am
saying:  please...someone...anyone....show me "pure" that isn't hopelessly
complex.  We've seen attempts like that (xml,xsl,xsl fo, etc) and we've
rejected it.  I'm not convinced it is possible nor desirable.

The Regions draft seems like so much more than it is on its own because it
attempts to explain the magic of, and provide a primitive for so many other
proposals in the process IMO. On it's own, its utility is simple and uses
elements/explains the relationships.

> --
> Karl Dubost 🐄
> http://www.la-grange.net/karl/
>