Re: Headline: Styles pondering desertion to Content!

Lachlan Hunt wrote:
> 
> Wingnut wrote:
> 
>> ...this new "floating, bound, re-useable, object-tag-made border" does 
>> one OTHER drastic thing to the CSS spec. It opens the possibility of 
>> removing all MARGIN settings from all containers and box models.  Let 
>> me try to explain how.
> 
>   You have to remember that CSS is not only for XHTML, it's for any kind 
> of XML document, so even in the unlikely event that your OTMB is added 
> to XHTML, CSS must not change so drastically because of it.

I can see your point, but in the same breath, we must not let CSS become 
solidified beyond change ideas... just because its being used by 
multiple applications.  In most folks' logic, border is "an adornment" 
that could be labeled as content OR presentational.  And using that same 
logic, an oval/circular border deserves to be right next to the square 
border.  And so does underline and overline (partial borders).  Then, so 
does triangle border, so where is triangle box model?  Where is circular 
box model?  We got trouble... right here in River City.  Yes, there's 
always SVG to markup teacher-graded papers, but that sure seems like 
taking the long bus to school.  All in all, its not imperative that I 
point-out where I believe style and content have overlapped.  Its 
imperative that I think about making a "grading application" and 
toolbox of widgets... for teachers to quick-paste "over" a 
student-submitted HTML document.  And, yackin' with you big powerful 
spec-dogs about choices available now and in the future.  Bottom line 
is, I'm not going to build a library of 5000 different PNG's or SVG 
embeds/formulas... of an arrow, in every color, shape, pointing angle, 
arrowhead type, and shaft thickness IF... the W3C is going to be kind 
enough to consider some other method for "us".  The "Its hard to markup 
a graded school paper!" is a very large, very real hassle.  Maybe no 
more important than any other specialty document that HT/X ML struggles 
to markup.  In a way though, aren't we talking about an "after the fact 
whiteboarding system"?  Anyway, I'm getting long-winded again.  SVG is 
being looked-at.  Another system I call "hot dots" is being looked-at... 
which is a mouseover or clickable dot that gets placed strategically on 
a graded paper.  Opening the dot reveals teacher comments in a popup. 
But we lose much "teacher boldness and expressionism" in a hot-dot 
hypergrading like that.  Sigh.  Thanks for everyone's continued thoughts 
and comments on this subject!  (And for your patience with my yapping.)

> 
>> This hypothetical new object-tag-made-border, heretofore "OTMB", is 
>> something that is "binded" to one or more selector-found box models in 
>> the document...
> 
> <snip/> Long description of how the OTMB should work...
> 
>   The way in which you are describing these objects sounds very 
> presentational.  You seem to be confusing the difference between 
> semantics and presentation.
> 

Likely.  I call grading-dohickies "content" because they are "the data" 
of the grading process.  Teacher added data.  Its is not to "adorn" the 
original content.  Or is it?  :/  I'm not well versed with all the 
proper terminology, but I do know that I need some styling power on my 
ARROW element.  I need it aimable, colorable, widthable, lengthable, 
arrowheadable, dual-shaftable, tri-shaftable, etc etc.  Same with 
circles, brackets, braces, text, all need colors, fonts, sizings, AND 
ANGLING!  I need rotation around the z axis... for ALL these critters 
including rectangular borders and text.  So you see, CSS's border might 
be "a different critter" than what I want.  This is what you suggest... 
a complete different system.  But when these "grading mobs" get put to 
screen, in what form are they?  Will they need to be a pic in the end? 
If so, no good. I'm not going to draw a library of 100,000 different 
sized ovals for the oval library.  I would need the browser to "gen" the 
oval from the params in the object tag, ideally.

SVG?  Its canvas, to date, is at best... scarey.  Try to get a black 
background in an SVG!  Beyond these kludgey solves, is beyond my 
intelligence.  If I write an XML extension to markup these mobs, what 
browser will ever display them?  Keep in mind that the original content 
(the student's assignment) is likely in classic HTML, or as an actual 
.TXT file. These are the more-common paperless student formats.  So, 
going through a long, contorted conversion process, possibly to 
all-SVG... seems like such a gruesome walk through the swamp.  Thus, I'm 
checking with the W3C to see if they would give any thought to "beefing" 
the OBJECT tag in such a way as to ALLOW IT to have access to a possible 
new "paint-a-dohickey-anywhere" graphics subroutine in next year's 
browsers.  No, I'm doing MORE than "checking", I'm nearly BEGGING! :)

>  From your original post:
> 
>> A document full of original content, along with
> 
>  > teacher-added circles, arrows, margin scribblings,
>  > cross-outs, angled text with transparent background,
>  > all those "dohickies" teachers use to make comments
>  > on a student's assignment.
> 
>   Your original requirment of marking up all those "doohickies" does 
> have some semantics.  ie. Those circles, lines etc... do actually mean 
> something to the reader and are not just to make the document look 
> pretty (well, except for the smiley faces :-) ).  However, your proposed 
> implementation is nothing more than an object tag, which has no more 
> meaning the a <div> or <span> given appropriate classes with styles 
> applied.

Right.  An object tag is nothing without a "type" that can be mapped to 
the routine that is suppose to ACT on it.  But does it HAVE TO only be that?

Embed a bit of SVG with it?  A tiny piece of SVG canvas, absoulutely 
positioned?  That's using the object tag to access a special graphics 
engine if indeed one has the SVG-adorned Mozilla like I do.  But can a 
browser's graphics engine do it easier than firing up an SVG attachment? 
  Would it be useful to everyone to "power-up" the object tag to allow 
it to talk to "the new universal dynamic dohickie overlayer engine" that 
could be in our browsing future?  Like I have stated before, this 
hard-liner separation of content and presentation... leaves a few 
important document types in a state of no-can-do.  I am trying to "pay 
that bill" now.

> 
>   What you need is a completely seperate XML language, with an 
> appropriate namespace, that can be written within the XHTML document.  I 
> believe elements like these would be out of the scope of XHTML.
> For example, you may have elements like these:
> <x:spelling> (inicates incorrect spelling)
> <x:repeated> (indicates an unnecessarily repeated word)
> <x:comment>  (a comment added by the marker)
> <x:whatever> (???)
> 
>   You would then need an application that understands what these mean, 
> and/or an appropriate stylesheet to present them in a way a human can 
> percieve the meaning such as underlining, strike-through, highlighting, 
> etc...

Yep, we're talking complete document conversion out of its original 
format, and into a non-standardized format... just to "commentize" an 
HTML document written by another.  Doesn't it seem like we've missed a 
powerful use of markup with this?  And in the same act, didn't we 
box-out the whiteboarding-in-HTML community?  I'd say so.  And it all 
seems to be caused by our do-or-die separation of presentation and content.

> 
>   Also, you might like to take a look at InkML [1] (currently only a 
> working draft)
>   This would allow you to draw the lines, arrows, smiley faces, or 
> whatever on the screen and have them stored within an XHTML (or any 
> other XML) document.
> 
> CYA
> ...Lachy
> 
> [1] http://www.w3.org/2002/mmi/ink
> 
> 

Thanks "Lachy"!  Greats refs, great comments, great ideas! I appreciate 
the response!  Wingnut

Received on Thursday, 5 February 2004 10:44:04 UTC