SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 37
  1. #1
    SitePoint Zealot yacka's Avatar
    Join Date
    Aug 2006
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    IE7 and the border-box model

    Is there any way of getting IE6/7 to use the border-box model, width inclusive of borders and padding, while in xhtml strict mode and without relying on javascript or iframes?

  2. #2
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,108
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Why would you want to do such a thing? just to confuse the maintainers ?

  3. #3
    SitePoint Zealot yacka's Avatar
    Join Date
    Aug 2006
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by markbrown4 View Post
    Why would you want to do such a thing? just to confuse the maintainers ?
    I suspect the majority of people find the border box model much easier to understand and implement than the w3c standard, but let's not go down that path.

  4. #4
    SitePoint Wizard bronze trophy Tailslide's Avatar
    Join Date
    Feb 2006
    Location
    Bedford, UK
    Posts
    1,687
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Force them into quirks mode.

    But as stated - this will make ensuring cross-browser uninimity very hard - there's no advantage to it that I could think of.
    Little Blue Plane Web Design
    Blood, Sweat & Rust - A Land Rover restoration project

  5. #5
    SitePoint Zealot yacka's Avatar
    Join Date
    Aug 2006
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tailslide View Post
    Force them into quirks mode.

    But as stated - this will make ensuring cross-browser uninimity very hard - there's no advantage to it that I could think of.
    I am migrating some code encapsulated within tools that emit markup to xhtml strict compliance. Forcing quirksmode defeats that purpose. I want xhtml strict for more consistent behaviour.

    Users can apply width to these tools, but expect border-box behaviour, not content-box. This is why I need to use the border-box model. I can cheat by taking the width of the control and applying it to a wrapper, but that is something I am hoping to avoid.

  6. #6
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Then slap the XML encoding above the DOCTYPE for IE6.

  7. #7
    SitePoint Zealot yacka's Avatar
    Join Date
    Aug 2006
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dan Schulz View Post
    Then slap the XML encoding above the DOCTYPE for IE6.
    Am I not understanding something? Won't that force IE into quirksmode?

  8. #8
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    You want to use the border-box model but you don't want to use quirksmode you are in a sticky situation.

    anyways is this what you are looking for?
    http://www.quirksmode.org/css/box.html
    but oh such a shame box-sizing doesn't working IE Win just Mac.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  9. #9
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Isn't that what you're saying you want? A standards-based (W3C) box model is only possible in standards mode. A border box model needs to use quirks mode.

  10. #10
    SitePoint Zealot yacka's Avatar
    Join Date
    Aug 2006
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for trying to help guys. After much research and experimentation the answer is obviously no, or at least not directly.

  11. #11
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by yacka View Post
    I suspect the majority of people find the border box model much easier to understand and implement than the w3c standard, but let's not go down that path.
    Explain images in the border-box context then because that's one big reason it was abandoned.

  12. #12
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I suspect the majority of people find the border box model much easier to understand and implement than the w3c standard
    Which is the SGML model which has been the publishing model for many, many years. It makes a lot of sense to people in the business.

  13. #13
    SitePoint Member
    Join Date
    Jun 2009
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by vgarcia View Post
    Explain images in the border-box context then because that's one big reason it was abandoned.
    Who abandoned it exactly? I think it went like this: The W3C invented a "standard" that made sense to them; browser developers thought, "ah, better support that" and most designers went along kicking and screaming because there wasn't any choice. But now there is, as CSS3 will support "border-box" - I wonder why, if "content-box" was some kind of godsend?

    This explains it far more elegantly than I can:
    w's.quirksmode.org/css/box.html

    Summary: Designers care about how big an area of "content" is, and don't tell me, as a designer, that if I take a big fat pen and draw a big fat box around some text on a page that the box isn't also "content". It's on my page and people see it, so what else is it? An annotation? A doodle? It's content. Sorry but the W3C got their conceptualisation completely and utterly wrong.

    Imagine a picture frame. Imagine one of those picture frames which have a bit of white paper behind the image, visible around the edges of it, then the frame (or border) surrounds that.

    The image is content, like text, no argument there. The white spacing around it is "padding". Like packaging in a box. The frame (sides of the box) is the border. The minimum space allowed around it is margin.

    But let's be clear - if I have a wall on which to hang pictures in frames, then as far as I'm concerned, as a designer, the wall is the canvas, and the pictures, padding and frames included, is my *content* for that canvas.

    Sure, you can draw a parallel with the word "contents" = "that which is inside a container" to say how the W3C model makes sense. But who are they designing their standards for - linguists, semanticists or visual designers? That is the bone of contention here. The W3C got caught up in semantics and lost the plot with this one. Much as I hate to say it, MS got it right as far as designers were concerned.

    Explain why a design-based model was abandoned for one in which content can *flow through its border*?! That doesn't follow the idea of "contents of a box" either. Not any box I'd like to use anyway. Use of padding messes with sub-box positioning.

    Even a box itself can flow outside of its container box! If I put my picture frame inside a "box", should I assume the box will contain it, or that bits of it may stick out? If I throw alphabet noodles in a box, should they flow outside the box?

    If I want to put my box inside another box, should I have to remember how much padding I used inside the first one to work out how wide it is? Does it help me when its padding magically projects through the outer box like some 80's 3D game? (Mercenary for the C64 comes to mind).

    I note that the box surrounding the Smilies to the right of this textarea is flowing outside its container box. Who exactly does that make sense to? If the answer is "oh they didn't code it properly" then my question is why do I need to code especially to make a box stay inside another box?

    There is a reason why all browsers now support "border-box", and I for one intend to use it wherever possible because it *makes design easier*, something the W3C had difficulty understanding.

    (this my first post after joining btw - it's a "rejoinder join")
    Last edited by waveform; Jun 23, 2009 at 10:50.

  14. #14
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by yacka View Post
    Is there any way of getting IE6/7 to use the border-box model, width inclusive of borders and padding, while in xhtml strict mode and without relying on javascript or iframes?
    IE6/7 do not support XHTML. Neither does IE8.

    Not that it matters in this case, because I believe you are talking about the CSS rendering mode (standards vs quirks), which is a completely different thing.
    Birnam wood is come to Dunsinane

  15. #15
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How odd that this debate gets re-opened so often.

    Sure, you can draw a parallel with the word "contents" = "that which is inside a container" to say how the W3C model makes sense. But who are they designing their standards for - linguists, semanticists or visual designers? That is the bone of contention here. The W3C got caught up in semantics and lost the plot with this one. Much as I hate to say it, MS got it right as far as designers were concerned.
    You might want to include structuralists in your who-are-the-standards-for question. The concept of wrapping the container around the content is patently obvious. Stuffing content into a given box, not so much. At least, that's true for designers who are comfortable with a dynamic, interactive medium such as the web, as opposed to a static, non-interactive medium such as print.

    That's not to say that the border-box model isn't handy at times. Firefox has long used the border-box model for tables. It isn't done to appease graphic designers, but to properly handle the special structural considerations required of the table container. There are other specific problems that might be more easily dealt with using a border-box model. The trouble is that the model has serious WAD logic bugs that the content model doesn't. The content model may sometimes require a little more thinking on the part of the coder, but is unlikely to break the well designed page.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  16. #16
    SitePoint Member
    Join Date
    Jun 2009
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    How odd that this debate gets re-opened so often.
    Not at all, it's because people find the new model objectionable. It'll calm down a lot once it's clear there's an easy way to switch.

    Quote Originally Posted by gary.turner View Post
    You might want to include structuralists in your who-are-the-standards-for question. The concept of wrapping the container around the content is patently obvious.
    .. to structuralists I assume.

    Quote Originally Posted by gary.turner View Post
    At least, that's true for designers who are comfortable with a dynamic, interactive medium such as the web, as opposed to a static, non-interactive medium such as print.
    Oh please, that smacks of elitism (though that was also a great C64 game). The web was a "dynamic, interactive medium" long the before the W3C came along.

    Even as a coder it doesn't make much sense: When I ask the DOM "what is the width of element xyz?" I want the width of the *element*. I'm not asking about the width of the element's text node - which should stay where I want it to stay, inside the bounds of my dynamic and interactive box. If the text overflows the box's border, does width return the *real actual* width of the text outside the box as rendered? Strangely, no. So, suddenly, there's no access to this so-called "content box" anyway. Content has a bit of a life of its own now.

    Besides this "bug", perhaps the argument of what constitutes "width" is academic. Measure it from wherever, as long as it's uniformly adopted and behaves itself. The real problems are all this business of overflowing a parent box's boundaries and the affect padding now has on positioning reference points. What a headache that is. Seriously, tell me this new box model means *less* javascript code for dhtml than the old one (assuming the old one had become standard)?

    Quote Originally Posted by gary.turner View Post
    The trouble is that the model has serious WAD logic bugs that the content model doesn't.
    WAD stands for "works as designed" so "WAD bug" is an oxymoron, isn't it? Maybe depends what you're calling a bug.. you mean the conflicts between browser implementations?

    A fairly recent forum by the W3C themselves discussed the limitations and problems of the current CSS version. It's always under review. Perhaps not the same bugs, just different ones.
    w's.w3.org/Talks/2008/0911-CSS-Amsterdam/

    Quote Originally Posted by gary.turner View Post
    The content model may sometimes require a little more thinking on the part of the coder, but is unlikely to break the well designed page.
    You could say that of the border-box model too. Except content didn't flow out of them! The box grew with the content. Did W3C provide an alternative like "overflow: growbox" or something in case we want different behaviour? Nup. Nice idea perhaps, sloppy implementation definitely.

    Perhaps if you explained why content overflow is a good idea and how to manage it, I'll understand your css position (pardon the pun) better.

    They just don't think about practicalities. Why else do we still not have vertical centering of content or a host of other dead-simple but invaluable layout features? Their focus seems remarkably misplaced. I mean, if you want to replace tables with CSS, then give us equivalent functionality at least.

    We need a body to regulate and standardise the language, of course. But it needs to be more practical and real-world, less academic and political. Even in terms of "structure" the thing is a mess IMO. We've gone from nested tables to nested divs - not a huge improvement there.

    They keep missing opportunities to really advance the medium. Why else are we seeing Silverlight and Flash competing now in the application space? Because HTML & CSS for apps is still a mess for coders and designers in any complex application. Look into any popular JS library - YUI, jQuery, Mootools, whatever (bless their socks) - you'll see many sizing and positioning complexities introduced by the content-box model which would be so much simpler in the border-box model. And it would still be dynamic and interactive.

  17. #17
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am not going to reply to all your gripes.
    Quote Originally Posted by waveform View Post
    Not at all, it's because people find the new model objectionable. It'll calm down a lot once it's clear there's an easy way to switch.
    It is not a new model. There was no width attribute until html3.2, and then only on select elements such as hr, but not div or p. CSS1 described the content box model from the get-go. If you learned the wrong way, what's your beef?

    ..[sic] to structuralists I assume.
    HTML is a markup language for describing the structure of a document, so I hope so.

    Oh please, that smacks of elitism (though that was also a great C64 game). The web was a "dynamic, interactive medium" long the before the W3C came along.
    That, elitism, is a specious argument. Until Netscape brought us a scripting language, the web was not what you'd call dynamic. It did offer forms. The W3 formalized IETF's rfc 1866 in 1995 as html2. HTML had only existed since 1990.

    Even as a coder it doesn't make much sense: When I ask the DOM "what is the width of element xyz?" I want the width of the *element*. I'm not asking about the width of the element's text node - which should stay where I want it to stay, inside the bounds of my dynamic and interactive box. If the text overflows the box's border, does width return the *real actual* width of the text outside the box as rendered? Strangely, no. So, suddenly, there's no access to this so-called "content box" anyway. Content has a bit of a life of its own now.
    I have no idea what you're going on about. Overflow is not a box model issue. I assume that you're melding IE's faulty border box model with IE's really, really stupid version of a new block formatting context known as hasLayout. hasLayout was the epitome of WAD bugs in action. Most of IE6 and below's rendering bugs, including its really screwed up mistreatment of overflow:visible are due to hasLayout. IE7 was patched to fix most of the hasLayout rendering bugs, and IE8 has killed the concept, and adopted a proper block formatting context.

    Besides this "bug", perhaps the argument of what constitutes "width" is academic. Measure it from wherever, as long as it's uniformly adopted and behaves itself. The real problems are all this business of overflowing a parent box's boundaries and the affect padding now has on positioning reference points. What a headache that is. Seriously, tell me this new box model means *less* javascript code for dhtml than the old one (assuming the old one had become standard)?
    One, overflow is not, I repeat, not a box model issue. Two, I have never dealt with a javascript/positioning issue where there would have been more than a trivial difference.

    WAD stands for "works as designed" so "WAD bug" is an oxymoron, isn't it? Maybe depends what you're calling a bug.. you mean the conflicts between browser implementations?
    No, I mean that the border model will/can break itself due to its design.

    <snip>
    You could say that of the border-box model too. Except content didn't flow out of them! The box grew with the content. Did W3C provide an alternative like "overflow: growbox" or something in case we want different behaviour? Nup. Nice idea perhaps, sloppy implementation definitely.
    The content didn't grow out of them because of that massive WAD bug, hasLayout; a different and orthogonal issue from the box model.

    Perhaps if you explained why content overflow is a good idea and how to manage it, I'll understand your css position (pardon the pun) better.
    Because it is better for the content to overflow than have the box expand, breaking the layout.

    They just don't think about practicalities. Why else do we still not have vertical centering of content or a host of other dead-simple but invaluable layout features?
    We do have it. Learn css.

    Their focus seems remarkably misplaced. I mean, if you want to replace tables with CSS, then give us equivalent functionality at least.
    Again, learn css and well structured, semantic html. CSS does not replace tables. Tables are structural elements, and css is a presentational declarative language.

    We need a body to regulate and standardise the language, of course. But it needs to be more practical and real-world, less academic and political.
    The standards are written primarily by the UA vendors, for the UA vendors, to describe how those UAs should render html, css, and javascript. It is up to developers to understand these standards. It doesn't get much more real world than that. If you don't understand it, perhaps you should study it a bit more.

    Even in terms of "structure" the thing is a mess IMO. We've gone from nested tables to nested divs - not a huge improvement there.
    Anyone who has done that, doesn't understand what css and semantic html are all about.

    They keep missing opportunities to really advance the medium. Why else are we seeing Silverlight and Flash competing now in the application space? Because HTML & CSS for apps is still a mess for coders and designers in any complex application.
    HTML, css, and js are for documents. Flash, Silverlight, audio and video players, pdf viewers, etc. are plugins that extend the document. I see no conflict.

    Look into any popular JS library - YUI, jQuery, Mootools, whatever (bless their socks) - you'll see many sizing and positioning complexities introduced by the content-box model which would be so much simpler in the border-box model. And it would still be dynamic and interactive.
    Look into any of those libraries, and you'll see potloads of cruft, all due to their attempts to be all things to all people. Write your own lean, mean, fighting machine library.

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  18. #18
    perfect = good enough peach's Avatar
    Join Date
    Jun 2004
    Location
    -Netherlands-
    Posts
    1,383
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    interesting discussion, I have to admit I've never though much about how the box models compare but I definitely like waveform's style of discussion, welcome to Sitepoint .

  19. #19
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    190
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Much like this discussion does, applying analogies that are true for non-interactive mediums to this argument was something I guess (as I wasn't in the web profession then) the W3C did when it developed the box model.

    However, the same logic that applies to pictures/paintings etc, cannot necessarily be transferred to the web; for example, artists who practice on static mediums don't have to deal with the relationship between percentage and fixed values when applied to the same box. This issue in particular, is something I have difficulty imagining the W3C didn't invisage, when it developed the spec.
    Last edited by jameshopkins; Jun 24, 2009 at 08:20.

  20. #20
    SitePoint Member
    Join Date
    Jun 2009
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jameshopkins View Post
    However, the same logic that applies to pictures/paintings etc, cannot necessarily be transferred to the web; for example, artists who practice on static mediums don't have to deal with the relationship between percentage and fixed values when applied to the same box.
    You're right, the analogy only goes so far, but I just wanted to illustrate the differing views about content and composition - coming from an artistic/design standpoint it doesn't matter what the medium is - it could be sand or a physically interactive installation - all we want is *control* (cue evil laughter) over it, and/or at its behaviours. We need good tools, because we care about the visual & interactive result. The web isn't just a series of documents. Everyone who puts up a page about their school or their dog is wanting to communicate something. That's what design is about.

    And I just noticed Gary's sig. Yes, *bad* designers end up creating a bad experience. We're clearly coming from different perspectives with different needs in mind.

    But I don't see why a language (which for a long time has been more than just a "markup" language) can't cater for different uses for the medium of the Web. Great document model and accessibility doesn't have to be exclusive of great presentation & design ability.

    Perhaps one day we'll have markup which directs different readers/apps in different ways through a document. Same idea as specifying tab-order through form fields. Perhaps tags which surround "semantic blocks", linked to each other by contextual pointers. Like anchors, but strung together, marking different routes through connected documents, not just point A to B links as we have now. But I digress...

  21. #21
    SitePoint Member
    Join Date
    Jun 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds interesting. Would really like to know what this border-box model is all about

  22. #22
    SitePoint Member
    Join Date
    May 2009
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I dont like IE , thats why I use Safari or Firefox...but IE??..just for test!!

  23. #23
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Because it is better for the content to overflow than have the box expand, breaking the layout.
    That's what real boxes do, anyway. Fill a moving box with too many books, and they spill out. The moving box doesn't grow. Except in IE6.

    They just don't think about practicalities. Why else do we still not have vertical centering of content or a host of other dead-simple but invaluable layout features? Their focus seems remarkably misplaced. I mean, if you want to replace tables with CSS, then give us equivalent functionality at least.
    I've always wondered why the ease of figuring out equal, auto margins on the sides couldn't be used for the equal, auto margins vertically. Math is math?
    Though the 100% height thing... people were making 100% high tabled pages, when apparently height wasn't ever supposed to be an attribute of tables. But again, we can make something 100% wide. While the default of collapsing to fit vertical amounts of content is fine, it would be nice to easily be able to override that, instead of the complicated multiple-container tricks you find on Paul's or Stu's pages.

    So I point to those things to tell programmers that no, clearly, the CSS specs were NOT written by designers, because designers would have insisted on being able to do some of these things with blocks.

    Though I suppose you could call display: table the equivalent functionality, but most of the time, if someone's supposed to look and act like a table, it's probably supposed to be a real table anyway. I don't like adding display: table on stuff JUST to be able to vertically center my freakin' text (so, I don't).

    I am glad the border-box model (what we see in quirks modes in IE) didn't catch on. The idea that boxes' outer skins and borders expand out when padding is added makes total sense, esp for me, coming from a medical background : ) What happens when you add padding to a human? What happens to their outer edge? What happens to the amount of non-padding that's inside of them? Content-box model seems to follow the human box model : )

  24. #24
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    I've always wondered why the ease of figuring out equal, auto margins on the sides couldn't be used for the equal, auto margins vertically. Math is math?
    Because the height usually depends on the content. That means you'd have to lay out the content before you could place the container, which would make incremental rendering impossible.

    It's different with width, since it depends on the width of the containing block, which is known beforehand. There are cases where it might depend on the content as well, but the CSS spec says these are 'undefined'.

    You could allow automatic vertical margins, but you'd have to require a fixed height on the parent container and that would be too much of a restriction to make it useful. Or you could forgo incremental rendering, but who'd want that?
    Birnam wood is come to Dunsinane

  25. #25
    SitePoint Member
    Join Date
    Jun 2009
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    Because the height usually depends on the content. That means you'd have to lay out the content before you could place the container, which would make incremental rendering impossible.
    Tables do it perfectly well. I don't see the difference between that and not knowing where to, say, word-break a page of text based on a fixed-width box. There's no incremental rendering there. As content is added to the DOM, the objects of the page re-adjust themselves. Dynamically add some content and the page adjusts. Where is the problem?

    Quote Originally Posted by AutisticCuckoo View Post
    It's different with width, since it depends on the width of the containing block, which is known beforehand.
    Not really - the width of a table, for example again, often isn't know until the entire set of rows is loaded. Browsers manage it perfectly fine.

    Quote Originally Posted by AutisticCuckoo View Post
    There are cases where it might depend on the content as well, but the CSS spec says these are 'undefined'.
    Which is odd, since almost every object on a page has undefined aspects - it's position depends on the position of everything around it. I'd say width is one of the *only* attributes which is most often fixed beforehand. But take inline instead of block elements, then that's not true either.

    Quote Originally Posted by AutisticCuckoo View Post
    You could allow automatic vertical margins, but you'd have to require a fixed height on the parent container and that would be too much of a restriction to make it useful. Or you could forgo incremental rendering, but who'd want that?
    Again, tables handle this routinely. There really is no problem with any of these things you mention IMO. Every time you resize your browser window (which is what HTML is designed to support after all) the page continually readjusts itself. What makes vertical centring any different?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •