What's the use case?

(In reply to comment #0)
> these need to be accessible especially from css attr(), calc(), and also
> from javascript,

Why?

> these need to be accessible when the element is available (when loaded).

Styles might not have been applied yet when the element is first available...

> currently, unless you have specified an element's height and width, there is
> no way to get the element's width and height values. 

Is getComputedStyle() not sufficient?

(In reply to comment #1)
> What's the use case?

I am not that familiar with UML diagramming to know what to do with use cases, sorry.

> 
> (In reply to comment #0)
> > these need to be accessible especially from css attr(), calc(), and also
> > from javascript,
> 
> Why?
> 

when accessing <div id="abc">hello</div> for the first time, if there is no css specifically setting these properties, you can't get them from js as much as you might want to (such as if you needed to move things around dynamically, but relatively or absolutely or shackled, etc whatever). one could argue that you could do a fixed job quite well with css, but js adds more functionality, that would be much more functional IF these properties were simply not blank when you access them before setting them. meaning, they should always have a value specifying the current location and size of the element. but right now they do not. this makes them unusable in some situations (like when you wish to do work with layers and relative positioning to top of page or to another element which may be in another layer). currently, layer element flow and the model for handling these attributes/properties prevents this.

I have a web page where I attempted to do these kinds of things, but failed miserably and found no workarounds to find the current location and size of an element. if you have an alternative you can come up with which would solve this problem, I should like to see it. seeing the names, I figured these were best-fit and mnemonic and easy to figure out for everyone who would want to use it. 

I am unsure why these properties are blank before setting in the first place. isn't that a bug? has nobody questioned it for years? why is it this way?

> > these need to be accessible when the element is available (when loaded).
> 
> Styles might not have been applied yet when the element is first available...

I already knew that from testing. precisely why I wrote this bug report (I am sure I wrote it well enough and put in good details) - and why I was unable to make some projects with CSS layers (z-index) and positioning I wanted. I didn't think "it's just not available yet" was a good excuse for not making the current position and size of an element available, always, somehow, cross-platform. this seemed the best way to do it.
I can't show you an example of what I am talking about, because it's not implementable the way things are now. I am just saying instead of blank, it should have a nice default value, or, some kind of properties should be available which do supply these things.

current issues I can think of for browser implementation are:
- the return value: you could argue for A. an expectation for a certain kind of dynamic number but always with the same dimension such as left:243px; or left:246 but this might conflict with being able to return the value a web developer sets unless you make a whole new set of properties that do the needed functionality, or B. a default value which may be DIFFERENT from the value a web developer sets with js or CSS. for instance, the default value may be for example 12em or 20px (for convenience) if it has text in it or 480px if an img, but web developer may set a value like 
- for B. or just general handiness for calc() and js, making the css available in other dimensions, such as a css property value dimension conversion function in JS like 
el.convertDim(cssPropertyNameString, toDimensionString) 
and css function like 
convertDim(cssValueString,toDimensionString)
the browser has the dimensions already inside itself and knows internally what the conversions are I should guess in some internal variables in a class or something. this is just exposing this as functions. without these, it's going to be hard to manage differing dimensions (such as converting between em and px). in fact, it already is difficult without these.


> 
> > currently, unless you have specified an element's height and width, there is
> > no way to get the element's width and height values. 
> 
> Is getComputedStyle() not sufficient?

based on my cross-major-browser testing, getComputedStyle() doesn't work on all platforms (it's just not available on everything, .style is not available on all platforms, and .style[] I think it was is not available on all platforms, .setAttribute() clobbers a whole style, and ). need something that works for modifying styles cross-platform too, but I guess that would be a separate bug for me to report. :-) in fact, I have found NO code that is fully cross-browser. see the code in o'reilly's javascript cookbook page 265 to see what I mean - I did a lot of googling for this. I tried nearly everyone's "cross-browser" code in all major browsers and nothing worked cross-browser in safari, chrome, IE10, ff, o, but have not tested jquery yet. I didn't want to have to load 250k of heavy source to just change a style.

(In reply to comment #2)

> based on my cross-major-browser testing, getComputedStyle() doesn't work on
> all platforms

That problem is not solved by adding more redundant features to the spec. Nothing says that the new features will work any better on the same platforms. Please file bugs on the vendors that don't follow the spec for getComputedStyle.

getComputedStyle can't be used in CSS. I am looking for something that can be used with calc() and attr() also. I think this wbug was closed prematurely without reading the bug report (even the original post).
I tried to be as specific as possible, yet it was ignored for a JS-only solution.

So to be clear, in JS, getComputedStyle is sufficient, assuming it is properly implemented, but you want the same thing in CSS?

Your comments seem to revolve around JS uses, not CSS uses.

What is the use case for having this information from CSS? Can you give a concrete example of what you are trying to do?

currently, .getComputedStyle() is not available on all browsers. every browser has its own method for accessing style via js.

for js, I agree there should be a consolidated method across browsers for accessing style so our js code works cross-platform and is not multiplied in size.

what I was hoping for was something that could be accessed using style in js as well as via

if DOM necessitates a naming clash (?) between the attribute name and the style, then something will obviously have to be done (I know of nothing, but I wonder, please confirm if using width, height, top, left as both attributes and style would cause a problem). 

if .getComputedStyle() in js is a w3c recommendation as the common way to get/set style, this is of interest to me. I would therefore expect the style to be accessible through this. as for the attributes, they should be accessible through .getAtribute() and .setAttribute() in js as normal. I would also expect width, height, left, top to have a default value that is not blank and always be usable in calc() and attr().

if you think this kind of functionality for width, left, top, height is best served via other names for those style+attributes because current functionality of web pages could be broken by the fact that someone might expect the the existing width, left, top, height to have blank for a default, then I have provided some alternative names in this report, such as 
elementWidth:Int32, READ/WRITE
elementHeight:Int32, read/write
elementAbsTop:Int32, READ/WRITE
elementAbsLeft:Int32, read/write
OR
elWidth:Int32, READ/WRITE
elHeight:Int32, read/write
elAbsTop:Int32, READ/WRITE
elAbsLeft:Int32, read/write

where these values are in px.

You have not addressed this:

(In reply to comment #5)

> What is the use case for having this information from CSS? Can you give a
> concrete example of what you are trying to do?

define "use case"

congrats. you wore me out. I give up. I don't care anymore. do whatever you want.

:-(

A use case is ideally a user wanting to do something, but could be something or someone else wanting to do something.

http://en.wikipedia.org/wiki/Use_case

Example: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-May/019681.html (I don't expect an essay like this, just one paragraph explaining the use case/problem)

I had a project (a coupld of times in fact) where I tried to reposition elements based on another element's current position (usually relating to layers, because elements in a layer don't flow starting from top of document like I want it to). so to make a layers page work, I would have to reposition all the elements with js. I thought I had mentioned this 2 or 3 times. that's my use case. it's not possible to show you a working example because it's not possible right now, because elements don't currently give out their absolute position. and I am not sure you can do element shackling now unless you have already given your existing elements a size and position to start with.

sorry for earlier comment, it's been a hard month, nothing has been working right. everything I am using has a bug in it that prevents me from working.

let's see if I can drum up an example:

<div id="i1" style="z-index:1">hello<img src="abc.jpg" alt="abc">, Jake!</div><table>
<tr><td>a</td><td>b</td><td>c</td></tr>
<tr><td>a</td><td id="i3"><img src="def.png" alt="def"></td><td>c</td></tr>
<tr><td>a</td><td>b</td><td>c</td></tr>

<div id="i2" style="z-index:2" style="position:absolute;left:attr();">testing...<img src="abc.jpg" alt="abc"></div><!-- position this element over the <td id="3"><img src="def.png" alt="def"></td> -->


ooh - ouch. there is nothing currently in css to address a specific but different id is there?
I had hoped you could do something like #i3.attr(width).  how do you get the specific attr() of a specific element without getting all elements in css? I need to see some examples before I can come up with any working code formatting...
without this I can't proceed. but it sure would be a nice thing to have!
I just read that css attr() currently (?) can't be addressed outside its own element, if I am getting this right. that's unfortunate, some more functionality that made css attr() addressable from other elements would make it wonderfully functional.

*** Bug 22766 has been marked as a duplicate of this bug. ***

(In reply to comment #11)
> I had a project (a coupld of times in fact) where I tried to reposition
> elements based on another element's current position (usually relating to
> layers, because elements in a layer don't flow starting from top of document
> like I want it to). so to make a layers page work, I would have to
> reposition all the elements with js.

OK, so you want to position things relative to other elements.

> [...] and I am not sure you can do element shackling
> now unless you have already given your existing elements a size and position
> to start with.

What is element shackling?

> let's see if I can drum up an example:
> 
> <div id="i1" style="z-index:1">hello<img src="abc.jpg" alt="abc">,
> Jake!</div><table>
> <tr><td>a</td><td>b</td><td>c</td></tr>
> <tr><td>a</td><td id="i3"><img src="def.png" alt="def"></td><td>c</td></tr>
> <tr><td>a</td><td>b</td><td>c</td></tr>
> 
> <div id="i2" style="z-index:2"
> style="position:absolute;left:attr();">testing...<img src="abc.jpg"
> alt="abc"></div><!-- position this element over the <td id="3"><img
> src="def.png" alt="def"></td> -->

Thanks, that's helpful.


Does Flexbox or Grid address your use case?

http://dev.w3.org/csswg/css-flexbox/
http://dev.w3.org/csswg/css-grid/

flex talks about building layouts in 2 dimensions, I want to do it in 3 dimensions. that's what z-index is for isn't it?

there isn't much css support for box models & such in that 3rd dimension. it's kind of an orphan.

I tried http://jesusnjim.com/test/css-flex.html based on examples from the spec.
but it didn't do anything different than if I were to leave off the z-index.
to get that to work like the use case, I would somehow have to be able to make elements relative to another without having to specify positions. am I missing something?

maybe you can show me an example that can get me thinking in the right direction.
 the flex spec I am having a bit of a time trying to be able to apply. I don't 100% understand it yet based on what I have read the abtract is clear enough, but I would not know how to make code and make code do what I want it to with flex. grid says it's 2D layout for GUIs, once again I am stuck with no way to relatively position my element. tried position:relative and position:absolute but they are not doing it, but getting close with those, but still no way to address elements in css - I gotta put my thinking cap on some more.

storm here, I gotta shutdown

having a feature like what I was wanting could make better web apps for online photo and text/object editing and such I would think. usually people want to move objects forward and backward, bring to top and send to bottom, etc. better layers support would enable this sort of thing, provided people didn't have to absolute address everything on the page (that's hard). there's an additional use I just though of. the idea of being able to layer elements effectively could be very useful for web apps. especially since you can specify opacity and such things (now for masks... maybe I am getting into another bug report with masks... but it's a very useful idea, not sure if it's easily implementable though).




shackling is a term coined by the o'reilly css cookbook.
http://my.safaribooksonline.com/book/web-development/css/9781449377250/css-basics/using_shackling_positioning

My thinking was that it might be possible to use the 'order' property to achieve the result, but it wouldn't apply to the table cell so it doesn't work.

Do I understand correctly that you basically want to achieve this result but using only CSS? And that it is a requirement that #i2 is not a descendant of #i3 in the markup?

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2504

http://krijnhoetmer.nl/irc-logs/whatwg/20130903#l-437

# [19:24] <TabAtkins> zcorpan: Regarding that bug, depending on his markup Grid can handle that.  Otherwise, it's dependent on us improving the Position property, which fantasai and I intend to do next year.  
# [19:24] <zcorpan> TabAtkins: see the last comment for the markup  
# [19:26] <TabAtkins> zcorpan: Right, if he actually needs the <table>, he'll have to wait for Position.  If he's just wanting to put things in a grid, and can make #i2 a sibling of the other "cells", then Grid'll do.  
...
# [19:27] <zcorpan> TabAtkins: can grid create cells that overlap?  
...
# [19:28] <TabAtkins> And yes, grid items can overlap.  
# [19:28] <TabAtkins> (Named grid areas, created by the template, can't, but you can always manually specify the position and size of grid items.)

http://www.xanthir.com/blog/b48H0

#i3 { position:absolute; position-root:element(#i2); top:0; right:0; bottom:0; left:0 }

...seems to address the given use case.

that's the css part. kind of.
I never knew element() existed. all I knew of were calc() attr() and toggle().
the px values still need to be accessible always for use with css attr() and in js. I was thinking of something more like a js dot notation to access things so the context of the element() didn't get lost. that's what makes the js and java and c++(?) dot notation so useful. it *keeps context info*. without that, doign such complicated stuff is kinda hokey/hairbrained to read and to write/code. but wasn't . already in use by css for something else? as an engineer, I would like to see something like 
left:element(#i3).attr(left); 
or 
left:element(#i3).calc(attr(left) + 5em);
that would be most intuitive to me. and also as a js programmer. (those functions are looking awful good right now...) I am liking what I see so far. I think you have something there!

I can't think of any other uses for such dot notation at this time. but I wouldn't be surprised if there were a lot more where addressability and context is concerned.

ahh yes, classes. hmm. I hope someone has a workaround for this. or maybe dot-notation can still be used - I hope, parser tweaking. I still think dot notation could lead to some interesting things now that there's a context of a specific element() or collection of elements(). you could say things like "I want this group of elements to have their width attribute set to 50%-20px. all without having to use JS. but I still want to be able to do this with JS also, which means having some sort of ability to read pixel positions of elements and element sizes at all times. this way, web apps still have their functionality.  

maybe I should split this into 2 different bug reports? one for css and leave this one for js?


I put the the example on jsfiddle here: http://jsfiddle.net/jmichae3/3FcNS/14/
for folks to tinker with.

the jsfiddle versioning is automatic and is on the end of the URL as an integer version number. that way, the original doesn't get lost in the shuffle (and yes, you can go back to an older version). so if you think you have an answer, you can simply post the url here.

I will say that the table doesn't act anything like I want it to with image+surrounding text in ff.


I am putting this up on jsfiddle so folks can tinker with it and test and post changes and results.

the 2 images should be right on top of each other with left corners touching if it were to work the way I wanted it.

it doesn't do that now.

jsfiddle also seems to be an online HTML5+CSS+JS viewer+editor. that's why I am using it.

(In reply to comment #18)
> maybe I should split this into 2 different bug reports? one for css and
> leave this one for js?

Yes, but the other way around, please, since we have an understanding of the CSS use case in this bug.

(I think the JS use case is addressed by GetStyleUtils#usedStyle or HTMLElement#offsetTop, offsetParent, clientWidth, et al, but let's take that in a new bug.)

having a problem with the test code. I shrunk the images and was surprised by what they are doing, and then not so surprised when I looked at the position:absolute
http://jsfiddle.net/jmichae3/3FcNS/21/
it seems to be not doing what I want.

I see where some of the problem is coming from - currently, absolute means from top left corner of screen, and I think relative means relative to the current element?
what I am looking for is relative to some other element, regardless of the layer because the layer makes no difference, unless layers change, the browser is going to see px positioning the same regardless. that's probably a best summary, which is my use case.

to do this, I need:
- always-on js position and size data for every element
- always-on css position and size data for every element
for the use case, I need:
- a css relative addressing system from one element to another with ability to access attr() and therefore do calc().

[pasted from collision]

question about offsetTop, offsetParent, clientWidth: my understanding is that those are not available in all browsers, correct?
again, need for consistency is what I am asking for. are these available for each element? let me try it with a new fiddle.

http://jsfiddle.net/jmichae3/3FcNS/26/

those almost address it. don't have absolute top though. using a debugger and looking at e at 
http://JesusnJim.com/test/css-flex.html I have nothing to go on for an absolute top. this is a problem.
no property for this. please fix?

Please don't change the component when you comment. (If you get a collision, go back, reload, then post your comment.)

position-root does what you want but it is not implemented in browsers yet, so you can't test it. It's not even in a spec yet.

As for specced things not being implemented consistently (offsetTop et al), we can't do anything in the spec to solve that. The implementations need to be fixed, and this is the wrong forum for that (file bugs on the relevant browsers instead).