No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser. Try it.
brave1979
layout for your web page, nested as deep as you like, adjusting to
width and height of a browser window. You just describe it in
javascript object and that's all. No need to know CSS hacks, no need
to clutter your html with tables.
Rik Wasmus
> Please check out my javascript library
Using javascript for layout.... terrible idea. And hardly crossbrowser.
--
Rik Wasmus
Harlan Messinger
You are using tables, you're just using Javascript to create them:
<table style="border-collapse: collapse; width: 100%; height:
100%;"><tbody><tr><td style="padding: 0pt 0pt 10px; vertical-align:
bottom; width: 100%; height: 100%; text-align: center;"><table
style="border-collapse: collapse; width: 300px; height: 100%;
margin-left: auto; margin-right: auto;"><tbody><tr><td style="padding:
0pt; vertical-align: top; width: 100%; height: 10%;"><table class="blue"
style="border-collapse: collapse; width: 100%; height:
100%;"><tbody><tr><td style="padding: 0pt; vertical-align: top; width:
100%; height: 100%;"><div
id="header">#header</div></td></tr></tbody></table></td></tr><tr><td
style="padding: 0pt; vertical-align: top; width: 100%; height:
100%;"><table style="border-collapse: collapse; width: 100%; height:
100%;"><tbody><tr><td style="padding: 0pt; vertical-align: top; width:
20%; height: 100%;"><div style="background: transparent none repeat
scroll 0%; overflow: hidden; width: 20%; line-height: 1px; height: 1px;
margin-top: -1px; -moz-background-clip: -moz-initial;
-moz-background-origin: -moz-initial; -moz-background-inline-policy:
-moz-initial;"></div><table class="red" style="border-collapse:
collapse; width: 100%; height: 100%;"><tbody><tr><td style="padding:
0pt; vertical-align: top; width: 100%; height: 100%;"><div
id="menu">#menu</div></td></tr></tbody></table></td><td style="padding:
0pt; vertical-align: top; width: 100%; height: 100%;"><table
class="yellow" style="border-collapse: collapse; width: 100%; height:
100%;"><tbody><tr><td style="padding: 0pt; vertical-align: top; width:
100%; height: 100%;"><div
id="content">#content</div></td></tr></tbody></table></td></tr></tbody></table></td></tr><tr><td
style="padding: 0pt; vertical-align: top; width: 100%; height:
15px;"><table class="gray" style="border-collapse: collapse; width:
100%; height: 15px;"><tbody><tr><td style="padding: 0pt; vertical-align:
top; width: 100%; height: 100%;"><div
id="footer">#footer</div></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table>
brave1979
> On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <brave1...@o2.pl> wrote:
> > Please check out my javascript library
>
> Using javascript for layout.... terrible idea. And hardly crossbrowser.
Safari and Konqueror then ?
More important is that with my lib you can achieve being crossbrowser
almost effortless and your html files and even css files stay clean
hack-free, table-free.
brave1979
<hmessinger.removet...@comcast.net> wrote:
> brave1979 wrote:
> > Please check out my javascript library that allows you to create any
> > layout for your web page, nested as deep as you like, adjusting to
> > width and height of a browser window. You just describe it in
> > javascript object and that's all. No need to know CSS hacks, no need
> > to clutter your html with tables.
>
> >http://www.bravelayout.scarabeo.biz/Quickstart
>
> You are using tables, you're just using Javascript to create them:
I'm not using tables in my html, isn't that enough? I keep my html
clean and I can order content any way I want. It's human friendly and
robot friendly.
Beauregard T. Shagnasty
> "Rik Wasmus" wrote:
>> brave1979 <brave1...@o2.pl> wrote:
>>> Please check out my javascript library
>>
>> Using javascript for layout.... terrible idea. And hardly
>> crossbrowser.
>
> Really? How do you call a thing that works in IE, Firefox, Opera,
> Safari and Konqueror then ?
Disable JavaScript, like ~10% of your visitors, and look at your page
again. Not everyone has it enabled, or available - stripped by a
corporate firewall, for example - so your method has similar results to
turning off your web server for a month every year.
I would have expected you to have at least a link to a demonstration
page at the link you mentioned.
You say, "You just need to write something like this!"
but it is a *lot* easier just to write regular old HTML than your
script, with its errors. A *lot* easier.
You also say, "HTML is horrible. It's not suitable for anything more
visually complicated than a short school essay. " You must be new to
this game. HTML and CSS can do much more than you seem to realize.
And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
a bit less than your convoluted approach.
> More important is that with my lib you can achieve being crossbrowser
> almost effortless and your html files and even css files stay clean
> hack-free, table-free.
My HTML and CSS files are already "hack-free". You will have to explain
in some detail why you think differently.
Your other post:
> I'm not using tables in my html, isn't that enough?
No. It is still using "tables for layout", a process we keep stressing
should be avoided.
> I keep my html clean and I can order content any way I want. It's
> human friendly and robot friendly.
Your sample code is using a Transitional doctype. What are you
transitioning from? That's for legacy pages; use Strict instead. You
assign font size in pixels; that too has gone the way of the dodo bird.
Use percentages instead. See:
http://k75s.home.att.net/fontsize.html
Clean code? <lol> See:
<http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.bravelayout.scarabeo.biz%2FQuickstart>
This page is not Valid XHTML 1.0 Transitional!
Result: Failed validation, 119 Errors
Human friendly, perhaps, to the other 90%.
Robots (search engines?) don't read and execute JavaScript.
You need to rethink what you are doing.
--
-bts
-Friends don't let friends drive Vista
Harlan Messinger
> On Dec 30, 7:02 pm, Harlan Messinger
> <hmessinger.removet...@comcast.net> wrote:
>> brave1979 wrote:
>>> Please check out my javascript library that allows you to create any
>>> layout for your web page, nested as deep as you like, adjusting to
>>> width and height of a browser window. You just describe it in
>>> javascript object and that's all. No need to know CSS hacks, no need
>>> to clutter your html with tables.
>>> http://www.bravelayout.scarabeo.biz/Quickstart
>> You are using tables, you're just using Javascript to create them:
>
> I'm not using tables in my html, isn't that enough?
Enough for what? Evidently you're misunderstanding the intent of the
guidance to avoid using tables for layout.
> I keep my html
> clean
By switching to Javascript to lay out your page, which is worse?
> and I can order content any way I want. It's human friendly and
> robot friendly.
Not if the human isn't using Javascript.
Rik Wasmus
> On Dec 30, 5:49 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
>> On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <brave1...@o2.pl> wrote:
>> > Please check out my javascript library
>>
>> Using javascript for layout.... terrible idea. And hardly crossbrowser.
> Really? How do you call a thing that works in IE, Firefox, Opera,
> Safari and Konqueror then ?
A thing that works in certain browsers under certain conditions provided
they have certain settings? It would not work in my Opera, as I myself
have javascript disabled for most sites, save a few exceptions.
> More important is that with my lib you can achieve being crossbrowser
> almost effortless and your html files and even css files stay clean
> hack-free, table-free.
I have no real trouble getting nice layouts in all browsers without any
hacks in CSS or javascript (oh yes, I do use it to provide extended
usability/features for those who have it enabled, those who have it
disabled don't miss anything). No, they are not pixel for pixel alike,
then again, I don't design them to need that.
Really knowing CSS & HTML, and the way to publish on the www is quite
enough.
--
Rik Wasmus
brave1979
> >> crossbrowser.
>
> > Really? How do you call a thing that works in IE, Firefox, Opera,
> > Safari and Konqueror then ?
>
> Disable JavaScript, like ~10% of your visitors, and look at your page
> again. Not everyone has it enabled, or available - stripped by a
> corporate firewall, for example - so your method has similar results to
> turning off your web server for a month every year.
Can you show me some hard data backing up your claim that 10% of
visitors do not have Javascript enabled? Even for such people all
content is still readable and if you really care you can provide them
with something easy on eyes.
> I would have expected you to have at least a link to a demonstration
> page at the link you mentioned.
> You say, "You just need to write something like this!"
> but it is a *lot* easier just to write regular old HTML than your
> script, with its errors. A *lot* easier.
This is very simple example. True strength of my approach is ability
to nest layouts, and ability to change them as requirements change.
> You also say, "HTML is horrible. It's not suitable for anything more
> visually complicated than a short school essay. " You must be new to
> this game. HTML and CSS can do much more than you seem to realize.
Actually I'm pretty old to this game and tired from countless
occasions when I tried to get something look good and do what I want
in different browsers. I joined this game before such thing as
tableless layout was even possible.
> And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
> a bit less than your convoluted approach.
It's not weight in bytes that matters. It's weight in hours of
programmer time stolen that matters.
And for more complex layout there should be no significant difference
in size between my approach and css hacking.
> > More important is that with my lib you can achieve being crossbrowser
> > almost effortless and your html files and even css files stay clean
> > hack-free, table-free.
>
> My HTML and CSS files are already "hack-free". You will have to explain
> in some detail why you think differently.
Then you are lucky guy, browsing internet tells me not everybody is as
lucky as you. Explain? underscore hack, asterisk hack, .clearfix ...
I'm sure you know what I'm talking about.
> Your other post:
>
> > I'm not using tables in my html, isn't that enough?
>
> No. It is still using "tables for layout", a process we keep stressing
> should be avoided.
Could you remind me real quick why this should be avoided? Semantic
html, uncluttered html, crossbrowser comes to my mind. My approach has
this qualities. Or maybe tables has been declared as devils spawn by
vatican and should be as such?
> > I keep my html clean and I can order content any way I want. It's
> > human friendly and robot friendly.
>
> Your sample code is using a Transitional doctype. What are you
> transitioning from? That's for legacy pages; use Strict instead.
Maybe you can put browser in quirks mode with strict doctype
declaraion, I haven't tried that yet. It's work in progress.
> You
> assign font size in pixels; that too has gone the way of the dodo bird.
> Use percentages instead. See:http://k75s.home.att.net/fontsize.html
This has nothing to do with my lib so you can specify fonts any way
you like while using it. I like pixels for this simple example.
> Clean code? <lol> See:
> <http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.bravelay...>
>
> This page is not Valid XHTML 1.0 Transitional!
> Result: Failed validation, 119 Errors
Why do you try to validate it as XHTML if it's indicated as HTML
Transitional in DOCTYPE?
It's valid HTML 4.01 Transitional (after some minor fixes).
> Human friendly, perhaps, to the other 90%.
> Robots (search engines?) don't read and execute JavaScript.
And that's good because visual layout of a page is none of their
interest.
> You need to rethink what you are doing.
I am constantly rethinking almost everything I am doing.
brave1979
<hmessinger.removet...@comcast.net> wrote:
> brave1979 wrote:
> > On Dec 30, 7:02 pm, Harlan Messinger
> > <hmessinger.removet...@comcast.net> wrote:
> >> brave1979 wrote:
> >>> Please check out my javascript library that allows you to create any
> >>> layout for your web page, nested as deep as you like, adjusting to
> >>> width and height of a browser window. You just describe it in
> >>> javascript object and that's all. No need to know CSS hacks, no need
> >>> to clutter your html with tables.
> >>>http://www.bravelayout.scarabeo.biz/Quickstart
> >> You are using tables, you're just using Javascript to create them:
>
> > I'm not using tables in my html, isn't that enough?
>
> Enough for what? Evidently you're misunderstanding the intent of the
> guidance to avoid using tables for layout.
content, clean html, separating defining visual aspects from defining
content. My lib does all that, and it's easy to use.
> > I keep my html
> > clean
>
> By switching to Javascript to lay out your page, which is worse?
How is it worse?
> > and I can order content any way I want. It's human friendly and
> > robot friendly.
>
> Not if the human isn't using Javascript.
Just as most of web 2.0 and all that nice ajax ;-)
brave1979
> On Sun, 30 Dec 2007 23:46:20 +0100, brave1979 <brave1...@o2.pl> wrote:
> > On Dec 30, 5:49 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
> >> On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <brave1...@o2.pl> wrote:
> >> > Please check out my javascript library
>
> >> Using javascript for layout.... terrible idea. And hardly crossbrowser.
> > Really? How do you call a thing that works in IE, Firefox, Opera,
> > Safari and Konqueror then ?
>
> A thing that works in certain browsers under certain conditions provided
> they have certain settings? It would not work in my Opera, as I myself
> have javascript disabled for most sites, save a few exceptions.
Is that really valid argument against my lib that you have found
proper option in your browser and disabled it?
Is a fact that I disabled CSS in my browser a valid argument against
tableless layouts? Should you use tables and 1px gifs because of that
fact?
> > More important is that with my lib you can achieve being crossbrowser
> > almost effortless and your html files and even css files stay clean
> > hack-free, table-free.
>
> I have no real trouble getting nice layouts in all browsers without any
> hacks in CSS or javascript (oh yes, I do use it to provide extended
> usability/features for those who have it enabled, those who have it
> disabled don't miss anything). No, they are not pixel for pixel alike,
> then again, I don't design them to need that.
You design them. That's the reason why they are easy for you to code.
And you still can get them right in all browsers.
Person who knows photoshop and person who knows html are not always
the same person. You can remove from your design things that you don't
know how to do in html. But when coders get prepared, discussed and
accepted layout in psd they can only do their best.
> Really knowing CSS & HTML, and the way to publish on the www is quite
> enough.
Internet is living proof for that but assembler is also quite enough
to implement anything at any machine, it's just not the most efficient
way.
Beauregard T. Shagnasty
>>>> Using javascript for layout.... terrible idea. And hardly
>>>> crossbrowser.
>>
>>> Really? How do you call a thing that works in IE, Firefox, Opera,
>>> Safari and Konqueror then ?
>>
>> Disable JavaScript, like ~10% of your visitors, and look at your
>> page again. Not everyone has it enabled, or available - stripped by
>> a corporate firewall, for example - so your method has similar
>> results to turning off your web server for a month every year.
>
> Can you show me some hard data backing up your claim that 10% of
> visitors do not have Javascript enabled? Even for such people all
> content is still readable and if you really care you can provide them
> with something easy on eyes.
http://www.w3schools.com/browsers/browsers_stats.asp
varies between 6-12% over the last few years. Note I said *~* 10%. That
means circa 10%. There are other stat sites which you can probably find
via Google.
>> I would have expected you to have at least a link to a demonstration
>> page at the link you mentioned.
..and do you have one of these?
>> You say, "You just need to write something like this!"
>> but it is a *lot* easier just to write regular old HTML than your
>> script, with its errors. A *lot* easier.
>
> This is very simple example. True strength of my approach is ability
> to nest layouts, and ability to change them as requirements change.
What kind of "nesting" would I want to do? Nest tables?
>> You also say, "HTML is horrible. It's not suitable for anything more
>> visually complicated than a short school essay. " You must be new to
>> this game. HTML and CSS can do much more than you seem to realize.
>
> Actually I'm pretty old to this game and tired from countless
> occasions when I tried to get something look good and do what I want
> in different browsers. I joined this game before such thing as
> tableless layout was even possible.
Me too, but that's not an excuse.
>> And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
>> a bit less than your convoluted approach.
>
> It's not weight in bytes that matters.
Of *course* it matters! Ever use dial-up?
> It's weight in hours of programmer time stolen that matters.
That applies to one person, not thousands of visitors' time. You would
rather churn out pages quickly, then penalize all of the visitors with
bloated pages?
> And for more complex layout there should be no significant difference
> in size between my approach and css hacking.
CSS hacking? Hacking? You think we need to 'hack'? <g>
>>> More important is that with my lib you can achieve being
>>> crossbrowser almost effortless and your html files and even css
>>> files stay clean hack-free, table-free.
>>
>> My HTML and CSS files are already "hack-free". You will have to
>> explain in some detail why you think differently.
>
> Then you are lucky guy, browsing internet tells me not everybody is
> as lucky as you. Explain? underscore hack, asterisk hack, .clearfix
> ... I'm sure you know what I'm talking about.
Oh, you are talking about *authoring* "hacks"... I don't consider good,
semantic HTML or carefully crafted CSS "hacking". I thought you meant
someone - some black hat person - could hack your server files. <shrug>
>> Your other post:
>>
>>> I'm not using tables in my html, isn't that enough?
>>
>> No. It is still using "tables for layout", a process we keep stressing
>> should be avoided.
>
> Could you remind me real quick why this should be avoided?
Read the archives of these groups.
> Semantic html, uncluttered html, crossbrowser comes to my mind.
Semantic. How is a column of menu items related to a block of content
adjacent to it? Tables are for data.
> My approach has this qualities. Or maybe tables has been declared as
> devils spawn by vatican and should be as such?
For layout, yes. The Pope told me.
>>> I keep my html clean and I can order content any way I want. It's
>>> human friendly and robot friendly.
>>
>> Your sample code is using a Transitional doctype. What are you
>> transitioning from? That's for legacy pages; use Strict instead.
>
> Maybe you can put browser in quirks mode with strict doctype
> declaraion, I haven't tried that yet. It's work in progress.
What?
>> You assign font size in pixels; that too has gone the way of the dodo
>> bird. Use percentages instead. See: http://k75s.home.att.net/fontsize.html
>
> This has nothing to do with my lib so you can specify fonts any way
> you like while using it. I like pixels for this simple example.
Most of us prefer percentages for font sizing because when the visitor
hits the "upsize" key, the content won't jump out of your pixel-sized
boxes. And IE won't resize, thus annoying your visitors with less than
perfect vision.
>> Clean code? <lol> See:
>> <http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.bravelay...>
>>
>> This page is not Valid XHTML 1.0 Transitional!
>> Result: Failed validation, 119 Errors
>
> Why do you try to validate it as XHTML if it's indicated as HTML
> Transitional in DOCTYPE?
> It's valid HTML 4.01 Transitional (after some minor fixes).
Read the validator link again. It's your page .. the link you posted.
Your site. My sites have no errors.
>> Human friendly, perhaps, to the other 90%.
>> Robots (search engines?) don't read and execute JavaScript.
>
> And that's good because visual layout of a page is none of their
> interest.
So anything in your JavaScript is ignored.
>> You need to rethink what you are doing.
>
> I am constantly rethinking almost everything I am doing.
That's a good sign.
brave1979
> > visitors do not have Javascript enabled? Even for such people all
> > content is still readable and if you really care you can provide them
> > with something easy on eyes.
>
> http://www.w3schools.com/browsers/browsers_stats.asp
> varies between 6-12% over the last few years. Note I said *~* 10%. That
> means circa 10%. There are other stat sites which you can probably find
> via Google.
though. I think you should look at number for 2007 which is 6% and
seems to be dropping (probably due ajax people don't want to cripple
themselves anymore).
> >> I would have expected you to have at least a link to a demonstration
> >> page at the link you mentioned.
> ..and do you have one of these?
I am sorry but I still don't know what do you mean by demonstration.
Link I have given point to my wiki directly to simples example.
> >> You say, "You just need to write something like this!"
> >> but it is a *lot* easier just to write regular old HTML than your
> >> script, with its errors. A *lot* easier.
>
> > This is very simple example. True strength of my approach is ability
> > to nest layouts, and ability to change them as requirements change.
>
> What kind of "nesting" would I want to do? Nest tables?
Nest layout components inside layout components. Split footer into
columns, give left column it's own footer. Split content area into
three columns and give them their own header.
> >> You also say, "HTML is horrible. It's not suitable for anything more
> >> visually complicated than a short school essay. " You must be new to
> >> this game. HTML and CSS can do much more than you seem to realize.
>
> > Actually I'm pretty old to this game and tired from countless
> > occasions when I tried to get something look good and do what I want
> > in different browsers. I joined this game before such thing as
> > tableless layout was even possible.
>
> Me too, but that's not an excuse.
It's not an excuse. It's a motivation.
> >> And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
> >> a bit less than your convoluted approach.
> > It's not weight in bytes that matters.
> Of *course* it matters! Ever use dial-up?
Yes. Please give these argument to all the people cramming video
adverts on webpages.
I know it matters but there are things that matter more.
> > It's weight in hours of programmer time stolen that matters.
> That applies to one person, not thousands of visitors' time. You would
> rather churn out pages quickly, then penalize all of the visitors with
> bloated pages?
Pages done with help of my lib are not bloated. For bigger more
complex pages it should be about same size or even smaller than css
+html equivalent.
> > And for more complex layout there should be no significant difference
> > in size between my approach and css hacking.
> CSS hacking? Hacking? You think we need to 'hack'? <g>
Every time you use float to make a column you hack. Floats were not
intended to be used as columns so you use something in clever
unintended way to achieve some goal therefore you hack.
> >>> More important is that with my lib you can achieve being
> >>> crossbrowser almost effortless and your html files and even css
> >>> files stay clean hack-free, table-free.
>
> >> My HTML and CSS files are already "hack-free". You will have to
> >> explain in some detail why you think differently.
>
> > Then you are lucky guy, browsing internet tells me not everybody is
> > as lucky as you. Explain? underscore hack, asterisk hack, .clearfix
> > ... I'm sure you know what I'm talking about.
>
> Oh, you are talking about *authoring* "hacks"... I don't consider good,
> semantic HTML or carefully crafted CSS "hacking". I thought you meant
> someone - some black hat person - could hack your server files. <shrug>
Sorry. I'm not native speaker? Would it be clearer If I used bunny
ears around word hack like you did?
> >> Your other post:
>
> >>> I'm not using tables in my html, isn't that enough?
>
> >> No. It is still using "tables for layout", a process we keep stressing
> >> should be avoided.
>
> > Could you remind me real quick why this should be avoided?
>
> Read the archives of these groups.
That was even quicker than I expected.
> > Semantic html, uncluttered html, crossbrowser comes to my mind.
>
> Semantic. How is a column of menu items related to a block of content
> adjacent to it? Tables are for data.
If you use my lib you can put them at the end of the file, at the
beginning of the file, near other ways of navigating .... anywhere!
Because order of things in your html file has nothing to do with where
they will appear on your webpage. Perhaps I have not stated this
clearly enough in my wiki.
> > My approach has this qualities. Or maybe tables has been declared as
> > devils spawn by vatican and should be as such?
>
> For layout, yes. The Pope told me.
Ok, but do you see any of them in my html source file?
> >>> I keep my html clean and I can order content any way I want. It's
> >>> human friendly and robot friendly.
>
> >> Your sample code is using a Transitional doctype. What are you
> >> transitioning from? That's for legacy pages; use Strict instead.
>
> > Maybe you can put browser in quirks mode with strict doctype
> > declaraion, I haven't tried that yet. It's work in progress.
>
> What?
I guess you can't help me with this. :-)
> >> You assign font size in pixels; that too has gone the way of the dodo
> >> bird. Use percentages instead. See:http://k75s.home.att.net/fontsize.html
>
> > This has nothing to do with my lib so you can specify fonts any way
> > you like while using it. I like pixels for this simple example.
>
> Most of us prefer percentages for font sizing because when the visitor
> hits the "upsize" key, the content won't jump out of your pixel-sized
> boxes. And IE won't resize, thus annoying your visitors with less than
> perfect vision.
Wasn't that the rationale for specifying box sizes with em instead of
pixels ?
Are you sure that this is what specifying font sizes in percents is
all about?
Page you've linked to just says something about IE not being able to
resize texts with fonts specified in pixels.
> >> Clean code? <lol> See:
> >> <http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.bravelay...>
>
> >> This page is not Valid XHTML 1.0 Transitional!
> >> Result: Failed validation, 119 Errors
>
> > Why do you try to validate it as XHTML if it's indicated as HTML
> > Transitional in DOCTYPE?
> > It's valid HTML 4.01 Transitional (after some minor fixes).
>
> Read the validator link again. It's your page .. the link you posted.
> Your site. My sites have no errors.
Oh. Sorry. You checked the wiki I use. Sure It does not validate. I
just used standard template, perhaps you should communicate this
validation issue to template author. Perhaps he will be interested.
This template does not use my lib.
If you are so surprised that I can do something such nasty as
publishing nonvalidating webpage then I must want you that I also
visit toilet each single day! ;-)
When I validate example using my lib with validator
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.bravelayout.scarabeo.biz%2Fexamples%2Fexample0.html&charset=%28detect+automatically%29&doctype=Inline&group=0
I get message that this page is valid with only one warning about me
not specifying charset.
> >> Human friendly, perhaps, to the other 90%.
> >> Robots (search engines?) don't read and execute JavaScript.
>
> > And that's good because visual layout of a page is none of their
> > interest.
>
> So anything in your JavaScript is ignored.
Yes! That's the whole point. Ignored same way as your css file is
ignored by any search engine robot.
Harlan Messinger
> On Dec 31, 12:31 am, Harlan Messinger
> <hmessinger.removet...@comcast.net> wrote:
>> brave1979 wrote:
>>> On Dec 30, 7:02 pm, Harlan Messinger
>>> <hmessinger.removet...@comcast.net> wrote:
>>>> brave1979 wrote:
>>>>> Please check out my javascript library that allows you to create any
>>>>> layout for your web page, nested as deep as you like, adjusting to
>>>>> width and height of a browser window. You just describe it in
>>>>> javascript object and that's all. No need to know CSS hacks, no need
>>>>> to clutter your html with tables.
>>>>> http://www.bravelayout.scarabeo.biz/Quickstart
>>>> You are using tables, you're just using Javascript to create them:
>>> I'm not using tables in my html, isn't that enough?
>> Enough for what? Evidently you're misunderstanding the intent of the
>> guidance to avoid using tables for layout.
> I thought tables were avoided for some real benefits like semantic
> content, clean html, separating defining visual aspects from defining
> content.
They're semantically just as incorrect if you have Javascript generating
them in the browser as they would be if the author had coded them
directly. I will grant you the separation aspect of your argument. Then
there's also the issue of flexibility of layout in different browsers
and different viewport sizes.
> My lib does all that, and it's easy to use.
Ease is good, but it isn't the issue.
>
>>> I keep my html
>>> clean
>> By switching to Javascript to lay out your page, which is worse?
> How is it worse?
For the same reason that it would be worse if your entire file consisted of
<html>
<script type="text/javascript">
document.write("<head>");
document.write("<title>This is the title</title>");
// and so on
</script>
>
>>> and I can order content any way I want. It's human friendly and
>>> robot friendly.
>> Not if the human isn't using Javascript.
> Just as most of web 2.0 and all that nice ajax ;-)
That's good for functionality that goes beyond basic presentation. You
should be able to see plain old content without Javascript, and beyond
that it's also best to have non-Javascript fallbacks whenever you can.
FOR EXAMPLE, I headed out one night to a restaurant I'd just read about,
and I'd noted the address, but the place where I'd mentally located it
turned out not to be where it was. I'd forgotten the street number by
that point, so I pulled out my PDA to Google it. I found their
website--which, except for the name of the restaurant, was completely
blank. No links, no buttons, because everything was set up to depend on
Javascript. Dumb, dumb, dumb.
Michael Fesser
>> > This is very simple example. True strength of my approach is ability
>> > to nest layouts, and ability to change them as requirements change.
>>
>> What kind of "nesting" would I want to do? Nest tables?
>Nest layout components inside layout components. Split footer into
>columns, give left column it's own footer. Split content area into
>three columns and give them their own header.
And why does this require unreliable client-side scripting? The same can
be done with server-side scripting and clean, appropriate HTML as the
result.
>> > And for more complex layout there should be no significant difference
>> > in size between my approach and css hacking.
>> CSS hacking? Hacking? You think we need to 'hack'? <g>
>Every time you use float to make a column you hack. Floats were not
>intended to be used as columns so you use something in clever
>unintended way to achieve some goal therefore you hack.
I beg to differ. The behaviour of floats is exactly defined and
described in detail in the CSS spec. That's not what I'd call a hack.
>> > Semantic html, uncluttered html, crossbrowser comes to my mind.
>>
>> Semantic. How is a column of menu items related to a block of content
>> adjacent to it? Tables are for data.
>If you use my lib you can put them at the end of the file, at the
>beginning of the file, near other ways of navigating .... anywhere!
>Because order of things in your html file has nothing to do with where
>they will appear on your webpage. Perhaps I have not stated this
>clearly enough in my wiki.
The order of elements _does_ matter. If you need scripting or CSS to
bring the elements in a senseful order and make your site usable, then
it's a broken design right from the beginning.
>> > My approach has this qualities. Or maybe tables has been declared as
>> > devils spawn by vatican and should be as such?
>>
>> For layout, yes. The Pope told me.
>Ok, but do you see any of them in my html source file?
Doesn't matter. Written in the HTML or generated by a script - it's the
same thing. If your script generates tables, then you _are_ using tables
to layout the HTML.
>> >> Your sample code is using a Transitional doctype. What are you
>> >> transitioning from? That's for legacy pages; use Strict instead.
>>
>> > Maybe you can put browser in quirks mode with strict doctype
>> > declaraion, I haven't tried that yet. It's work in progress.
>>
>> What?
>I guess you can't help me with this. :-)
It would help if you would explain your problems with a strict DTD.
>> >> Human friendly, perhaps, to the other 90%.
>> >> Robots (search engines?) don't read and execute JavaScript.
>>
>> > And that's good because visual layout of a page is none of their
>> > interest.
>>
>> So anything in your JavaScript is ignored.
>Yes! That's the whole point. Ignored same way as your css file is
>ignored by any search engine robot.
Usually a CSS is not required in order to make a site usable, whereas
your JavaScript is. No JS, no content. CSS is optional and properly
built sites work perfectly well without it, so SEs don't have to care
about it at all.
Micha
Harlan Messinger
> Actually I'm pretty old to this game and tired from countless
> occasions when I tried to get something look good and do what I want
> in different browsers. I joined this game before such thing as
> tableless layout was even possible.
>
>> And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
>> a bit less than your convoluted approach.
> It's not weight in bytes that matters. It's weight in hours of
> programmer time stolen that matters.
That's what *server*-side programming is good for. You write routines to
automate the generation of HTML on the *server* to save yourself the
effort of coding it all manually. Then the user gets HTML, not script
that may or may not work in his browser.
Harlan Messinger
In fairness, that's not an issue in the OP's case. The content *is*
present in HTML, in more or less the same form it would be if CSS
instead of Javascript was being used for the layout.
Ben C
> On Dec 31, 12:31 am, Harlan Messinger
><hmessinger.removet...@comcast.net> wrote:
>> brave1979 wrote:
>> > On Dec 30, 7:02 pm, Harlan Messinger
>> > <hmessinger.removet...@comcast.net> wrote:
>> >> brave1979 wrote:
>> >>> Please check out my javascript library that allows you to create any
>> >>> layout for your web page, nested as deep as you like, adjusting to
>> >>> width and height of a browser window. You just describe it in
>> >>> javascript object and that's all. No need to know CSS hacks, no need
>> >>> to clutter your html with tables.
>> >>>http://www.bravelayout.scarabeo.biz/Quickstart
>> >> You are using tables, you're just using Javascript to create them:
>>
>> > I'm not using tables in my html, isn't that enough?
>>
>> Enough for what? Evidently you're misunderstanding the intent of the
>> guidance to avoid using tables for layout.
> I thought tables were avoided for some real benefits like semantic
> content, clean html, separating defining visual aspects from defining
> content. My lib does all that, and it's easy to use.
Those are some of the reasons given, but there is another one, which is
that many features of table layout aren't defined precisely in any
specification, and many things are deliberately undefined.
That means the best you can do is test in a few browsers, but you don't
know if your page will look how you intended on browsers you didn't test
in or on future versions of the ones you did test in, unless you stick
only to the subset of table layout behaviour that is defined, which is
likely to be too restrictive.
You have a point that floats weren't really intended for doing columns
with either, but at least the behaviour you should get is well-defined.
brave1979
> > content, clean html, separating defining visual aspects from defining
> > content.
>
> They're semantically just as incorrect if you have Javascript generating
> them in the browser as they would be if the author had coded them
> directly.
something like "meaningful". And writing semantic html is writing html
that has meaning and structure associated with this meaning not just
html that is the tag soup to force browser to render properly (as with
table layout).
> >>> I keep my html
> >>> clean
> >> By switching to Javascript to lay out your page, which is worse?
> > How is it worse?
>
> For the same reason that it would be worse if your entire file consisted of
>
> <html>
> <script type="text/javascript">
> document.write("<head>");
> document.write("<title>This is the title</title>");
> // and so on
> </script>
It's not the same. With your example you devoid visitors (with js
turned off) of content. You also do the same with browsers that do not
execute javascript and search engine robots.
It's far far worse than doing layout in html.
> >>> and I can order content any way I want. It's human friendly and
> >>> robot friendly.
> >> Not if the human isn't using Javascript.
> > Just as most of web 2.0 and all that nice ajax ;-)
>
> That's good for functionality that goes beyond basic presentation. You
> should be able to see plain old content without Javascript, and beyond
> that it's also best to have non-Javascript fallbacks whenever you can.
But with my BraveLayout you can see plain content even when you don't
have js enabled. Just the same way you can see plain content when you
view CSS layout with browser With CSS disabled.
> FOR EXAMPLE, I headed out one night to a restaurant I'd just read about,
> and I'd noted the address, but the place where I'd mentally located it
> turned out not to be where it was. I'd forgotten the street number by
> that point, so I pulled out my PDA to Google it. I found their
> website--which, except for the name of the restaurant, was completely
> blank. No links, no buttons, because everything was set up to depend on
> Javascript. Dumb, dumb, dumb.
Yeah. It happens. And this is much much worse than what I am trying to
do here. If that page was done using BraveLayout you would see all
content. Maybe ordered diffrently. Maybe a little bit chaotic if
authors didn't thought about people like you. But you could still see
content and you could still navigate around it.
brave1979
> .oO(brave1979)
>
> >> > This is very simple example. True strength of my approach is ability
> >> > to nest layouts, and ability to change them as requirements change.
>
> >> What kind of "nesting" would I want to do? Nest tables?
> >Nest layout components inside layout components. Split footer into
> >columns, give left column it's own footer. Split content area into
> >three columns and give them their own header.
>
> And why does this require unreliable client-side scripting? The same can
> be done with server-side scripting and clean, appropriate HTML as the
> result.
disabling this elements on some of you subpages.
I am saying that you can take standard pure 2 column CSS layout from
internet (where it was put by smart people who figured way how to
force browser to display it).
But if you want to have right column of this layout similar way (to
have its own header footer and two columns) then there is no easy way
to do it.
> >> > And for more complex layout there should be no significant difference
> >> > in size between my approach and css hacking.
> >> CSS hacking? Hacking? You think we need to 'hack'? <g>
> >Every time you use float to make a column you hack. Floats were not
> >intended to be used as columns so you use something in clever
> >unintended way to achieve some goal therefore you hack.
>
> I beg to differ. The behaviour of floats is exactly defined and
> described in detail in the CSS spec. That's not what I'd call a hack.
Does the word "column" appear anywhere on this spec? Does any example
of use in specs shows how to use it to make column?
http://www.w3.org/TR/REC-CSS2/visuren.html#floats
Clever way of exploiting system for your own purposes is called a
hack.
> >> > Semantic html, uncluttered html, crossbrowser comes to my mind.
>
> >> Semantic. How is a column of menu items related to a block of content
> >> adjacent to it? Tables are for data.
> >If you use my lib you can put them at the end of the file, at the
> >beginning of the file, near other ways of navigating .... anywhere!
> >Because order of things in your html file has nothing to do with where
> >they will appear on your webpage. Perhaps I have not stated this
> >clearly enough in my wiki.
>
> The order of elements _does_ matter. If you need scripting or CSS to
> bring the elements in a senseful order and make your site usable, then
> it's a broken design right from the beginning.
When doing table layouts you must order your content to fit tables.
When you are doing pure css layouts you often have to order your
content to fit adjecent columns simulated by floats.
When you are doing BraveLayout you may order your content exactly
according to its meaning, you are not constrained by visual layout of
a page in any way.
> >> > My approach has this qualities. Or maybe tables has been declared as
> >> > devils spawn by vatican and should be as such?
>
> >> For layout, yes. The Pope told me.
> >Ok, but do you see any of them in my html source file?
>
> Doesn't matter. Written in the HTML or generated by a script - it's the
> same thing. If your script generates tables, then you _are_ using tables
> to layout the HTML.
But I still don't understand what is wrong with doing this.
I know what's wrong with putting tables in your html to achieve visual
effect but I can't understand why you consider them evil when they are
used the way I use them. I have not seen any argument for this yet.
Because so far I've just seen statement "tables for layout are evil"
repeated like a mantra.
> >> >> Human friendly, perhaps, to the other 90%.
> >> >> Robots (search engines?) don't read and execute JavaScript.
>
> >> > And that's good because visual layout of a page is none of their
> >> > interest.
>
> >> So anything in your JavaScript is ignored.
> >Yes! That's the whole point. Ignored same way as your css file is
> >ignored by any search engine robot.
>
> Usually a CSS is not required in order to make a site usable, whereas
> your JavaScript is. No JS, no content. CSS is optional and properly
> built sites work perfectly well without it, so SEs don't have to care
> about it at all.
Please see my example. Disable javascript. You will still see all the
content. There just will be no layout. http://bravelayout.scarabeo.biz/examples/example0.html
brave1979
So you say that programmers who do html and css don't spend any time?
Someone has to code this html and his time I intend to save.
brave1979
> Those are some of the reasons given, but there is another one, which is
> that many features of table layout aren't defined precisely in any
> specification, and many things are deliberately undefined.
>
> That means the best you can do is test in a few browsers, but you don't
> know if your page will look how you intended on browsers you didn't test
> in or on future versions of the ones you did test in, unless you stick
> only to the subset of table layout behaviour that is defined, which is
> likely to be too restrictive.
>
> You have a point that floats weren't really intended for doing columns
> with either, but at least the behaviour you should get is well-defined.
I agree with you. If I could achieve the flexibility I require with
floats I would generate floats not tables with my lib. Just for the
sake of mental health of people who hate for the tables running
through their veins.
But your point is at the moment rather theoretical than practical.
You also don't know how your pure css layout will look on browsers you
have not tested. You know only how it should look if browser was built
according to full specs which rarely happens. So it's more like
placing the blame on someone else than really addressing the problem.
As for future versions of common browsers, they are no problem because
BraveLayout relies on quirks mode which is currently never touched by
browser developers. They improve standards mode, but they keep quirks
mode for backwards compatibility with older pages. It's highly
unlikely that some browser development team decides to remove quirks
mode from their browser as some point in near future. And even then my
lib could probably be improved to support such browser.
Ben C
> As for future versions of common browsers, they are no problem because
> BraveLayout relies on quirks mode which is currently never touched by
> browser developers. They improve standards mode, but they keep quirks
> mode for backwards compatibility with older pages. It's highly
> unlikely that some browser development team decides to remove quirks
> mode from their browser as some point in near future.
It's not that simple. The problem is that the unspecified parts of table
formatting are a complicated mess.
Look at Firefox's documentation of quirks mode:
http://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior
It's all nice and clear, until we get to the bottom of the Tables
section. "The basic table layout strategy handles widths differently in
some way"
I wonder what QA tests exist for this different handling, and if they
cover all of the processing that the output of your lib needs. I wonder
if anyone really knows what it does, or if the plan is just to try to
ignore it until it goes away.
Perhaps developers won't be touching that part intentionally, but a
change elsewhere could easily affect the way it works.
And what about browsers that aren't IE, Gecko, Opera or KHTML? As more
browsers, and therefore the web itself, get closer to conforming to the
W3C standards, the playing field opens up because, with specifications,
it's much easier for anyone to implement a browser. How much cursory
support for unspecified quirks-mode table column width calculations do
you expect these newer browsers will attempt?
You would be better off to output strict mode tables, avoid rowspan and
colspan altogether, and be careful with percentages.
> And even then my lib could probably be improved to support such
> browser.
Your lib provides authors with an alternative way of describing layouts
that isn't CSS or tables, although it has more in common with tables,
which is probably why the output is in the form of tables.
It's possible that it does provide a way of writing more succintly the
things some people wanted to do with tables in the days when they used
them for layout.
But you're relying on consistent JS implementation between browsers
instead. Is that any more reliable than their CSS implementations? Not
much if at all.
I don't see the need to-- why not instead write your preprocessor in
some reasonably reliable cross-platform programming language (Python,
Java, etc.) and then people can run it on their own development machines
or servers and just put the output on the web? I don't see the need to
run it on the client's JS interpreter at all.
brave1979
> On 2007-12-31, brave1979 <brave1...@o2.pl> wrote:
>
> > On Dec 31, 9:25 am, Ben C <spams...@spam.eggs> wrote:
> [...]
> > As for future versions of common browsers, they are no problem because
> > BraveLayout relies on quirks mode which is currently never touched by
> > browser developers. They improve standards mode, but they keep quirks
> > mode for backwards compatibility with older pages. It's highly
> > unlikely that some browser development team decides to remove quirks
> > mode from their browser as some point in near future.
>
> It's not that simple. The problem is that the unspecified parts of table
> formatting are a complicated mess.
>
> Look at Firefox's documentation of quirks mode:
>
> http://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior
>
> It's all nice and clear, until we get to the bottom of the Tables
> section. "The basic table layout strategy handles widths differently in
> some way"
>
> I wonder what QA tests exist for this different handling, and if they
> cover all of the processing that the output of your lib needs. I wonder
> if anyone really knows what it does, or if the plan is just to try to
> ignore it until it goes away.
consistent across different modern browsers. Even sometimes more
consistent than standards mode especially in areas when specs are
lacking like in case of 100% height for tables and table cells.
> Perhaps developers won't be touching that part intentionally, but a
> change elsewhere could easily affect the way it works.
As I understand standards mode rendering is quite independent of
quirks mode in modern browsers so there is low probability that quirks
mode will be affected during development of standards. And my lib is
not carved in stone. It's not even compiled. Anyone can change it to
adjust it to "features" introduced in some browsers. It's just layer
of abstraction isolating layout definition from inconsistent rendering
engines.
> And what about browsers that aren't IE, Gecko, Opera or KHTML? As more
> browsers, and therefore the web itself, get closer to conforming to the
> W3C standards, the playing field opens up because, with specifications,
> it's much easier for anyone to implement a browser. How much cursory
> support for unspecified quirks-mode table column width calculations do
> you expect these newer browsers will attempt?
I really hope that before that newer browser gain market share HTML5
(or six or something else) and next versions of CSS will be widely
adopted standards and my lib will evolves into something that uses
those standards. I may even imagine compiler that automatically
translated my layout definition to proper CSS3 or CSS4 or whatever
will be best used for layouts in the future.
> You would be better off to output strict mode tables, avoid rowspan and
> colspan altogether, and be careful with percentages.
I don't know about strict mode (it varies greatly across browsers in
areas where the specs are lacking) but I learned early that colspans
and rowspans should be avoided at all costs, and that percentages
should be used carefully. BraveLayout.js was written with this things
in mind.
> > And even then my lib could probably be improved to support such
> > browser.
>
> Your lib provides authors with an alternative way of describing layouts
> that isn't CSS or tables, although it has more in common with tables,
> which is probably why the output is in the form of tables.
>
> It's possible that it does provide a way of writing more succintly the
> things some people wanted to do with tables in the days when they used
> them for layout.
>
> But you're relying on consistent JS implementation between browsers
> instead. Is that any more reliable than their CSS implementations? Not
> much if at all.
Actually yes, I learned from experience that it's much more
consistent. And inconsistencies are much easier to deal with.
> I don't see the need to-- why not instead write your preprocessor in
> some reasonably reliable cross-platform programming language (Python,
> Java, etc.) and then people can run it on their own development machines
> or servers and just put the output on the web? I don't see the need to
> run it on the client's JS interpreter at all.
This preprocessor would have to generate css and tables in html
because I have not seen any way of doing things BraveLayout does in
pure css. And there should not be tables cluttering your html source.
If not for that the preprocessor would be preferred solution.
Beauregard T. Shagnasty
> That's what *server*-side programming is good for. You write routines
> to automate the generation of HTML on the *server* to save yourself
> the effort of coding it all manually. Then the user gets HTML, not
> script that may or may not work in his browser.
I've given up trying to reason with him...
I would also love to see a real demo page, with some real content, and
that is still visible when JavaScript is unavailable.
http://k75s.home.att.net/show/brave.jpg
Harlan Messinger
>>> I thought tables were avoided for some real benefits like semantic
>>> content, clean html, separating defining visual aspects from defining
>>> content.
>> They're semantically just as incorrect if you have Javascript generating
>> them in the browser as they would be if the author had coded them
>> directly.
> Sorry. Maybe I am misunderstanding word "semantic". I thought its
> something like "meaningful".
Yes.
> And writing semantic html is writing html
> that has meaning and structure associated with this meaning not just
> html that is the tag soup to force browser to render properly (as with
> table layout).
Exactly. And tag soup is tag soup no matter how you generate it, whether
by hand or with Javascript. The contents of your page that aren't
logically a table, don't *become* logically a table just because you let
Javascript generate the table-related tags.
Ben C
>> I don't see the need to-- why not instead write your preprocessor in
>> some reasonably reliable cross-platform programming language (Python,
>> Java, etc.) and then people can run it on their own development machines
>> or servers and just put the output on the web? I don't see the need to
>> run it on the client's JS interpreter at all.
> This preprocessor would have to generate css and tables in html
> because I have not seen any way of doing things BraveLayout does in
> pure css. And there should not be tables cluttering your html source.
I suppose they would be annoying if you used a screen reader or
something.
I think I see your point: nice uncluttered HTML is not just for
authors, but also better for users.
Ben C
Isn't the idea of his system that the HTML stays as nice clean HTML,
and is only munged into a sea of tables by the JS?
Bergamot
> On Dec 31, 7:02 am, Michael Fesser <neti...@gmx.de> wrote:
>>
>> The behaviour of floats is exactly defined and
>> described in detail in the CSS spec. That's not what I'd call a hack.
> Does the word "column" appear anywhere on this spec?
>
> hack.
Nah, I'd call it being creative. Just because the CSS specs don't
explicitly say you may use properties for particular visual effects
doesn't mean you can't.
>> If your script generates tables, then you _are_ using tables
>> to layout the HTML.
>
> I know what's wrong with putting tables in your html to achieve visual
> effect but I can't understand why you consider them evil when they are
> used the way I use them.
The document tree is what the browser/user sees. Why do you think
generating it via script instead of coding it in the HTML makes a
difference?
--
Berg
Bergamot
>
> This template does not use my lib.
You don't use your own product? Why would you expect anyone else to?
--
Berg
while-one
> Please check out my javascript library that allows you to create any
> layout for your web page, nested as deep as you like, adjusting to
> width and height of a browser window. You just describe it in
> javascript object and that's all. No need to know CSS hacks, no need
> to clutter your html with tables.
>
> http://www.bravelayout.scarabeo.biz/Quickstart
There *is* a strong argument for this sort of thing in the
"complex web-app" context. But to fill that niche you
need a system like Google's GWT, that somehow also includes
asynchronous server communication.
I spent 4 months working on a (now defunct) interface
to XML database project that included a drag-and-drop
editor for building complex hierarchical data entry forms (for
describing
experimental data). Those forms, once 'saved,' where
automatically operational--you could fill them out
and save data. Another form allowed dynamic creation
of complex query forms (select all data where creation_date
between xxx and /exp/protocol/ == 'whatever' etc.
And that worked, all built with mouse clicks, with no
intervention by a programmer. It would have been a nightmare
to code without GWT (code in java, compile to javascript).
Mouseover Select Option choices can update the server without re-
drawing the
screen, for instance. But that's just one of many examples.
So, this sort of thing is outside the context of simple "here I am
websites." It's at its best for highly complex, interactive
web-based GUI screens. But you do need the xmlhttpheaderreq
stuff. Else you went to New York but you got off in Chicago.
brave1979
<a.nony.m...@example.invalid> wrote:
> I would also love to see a real demo page, with some real content, and
> that is still visible when JavaScript is unavailable.
examples will be coming soon. Actually I already have some running web
application built using BraveLayout but it's little more complex so
It's not good for first example. I also need to clean it up a little
bit. I will keep you informed. Until then please feel free to
experiment with BraveLayout yourself.
brave1979
But noone ever sees this tables. You must be able to see current DOM
tree to ever see any table generated by BraveLayout. Most browsers
does not even has that option out of the box. If you just "View
Source" you won't see any table. If you download my page with some
other program like wget you won't see any table either. What does it
matter if browser internally renders tables to display the content if
those tables are not visible anywhere else?
brave1979
Yes. Your html source stays nice and clean. Layout is generated
internally in browser by javscript while the page loads. When it
finishes loading parts of source html are placed in the right spots of
generated layout.
brave1979
> brave1979 wrote:
> > On Dec 31, 7:02 am, Michael Fesser <neti...@gmx.de> wrote:
>
> >> The behaviour of floats is exactly defined and
> >> described in detail in the CSS spec. That's not what I'd call a hack.
> > Does the word "column" appear anywhere on this spec?
>
> > Clever way of exploiting system for your own purposes is called a
> > hack.
>
> Nah, I'd call it being creative. Just because the CSS specs don't
> explicitly say you may use properties for particular visual effects
> doesn't mean you can't.
also creative and the fact that it wasn't built for that doesn't mean
you can't do it (at least when no one is watching ;-)).
> >> If your script generates tables, then you _are_ using tables
> >> to layout the HTML.
>
> > I know what's wrong with putting tables in your html to achieve visual
> > effect but I can't understand why you consider them evil when they are
> > used the way I use them.
>
> The document tree is what the browser/user sees. Why do you think
> generating it via script instead of coding it in the HTML makes a
> difference?
User does not see DOM tree, he sees rendered page. What actually is in
DOM tree usually does not interest him. But he may be interested in
html source file, and this is kept clean and readable in my method.
brave1979
using BraveLayout. I'm gonna show it to you later. I also have done
webpage of some small company with very early protoype of this lib and
it works for almost a year without any complaint whatsoever, but this
I am not going to show you this one because I know how strong some
people feel about css, and i don't want anyone to trouble my client.
Harlan Messinger
Yes. But HTML generated by code is HTML. The precept is not "HTML
written by hand and stored in a file should be clean and meaningful" but
"HTML should be clean and meaningful".
brave1979
> So, this sort of thing is outside the context of simple "here I am
> websites." It's at its best for highly complex, interactive
> web-based GUI screens. But you do need the xmlhttpheaderreq
> stuff. Else you went to New York but you got off in Chicago.
ditch html altogether for all purposes in favor of something like ZK
or OpenLaszlo but I didn't like the idea of troubling my visitors with
downloading huge framework and learning myself new metalanguage to
probably discover at some point that it also has some severe
limitations.
I just needed small simple library that could allow me to build layout
quickly without cluttering html file. I even considered using flash
not js and generated tables for this purpose, but I don't know flash
that good. Maybe I'll try it in the future as an exercise.
Rob Waaijenberg
>
> But noone ever sees this tables. You must be able to see current DOM
> tree to ever see any table generated by BraveLayout. Most browsers
> does not even has that option out of the box. If you just "View
> Source" you won't see any table. If you download my page with some
> other program like wget you won't see any table either. What does it
> matter if browser internally renders tables to display the content if
> those tables are not visible anywhere else?
Do you ever read back what you wrote, before you post it?
To me it doesn't make sense.
If a page uses tables for lay-out and I use "view source"
I can see them allright.
"...internally renders tables..."???????????????????
Huh????
--
Rob
brave1979
> written by hand and stored in a file should be clean and meaningful" but
> "HTML should be clean and meaningful".
suggested (as far as I know) that DOM Tree should be clean and
meaningful.
Tim Streater
<7bbabf1b-76cd-4bf8...@1g2000hsl.googlegroups.com>,
brave1979 <brav...@o2.pl> wrote:
> On Dec 31, 2:58 pm, Bergamot <berga...@visi.com> wrote:
> > brave1979 wrote:
> > > On Dec 31, 7:02 am, Michael Fesser <neti...@gmx.de> wrote:
> >
> > >> The behaviour of floats is exactly defined and
> > >> described in detail in the CSS spec. That's not what I'd call a hack.
> > > Does the word "column" appear anywhere on this spec?
> >
> > > Clever way of exploiting system for your own purposes is called a
> > > hack.
> >
> > Nah, I'd call it being creative. Just because the CSS specs don't
> > explicitly say you may use properties for particular visual effects
> > doesn't mean you can't.
> Kicking the vending machine in the right spot to get some coins is
> also creative and the fact that it wasn't built for that doesn't mean
> you can't do it (at least when no one is watching ;-)).
No, it's theft. And like all hacks, it doesn't scale.
brave1979
wrote:
> brave1979 schreef:
>
>
>
> > But noone ever sees this tables. You must be able to see current DOM
> > tree to ever see any table generated by BraveLayout. Most browsers
> > does not even has that option out of the box. If you just "View
> > Source" you won't see any table. If you download my page with some
> > other program like wget you won't see any table either. What does it
> > matter if browser internally renders tables to display the content if
> > those tables are not visible anywhere else?
>
> Do you ever read back what you wrote, before you post it?
ask questions and I'll try to rephrase what I said.
> To me it doesn't make sense.
>
> If a page uses tables for lay-out and I use "view source"
> I can see them allright.
If they are generated by the javascript you can't. I don't know what
browser you are using but when you do "View Source" in IE, Firefox,
Konqueror, Opera, probably Safari you will see only what was actually
read from the web server, not the things javascript generated in your
browser.
Are you sure that when you go to page: http://www.bravelayout.scarabeo.biz/examples/example0.html
and "View Source" you can see any table ?
What browser you are using?
brave1979
> > also creative and the fact that it wasn't built for that doesn't mean
> > you can't do it (at least when no one is watching ;-)).
>
> No, it's theft.
clever and all are breaking some rules. And some are commonly used to
circumvent limitation of some systems.
> And like all hacks, it doesn't scale.
great line :-) applies to css *authoring* "hacks" as well ;-)
Ben C
[...]
>> Isn't the idea of his system that the HTML stays as nice clean HTML,
>> and is only munged into a sea of tables by the JS?
>
> Yes. But HTML generated by code is HTML.
His code doesn't generate HTML.
He has annoyingly removed whitespace from the source. I wish people
wouldn't do that. But all the same you can see that he's creating the
DOM tree with createElement and appendChild, not innerHTML.
(See
http://www.bravelayout.scarabeo.biz/examples/BraveLayout-standalone-min.js
and http://www.bravelayout.scarabeo.biz/examples/example0.html)
At no point does nasty HTML exist, unless you count things like the
Firebug turning the DOM tree back into sort of HTML for the purpose of
displaying it.
brave1979
> > Yes. But HTML generated by code is HTML.
>
> His code doesn't generate HTML.
>
> He has annoyingly removed whitespace from the source. I wish people
> wouldn't do that. But all the same you can see that he's creating the
> DOM tree with createElement and appendChild, not innerHTML.
>
> andhttp://www.bravelayout.scarabeo.biz/examples/example0.html)
If you want source try: http://www.bravelayout.scarabeo.biz/examples/BraveLayout-standalone.js
http://www.bravelayout.scarabeo.biz/examples/BraveLayout-standalone-min.js
is a minified version (quite unreadable)
Rob Waaijenberg
>> Yes. But HTML generated by code is HTML. The precept is not "HTML
>> written by hand and stored in a file should be clean and meaningful" but
>> "HTML should be clean and meaningful".
> Generated HTML is not HTML anymore.
First you generate something (quote: "Generated HTML" )
and after you do, it magically turns into something else? (quote: "is
not HTML anymore")
> It is DOM Tree, and no one ever
> suggested (as far as I know) that DOM Tree should be clean and
> meaningful.
Clean and meaningful,
those are qualities that should applie to thoughts
and usenet-posts.
--
Rob
Rob Waaijenberg
I can't see any tables, because there are no tables.
In the post that is quoted above, you made several statements that
implied there were tables but that they couldn't be seen.
("..noone ever sees this tables...")
("What does it matter if browser internally renders tables...")
In your exemple-page you don't generate tables, you generate DIV's.
I'm starting to believe that for you 'tables' are the same as 'divs'.
--
Rob
Bergamot
>
> I think I see your point: nice uncluttered HTML is not just for
> authors, but also better for users.
I bet it's not so uncluttered by the time he's done with all the script-foo.
--
Berg
Bergamot
> On Dec 31, 2:58 pm, Bergamot <berga...@visi.com> wrote:
>>
>> The document tree is what the browser/user sees. Why do you think
>> generating it via script instead of coding it in the HTML makes a
>> difference?
> User does not see DOM tree, he sees rendered page.
The browser sees the document tree. The user sees the browser's
rendering of that tree. It's illogical to keep separating the 2.
> What actually is in
> DOM tree usually does not interest him. But he may be interested in
> html source file, and this is kept clean and readable in my method.
User's could care less about your HTML source code. They *do* care about
what the browser does with the code.
--
Berg
Bergamot
>
> I don't know about strict mode (it varies greatly across browsers in
> areas where the specs are lacking)
Cite an example, please.
--
Berg
Harlan Messinger
All right, you're technically correct. So he's creating an HTML DOM
*tree* that is still a semantically incorrect representation of the
logical structure of the document.
Harlan Messinger
> On Dec 31, 2:16 pm, Harlan Messinger
> <hmessinger.removet...@comcast.net> wrote:
>> brave1979 wrote:
>>>>> I thought tables were avoided for some real benefits like semantic
>>>>> content, clean html, separating defining visual aspects from defining
>>>>> content.
>>>> They're semantically just as incorrect if you have Javascript generating
>>>> them in the browser as they would be if the author had coded them
>>>> directly.
>>> Sorry. Maybe I am misunderstanding word "semantic". I thought its
>>> something like "meaningful".
>> Yes.
>>
>>> And writing semantic html is writing html
>>> that has meaning and structure associated with this meaning not just
>>> html that is the tag soup to force browser to render properly (as with
>>> table layout).
>> Exactly. And tag soup is tag soup no matter how you generate it, whether
>> by hand or with Javascript. The contents of your page that aren't
>> logically a table, don't *become* logically a table just because you let
>> Javascript generate the table-related tags.
>
> But noone ever sees this tables.
Since the objections to using tables for layouts have nothing to do with
what anyone *sees*, this is irrelevant.
Bergamot
>
> Is a fact that I disabled CSS in my browser a valid argument against
> tableless layouts?
Absolutely not. It is an argument *for* tableless layouts.
> Should you use tables and 1px gifs because of that fact?
You are ignoring the fact that CSS is intended to be optional. The days
of "must look the same in all browsers" are over.
> Person who knows photoshop and person who knows html are not always
> the same person.
Yes, and... ?
> You can remove from your design things that you don't
> know how to do in html.
If the designer and coder are 2 different people, there should be no
reason to do this. If they are the same person, then it sounds like a
case of The Peter Principle.
> But when coders get prepared, discussed and
> accepted layout in psd they can only do their best.
If the coder is competent, what's the problem? If they aren't, you hired
the wrong person. Or are you allowing the designer put something
together inappropriate for the web, like rigid pixel-perfect layouts?
--
Berg
Ben C
But what's wrong with that? If someone wants to do something else with
the HTML other than display it in a browser (read it, process it with
some other tool, etc.) then they use the source which is the definitive
representation. The DOM tree created by the JS program only exists
temporarily in the browser instance in which it's being displayed. I
don't see how it's hurting anyone.
Harlan Messinger
> On 2007-12-31, Harlan Messinger <hmessinger...@comcast.net> wrote:
>> Ben C wrote:
>>> On 2007-12-31, Harlan Messinger <hmessinger...@comcast.net> wrote:
>>>> Ben C wrote:
>>> [...]
>>>>> Isn't the idea of his system that the HTML stays as nice clean HTML,
>>>>> and is only munged into a sea of tables by the JS?
>>>> Yes. But HTML generated by code is HTML.
>>> His code doesn't generate HTML.
>>>
>>> He has annoyingly removed whitespace from the source. I wish people
>>> wouldn't do that. But all the same you can see that he's creating the
>>> DOM tree with createElement and appendChild, not innerHTML.
>>>
>>> (See
>>> http://www.bravelayout.scarabeo.biz/examples/BraveLayout-standalone-min.js
>>> and http://www.bravelayout.scarabeo.biz/examples/example0.html)
>>>
>>> At no point does nasty HTML exist, unless you count things like the
>>> Firebug turning the DOM tree back into sort of HTML for the purpose of
>>> displaying it.
>> All right, you're technically correct. So he's creating an HTML DOM
>> *tree* that is still a semantically incorrect representation of the
>> logical structure of the document.
>
> But what's wrong with that?
The whole point of a Document Object Model is to represent a document as
a hierarchical collection of its components labeled according to what
each of them IS. Therefore, if something that isn't a table is added to
the document as a table, it's technically incorrect. Period. The
guidelines against doing this in the markup exist for the same reason.
If you want you *can* use Javascript to wrap blocks of non-heading text
into H1 elements just because you want them to be larger and browsers
will usually display them larger, and you *can* use Javascript to wrap
blocks of non-quoted material into blockquote elements just because you
want them to be indented and you know that browsers will indent them,
but within the context of the Document Object Model, it is *incorrect*.
> If someone wants to do something else with
> the HTML other than display it in a browser (read it, process it with
> some other tool, etc.) then they use the source which is the definitive
> representation. The DOM tree created by the JS program only exists
> temporarily in the browser instance in which it's being displayed. I
> don't see how it's hurting anyone.
It also doesn't hurt anyone if you write HTML in this day and age that
only displays properly in Netscape 4.5. Whether something hurts anyone
isn't the issue. (At least no one has expounded, in any of the messages
that I've read [because I haven't read all of them], on their *right* to
code this way, but I won't be surprised if someone pulls that one out
next. My answer will be the same: *rights* are not the point.)
Ben C
>>> All right, you're technically correct. So he's creating an HTML DOM
>>> *tree* that is still a semantically incorrect representation of the
>>> logical structure of the document.
>>
>> But what's wrong with that?
>
> The whole point of a Document Object Model is to represent a document as
> a hierarchical collection of its components labeled according to what
> each of them IS.
I don't understand that at all. I thought the whole point of the DOM was
so that you could write scripts to create elements, change their
attributes, etc.
Note also that the DOM interfaces allow you to create a tree that can't
be represented by valid HTML at all-- you can make a <span> a child of a
<tr> if you want to.
> The guidelines against doing this in the markup exist for the same
> reason. If you want you *can* use Javascript to wrap blocks of
> non-heading text into H1 elements just because you want them to be
> larger and browsers will usually display them larger, and you *can*
> use Javascript to wrap blocks of non-quoted material into blockquote
> elements just because you want them to be indented and you know that
> browsers will indent them, but within the context of the Document
> Object Model, it is *incorrect*.
Can you tell me where I can find a standard or specification saying
anything like this about the DOM? If it is a matter of technical
correctness then there ought to be one.
>> If someone wants to do something else with
>> the HTML other than display it in a browser (read it, process it with
>> some other tool, etc.) then they use the source which is the definitive
>> representation. The DOM tree created by the JS program only exists
>> temporarily in the browser instance in which it's being displayed. I
>> don't see how it's hurting anyone.
>
> It also doesn't hurt anyone if you write HTML in this day and age that
> only displays properly in Netscape 4.5. Whether something hurts anyone
> isn't the issue.
[...]
OK I didn't mean literally hurt anyone.
There are technical reasons why HTML has to be valid, and there are
pragmatic reasons why it is good style to make appropriate use of the
HTML elements to represent the structure and content.
But I don't see that any of reasons apply to a DOM tree you create only
with scripting.
Harlan Messinger
> On 2007-12-31, Harlan Messinger <hmessinger...@comcast.net> wrote:
> [...]
>>>> All right, you're technically correct. So he's creating an HTML DOM
>>>> *tree* that is still a semantically incorrect representation of the
>>>> logical structure of the document.
>>> But what's wrong with that?
>> The whole point of a Document Object Model is to represent a document as
>> a hierarchical collection of its components labeled according to what
>> each of them IS.
>
> I don't understand that at all. I thought the whole point of the DOM was
> so that you could write scripts to create elements, change their
> attributes, etc.
Yes, but not *invalid* ones. The DOM is a hierarchical object *model* of
the document. If you use it to build a representation of an *invalid*
document, then the representation is invalid. If you use it to build a
representation of a semantically flawed document, then you have a
semantically flawed representation. A paragraph is still supposed to be
a paragraph, a title a title, a table a table, a list a list, a
quotation a quotation, and so forth. A misrepresentation of any of these
is a misrepresentation. If the DOM tree has something labeled as a
"table" that isn't a table, it's a misrepresentation.
If you find it useful to introduce misrepresentations, to overcome
shortcomings in either the HTML model or commonly used browsers, or to
inject special functionality (as when people nest elements in
superfluous divs for the sake of permitting extra-fancy CSS tricks),
justify it however you may, but don't imagine that that makes it
anything other than an incorrect representation.
brave1979
to 100%
brave1979
> brave1979 wrote:
> > On Dec 31, 2:58 pm, Bergamot <berga...@visi.com> wrote:
>
> >> The document tree is what the browser/user sees. Why do you think
> >> generating it via script instead of coding it in the HTML makes a
> >> difference?
> > User does not see DOM tree, he sees rendered page.
>
> The browser sees the document tree. The user sees the browser's
> rendering of that tree. It's illogical to keep separating the 2.
are already separate. I'm not separating anything artificially.
> > What actually is in
> > DOM tree usually does not interest him. But he may be interested in
> > html source file, and this is kept clean and readable in my method.
>
> User's could care less about your HTML source code. They *do* care about
> what the browser does with the code.
They do care about what they see, and some of them do care what is
read from server (since it's not always rendered, sometimes it's just
analyzed and used to update index of some search engine).
They certainly do not care about what browser does between the thing
they see when they "View Source" and what they see when they look at
page.
brave1979
need to be put in layout, BraveLayout.end() after them and
Bravelayout.fill() at the end of the file or in onload event.
That is all the clutter you have to introduce to your html file no
matter how complex your layout is. Apart from that you can organize
html file as meaningful and semantic as you can.
brave1979
explain it step by step since you are interested.
1. You place you content in html file organizing it according to
contents structure so it is semantic, meaningful, etc.(It's the divs
you see while viewing source of my example)
2. Before your meaningful html tags you put BraveLayout.start(layout)
where "layout" is description of desired layout as javascript object.
3. After the content you place BraveLayout.end(), and at the end of
your file you place BraveLayoyut.fill()
When page is loaded and browser reaches BraveLayout.start(layout) it
generates dom tree necessary to achieve desired layout. It does this
by generating table, tr, td nodes in DOM Tree of currently loading
page.
When all of the page is loaded and BraveLayout.fill() is run browser
rips meaningful content tags (in my example divs) and places them in
proper spots of generated layout (table cells generated by my library)
indicated in layout definition.
So it ends up looking nice, being defined easily and keeping html
source file clean.
brave1979
wrote:
same thing. "Genreated HTML" is just a shorthand for "generated parts
of dom tree" since you cannot actually generate HTML (as seen in "View
Source") using javascript. You can only modify DOM tree built from
HTML file read from the webserver.
brave1979
<hmessinger.removet...@comcast.net> wrote:
> All right, you're technically correct. So he's creating an HTML DOM
> *tree* that is still a semantically incorrect representation of the
> logical structure of the document.
I think that's a new sermon. I never heard anyone preaching that. ;-)
brave1979
<hmessinger.removet...@comcast.net> wrote:
Some objections to table layouts are especially targeted at things
seen by people who "View Source" and by search engine robots who try
to index your page so it's not completely irrelevant.
brave1979
> brave1979 wrote:
>
> > Is a fact that I disabled CSS in my browser a valid argument against
> > tableless layouts?
>
> Absolutely not. It is an argument *for* tableless layouts.
properly than it's an argument against my layout.
And If I cripple my browser in a way that I can't view your layout
properly it's argument *for* your layout?
Isn't it a little bit unfair?
> > Should you use tables and 1px gifs because of that fact?
>
> You are ignoring the fact that CSS is intended to be optional. The days
> of "must look the same in all browsers" are over.
Tell this to you client or employer.
> > Person who knows photoshop and person who knows html are not always
> > the same person.
>
> Yes, and... ?
And the person sitting behind photoshop can invent something you won't
be able to do in few hours because he does not know the pitfalls of
pure css layouts.
And even If you can get it at some point as intended you will spend to
much of your time on this so you are wasting valuable resource.
And at some point layout can be slightly redesigned to fit clients
changing needs, and changing pure css layout is rarely easy.
> > You can remove from your design things that you don't
> > know how to do in html.
>
> If the designer and coder are 2 different people, there should be no
> reason to do this. If they are the same person, then it sounds like a
> case of The Peter Principle.
Sorry. I fail to see the connection with The Peter Principle.
> > But when coders get prepared, discussed and
> > accepted layout in psd they can only do their best.
>
> If the coder is competent, what's the problem? If they aren't, you hired
> the wrong person. Or are you allowing the designer put something
> together inappropriate for the web, like rigid pixel-perfect layouts?
World is not perfect. Often you need things that may be considered
inappropriate at some time or another.
Competent coder is a valuable resource and letting him waste many
hours of his time on converting psd to html is not very rational use
of this resource.
Ben C
The rules in strict mode are very simple. "Circular percentages", i.e.
percentage heights of auto-height containers are treated as auto.
You may get differences in browsers resulting from slightly different
interpretations of the "initial containing block". Setting html, body {
height: 100% } should remove those inconsistencies.
In quirks mode however browsers often try to make circular percentages
"work"-- sometimes by making them percentages of the viewport height or
in the case of table cells first computing the auto height of the cell
and then taking a percentage of that. This is where the specs are
lacking.
Better to find a way not to rely on circular percentages and use strict
mode.
If you're finding that some browsers do allow circular percentages of
table cells even in strict mode, then that's not an inconsistency where
the spec is lacking, it's just a violation of the spec, so don't use
it-- it's a bug and might actually get fixed.
Rob Waaijenberg
> ... converting psd to html is not very rational use
> of this resource.
IMHO it is not rational *anytime*
--
Rob
Rob Waaijenberg
> You completely misunderstood me and the whole concept. So I'll try to
> explain it step by step since you are interested.
>
Allright, I'll follow in your footsteps...
> 1. You place you content in html file organizing it according to
> contents structure so it is semantic, meaningful, etc.(It's the divs
> you see while viewing source of my example)
OK, I understand this
(my only problem is that divs are not meaningful, but we'll let that rest)
> 2. Before your meaningful html tags you put BraveLayout.start(layout)
> where "layout" is description of desired layout as javascript object.
Do I understand correctly that you have different lay-outs ready,
and here you chose one of them in "BraveLayout.start(layout)"???
> 3. After the content you place BraveLayout.end(), and at the end of
> your file you place BraveLayoyut.fill()
>
> When page is loaded and browser reaches BraveLayout.start(layout) it
> generates dom tree necessary to achieve desired layout. It does this
> by generating table, tr, td nodes in DOM Tree of currently loading
> page.
This is what you meant by "internally rendered tables"?
> When all of the page is loaded and BraveLayout.fill() is run browser
> rips meaningful content tags (in my example divs) and places them in
> proper spots of generated layout (table cells generated by my library)
> indicated in layout definition.
>
Here I'm definitely lost.
I will blame this on my ignorance of javascript. I just don't know
enough about it.
But what I read here is:
- there are meaningful tags
- there is a lay-out made by table cells
- tags are put inside the table cells.
This brings to mind two questions:
1. Why not use a ready-made table layout and fill it up with content.
2. In case I misunderstood the last steps: if table-cells can't be seen
(or in fact do not exist), what then is the difference with a css-based
lay-out.
--
Rob
Ben C
> Ben C wrote:
>> On 2007-12-31, Harlan Messinger <hmessinger...@comcast.net> wrote:
>> [...]
>>>>> All right, you're technically correct. So he's creating an HTML DOM
>>>>> *tree* that is still a semantically incorrect representation of the
>>>>> logical structure of the document.
>>>> But what's wrong with that?
>>> The whole point of a Document Object Model is to represent a document as
>>> a hierarchical collection of its components labeled according to what
>>> each of them IS.
>>
>> I don't understand that at all. I thought the whole point of the DOM was
>> so that you could write scripts to create elements, change their
>> attributes, etc.
>
> Yes, but not *invalid* ones.
Well, we were originally talking about "semantically correct
representations of logical structure", which HTML validity is related
to, but no guarantee of.
The DOM tree isn't subject to the requirements of the HTML DTD. Try this
script, for example:
function main()
{
var body = document.getElementsByTagName("body")[0];
var tr = document.createElement("tr");
var span = document.createElement("span");
var text = document.createTextNode("Look at me, I'm not valid HTML");
body.appendChild(tr);
tr.appendChild(span);
span.appendChild(text);
}
window.onload = main;
As far as I know there's nothing technically wrong with doing that. Not
that BraveLayout actually is creating DOM trees that would have been
invalid HTML as far as I know.
> The DOM is a hierarchical object *model* of the document. If you use
> it to build a representation of an *invalid* document, then the
> representation is invalid.
I don't see it that way. HTML should be valid because it's usually being
parsed by a (slightly laissez-faire) HTML parser in a browser that will
patch it up to some extent if it's not. You also might want to use it
with other programs besides browsers.
The DOM tree is the result of parsing the HTML. If you create the DOM
tree directly with JS there's no requirement for it to correspond to
valid HTML.
There are some less restrictive requirements-- #text nodes have to be
leaves, that kind of thing, and you get DOM exceptions if you transgress
those. But nothing in the DOM specification that I know of says a span
can't be a child of a tr.
> If you use it to build a representation of a semantically flawed
> document, then you have a semantically flawed representation.
It's not flawed at the level at which it exists.
In programming people sometimes talk about a "semantic gap"-- programmer
writes in a high-level language expressing her intentions, and good
style is to use the programming constructs that best express those
intentions even though she could pervert different ones instead and it
would still work.
For example in C programming you write a for loop to iterate over the
elements of an array, not a couple of if statements and a goto, although
those would work just as well.
The compiler turns all this into something the programmer would rather
not have had to write in the first place: machine code that's a great
"semantic representation" from the point of view of the machine
executing it, but no longer of the programmer's intentions, apart from
the fact that it's still supposed to work. The compiler has crossed the
semantic gap.
BraveLayout is a sort of compiler, that turns the author's semantically
pukka HTML and styling instructions (written in BraveLayout's own
language rather than in CSS) into what is effectively a machine-readable
intermediate representation-- a DOM tree consisting of lots of tables.
That doesn't violate any technical specifications and isn't bad style.
There's no reason per se why valid HTML couldn't be used as an
intermediate representation in some system either, although BL doesn't,
and brave1979 makes the point that the server should deliver the
original document in case the user wants to do something else with it.
Whether there's any point in anyone using BraveLayout is another
question. Most of the situations I've seen where people have said "I
have to use tables for this because CSS sucks" are not due to any poor
design of CSS itself but because of the restriction that parts of it, in
particular display: inline-block, aren't widely-enough implemented yet.
Designing an alternative way to produce table-based layouts is a step
backwards, but in this case at least an innovative step backwards.
Ben C
> Sorry. "Genrated HTML" and "is not HTML anymore" actually mean the
> same thing. "Genreated HTML" is just a shorthand for "generated parts
> of dom tree" since you cannot actually generate HTML (as seen in "View
> Source") using javascript. You can only modify DOM tree built from
> HTML file read from the webserver.
JS (running in a browser) can generate HTML using innerHTML. Although
you still won't see the generated stuff with View Source.
brave1979
wrote:
> > 1. You place you content in html file organizing it according to
> > contents structure so it is semantic, meaningful, etc.(It's the divs
> > you see while viewing source of my example)
>
> OK, I understand this
> (my only problem is that divs are not meaningful, but we'll let that rest)
#menu ... this could be clearer.
> > 2. Before your meaningful html tags you put BraveLayout.start(layout)
> > where "layout" is description of desired layout as javascript object.
>
> Do I understand correctly that you have different lay-outs ready,
> and here you chose one of them in "BraveLayout.start(layout)"???
Usually I have only one layout described in javscript variable named
layout. And "BraveLayout.start(layout)" builds it according to the
description. But I may have more than one layout each described in
different js variable and with
BraveLayout.start(layoutOfRegistrationPage) I may indicate which
layout I need to be created for me.
> > 3. After the content you place BraveLayout.end(), and at the end of
> > your file you place BraveLayoyut.fill()
>
> > When page is loaded and browser reaches BraveLayout.start(layout) it
> > generates dom tree necessary to achieve desired layout. It does this
> > by generating table, tr, td nodes in DOM Tree of currently loading
> > page.
>
> This is what you meant by "internally rendered tables"?
Yes.
> > When all of the page is loaded and BraveLayout.fill() is run browser
> > rips meaningful content tags (in my example divs) and places them in
> > proper spots of generated layout (table cells generated by my library)
> > indicated in layout definition.
>
> Here I'm definitely lost.
> I will blame this on my ignorance of javascript. I just don't know
> enough about it.
> But what I read here is:
> - there are meaningful tags
> - there is a lay-out made by table cells
> - tags are put inside the table cells.
Yes, you got it right.
> This brings to mind two questions:
>
> 1. Why not use a ready-made table layout and fill it up with content.
It's easier to describe layout in js object then write all the table
tr td tags by hand. And I still would need javascript to place tags
inside proper table cells.
And if "pure css" people seen any tables in my source files they would
burn me alive. :-)
And by abstracting layout definition from it's implementation
(currently tables) I may some day change implementation to something
else than tables (some new features of html5 or css3) and keep
previously defined layouts working.
> 2. In case I misunderstood the last steps: if table-cells can't be seen
> (or in fact do not exist), what then is the difference with a css-based
> lay-out.
Table cells exist only in DOM Tree so table, tr, td tags can't be seen
when viewing source files.
CSS layouts uses only CSS styles for positioning meaningful tags on
page. BraveLayout uses additional generated elements (tables and table
cells) in DOM Tree to do the positioning.
Advantages of BraveLayout is that you can achieve more complex
crossbrowser layouts easier.
Bergamot
> On Dec 31 2007, 7:56 pm, Bergamot <berga...@visi.com> wrote:
>> brave1979 wrote:
>>
>> > Is a fact that I disabled CSS in my browser a valid argument against
>> > tableless layouts?
>>
>> Absolutely not. It is an argument *for* tableless layouts.
> So if you cripple your browser in a way that you can't view my layout
> properly than it's an argument against my layout.
No, it means I don't need (or want) your layout to use the page. I
disable CSS surprisingly often, usually because poorly thought out
designs don't adapt to my browser set up.
> And If I cripple my browser in a way that I can't view your layout
> properly it's argument *for* your layout?
You don't seem to get that it's not for *any* layout.
>> You are ignoring the fact that CSS is intended to be optional. The days
>> of "must look the same in all browsers" are over.
> Tell this to you client or employer.
Are they experts in web stuff? It is your responsibility as a subject
matter expert to teach them the error of their ways. Unless the
employer/client is a real jerk, they usually listen if you do it in a
respectful manner.
>> > Person who knows photoshop and person who knows html are not always
>> > the same person.
>>
>> Yes, and... ?
> And the person sitting behind photoshop can invent something you won't
> be able to do in few hours because he does not know the pitfalls of
> pure css layouts.
It's not really a matter of CSS layouts vs table layouts here. It's a
matter of designing something suitable for the web in general. Teach
them that the web is not paper. If you aren't willing to do that, then
you'll forever be in a no-win position.
--
Berg
Bergamot
> On 2007-12-31, Harlan Messinger <hmessinger...@comcast.net> wrote:
>>
>> So he's creating an HTML DOM
>> *tree* that is still a semantically incorrect representation of the
>> logical structure of the document.
>
> But what's wrong with that?
Anybody tried this thing with JAWS or some other screen reader?
--
Berg
Ben C
The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup. I don't know if that actually works.
brave1979
> brave1979 wrote:
> > On Dec 31 2007, 7:56 pm, Bergamot <berga...@visi.com> wrote:
> >> brave1979 wrote:
>
> >> > Is a fact that I disabled CSS in my browser a valid argument against
> >> > tableless layouts?
>
> >> Absolutely not. It is an argument *for* tableless layouts.
> > So if you cripple your browser in a way that you can't view my layout
> > properly than it's an argument against my layout.
>
> No, it means I don't need (or want) your layout to use the page. I
> disable CSS surprisingly often, usually because poorly thought out
> designs don't adapt to my browser set up.
>
> > And If I cripple my browser in a way that I can't view your layout
> > properly it's argument *for* your layout?
>
> You don't seem to get that it's not for *any* layout.
> >> You are ignoring the fact that CSS is intended to be optional. The days
> >> of "must look the same in all browsers" are over.
> > Tell this to you client or employer.
>
> Are they experts in web stuff? It is your responsibility as a subject
> matter expert to teach them the error of their ways. Unless the
> employer/client is a real jerk, they usually listen if you do it in a
> respectful manner.
Experts are not to teach anybody anything, that's what teachers are
for. Experts are to use their experise to help people do things they
want to do but don't know how to do themselves.
If you can tell your client what he wants/needs (and that is by
accident one of the things you can do and like to do) then you are
really lucky guy. :-)
In my life It's more like Golden Rule: "He Who Has The Gold Makes The
Rules"
> >> > Person who knows photoshop and person who knows html are not always
> >> > the same person.
>
> >> Yes, and... ?
> > And the person sitting behind photoshop can invent something you won't
> > be able to do in few hours because he does not know the pitfalls of
> > pure css layouts.
>
> It's not really a matter of CSS layouts vs table layouts here. It's a
> matter of designing something suitable for the web in general. Teach
> them that the web is not paper. If you aren't willing to do that, then
> you'll forever be in a no-win position.
Once you have technology to achieve what they want everybody wins.
They have what they want. And you can deliver it to them easily.
Bergamot
I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.
> I don't know if that actually works.
It seems unlikely, to me anyway.
--
Berg
brave1979
>
> >> Anybody tried this thing with JAWS or some other screen reader?
>
> > The idea is that the screen reader would read out the uncluttered HTML,
> > not the generated table soup.
>
> I don't think it's that simple. All the major Windows screen readers use
> IE's rendering engine for web browsing. I presume they'll only "look" at
> the HTML if JavaScript is disabled.
>
> > I don't know if that actually works.
>
> It seems unlikely, to me anyway.
Could somebody test this please?
brave1979
> > On 2008-01-03, Bergamot <berga...@visi.com> wrote:
>
> >> Anybody tried this thing with JAWS or some other screen reader?
>
> > The idea is that the screen reader would read out the uncluttered HTML,
> > not the generated table soup.
>
> I don't think it's that simple. All the major Windows screen readers use
> IE's rendering engine for web browsing. I presume they'll only "look" at
> the HTML if JavaScript is disabled.
I've checked how jaws actually behaves.
It reads whatever is seen on the screen line by line. It does not read
HTML source. It does not read DOM tree. It seems like it reads actual
pixels visible on the screen.
So as far as I can figure out any layout that has more than one column
is not JAWS friendly because it reads one line from left column and
immediately, without stopping reads line from center column. And then
it reads second line from left column and immediately second line from
center column. I tested it with pages using my lib and pages from
zengarden. They behave exactly the same. I guess any person who uses
JAWS must probably disable javascript and css on all pages to avoid
multiple columns. In such case my layout and pure css layouts behave
exactly the same.
Bergamot
>
> I've checked how jaws actually behaves.
>
> It reads whatever is seen on the screen line by line. It does not read
> HTML source. It does not read DOM tree.
Have you verified that there aren't configuration options that do it
differently?
BTW, you do know that JAWS isn't the only reader, eh? It is probably the
most used one, though.
--
Berg
brave1979
> brave1979 wrote:
>
> > I've checked how jaws actually behaves.
>
> > It reads whatever is seen on the screen line by line. It does not read
> > HTML source. It does not read DOM tree.
>
> Have you verified that there aren't configuration options that do it
> differently?
that I exhausted all option available.
> BTW, you do know that JAWS isn't the only reader, eh? It is probably the
> most used one, though.
It makes sense that it tries to read actual pixels on the screen.
Hence the name "screen reader". Probably other screen readers do
something similar.
I think BraveLayout is quite safe to use, regarding people with
disabilities.
Chemixst
are complaining against tables even when there are none in the html!
One of the main reasons to not have tables is because it clutters up
the code, it does not matter if your output has tables that no one
sees, that is ridiculous for people to complain about... seems like
they are just trying to be rude.
You put hard work into a different layout solution which I think is
wonderful.
Of course there are a few concerns people have addressed but currently
I think it's pretty solid. I want to thank you, your bravelayout is
definately a step in the right direction.
Andy Dingley
> Sorry to see so many posts being overly critical, it seems like people
> are complaining against tables even when there are none in the html!
> One of the main reasons to not have tables is because it clutters up
> the code, it does not matter if your output has tables that no one
> sees, that is ridiculous for people to complain about... seems like
> they are just trying to be rude.
Oh, don't talk shite.
Jonathan N. Little
No the problem as I recall was that the "method" relied on client side
JavaScript to produce the page. In the 90's when DHTML was the buzz word
and security wasn't considered this "bird" may have flown. Requiring
JavaScript for your site to function is a bad idea today on too many
ways to list. Google if you want more info...
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com