Re: Accessibility of "CHM" format resources

These really are taking up too much time, but I'll try to elaborate as
best I can.

On 6/6/05, Tina Holmboe <tina@greytower.net> wrote:
> 
> On  6 Jun, Orion Adrian wrote:
> 
> > I consider it petty criticism when it has nothing to do with the
> > argument I was trying to make but is rather a backdrop.
> 
>   The argument you were trying to make was a statement:
> 
>     "CSS still is unusable for most of the web and requires
>      such an act of contortion to get anywhere near a
>      desireable result."
> 
>   which is easily disproven. Unless you by "desirable result" mean
>   "looking exactly as in the Photoshop drawing, everywhere", then all
>   you need to do is look at a real life example of a website which
>   actually *use* CSS, and only CSS, for layout.
> 
>        http://www.w3.org/Style/ ? http://www.opera.com ?
> 
>   Neither seem to jump through too many loops, and they are definetly
>   not dire pictures as you claim they must be. They work, both of them,
>   using CSS for layout - not a table in sight. Both could be improved,
>   code-wise, but that's *not* what we are "discussing".
> 

I find the choices interesting, but I would still say using float for
menu/content/menu to be an bastardization of the original intent. I
can make a rock work like a hammer, but I'd rather have a hammer.
Float wasn't designed to do that, but alas it is the best option at
hand.

Constants would allow for better management and avoid lines like:
	background:#eff0ec;
which when reading do me no good since I can't convert rgb codes into
color in my head. Also in the case of opera.com, it uses extensive use
of pixel lengths and sizes.

Taking an example out of my book. There's no sane way to mix em/ex
with percentage units with no method of calculation (an alternative
system I suggested in another part of this thread). So if I have a
border with my 3-column layout, it's just as likely to break apart
(columns will) as stay together.

> > (the actual languages themselves). I find that the current view of
> > them is very limited. What gets considered a programming language and
> > what doesn't very much seems to revolve not around the actual term,
> > but rather impressions left behind by the early prominent programming
> > languages.
> 
>   No, what is consider a programming language depends on whether or not
>   it is Turing-complete. That, of course, is a definition, one "we" have
>   all agreed on.
> 

Language changes even in the technical sense. It's best that you avoid
trying to insult me to make your point. "We" don't like that.

>   You are free to create your own definition, but, if you want to
>   communicate with others, a minimum of common ground is needed. Per the
>   definition programmers world wide agree upon, neither HTML nor CSS are
>   programming languages.
> 

I don't see the focus on this. This should have been a minor point and
then ignored.

>   Whether you consider them such will just serve to confuse the rest
>   of us and, ultimately, lead to your statements being dismissed. When
>   someone talk about how much chocolate cream is needed for a K70 grade
>   concrete, builders tend to zone out until he goes away and leaves them
>   alone.
> 

Again this has taken up too much time. I'm also not talking about
something so radical that the rest of you didn't get my meaning. If I
call a truck a car, you still get my drift. Not one of you I would
imagine thought I was talking about something other than CSS when I
said CSS programming language. Please drop it.

> > As a matter of conformity, no it's not traditionally called a
> > programming language nor thought of as one. I, however, hold a broader
> > view.
> 
>   And that's the real gist of it, isn't it?  You've brought forth the
>   Big Argument, with which no-one can argue. Regardless of what I say,
>   I'm on the closed-mind side.
>
>   Nothing new.
> 

No. I never said you had to agree. I never said you had to have the
same viewpoint. But forcing the restriction upon me over a rather
trivial matter (and it is trivial) you are closing off options from
me.

> > I do have a firm grasp of programming, accessibility, platform design
> > and many other things. It doesn't really matter where I got them. So
> 
>   I doubt this claim. However, let's move on to the issues raised:

This is just insulting. I have been known to be tactless, but this is
just instulting. As far as I can tell you're either calling me a liar
or delusional (i.e. not in touch with the real world).

>     "I'm talking about the pains it takes to setup a multi-column
>     layout."
> 
>       - I assume you refer to re-flowing, newspaper-style, content
>         columns, as the usual menu-content-menu styles are easily
>         achieved. Now, newspaper-style columns of content might just be
>         a rather poor idea on the web - I'm pondering what'll happen if
>         one magnify the content; how to tell where one column end and
>         another being ... - and is, regardless, covered in CSS 3.
> 
>     "I'm talking about poor naming of elements."
> 
>       - there are no elements in CSS, unless you mean pseudo-elements. I
>         can only assume that you've gotten them mixed up with the SGML term.
>         Perhaps you are referring to *properties* - the only one I can think of
>         with a really *odd* name is "text-align", but regardless: what has the
>         names of properties to do with the usability of CSS?

