Re: CSS aims

>
> I'm saying that here, because I have the feeling, you have a programmatic
> view of a Web page. When I have a content view. The meaning of the content
> of the page is what matters the most for me. And I guess what matters the
> most for you is how you can interact with the content. And it's why we are
> not talking about the same thing when we say structure or semantics.


Ok, let me try to clarify - feel free to improve on this:

Semantics aren't a thing I can point to - they are about meaning.  For
"real" documents (which I define for purposes to be used here as in the
things you could in theory print on paper or have read to you - which is
where the concept really originates), there is a pretty nice serialization
for conveying semantics about a document - HTML - and it provides a, not
wonderful but provenly decent and increasingly good, means for expressing
the sorts of semantic structures that describe this sort of document.  And
why wouldn't it - that was it's purpose.

The DOM is a tree representation of structures, it really couldn't give a
shit about semantics.  BUT... and this is important -- the DOM is created
(in the browser, let's please not get too meta unless you are going
somewhere specific with it) is by parsing that serialization - HTML.  So
there is a keen, but clear relationship there.  I didn't create it, I'm
just saying "it's there".  That isn't a programatic point of view, it's
just a statement.  As a result it generally winds up containing about the
same level of semantic information as the serialization that created it.
 I'm not sure if that matters, it's just a statement.

CSS operates on on this tree structure (DOM), and it also doesn't give a
shit about semantics... BUT ... the DOM came from the serialization, so
there is a relationship there.  This is not a programatic view, it's just a
statement.

Sticking with only talking about a case that involves no scripting (not
because I think one is better or worse, I just admit that they both exist
and want to keep it simple) this is all well and good until you want to
render or display something visually which doesn't quite sync up with how
it is semantically described.  Why?  Because CSS is based on the DOM.  It
is extremely limited (currently) in it's ability to take those DOM
structures and lay them out at the designers whim to do all sorts of
interesting things... Some of these are the kinds of things we do with
physical documents too - so that is a problem that a lot of people feel
very strongly about and the CSS WG has been pondering for a long time.
 Currently the nature of CSS and rendering is very very married to the DOM
created by HTML, that will change.  The question is a matter of degrees:
How, how much, why, and how to get there.

Now, beyond this simple set of relationships described above relating to
what I have called "real" documents - much of the Web, in reality, is
considerably more than just that - right?  We involve behavior and dynamic
interaction beyond what you could print out.  This too is not "my
programatic view" it's just a statement of reality.  For a vast amount of
the Web to work requires the DOM to be used by scripting as well.


>
> > 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.
>
> You see. That doesn't matter for me. What matters to me is that there is
> this piece of text which has a specific meaning, and I can *eventually*
> hook style information about it. Remove the style and the text is still
> meaningful.
>

This seems to be an illustration which we agree shows things working
well/pretty much as intended.  Does it not?  What's to disagree about?  If
you say "it doesn't matter to me" you aren't speaking of the the whole
system, you are just speaking of HTML and I'm not sure the purpose of the
conversation.  It should matter to you that that works I would think.


>
>
> > 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?
>
>
> Ah interesting. I was using it's "getting muddier" because I consider
> putting numbers on "ul" is doing an inappropriate use of style to try to
> convey semantics information (to only one category of people, those with
> eyes to read it) which is not existent in the original text. So there
> **is** a clear distinction.


I see.  And I think this stems a little in part from our XML history - I'd
like to think that the content in this document can be displayed any number
of ways with different CSS.  With additional meta information in the page
it is very plausible that there are other views - but let me give you one
that doesn't require any.  "10 Groceries you need" is something which
conveys no priority, but would often display numerics in the list.  It
wouldn't be an ordered list because you wanted to show numbers, else you
would be mixing semantics with presentation, no?


> > 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.
>
>
> The fact that people are using hacks all the time doesn't validate the
> hacks. The fact that my English grammar is utterly broken, and you can try
> to understand it, doesn't make my English grammar correct. :)
>
> You misunderstand the weight and direction of my comments.  If you have
something that works on billions of pages which we have great experience
with and has wider spread adoption than just about anything in the history
of humankind, it worries me to change it radically.  We've tried changing
it radically.  I prefer a progressive, iterative approach unless someone
can show me something so blindingly clear that I cannot argue it.  I have
not seen, nor can imagine that thing.  I can imagine a great number of
intermediate forms.



>
> > I haven't even gotten into dynamism - I'm still talking old school page
> here!
>
> […] old school page… let me sigh. ;)
> It's not because some people pack meaningless JSON files and renders it
> through JS on the client side that it makes it better or more modern. :)
>
>
I made no claim of better or more modern, I merely recognized that this
phase of my example doesn't even involve the additional DOM importance
created by how we do dynamic updates - it is "original intent" kind of
stuff.


> > 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?
>
>
> AH! You are talking about programm semantics, not text semantics. This is
> a very interesting topics and indeed we had a tendency by lack of other
> tools of using plenty of hacks to try to achieve what we could do with the
> browsers. hacks
>
> For example,
> * people tried to use table for creating layout.
> * many Web pages are using lists for making menus, UIs which are shared
> across the full Web site.
> * some Web sites are complete applications encapsulating the real
> semantics document (Webmail app, codepen sites, etc.)
>
> All of these I consider them as abuse of html, because people didn't have
> a way to play with a common language for interfaces hooked directly in the
> browser chrome.
>
>
So your answer is "everyone just stop using the web for that?!?!?"  There
must be more to your statement that I do not understand.  We don't get to
pick where we start - we start here :)  This is the reality that we live in
and I will bet you vital bodily appendages that the Web as we know it isn't
going to be supplanted by something "new" any time soon.  So the question
is - how do we make it better... If you start from the point of "that is
all hacks and we should be doing none of it" - I'm really not sure where we
go from there...



> It's quite ironic that for example the link rel="next/prev/up/etc"
> disappeared from Opera and Netscape and that we are consistently recreating
> this feature into the HTML. Why? Because people had no interoperable way to
> modify the chrome with their own style.
>
>
> > 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.
>
>
> People are already doing that and it doesn't seem fine to me. :)
>
>
Ok, so ... how?  Again, is it just "please stop that?" or  "Get off my
lawn!" ??



> > 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.
>
> It is :)
>
>
> > 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.
>
>
> So you are calling for a UI language. This has been tried many times. :)
> Maybe we can try again. I let other people who burned themselves with XUL,
> sXBL, etc. And all of that without entering the classical discussion of
> "feel native" aka how the Web application is mimicking the silo of the
> platform it's on. :)
>
>
I'm not "calling for" anything - I really wish people would stop saying
that. I am trying to have a rational discussion about what the appropriate
level of separation is, what we can imagine, how to get there and sharing
my own perspective.  I'm not even "advocating" for something radical, I'm
asking for more rationale from others who are!



> > 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.
>
>
> It is not. You got that reverse. Huh. But it shows perfectly where you
> come from. You are a programmer not a writer ;) without reproaches. The
> classical lightbulb metaphor: it's a filament burning atoms, it's a tool
> for giving me light, it's an object of design, etc. :) Same object
> different interpretation.
>
>
> Alright.  I'm not sure how your turning me into lightbulb advances the
conversation in any meaningful way, but at least I can be happy you think I
am bright ;)




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


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