Re: CSS aims

(My apologies to Ambrose for the personal only response :) this time to the
list)

To set some ground, I percieve this discussion as "Is it appropriate to,
and to what extent can, we seperate Semantics from Presentation, and what
tools should be brought to bear to do so?"

Definitions

Semantics
http://en.wikipedia.org/wiki/Semantics
"Semantics is the study of meaning."

Meaning
http://en.wikipedia.org/wiki/Meaning_%28linguistics%29
In linguistics, meaning is what the source or sender expresses,
communicates, or conveys in their message to the observer or receiver, and
what the receiver infers from the current context.

Structure
http://en.wikipedia.org/wiki/Structure
Structure is a fundamental, tangible or intangible notion referring to the
recognition, observation, nature, and permanence of _patterns and
relationships of entities_.

Presentation
http://www.merriam-webster.com/dictionary/presentation
"the way in which something is arranged, designed, etc. : the way in which
something is presented"


Restateing the  question in these terms "Can we, and should we, seperate
what a provider is trying to communicate from the way in which is is
arranged and presented, and how should this be achieved".

I will give my answer and thoughts out of order. Should we? There is a
strong reason, in my mind, to tend towards the ability to seperate the two
- typically it is different skill sets, and thus different individuals,
responsible for providing these two goals.  In print documentation and more
typical "web pages", there will be authors who create the communication -
essentially describing something (the Meaning), and there will be editors
or graphic designers who will create the "presentation" of that
documentation in a way that is pleasing to the eye or sets a mood or fits a
publication medium.  Applications will be built by engineers who will
provide data, relationships, and functions for a user, while again
designers will be brought to bear on the problem of making those functions
and content look good and follow "usability" and "stylistic" guidelines.

In different oranizations, that seperation can be more or less, but many
organizations that seperation is very strong, and each has their own
responsibility in the job at hand, and not having a way to clearly seperate
AND join these responsibilities, makes the job a constant compromise and
requires a very high level of interaction and interplay between these two
functions - designers requiring engineers (or content providers) to modify
their semantic output to provide structures for purely presentational
aspects.

So to me "should we" is answered: YES. And how completely? As completely as
possible to allow as loose a coupling between these two jobs as possible.

Can we - I dont really think this needs to be discussed, it is clear to me
(and i think anyone) that we CAN seperate these things, the real issue is
can we and still have a realistically useable system.

So before we can get to the how, I think we need to clarify a few more
points. Most discussion of HTML vs CSS talk about semantics vs display. But
what throws a monkey wrench in the discussion is that HTML=Semantics and
CSS=display is not quite the correct formula!

HTML represents STRUCTURE (patterns and relationships of entities)
extremely well, (in particular heirarchical structure, but that is only
tangentally important). HTML, via specialized tags and attributes, can also
express various dimensions of meaning as well.

By definition, semantics will require structure and meaning, so HTML as an
existing tool would make sense to convey the same.

CSS, by contrast, expresses visual aspects of presentation well (and aural
CSS etc other forms of presentation - I will focus on visual as I have only
moderate experience with the others) except for one - positional/relational
aspects of that presentation!

I feel like this would lead to an obvious conclusion - visual STRUCTURE
could be represented by the tool we have at hand for structure - HTML.

I hear the cry already - but you said you wanted these things seperated!
And indeed I did, and have not at this point contradicted myself. I did NOT
say that the same HTML that is used to supply semantic structure should
also be the HTML that provides presentational structure! And that seems to
be the key.

Yes, we could provide CSS with additional constructs to represent
structure, or introduce yet another language for describing "presentational
structure" but that does not seem to be a reasonable idea, with a perfectly
workable tool already in hand.

So do we simply have two uses of HTML, that previously were forced to be
co-mingled, and part of our answer would be how do we provide for a cleaner
speration of semantic html from presentational html? It also seems to me
that the up-coming Web Component specs may provide us some of the answers
to this as well...

What I can see missing, and the way to move this conversation forward, is
providing the correct tools to connect the various pieces at the right
points. It is clear there are some opens on how and where you would insert
the presentational structure parts if they do not pre-exist in the semantic
structure. This is where effort should be expended to close these gaps, and
allow the tools we have to comfortably satisfy these two needs without
requiring the comingling of concerns.





On Fri, Jan 24, 2014 at 1:10 PM, Ambrose Little <ambrogio@gmail.com> wrote:

> It seems to me this thread has strayed away from the original question,
> which is in itself fairly interesting.
>
> "Is it plausible to imagine a *clean/reasonably complete decoupling* of
> presentation from structure without adding *dubious amounts of complexity*
> ?”
>
> Part of the problem with the question is “dubious amounts of complexity”
> is very ill defined and largely a subjective value judgment. I guarantee
> that my bar for dubious amounts of complexity is probably lower than many
> devs. While we’re all relating our past scars, I’ve seen very many cases of
> this—introducing extra complexity for the sake of conceptual purity (even
> when motivated towards otherwise good ends). This is across numerous
> technologies and frameworks...
>
> Anyways, to answer the question, I think we’d have to have some shared
> sense of what “dubious amounts of complexity” is, and I doubt that’s gonna
> happen, because, again, it’s a value judgment tied up in the perceived
> goods/goals of any given design.
>
> It’s also subject to a question of who has to face the complexity and
> when.
>
> The same problem exists for “clean/reasonably complete.”  The qualifiers
> are going to rely on the observer’s judgment.
>
> I suspect there are plenty of HTML wonks who think the current spec is a
> pretty good incarnation of what you are asking for. The problem is the
> world that they imagine HTML thriving in is far less complex than the
> reality of the world we actually live in.
>
> And there’s the rub—none of us has the capability to grapple with the
> staggering complexities of all of the real-world usage scenarios of Web UI
> technologies. Anyone who says differently is selling something. And those
> scenarios are growing exponentially in step with increasingly ubiquitous
> computing.
>
> In the face of such real life complexity, any proposal that claims it can
> achieve clean/reasonably complete decoupling without dubious amounts of
> complexity must necessarily fudge something. Either it fudges the meanings
> of the vague terms, or it vastly limits its problem domain.
>
> Now does that mean we throw in the towel? Of course not. Does that mean we
> swing the pendulum back to inline/mixing in everything? Of course not. It
> simply acknowledges the reality that we are faced with and suggests that
> while not sacrificing the good principle of decoupling (which has definite
> practical benefits, not just academic/conceptual purity), we shouldn’t
> expect to find a solution that magically makes the complexity go away. It
> just migrates around.
>
> And that’s why I actually thought this was a decent statement/approach to
> deal with the question:
> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies (thanks,
> Marcos)
>
> Although I find it still smacks of too much document-content-centricity,
> the underlying sentiment points in the right direction. It’s easy to
> champion principles (like SoC) over competing practical realities and/or
> other competing principles. The trick is finding a good balance between
> them.
>
> In any case, one of the things that I find motivational about this group
> is the idea that we take a practical-first approach—letting the future
> emerge evolutionarily from real-world usage (hacking) and concerns,
> iteratively improving, rather than expecting a group of people to
> preemptively imagine (and sufficiently design for) all possible cases. That
> is, as I see it, both the only practical, and indeed the best, way forward
> for the Web.
>
> -a
>
>