Re: CSS aims

Le 24 janv. 2014 à 13:47, Brian Kardell <bkardell@gmail.com> a écrit :
>> 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).[…]
> Are you implying that this is a misuse of an unordered list??? Wow i hope not.


A grocery shopping list is exactly the use case of "ul". The *text* has this meaning. It has also other meaning which are not defined in HTML by default such as the quality of the items, for example vegetables.

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.


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


> 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 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. :)


> 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. :)


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

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. :)

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



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

Received on Friday, 24 January 2014 15:07:54 UTC