Re: CSS aims

On Thu, Jan 23, 2014 at 1:10 PM, Simon St.Laurent <simonstl@simonstl.com>wrote:

> On 1/23/14 12:57 PM, Brian Kardell wrote:
>
>>     It depends on what you are meaning by structure, what you mean by
>>     presentation, and what you mean by… meaning. :)
>>
>> Given where we are in Web history, doesn't it feel like there should be
>> a fairly simple canonical definition we can point to to answer that
>> question?  Where is it?  Does it exist?
>>
>
> No, it doesn't exist.  These - meaning in particular - are human terms.
>
>
>  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.
>>
>> Now let's say you want to add an icon to the left of that - is that
>> style or structure?  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.
>>
>> But -- what if I decide I might want to interact with it somehow?  Does
>> that change its nature?  Now I need it to be a real element and -- seems
>> legit.
>>
>
> Does there have to be a single answer to this?  I've been lurking on this
> list for a long while, and broadly support its aims, but this whole thread
> feels to me like programmers trying to nail jelly on the wall. Locking web
> content into the kinds of boxes that are typical of other GUI development
> environments seems like a guaranteed loss to me overall.
>
> Let authors and app creators use HTML.  It's not that precise but it
> doesn't have to be.  Then layer on CSS, and layer on JavaScript as needed.
>  It doesn't all have to work the same way every time.
>
> Much of what I like about prollyfills and Web Components is that they let
> developers encapsulate these decisions, allowing people to share
> functionality without insisting that they all do it the same way.
>
> I'll write more about this at length someplace when I have time.
>
> Thanks,
> --
> Simon St.Laurent
> http://simonstl.com/
>
> Simon,

Having read what you said, I'm not sure which part of what I wrote in any
of my posts you actually disagree with.

There is a purist notion that there is a very important difference and that
presentation should be the realm of CSS.  Layouts are presentation - but
CSS has been trying to solve this problem (how do I express layout in CSS
(meaning specifically NOT using markup, but the language of CSS) when I
need boxes and relationships that aren't in the DOM) since at least 1996.
 I think this is a laudable goal, but I have not seen any proposal for such
a thing that doesn't involve dubious amounts of complexity or hasn't been
ignored.

The reason that this comes up is that there are currently a number of
proposals underway in the CSS working group which involve some form of this
box generation/management - IE - new magic.  We haven't explained the old
magic :)
Alan (one of our group members from Adobe) has a proposal for Regions in
CSS which attempts to expose a cross-cutting primitive to explain these.  I
think it's reasonable to debate whether it is the right primitive, etc -
but there have been a number of efforts to stymie it simply because it
recognizes a relationship between DOM and CSS which has always been there
(and I am arguing, probably wont go away any time soon).  In other words,
instead of requiring you to use some brand-new language for defining boxes
or slots in a layout, Regions allows you to just use HTML.  This is
considered to some a high crime because it goes against the "core aims of
CSS".

My purpose in asking these questions might seem academic, but there are
actually fairly concrete reasons that this sort of existential crisis
blocks abilities to uncover primitives or make good proposals for CSS.   I
think it's important that we get past the purist argument if possible for
all of the many reasons stated in this thread.


-- 
Brian Kardell :: @briankardell :: hitchjs.com