Re: CSS aims

On 1/23/14, 10:44 AM, "Brian Kardell" <bkardell@gmail.com> wrote:

>
>
>
>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".

Regions is agnostic about where the boxes come from. You can just use
HTML. Or you can use pseudo-elements like ::before and ::after. Or you can
use any new box-generation mechanism we devise (such as grid ::slots). The
crime being discussed is allowing the use of presentational elements in
the markup as regions. My position is that while I agree that separation
of concerns is a good principle to evaluate proposals against, it should
not be a hard stop to extending the web. I’d like to proceed with regions
using HTML elements for now, with the hope that new ways of generating
boxes in CSS appear in the future.

Thanks,

Alan

Received on Thursday, 23 January 2014 18:55:12 UTC