Re: Headline: Styles pondering desertion to Content!

Jewett, Jim J wrote:

> 	[I want] a method to dynamically draw arrows, borders, 
> 	and text THAT CAN Z-ROTATE... onto an xml document. 
> 
> Nothing dynamic will happen strictly in xhtml.

ookay.  Not sure what that means... but I do understand the need for 
"core regimentation" amongst the xhtml modules, so I think I see what 
you're saying.  This might be considered "fancy stuff".

> 
> There are other xml modules that deal with behavior, but I suspect
> what you really want is even simpler.  Try one of
> 
> (1)	simple markup plus CSS - should do what I *think* you really want

I don't think we're allowed to spin a box model around the z-axis yet, 
afaik.  Am I wrong?  That would be pretty embarassing for me.  Not like 
I haven't already embarassed myself with these posts. :)

> (2)	SVG - markup to do what you describe, but not yet well-supported

Yep, complete document conversion.  I mentioned that earlier as a 
less-than-likeable method.  But yes, correct.

> (3)	scripting, like javascript or even java - total control, already 
> 	well-supported, but not simple

I don't think you'll be spinning a box model around its z-axis from java 
or any other dom-manipulatin' byte-whackin' environment.  I've looked in...

  http://www.w3.org/TR/2002/WD-css3-box-20021024/#property

...and see no mention of z-rotation, with or without "characters stay 
upright as box model rotates" extra choice. :)

> 
>>I want tools to "commentize" a previously marked-up document. 
> 
> 
> If you're willing to modify the document, then adding a simple markup
> tag (it could even be span or div with a class attribute) will indicate 
> where the comments go, and CSS will let you make it look right.  The
> "right" CSS sheet may not be written yet, but you can do it once and 
> distribute it.
> 

No z-axis stuff.  Generally, its hard to make a big fat arrow with 
adjustable arrowheads and shafts... in a standard box model... even if 
one COULD rotate box models to aim different ways.  There's not much 
versatility in arrow types, when using a box model to make one. 
Besides, you really CAN'T rotate a box model.  You can likely only 
rotate its contents in such a way as to FAKE z-rotate it.  Otherwise, 
relative content borders and reflowings would be a nightmare for the 
layout folk.  So, we come back to the object tag, and using a BUILT INTO 
THE BROWSER plugin... so is it a plugin anymore?  It is my belief that 
the canvas on most browsers already has the power to do SVG-like 
things... like overlaying a chunk of pixels.  SO, maybe one might think 
"Stay out of the FLOW of the webpage and the markup language... and use 
plugin-like tech".  But, I don't want something creating an alien-type 
of canvas to kludge-onto a layer "over" the html.  I want the same 
rendering engine that painted the HTML canvas... to do the symbol.  A 
builtin plugin, accessed via the object tag.  Some, have taken the 
daring step of calling these things "browser features". :)  Let's be 
careful not to make the mistake of thinking that the browser's abilities 
is NOT any of the W3C's concern.  It certainly is.  It tells the W3C 
what IS possible, and therefore what to honor within the spec.  This is 
one way that new web tech is introduced.  Folks come up with a browser 
feature, and then the W3C allows access to it via the specs.
Or, that's totally NOT how it works. :)

> 
>>I want, at minimum, z-axis-aimable, styleable, dynamic arrows,
>>and secondly, z-axis-aimable, styleable, text and borders.  
> 
> 
> You can get that with CSS, but it may not be as styleable or dynamic
> as you like.  
> 
> If not, you can either use SVG, or create images (a one-time process) 
> and load them with the CSS.  You may also be able to get most of the 
> standard marks from either unicode or a symbol font, depending on 
> what fonts your users have installed.  If you can do this, it is better
> than using a picture.
> 

Agree.  I got pooped-out just reading about those processes!  When I 
wake from my nap, will there be an ARROW element in the xhtml spec... 
and a z-rotation parameter in css3?  :)

> 
>>In a way, I suppose, I am just asking W3c permission to use 
>>their OBJECT tag as an access point TO the dynamic dohickie 
>>rendering engine 
> 
> 
> You have permission.  Your plugin probably won't be as well-supported
> as quicktime just yet, but you can certainly distribute it to your own
> users.  I think it isn't the easiest way, but you can do it.

I'm hoping for the "internal plugin"... where everyone decides this is a 
good enough idea... to implement it into all browsers by tomorrow 
morning.... and then I'll get started writing re-useable dohickie 
formulas for the new internal object-tag parser and dohickie-maker. :o

> 
>>That, is likely true.  I guess maybe I was HOPING that xHTML's 
>>extensibility would be able to do future needs.  
> 
> 
> Part of the extensibility is modularization.  It is possible to support
> XHTML+SVG in the same document, but it is also legal to write
> a browser that does not know SVG, and just hand SVG off to a plugin.
>  
> 
>>"Leave OBJECT tag alone.  Extend xhtml with a module to fit 
>>my needs, then go begging to browser and/or plugin makers to 
>>build a renderer for it."?
> 
> 
> Most browsers will already render your new module; they just 
> won't have built-in defaults for the styles, so you'll have to include 
> a stylesheet if you want it to look right.
> 

And there comes our lack of z-rotation yet again.  Nope, this can't be 
done with standard CSS.  The browsers and spec are not ready to 
z-rotate. We COULD open a "layer" in the browsers... maybe call it the 
relative-absolute layer.  This layer's elements, all made from object 
tags... "floats" over the regular HTML canvas, so it is absolutely 
positioned in that respect... but each of its elements is "attached" or 
"bound" to an HTML-layer element... or possibly actually absolutely 
positioned ON the underlying HTML element, aiming at a particular WORD 
or CHARACTER of a text element.  So, the MOB or SPRITE layer has all 
object-tag-made elements, and the entire layer is absolutely positioned 
though likely in upper left of its container element... and each of its 
elements is (pecision-)bound to an HTML-layer element beneath, and 
travels with it during resizings, scalings, and reflows.  Is THAT too 
much to ask for?  :))

Best regards!  Thanks for the excellent reply, JJ!  Wingnut

Received on Friday, 6 February 2004 12:39:25 UTC