Re: Publishing the flexible box model

I believe the thrust of the debate in this thread is whether "flex"  
should be its own set of properties (and display value) or should it  
be a unit of measure.

I don't think Andrew meant that authors would not be able to use  
floats or tables for layout if we really wanted to. His point seemed  
to be that flex could add a new way to do certain types of layout that  
previously might have been done with floats or tables,  and I find no  
fault with that idea. I don't think the concept of "flex" as a  
measurement unit should be attacked just because authors may choose to  
continue to use floats in ways they found advantageous over flex.

There are still many authors who find tables to be the easiest way to  
achieve their layout needs, and who find it awkward and difficult  
trying to do the same thing with floats and negative margin, or  
absolute positioning. You don't have to agree with those authors'  
choices. If flex, in whatever form, can provide a new, simpler way to  
achieve the same layout ends then shouldn't we, as authors, welcome  
that? Can we not attack Andrew for suggesting that flex can help with  
layout problems that many people use tables or floats to do now? Maybe  
he overstated the scope of how much floats would be rendered  
irrelevant, but his basic point of its usefulness is sound. I think we  
all agree without argument that floats will not be going away any time  
soon, and that if there are ambiguities to "block formating context"  
that they should be resolved. Let's try to keep this thread focused on  
how flex should be defined and implemented.



On Jun 7, 2008, at 7:48 AM, Alan Gresley wrote:

>
> Andrew Fedoniouk wrote:
>
>> Opportunities that flexes provide outweigh possible issues  
>> significantly. I wish flexes were in CSS from the very beginning.
>> That would simplify spec significantly (in particular all about  
>> floats).
>
>
> There is nothing wrong with the float model. It's the 'block  
> formating context' model that need redefining since we only have  
> trouble with floats mostly when they are followed in the source by  
> an elements that establish a new 'block formating context' such a  
> position:absolute, position:fixed, overflow:auto or overflow:hidden.
>
>
>> And yet it will make obsolete that holy-wars about tables
>> used for layout purposes. Flexes give even more than you can do  
>> with html tables.
>> As I said in 3 years that we are using flexes we didn't met  
>> anything that could not be resolved in boundaries of
>> CSS constraints/ideology.

This is an important point that Andrew made. In his 3-year experience  
with flexes, he dealt with some challenges in how they interact with  
other rules, etc., but those challenges were all met and implemented  
in a way that did not go outside of what CSS allows and encourages.

> The only constraints of CSS2.1 is the self imposed constraints of  
> undefined behavior.

Of course that is not true. CSS defines many constraints. It must. For  
instance, when I specify a color, I am constrained to use the color- 
specification models that CSS allows. I cannot just say  
{ color:watermelon }, because I must operate within the constraints of  
how CSS defines color values.

> All behaviors must be spelled out explicitly as A, B and C. An  
> implementation should not have a choice to have a guess of a desired  
> behavior.
>
> If such a situation continues to happen then effectively you are  
> allowing a large share of CSS properties and values to be useless  
> for authors to use. It pointless adding (CSS3) to something (CSS2.1)  
> that will never be resolved or work.
>
>
>>> So, we need a spec proposal that carefully considers all the  
>>> possible interactions between flex-units and CSS layout where flex- 
>>> units can be used, and describes how issues (such as the ones  
>>> already raised) are resolved.
>>>
>> I agree. The problem is that I am personally is not that good in  
>> writing specs. If someone will help me than we can come up with  
>> something.[...]
>
>
> This raises an important question. If you are personally not good at  
> writing specs, can you be good at understanding the currents specs?
>
> This can also apply generally, can a good spec be written by those  
> who are not experience enough in using CSS?

That really sounds like a personal attack against Andrew, and is  
uncalled for. Lets limit our arguments to be for or against the  
proposals, and not against the person.

>
>
>
>> -- 
>> Andrew Fedoniouk.
>> http://terrainformatica.com
>
>
> Alan
>

Received on Saturday, 7 June 2008 17:04:28 UTC