Element as per my dictionary, defintion 1:

A fundamental, essential, or irreducible constituent of a composite entity.

If we're not speaking English please tell me.

>     "I'm talking about implicit interactions between properties that authors
>      still have to learn."
> 
>       - This one I don't understand. Unless giving a GUI-based frontend, one might
>         presume that authors will always have to *learn* the language they are
>         working with. Again, what has this got to do with whether CSS can be used
>         to achieve layout today?

I referring to implicit versus explicit rules. Implicit rules are
harder to learn statistically. Explicit ones which can be easily
categorized are easier. CSS uses in several places rules that are
dependant on the style rule, but not described in the language's
grammar as a whole (therefore they are implicit).

>     "I'm talking about thge lack of user constants, a simple construct with
>      no cascading technical issues."
> 
>       - We can discuss that, of course; though there really are little point
>         in having such a feature in CSS per se. However, and again, does this in
>         any way prevent you from using stylesheets, today, for layout? That was
>         your original contention, after all.
> 

I detailed this above. I once read that maintenance accounts for 80%
of production costs which more or less holds true with my experience.
Readability is crucial as it helps with maintenance. Organization is
critical as it helps with maintenance. Constants produce names which
are easy to remember than #45f923; Can you tell me the exact color
that is without cheating? I can't.

>     "I'm talking about the absurdity that are the display models (box, inline,
>      replaced, table, list)  Some are good, most are bad (especially table)."
> 
>       - Do tell. What's bad about 'table'? I'm not certifiable, you see, so
>         I don't know.

Certifiable? Wow. I'm not sure if that was a typo or another shot at me.

Here I am referring to the anonymous boxes and the inability to
address them. Someone said they had no issue with tree-markup. Here's
where I have an issue. While selectors can work here, they have an
issue since columns have no children. Either rows have have children
or columns, but not both. So we have an impass and CSS suggests no
such mechanism to resolve this.

>      "I'm talking about the inability to specify clearly that one element is
>       relative to another independant of the relationship in code."
> 
>        - Um? Elements - in the markup language - are relative to one another
>          depending ENTIRELY on their relationship in code. CSS should not, and
>          must not, do anything to impact that. The *markup language* define
>          the structure; CSS does not.

Presentation is not so inflexible that there are not times when
something would be better off not where it is in code, but where it is
most comprehensible on the screen.

>      "I'm talking about the claim that CSS works with many languages (as
>       long as they're tree-based and called HTML or XML)."
> 
>         - This has what to do with the usability of CSS on the web today?

It means that it has sacrificed tie-ins that would make life easier.
CSS could be more tightly integrated, but I have heard many times that
CSS isn't just for HTML or XML, but for any language. But the
selectors are clearly tree-based.

Making the selectors independant and modular would allow any language
to specify how the style rules relate to it.

>      "I'm talking about the non-modularity (only recently addressed) of CSS
>       and the total lack of extension mechanism including those things that
>       would allow for other languages to be styled."
> 
>        - Again I am confused. Are you thinking about allowing authors to extend
>          CSS? Or those who write the spec? The modularity of CSS 3 is simply
>          a matter of convenience, after all.

I'm talking about other specs talking about how they relate to CSS.
That way each language could specify the selectors, pseudoelement and
pseudoclasses it needed. Use cases that require look-ahead selection
could simply hook into it and many use cases would be opened up.

>      "I'm talking about all the little annoyances that come about any time
>       I've ever tried to code up a CSS page."
> 
>        - Indeed. These annoyances can have many reasons - poor browser support,
>          poor layouts, poor medium adaptation, poor knowledge of the languages
>          involved, details lacking from the languages, and so forth.
> 
>          Which do you think it is?

CSS's lack of relavent vocabulary to the tasks I am trying to
accomplish. Even following the spec it wouldn't handle it without
manipulation which I consider above and beyond. Along with many other
authors who don't contribute here.

>   Mind, I am sorry I lost my temper. Mea culpa. I really should know
>   better.

Orion Adrian

Received on Tuesday, 7 June 2005 01:58:42 UTC