CSS 3 Values and Units specifies vw, vh, and vm units.  These are respectively proportional to the width of the viewport, the height of the viewport, and the minimum of the two.  These would be extremely useful for authors -- quite a few very nasty hacks could be retired if we could use these (like <http://www.alistapart.com/articles/fauxcolumns/> and <http://matthewjamestaylor.com/blog/equal-height-columns-cross-browser-css-no-hacks>).
> for handling dynamic changes (to the size of the viewport).
Is "width: 100%" the same as "width: 1vw"?
Also, 100vw is the full width of the viewport, not 1vw.
I think I will need this to hide an element just outside of the viewport in the same place, without relying on a specific screen size.
The current practice for that is to offset by 999999px.
Thanks for the tip. However, this is for a slide-in CSS-animation where the speed will rely on how far off from the viewport the element is located. To control the speed, it's location would have to be just outside the viewport.
Also, according to Wikipedia (http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Cascading_Style_Sheets%29) this should be parity-IE9. I can't confirm it with my OS though.
> parity-IE9. I can't confirm it with my OS though.
Based upon my testing, WIE9 and WIE10PP1 both recognize |vw| and |vh| as valid units, but the units don't behave as described by the spec ; 100vw and 100vh end up being substantially wider and taller than the viewport.
I'm not aware that anyone is, although I'm not the most informed person on layout happenings these days.  I've thought about attempting to pick this up myself, as a way to learn more about the layout engine (in which I have lightly dabbled, mostly with painting-only changes, nothing affecting dimensions or positioning yet).  But I have other projects I've lightly committed myself to first (bug 483446 for one), so this would be back-burner of back-burner for me at best.
When you say "If I had the foggiest idea how I would contribute support myself": are you saying you have no idea because you don't know the code, because you don't know C++, because you don't program, because you've never worked with Mozilla code before, because you're solely an interested observer, or what?  If you know C++ but don't know Gecko, someone could help you get started and probably point you at the relevant code that would need touching.  I'm willing to do that, to the extent that I can (part of the appeal of doing this myself would be that it's a little bit of a stretch, so I'd probably point you at others assuming you met questions I couldn't answer at some point), if you're interested.
Of course, if you're not interested, that's fine too -- everyone has their thing.  But in case you are interested, but are just blocked on getting started and figuring out what to fix, we could help you with that -- just say the word.
Ah.  There are core Gecko hackers who picked up C++ while solely working on Gecko itself, but I'd guess they're not too common.  It's certainly doable, especially if you read a book on C++ as well (this is to an approximation what I did), but it's probably beyond Mozilla developers helping you with, unless you were to start that process yourself (and likely not on this exact bug).
And yeah, I think vw/vh/vm would be awesome too.  My "problem" is that I work primarily on the JS engine (and try to dabble heavily elsewhere), so layout hacking and other non-JS work is merely the occasional side project.
If C++ isn't your thing, I suppose there's always the possibility you could contract out the work to someone.  Although given Gecko's complexity, that's probably not too cost-effective for one random person, alas.  Beyond that I'm not sure there's much you personally could do, although I might just be missing something.
Actually those units are extremely handy. specially vh wit calc(), so you can vertically center an element on a page... I hope to see this soon!
Update on implementation: these units have been implemented in Chrome (not sure since which release) and Safari 6 Beta.
So. Yeah. This now works in Safari stable, Chromium stable and Internet Explorer 10.
And is certainly quite useful.
I hope you guys toss this in soon.  Would it really be that hard? I have no idea what you are doing in the backend, but I vaguely recall a discussion of some master unit (twip? something like that) surely a new unit is just a question of hooking it up. and you have other viewport dependent stuff already like percentage which is often viewport dependent.
http://m8y.org/tmp/testcase272.xhtml <- this btw is a test of something that's moderately annoying in Webkit and IE.
I'm not sure if it is a spec prob or a premature optimisation.
Percentage isn't viewport-dependent, it's containing block-dependent.  (...in general, at least.  I think.)  The constraint propagation system for percentages is pretty different from what would be needed for viewport-dependent units; I don't believe any such system exists in the layout engine right now.
I suspect this wouldn't be that difficult to hook up, tho (doing so efficiently *might* be another matter maybe), but I could be wrong about that.  And I've been too busy to spend my copious spare time noodling on a fix here (as a way to learn more about the layout code), alas.
The first question is whether to implement these in the style system (like 'em' units) or in layout (like '%').  I think it will be simpler to implement them in the style system.  I'm curious if others agree.
This approach could be optimized further (in particular, by maintaining a list of frames with such style contexts), but I think that's probably sufficient for a first pass.
Implementing in the style system would have the distinct benefit of them automatically working everywhere.  So it definitely seems preferable a priori; I agree that it's probably simpler to implement in addition to that.
WRT comment #16 by Jeff.
In my defense I know percentage is containing block - I just meant that the containing block can be the viewport, and my understanding was that you guys had generic layout units so you'd think this would just be one more syntax for something you have to calculate anyway.  From the other comments it does sound like there's two ways to do it.
Obviously the more generic one would be better.  Would want to use vw/vh absolutely everywhere.
I do hope you don't end up with that silly Webkit/IE bug where if the window is resize, the width/height of blocks changes, but not the text size, until I do a refresh or delete/add the rule.
Yes, but when it is the thing is actually a child of the viewport, not in an arbitrary place in the box tree.  So if the viewport changes size, it reflows its kids an everything works.  To do vh, when the viewport changes size you have to find all the subtrees that depend on that and reflow them.
FWIW, here's a bug I filed on that Webkit behaviour.
I really hope that's a bug in both Webkit/MSHTML and not some legit spec interpretation, but if it is legit, worth linking here I suppose.
And it's also why we've been saying this is actually not quite trivial to implement.
Hm.  Interesting.  I know the IE guys tend to skip -ms- 'cause no one ever bothers w/ IE prefixes, and the moz guys have been having the same problem as -o-pera w/ the goodies that Apple invented (amusingly Apple's transitions are completely broken in Safari forcing me to disable -webkit).
But... There's no equivalent for things like units.  You guys would presumably prefer not to ship a broken half-assed implementation.
Check with desktop IT for a different mail alias.
> Check with desktop IT for a different mail alias.
(1) It doesn't work with the test case found in the attachment. This _seems_ to be due to an unrelated bug and not the code in this patch, but I still haven't tracked down the root cause yet. The text in the red table cells seems to force those cells to be much larger than in other browsers.
(2) I haven't added test cases yet.
After talking with :dbaron I've resolved issue 1; the problem is related to table cells defaulting to 'vertical-align: baseline'. Some of the cells in the table have text, and some do not. The baseline of a cell without text is its top. Trying to align this with the baseline of cells that actually have text causes some ugly artifacts in the table rendering. This may work in Chrome / Safari because they don't implement 'vertical-align: baseline' correctly, though I have not verified this.
At any rate, the fix is to apply 'vertical-align: top' to all table cells. A modified test case is incoming.
Updated patch with accompanying reftests. All known issues are taken care of now, and the test cases all look good. Requesting review.
May be worth noting that your update of the testcase has changed its MIME type from application/xhtml+xml to text/html, which has changed the rendering mode from standards to quirks.
@Patrick: Whoops, thanks for catching that. Corrected.
Not that it really matters much, but it's usually easier to use text/html and force standards mode with <!DOCTYPE HTML>.
You're right it doesn't matter much, but I personally use application/xhtml+xml to catch my mistakes *in* the doc on the fly, and also, occasionally, for respone doc in XHR, where it is darn convenient, and certainly a lot better than regex for parsing, and tidier than an iframe.
oh well, yeah, doesn't matter and offtopic.
>    * between relative length units and pixel length units.
>    * the underlying CSS length would already have been scaled.
I think every caller of IsRelativeLengthUnit() actually wants false for these new units rather than true.  (I think they all care about whether the unit is relative to a font size, since they're either asking because of text-zoom (which should zoom all text, but not zoom it twice) or whether the behavior of the unit is inheritance-like for 'font-size'.)  The comment above the function could probably be improved.
Did you test that you get the correct behavior when zooming?  I think that's worth testing manually and adding a reftest for (see http://mxr.mozilla.org/mozilla-central/search?string=reftest-zoom ).
Otherwise I think this looks good, but I'd like to see the revisions for the first point.
Thanks for the feedback, David. I've made the changes you requested.
Specifically regarding the behavior while zooming, I did indeed check this and it works fine. (You CAN make the test case render in a ugly way if you zoom in really, really far, but that has more to do with the table layout code and is to be expected.) I've added a zoomed version of the reftest, which passes.
I don't see a Try link here, so I've pushed it myself. I'll land this if it's green.
Looks like this has build failures on Windows and mochitest failures on all platforms.
Thanks Ryan. Will have a look.
Ryan: was able to reproduce the mochitest failure; it boiled down to the order of two boolean checks in an if statement being reversed. I've modified the patch to fix that and it now passes the test. (I've commented things to make this issue more clear when people touch this code in the future.) I discussed this fix IRL with dbaron, and it's a tiny change, so I'm carrying over the r+.
dbaron and I have agreed that the relevant function could use some refactoring, but we'll address that in a separate bug.
I've got a try run going at https://tbpl.mozilla.org/?tree=Try&rev=415bcd4414f9. I'm not sure yet if the Windows failures were spurious or not; let's see if they reappear in this try run.
The problem appears to have been that Microsoft's compiler still, in 2012, does not fully support C99. This made compilation fail because of |fmin| and |fmax|. I switched over to C++'s |std::min| and |std::max|, which are probably a better choice anyway.
This should resolve the last remaining issue with this patch. I've got a try job going at https://tbpl.mozilla.org/?tree=Try&rev=91c40c4e1f0e to verify that. If all goes well with the try run I'll request checkin.
Try run for 91c40c4e1f0e is complete.
Excellent, try run looks good. Let's put this one to bed.
We are the first engine to implement this completely (relative to the CR)!
May be worth noting that the test case still fails when the viewport is made sufficiently small (based on testing in Nightly). I'm not sure if this is by design or not.
Nightly seems to enforce a minimum layout width for the table at small window sizes. That causes the table to no longer be placed correctly relative to the absolute-positioned elements.
Patrick, are you sure the viewport (as opposed to to the browser window) is being made small?
A number of Firefox extensions break the UI such that it won't shrink below some minimum width, so that you can make the window smaller than the UI and smaller than the web viewport.
> relative to the absolute-positioned elements.
I see what you mean, certainly. The test case could probably be better constructed so as not to fail at small window sizes. Viewport units do work correctly though. The problem is actually the text in the test. The presence of the text puts a lower bound on the size of the table cells, which causes the anomaly you're seeing. If you go through the DOM on the test page and delete every <p> node, you'll see that things behave as expected even with very small window sizes.
My bad; false alarm. Seth is right: the issue is a flawed test case that doesn't account for the minimum content width of table cells. I wrote a revised version, and Nightly passed that version without issue.